
The Zimbu programming language, by vim author Bram Moolenaar - mbrubeck
http://www.zimbu.org/
======
silentbicycle

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

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

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

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

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

~~~
raganwald
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_

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

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

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

~~~
mnemonik
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...](http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html#Primitives-
Networking)

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

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

~~~
eru
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?

~~~
silentbicycle
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

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

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

~~~
mbrubeck
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++.

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

~~~
albemuth
Read the article, he explains why.

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

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

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

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

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

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

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

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

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

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

------
omouse
Ouch, it burns the eyes.

~~~
Zak
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"?

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

