Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
The Zimbu programming language (zimbu.org)
47 points by mbrubeck on Oct 21, 2009 | hide | past | favorite | 51 comments


    * It has to be as fast as possible, so interpreted languages are out.
    * You don't want to micro manage memory, so C is out.
    * You don't want to require programmers to have a degree, so C++ is out.
    * You want fast startup and not depend on a big runtime, so Java is out.
    * It has to run on most systems, anything with a C compiler, so D is out.
    * You want to have fun making something new.
    No existing language really meets these demands, so let's create a new one that does.
Actually, Lua meets every point except the last one...it's byte-compiled, garbage collected, refreshingly free of exceptions-to-exceptions-to-rules you have to memorize, it starts and compiles faster than many other major contenders start, it runs on literally anything with an ANSI C compiler, and it's been in production use for over 15 years.

I use Emacs, but a Lua-extended vi could be very nice.


Several Scheme implementations as well as some lesser-known small Lisps qualify.

I think writing a new general-purpose language is something every programmer should try at least once, but don't fool yourself; there's probably an existing language that does what you want.

Now, back to work on that language idea I can't get out of my head involving pervasive generic functions....


I would like that language.

(I say, as I work on getting compute-effective-method working in Guile...)


I'm half-seriously considering implementing it. The basic form I have in mind is something that looks a bit like Clojure and runs on Parrot. I'm not attached to either of those ideas, but this being 2009, I think it should have some support for parallelism and access to libraries out of the gate.


chicken scheme is the only other language I can think of that compiles to C code.

He is not making an interpreted language. It compiles down to machine code that runs directly; not vm bytecode.


Ikarus Scheme compiles r6rs to native code. http://ikarus-scheme.org/index.html


Gambit Scheme does it better I think.



Well, if I ran the zoo, it would be retargetable to multiple graphic modes (I'm going to be running it in ssh+tmux half the time, so I'd prefer curses) and have a mix of vi's modal keybinding style and Emacs's buffer/mark ring/etc. model and extensibility.

Then again, with 2k loc, it shouldn't be that hard to break out the GTK...

UI model nonwithstanding, that's exactly the sort of project that Lua is designed for.


Neat. Let me know if you get there :-)

http://www.vim.org/scripts/script.php?script_id=1234 is handy.. You can also script vim with ruby and more..

http://www.vim.org/htmldoc/if_ruby.html


I think making the keywords all-caps is a mistake. Capital letters draw the eye -- all-caps doubly so, and at the expense of readability.

Anything in all-caps had better be pretty damn important for the programmer to read. And while keywords are vital to the compiler's understanding of the program, they are arguably among the least important text for the programmer to read, as they can generally be inferred from visual length, placement, and formatting.


Keywords are punctuation for programs. Keywords in capitals are shouting the punctuation out instead of the words. So just as you say, keywords in capitals are the equivalent of you writing:

I think making the keywords all DASH caps is a mistake PERIOD Capital letters draw the eye EMDASH all DASH caps doubly so COMMA and at the expense of readability PERIOD


don't forget syntax highlighting


also small caps are harder to type its just tedious to change the case so often


From the description, it seems like this project has the same goals as Gnome's new language, Vala:

http://live.gnome.org/Vala

Given the syntax choices, the main advantage I see in Zimbu is that creating a new language is more fun than porting an existing one.


For me the goals of zimbu look very much like the ones of ooc (it was mentioned a few days ago http://news.ycombinator.com/item?id=882864) and ooc looks much nicer than zimbu.


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.


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...


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.


`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.


...it wouldn't be as big an issue if Python's closures and scoping weren't problematic as well.


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?


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


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.


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...


That reminds me of CPL, which used the section symbol (http://en.wikipedia.org/wiki/Section_sign).


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)))))


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

?


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]
        );
      );


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.


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.


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.


It has to be as fast as possible, so interpreted languages are out. You don't want to micro manage memory, so C is out. You don't want to require programmers to have a degree, so C++ is out. You want fast startup and not depend on a big runtime, so Java is out. It has to run on most systems, anything with a C compiler, so D is out. You want to have fun making something new.

If you remove his last requirement I think lof of languages still qualify. Effeil for instance, and maybe OCaml.


I can understand why Bram wants to target C. Vim runs on almost every operating system and architecture. Right now that's only really possible with C-targeted languages, languages with portable VMs/intepreters written in C, and (to a slightly lesser extent) C++.


Uh... so exactly why should I stop using C, Python or Java (which are mature, distributed and have a lot of libraries) for a language which does not offer advanced new features, about no libraries and also features some... akward syntax? (Don't get me wrong, I can live with syntax with is not C-like, or python-like, but unbalanced braces are certainly just akward).


Read the article, he explains why.


This new language's designer makes the Vim text editor, a lovely editor with a ... regrettable scripting language.


Moolenaar is one of my biggest heroes in the software world. He created a tool (vim) that is probably on the short list of great free software... one that has catalyzed the creation of so many other tools. And he did it in the name of charity, to raise money for a children's clinic in Uganda.

If I end up having one tenth of the positive influence on the world as this fellow has already done, I'll count my life successful.


As much as I love Vim (and I use it all the time), I truly hate it's scripting language. I think Bram devote his time to improve VIm.


Perhaps Bram could devote his time to improving vim's scripting language.


> I think Bram devote his time to improve VIm.

vimim


From the inspirations page (http://www.zimbu.org/design/inspiration), he's "avoiding" on of the best features of ruby:

  Avoid:
    * expression by itself is return value, causes mistakes.


This has a massive impact on the language semantics, and should not be decided lightly - it strongly pushes it towards nested statements, rather than imperative steps with a result. Not as clear a distinction as pure functional vs. imperative, but with much of the same design baggage.


"Suppose you want to write a new program, something like a text editor."

Then I open up the GUI builder for almost any language, throw a pre-built text box in place, and press compile. Next?

Not arguing against the language itself. It's just that using "text editor" as a use case is about as descriptive as starting with "Suppose you want to write 'Hello World.'" It doesn't tell you anything about what the actual requirements are. Compiled isn't necessary to build a text editor. Java isn't excluded. Etc.


While you are right that a text-box is a bad example of a programming language, what he is talking about is a text editor.

A text box is not a text editor. After all, take a look at Vim or Emacs. They have their own languages, syntax highlighters, language analysis tools, GUI and ncurses tools, etc... A goodtext editor is a huge piece of software - millions of lines of code (I think), perhaps, in the case of Emacs.

Although I do agree with you - good examples are important.


I'm really impressed that Boo is mentioned as an influence. Don't see the ideas there, but I'm glad to see it spreading in some way.


If you appreciate the goals and design rationale of this language you should check out freepascal (http://www.freepascal.org) which fulfills similar needs and is mature with an active community.


As fast as possible is premature optimization in most cases. Python still wins.


Ouch, it burns the eyes.


This doesn't really contribute anything. How about "I think the all-caps keywords and unmatched braces are ugly" or "parallelism should be considered a requirement in a new application language and highly-stateful Java-style OO doesn't really seem like a good way to accomplish that"?


Thanks for giving good advise to a down-voted comment. I guess we should do that more often.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: