HN Explorer

35 comments

[ 2.8 ms ] story [ 95.4 ms ] thread
max_
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

gowld
Quite a contrast from Vim's infamous internal language for plugins.
finnh
Odd that the first example looks buggy:

    while i > size
    result += a [i++]
    }
Could be correct, but "while i < size" seems more likely...
User3456335
> 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.

sph
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.
mikepavone
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.
vore
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;
  }
layer8
In that case, I would prefer Pascal’s (and Basic’s) “end”, however.
zarzavat
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 :)
goku12
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.
cozzyd
Indeed. Things like di{ probably don't work...
kgwxd
> :)

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

The_Colonel
Many languages are designed with IDEs in mind and "dumb" text editors are not a concern.
vidarh
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)
norir
I have an even better idea:

  main(): int
    printf "hello"
    0
;)
lambda_garden
Trouble with that is invoking main and declaring main are too similar. I prefer this:

    let main () =
      printf "hello"
      0
sltkr
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.

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

frodowtf
Indentation provides visual structure. Matching braces hardly add value to it.
fferen
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...
ctenb
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.
vidarh
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.
augustk
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
Smaug123
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.

thechao
Sounds like gradual typing, maybe? That stuff was hot, years ago. Jeremy Siek is one the original inventors — his stuff is really approachable.
Jtsummers
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.

mikl
Other than VimScript and Vim9Script, of course.
whatscooking
Ugly programming language. I don’t know who would use it
jhoechtl
I see a lot of similarities to Golang.
_a_a_a_ 

    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.