The Zimbu programming language
zimbu.org
zimbu.org
The Hello World program: hello.zu:
FUNC Main() int
IO.write("Hello, World!\n")
RETURN 0
}
> Notes:> ...
> The } character is used to end a block. There is no {, we know where the block starts. This avoids useless discussions about where to put the {.
Excuse me, WHAT? When I saw the first code snippet I thought there was a typo, but the idea of using an unmatched close brace is so horrifying to me that I really have trouble looking further at this. Oddly the first thing that occurs to me is that in Vim it makes it hard to move between the beginning and end of a block, but I think I can safely assume that the author is fairly familiar with using Vim, seeing as he wrote it.
Having avoided useless discussion about where to put the "{" let's not start one about how to spell "end of block", eh? At least it's not some Unicode sigil.
The Zimbu programming language - https://news.ycombinator.com/item?id=17819857 - Aug 2018 (1 comment)
The Zimbu programming language - https://news.ycombinator.com/item?id=13258476 - Dec 2016 (54 comments)
The Zimbu programming language, by vim author Bram Moolenaar - https://news.ycombinator.com/item?id=894591 - Oct 2009 (51 comments)
> I use Emacs, but a Lua-extended vi could be very nice.
I wonder if the commenter is using neovim now that their wish has been made a reality
Because SQL has so many opinionated style guides rather than the One True Way I really enjoy spending time, if I have it, on making my SQL as Uniform and legible as I can. Sadly this is all closed source code nowadays. But my SQL files look almost like a table with clear 'rivers' along keywords. It makes my OCD brain go a little fuzzy inside when I finish :) Also having worked on a MONSTER of a financial system powered by stored procs and autogenerated SQL, I'm talking million line SQL files you can't load in a GUI, I am very fond of legible small SQL scripts nowadays.
[0] https://gist.github.com/mattmc3/38a85e6a4ca1093816c08d4815fb...
By making keywords all caps, (and presumably no other user defined names are all caps...I'm not sure if this is enforced by the language or not, but it's a simple enough convention that there is a very low likelihood of it being broken) you ensure that you have the entire namespace of words available to you as keywords for future enhancements to the language.
------------
5. The next compiler version will add a new feature
Once a compiler version is released programs will be written and distributed. The next version must not break the existing programs. Thus it must be possible to add keywords, types, modules, etc. without worrying that this might break someone's carefully crafted code.
Keywords are all-caps. No user symbol may be all-caps
Builtin type names are all lowercase. User types must start with an uppercase letter.
Builtin module names are all-caps. User modules must contain a lowercase letter.
Predefined methods start with an uppercase letter. User methods must start with a lowercase letter.
This may seem a bit strange at first, but one gets used to it very quickly. And the compiler gives a clear error message when making a mistake.In Go fields are made public by starting their name with an upper case.
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.
What a nice collection of horrible arguments.> It has to run on most systems, anything with a C compiler, so D is out.
Personally, this probably wouldn't be such a huge factor for me.
I actually think that something like Go would also be suitable for most of those other rules.
That said, the question eventually becomes about how often those actually are factors that might influence one's choice.
For example, in many cases the startup times won't be such a big deal (e.g. webapps with multiple instances), nor will runtime performance (e.g. Python scripts for shuffling some data around).
Yes it does. You can use GC for an OS but you end with slow, expensive, and very niche machines.
And yet Lisp machines were slow. I chalk that up to a proto-Common Lisp system, with 1970s compilation techniques, being just too much. Millions of lines of code of a fully dynamic software environment with a GUI debugger that let you step into any part of the system including the OS and lowest runtime layers and edit it live -- crammed into a couple megabytes and a couple MIPS. Of course it was slow.
Not that there's anything wrong with that! And a case could be made that much of the power in Lisp comes from the ease of turning it into, effectively, a different language.
But it's less "all the power of a high-level GC language and the ability to write low-level systems code" and more "all the power of a high-level GC language or the ability to write low-level systems code".
To take an example from the Lisp machines, here's the method (in the full OOP sense) for receiving UDP packets: https://twitter.com/RainerJoswig/status/1215728406823886854 High level code, which you can jump to while the system is running, edit, debug, recompile, but for a fairly low level networking task.
With modern SBCL, you get some nice compiled assembly from your code out of the box but you can output your own custom assembly if you want yet still not lose out on interactivity and recoverable errors (way beyond typical exception handling). You also never lose macros, so things like ugly-ish repetitive magic-number-seeming (technically from a datasheet) code poking at bits in status registers can be nicely abstracted. The topic of just GC and precisely managing memory when you need to is more involved, and I'll admit that certain strategies are little different from a C++ style (i.e. allocate a bunch of memory ahead of time and re-use it, rather than calling slow delete/letting the GC work to reclaim it), but even if Lisp isn't where the state of the art is (I'd give that to the JVM ecosystem where you have things like ZGC's average 50 microsecond pause times) the ones you have these days are a lot better than those of the 70s (which seems to be where some people think all GCs are still at) and the subset of low-level programming tasks where it really pays off to mess with a lot continues to get smaller...
Yes, Project Oberon[0] by Niklaus Wirth and Jürg Gutknecht is written in Oberon-07 which is a very small programming language with a garbage collector. The garbage collector is even written in Oberon-07.
Yes, bitbucket has dropped Mercurial. I'll look into putting Zimbu up on github. I'm not currently working on it, but some people might find it interesting and want to try it out.
I still can't get past the unpaired } as the ending delimiter. It's a superficial reason, but there are many languages out there, and it's easy to be picky.
one of the funniest things I have seen as a selling point for a pl.
I agree otherwise.