News for hackers. Stuff that matters.
Re:The Zimbu programming language, by vim author Bram Moolenaar by Janzert on Wednesday October 21, 2009 @12:03PM (#894902)
Ouch, unbalanced curly brackets to end blocks? Maybe it's something like significant indentation (python) that will become natural once used. On first presentation though it sure seems scary.
Re:The Zimbu programming language, by vim author Bram Moolenaar by mnemonik on Wednesday October 21, 2009 @12:39PM (#895006)
I actually thought that was the neatest thing about this proposed language. I didn't get too excited about any of the design goals, but regarding syntax, this seems pretty original.

It allows for less syntax, which is a win for readability and also less boilerplate tokens, but still gives you a little freedom to mess with your indentation, unlike python. It means that (true) lambdas wouldn't be a syntactical enigma like they would be in python.

I don't think that you would need to use "}" to end a block though, since it looks like its missing the opening bracket, but maybe double semicolons would work, since they apparently aren't used elsewhere:

    MAIN()
      IO.write("Hello, World!\n")
    ;;
To be honest, the syntax that I have found to be nicest on the eyes so far has been Io:

    whois := method(host,
        socket := Socket clone setHostName("rs.internic.net") setPort(43) 
        socket connect streamWrite(host, "\n")
        while(socket streamReadNextChunk, nil)
        return socket readBuffer
    )
taken from http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.h...
Re:The Zimbu programming language, by vim author Bram Moolenaar by bham on Wednesday October 21, 2009 @01:34PM (#895158)
Io is an absolute joy. It's too slow to be practical but that's my personal bent. Not everything has to be practical of course.
Re:The Zimbu programming language, by vim author Bram Moolenaar by eru on Wednesday October 21, 2009 @06:45PM (#895812)
`True lambdas' are overrated. The Python way is just fine. If you want to do anything that needs two lines, you are probably doing something complicated enough that this function deserves its own name.
Re:The Zimbu programming language, by vim author Bram Moolenaar by silentbicycle on Wednesday October 21, 2009 @08:08PM (#895934)
...it wouldn't be as big an issue if Python's closures and scoping weren't problematic as well.
Re:The Zimbu programming language, by vim author Bram Moolenaar by eru on Thursday October 22, 2009 @04:47AM (#896402)
As far as I know Python has true lexical scoping for functions, if not for blocks. (They used to have very limited scoping ages ago.)

What do you mean?

Re:The Zimbu programming language, by vim author Bram Moolenaar by silentbicycle on Thursday October 22, 2009 @06:51PM (#897881)
In Python 2.6:

    def acc(x):
        foo = x
        def closures_are_broken():
            foo += 1
            return foo
        return closures_are_broken
    
    
    def acc2(x):
        foo = [x]
        def closure_with_workaround():
            foo[0] += 1
            return foo[0]
        return closure_with_workaround
The former is an error ("UnboundLocalError: local variable 'foo' referenced before assignment"), the latter is a workaround by manually boxing the variable in a list. I'm not sure why that works, but it's rather ugly.

The same, in Lua:

    function acc(x)
       local foo = x
       return function()
                 foo = foo + 1
                 return foo
              end
    end
Re:The Zimbu programming language, by vim author Bram Moolenaar by eru on Friday October 23, 2009 @09:15AM (#898672)
Oh, yes. You are mutating variables. You shouldn't do that anyway in a functional setting.

Python's syntax forces the language to guess whether you want to make a new variable or use the variable of the same name from the outer scope. The heuristic they have, says that if you assign something to the variable, you get a new one by default. You can declare

  global x
before to assign to the variable in the outerscope.
Re:The Zimbu programming language, by vim author Bram Moolenaar by mbrubeck on Wednesday October 21, 2009 @12:53PM (#895033)
I agree that the choice of "}" makes this seem weirder than it needs to. Something that doesn't "look" unbalanced would be better. What about "end" (like in Ruby but with no "begin")? It may be longer, but I actually find it easier/faster to type than a curly brace...
Re:The Zimbu programming language, by vim author Bram Moolenaar by ajb on Wednesday October 21, 2009 @01:59PM (#895221)
That reminds me of CPL, which used the section symbol (http://en.wikipedia.org/wiki/Section_sign).
Re:The Zimbu programming language, by vim author Bram Moolenaar by gcb on Wednesday October 21, 2009 @12:41PM (#895011)
Probably what everyone said about python's indentation syntax.

I like both approaches. it's better then having useless {. In some cases improve readability over python lack of marks. and risking mod down by the audience we have here, it's (much (better then (the gratuitous use of (parenthesis in lisp)))))

Re:The Zimbu programming language, by vim author Bram Moolenaar by icey on Wednesday October 21, 2009 @01:18PM (#895111)

  how (
      is {
           this();
          }
      any();
      better(
               than[$parenthesis]
             );
      );

?
Re:The Zimbu programming language, by vim author Bram Moolenaar by DannoHung on Wednesday October 21, 2009 @01:30PM (#895150)
Why do people use full tabs and put the braces at the indentation level of the opening statement? I have discovered the one true coding style: 2 spaces indent, opening character immediately after opening statement, closing character on new line indented with preceding code block

    how (
      is {
        this();
        }
      any();
      better(
        than[$parenthesis]
        );
      );
Re:The Zimbu programming language, by vim author Bram Moolenaar by req2 on Wednesday October 21, 2009 @06:43PM (#895807)
A 2 space indent loses at 'visual overview' of larger (and more representative) expanses of code. A 4 space indent maintains clarity at the level of a skim or casual glance, even if it "fails" at the contrived (but simple) example shown here.
Re:The Zimbu programming language, by vim author Bram Moolenaar by DannoHung on Thursday October 22, 2009 @09:53AM (#896710)
Supporting "larger" expanses of code is a pathological feature, not a benefit. If the code doesn't break back to the baseline after more than half a page, there's something wrong with that code in 99.9% of the cases.
Re:The Zimbu programming language, by vim author Bram Moolenaar by req2 on Thursday October 22, 2009 @10:22AM (#896776)
Though true, a 2 space indent visually 'breaks' whenever there's (conservatively speaking) more than 8 lines of code on a single level followed by several further indented lines. After that, the indentation level of the immediately following less indented lines is not available to the average skimmer.