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.
There seems to be a LAMBDA ... } syntax as well that works as an expression. Along with the upper case keywords, I'm convinced this language is meant as a joke, but it's very, very subtle. For example, the "Inspiration" page lists as one of the things it intends to borrow from Java, "use of design patterns": http://www.zimbu.org/design/inspiration Like the one thing people love about Java are all the AbstractFactoryFactoryFactories.
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.
I wonder if the capitalization is required. What modern programming language would require capitalization? I use it in SQL and that makes sense given that SQL is often embedded in other programming language via strings and so the capitalization helps because there are there's no syntax highlighting. But otherwise I don't see the point of it.
I believe the argument here is that since it's currently an experimental language, future versions might include many currently unplanned keywords.
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.
From the "Design Principles" section that points out other rules (that seem to be compiler enforced) and the reasoning behind it:
------------
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.
When a Junior developer doesn't capitalize their SQL it makes my eye twitch, and it's not that I personally care, it's just that I'm so used to seeing it as a standard, and my brain wants to go with standards always.
I'm kinda the opposite. I always saw the older developers writing SQL in lowercase, so now when I see someone using caps, I think they must have just read a SQL book or something.
Caps with nice tabular lining so everything is neat. Handwritten SQL can feel a little like art, I really enjoy making mine look as uniform as possible
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.
I rarely touch SQL, so I don't really have much of an opinion on these matters. However, the last time I did have to touch it, the senior developer on the project used this as his personal shibboleth for differentiating junior and senior developers. By his reckoning, junior developers put SQL statements in caps because they were used to seeing that in textbooks. Senior developers would realise the importance of maintainability and use lower case out of respect for the next person to read the code.
All-capital writing is far harder to read for extended periods of time. If you're looking a a few short SQL statements embedded in other code or something, that's not a big issue. If you're editing screen-filling report queries or editing a long data structure full of various SQL statements, it's a bigger deal.
But there is syntax highlighting - what editor and language combination are you using? I know for a fact that SQL is highlighted inside Python and PHP strings in Sublime Text 4..
> Why Zimbu?
Suppose you want to write a new program, something like a text editor. What language would you write it in?
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.
I actually found most of them to be pretty reasonable.
> 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).
Can a language that uses GC (presumably, it says no manual memory management) be used to program an OS? Just wondering...
I think the home page is not very informative as it doesn't really tell me what features are there in this language, but just what it hopes to be. And tbh, from my experience using vim script, knowing its author may scare me away from this...
> Can a language that uses GC (presumably, it says no manual memory management) be used to program an OS?
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. One approach is to use a language that allows both GC and manually managed memory, perhaps a small subset of the full language proper. You then write the garbage collector itself and other runtime bits in that language. Another approach is to reduce the GC runtime to as small a blob as possible, and write it in C/assembly. The old LISP machines used both techniques -- there was an assembly language of sorts, that mapped closely to the high-level language, in which the most basic layer of the system like the GC was written.
Sure, the heritage of Lisp Machines shows that well enough. Or a modern version: https://github.com/froggey/Mezzano Not all GCs are equivalent, though.
Doing low-level programming in a Lisp is much like doing so with Cython or RPython: you're using effectively a different language with familiar syntax.
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".
You're maybe right with a generic idea of Lisp that includes all of Clojure and most Schemes and random GitHub "lisps", but I think Common Lisp (and its immediate predecessors) really does give you that and. "Going faster" or just lower doesn't really require anything like the contortions and sacrifices that something like moving from Python to Cython/RPython does. (As an aside, I recently came across and was amused by the existence of https://pypi.org/project/PeachPy/)
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...
Lisp machines weren't slow. The initial CADR machines around 1980 could run simple integer and maths code around as fast as the VAX/780, a very fast minicomputer costing ~$50,000 (processor only!) that was released around the same time.
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.
Project Oberon and its descendants would be a counterpoint to this assertion. GC'd systems language + OS can be made to work effectively and without requiring anything special.
He refers to Vim9 script in the comment about the lack of work on it on the top of the page, so apparently it saw work fairly recently. To my surprise, I thought it was long dead.
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.
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 like the idea of splitting FUNC and PROC, but still like the idea of enforcing some level purity on FUNCs at least not allowing them to invoke PROCs, but able to invoke other FUNCs.
> ...
> 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.
[1] http://www.zimbu.org/getting-started/hello-worlkd