Bram Moolenaar's programming language, Zimbu | Hacker News Reader

Bram Moolenaar's programming language, Zimbu

thenewstack.io

119 pointsMilnerRoute35 comments

I am not a user of Vim, but this guy used the "charity ware" model to do so much inspiring work in Uganda (my country).[0]

I hope I will be able to do something close to his achievements in my lifetime.

[0]: https://en.wikipedia.org/wiki/Bram_Moolenaar

> Zimbu’s trademark feature was the way it let coders omit the opening curly brace around a block of code. (“It looks a bit weird maybe, at first…” Moolenaar acknowledged to the audience. “Get used to it. It will work out fine.”)

Hahahaha, this is what we needed: a programming language with unmatched braces because the opening brace can be inferred from context... Well, no surprise that this is coming from the Vim creator.

Not that dumb as one might think. What is the purpose of the opening brace after a function declaration in C, for example? It's the only token accepted, so its sole purpose is symmetry with the closing brace, which has an actual purpose.

So it might look silly, but there is no deep reason it couldn't have just been

    int main()
       printf("hello");
    }

That's just as unambiguous to parse.

Technically, the opening brace is needed in C to support K&R style function declarations which apparently were still legal in C11 at least, but I doubt that's a feature anyone wants to replicate in a new language.

Not in the original C, where you had to declare function parameter types like so:

  int foo(x)
    int x;
  {
      return x;
  }

and not in C23 (or GNU C) either, where this is legal (this example is not super useful):

  int foo(int x) [[gnu::aligned]] {
    return x;
  }

In that case, I would prefer Pascal’s (and Basic’s) “end”, however.

Unmatched braces completely mess up text editors, which would need to include a full parser in order to pair-match brackets (it also creates an unresolved tension that will stay with you all day :)

I was going to say the same. And yes - it causes OCD in 90% of devs out there. But it also feels somewhat wrong for editors to match brackets to infer block hierarchy. What if blocks have some sane rule that we don't know yet (i.e other than bracketed blocks and indented blocks)? Perhaps treesitter is the one-stop solution for that problem.

Indeed. Things like di{ probably don't work...

> :)

That’s a mouth, not a paren :/ I won’t be able to sleep tonight :)) (that’s better

Many languages are designed with IDEs in mind and "dumb" text editors are not a concern.

Text editors need fairly complete parsers to match braces anyway. E.g. consider even something as simple as { "}" }. Or {"\"}. The former is reasonably unambiguous, but the latter requires knowing if the escape style of double quoted strings in the given language escapes the second '"' or not. Now try proc {"#{"}"}"} (valid Ruby) vs proc {"{\#{"}"}"} (invalid)

I have an even better idea:

  main(): int
    printf "hello"
    0

;)

Trouble with that is invoking main and declaring main are too similar. I prefer this:

    let main () =
      printf "hello"
      0

Why do we put spaces after punctuation in English?It's completely redundant.actually,why even put a capital letter at the beginning of a sentence?it can obviously be inferred.

OK, I'll stop now, but the point is: matching braces provide visual structure that's helpful to read code, even if it's syntactically redundant.

Prose is not a programming language, isn't it obvious?

One is designed for machines to parse unambiguously, the other has grown organically and chaotically over hundreds of years. Machine parsing has never been a design concern.

Indentation provides visual structure. Matching braces hardly add value to it.

You identified its purpose: symmetry.

Reminds me of TI-BASIC for the TI-83 graphing calculators... The closing ')' is optional at the end of a line, and omitting it could make your program slightly faster...

One step further would be to omit the second brace too. And we arrived at the Python design choice. I think only omitting the first brace is a middle ground most people find unappealing.

Hence Ruby or Oberon style of "end". Personally I have no intention of ever seriously using a language with significant indentation levels. It's not worth suffering the visual clutter.

Niklaus Wirth also removed the BEGIN keyword from control statements in Modula-2 and in Oberon.

Oberon:

  IF a < b THEN
     ...
  END

Pascal:

  IF a < b THEN
  BEGIN
     ...
  END

Odd that the first example looks buggy:

    while i > size
    result += a [i++]
    }

Could be correct, but "while i < size" seems more likely...

    int main()
       printf("hello");
    }

This is perfectly reasonable and has precedent in one of Wirth's languages (modular 3? Oberon?):

    /* Syntax from memory, may be wrong */
    function main(): integer
       println("hello");
    end;

This does potentially break a symmetry in the language as to how a begin…End / {...} local block can be declared, but whatever, that's easily fixed.

I don't see how this would make any particular issue for bracket matching (except one of the brackets isn't there, you match to something else such as the start of the function) and lexing/parsing is fast.

Just as a suggestion buy if everybody here actually write their own compiler, even a simple one, perhaps there would be less bikeshedding.

Last working version of the homepage from the Internet Archive: https://web.archive.org/web/20230529224014/http://www.zimbu..... Tried a couple of link, they seem to work.

Update: I was able to find the mercurial repo on https://bitbucket-archive.softwareheritage.org/projects/zi/z..., looks like it hadn't been updated since 2016.

EDIT: of course, moments after I submitted this comment, I found the following in the spec:

"For more flexibility, at the cost of performance and causing mistakes to be discovered only when the program is being executed, the dyn type can be used. A variable of this type can contain any kind of value or reference. Assignment to a dyn variable never fails. However, using the variable where a specific type is expected will invoke a runtime type check. For this purpose the dyn type stores information about the actual type."

Original comment below for posterity.

----

The article claims that Zimbu has "both static and dynamic typing", which sounds novel and interesting to me. But on the Zimbu site linked by a sibling, all I could find (on https://web.archive.org/web/20230529230025/http://www.zimbu....) was:

> It should work to have as much static type checking as possible, but make it possible to have dynamic types with runtime type checking.

Can anyone find any more details about this feature? (Or does it just mean "there's a type `obj` which is a supertype of every type", which is much less interesting except insofar as it interacts with what it means for something to be a reference vs value type?) The spec at https://web.archive.org/web/20230805135331/https://www.moole... is awfully long.

Sounds like gradual typing, maybe? That stuff was hot, years ago. Jeremy Siek is one the original inventors — his stuff is really approachable.

I suspect an autoincorrect incident. Jeremy Siek, he also has a couple compiler books out now (basically the same book, one with Python and one with Racket).

https://wphomes.soic.indiana.edu/jsiek/

Essentials of Compilation, both versions have a chapter on gradual typing.

For anyone else that wants to just skip to the language spec: https://www.moolenaar.net/z/zimbu/spec/zimbu.html

Other than VimScript and Vim9Script, of course.

Quite a contrast from Vim's infamous internal language for plugins.

I see a lot of similarities to Golang.

So...he invented Python?

Ugly programming language. I don’t know who would use it

Reply on news.ycombinator.com