With the orphaned closed curly braces and ALL CAPS keywords, it's like this language was created to make programmers twitch uncontrollably. The only thing he could do to make this more off-putting would be to mandate some kind of crazy double-tab indentation scheme. :-p
Really. I thought about that when I saw Ruby 10 years ago and didn't like to type end to close blocks. However
1. Space { } are three characters like e n d and using the idiomatic do when needed is only one more character (and the editor types end for me)
2. It looks better than an orphaned }
Other solutions:
1) Erlang has , instead of ; and . instead of } A long list of .s is not idiomatic (doesn't happen) but it would be pointless (pun intended) in a language where it does.
2) swallow the pill and use both braces.
Going the Python way (I suggest not using the : ) would be a radical change.
I also don't like the shouted COBOLish keywords. Were they necessary?
I prefer the braces over END not because of the character count but because my brain can't avoid reading "end" when I read the code, while closing braces don't cause a word to pronounced in my mind.
Also, just like you, I find that closing cascade of ENDs in nested statements is visual noise.
A cascade of end or a cascade of } is a bad smell about the code. I try my best to avoid that.
Python has a solution to that problem but I think it's worse than the problem. end and } never gave me as many bugs in 30 years as having to reindent in Python did in one year.
I like Python's relevant whitespace. It forces sloppy coders to organize their code in a more readable fashion. People who use tabs throw a wrench into the works, of course, but forcing them to fix the issues they've caused typically ensures it won't happen again.
I have written Python code since version 1.9 was first released, back in the 1990s, and I've worked on many large Python teams where we never ran into any issues with whitespace at all. We all set our tabs to 4 spaces, adhered to PEP8 formatting, and everything went as smoothly as any other language. I think it may just be what you're used to too.
That is an interesting reason. It may seem small, but I think it is a perfectly valid point.
I'm of the opposite opinion, but for similar reasons. I type using the Dvorak layout, and typing curly braces is a bigger pain in the nipple than typing "end." For me, "end" also makes reading code blocks easier, because it looks like the end of a paragraph. In other words, the fact that it does read like a sentence makes it stand out more for me than curly-braces do; especially when coders, who obviously have no style, put the opening curly-brace on the same line as the function definition or control loop. Hehe.
I think it is interesting to contemplate the subjective aspects of languages and syntax preferences. Probably not productive, but interesting none the less.
"Back in the days" when I was programming QBASIC, which uses capitalized keywords, it was really easy to spot typos in keywords. You could just write in lowercase, and the IDE would convert your keywords to uppercase if you didn't make a typo. While I admit that it looks kind of ugly, it is actually a huge practical advantage.
Python's colon is not for the sake of the compiler (you could theoretically parse a version of Python without them), there were studies that showed that it's easier for humans to read with it than without. A lot of Python's design decisions were made because it's easier for humans to read and write (keyword operators, whitespace syntax, explicit return).
Putting regexes in multi-choices like that is not a new idea - you can also do it in Ruby:
case "foo"
when /hello/
when /oo/
puts "hi"
end
I guess the new thing is having to state that it is a regex, which I assume is needed as the langauge here don't seem to have regex literals but are reusing strings (seriously, why do languages keep doing that? Did they learn nothing at all from Perl?)
Using capitalized keywords in order to make it easy to add keywords in the future reveals the author is probably not very familiar with the science of parsing. It's quite possible to introduce new keywords in future versions of the language and make sure your compiler won't choke simply because the word is being used as a variable name instead of an identifier.
The Ada variant seems to achieve a clearer goal: specify exactly where LSP / subtyping is desired, leaving the default behavior of un-decorated types alone. Explicit opt-out as in Zimbu seems odd.
> The really ugly bit is the macro system: Nim macros are awful.
If I had a penny for every time I see you say that on HN... :)
In any case, I disagree with you. Nim macros are really easy to work with, the AST construction is a bit verbose but that can be easily remedied by writing functions which make the construction easier.
Is that really true? An amazing amount of absolutely mission-critical infrastructure runs on code that was written once and probably never even code-reviewed.
Simplicity is the most difficult thing to engineer. I think this is a good example of that.
There are so many symbols, special cases, if ands and buts. When do things get $? When do things get ;? When do things get capitalized?
Making words capitalized shouldn't be needed. If your language is being used and the syntax of the language encompases more of then the meaning you are attemping to convey then you've poorly designed the language.
I think python is a good example of how to be simple. There are (), :, and whitespace. You have if, elif, def, and class (I'm not counting pass). The syntax and semantics are simple (although I don't like the reliance of whitespace as a block segregation technique).
It's hard to see the logic under the language in Zimbu. In python the logic is the language. When you see really pythonic code, the code are just expressing the ideas in a simple way using the language's keywords is a way to make it even simpler. For example
for account in database(outstanding_bill=True):
print(account.name)
As you can see, there is a syntax to this but it reads the same way as the program is meant to run. "For every account found in database that has outstanding_bills print the account name". The syntax is part of the meaning in this. In Zimbu..... I think work needs to be done. I'm just not getting it I don't think.
> There are (), :, and whitespace. You have if, elif, def,
> and class (I'm not counting pass).
I'm a big fan of Python, but I'm not sure what you're trying to say here. There are way, way more than four reserved words in Python (including ones like `False` which aren't immediately obvious as keywords due to the different capitalization). There are also way more symbols used than those you list: [] for lists/comprehensions, {} for dicts/sets, single/double asterisks for unpacking, @ for decorators, all the familiar symbolic bitwise operators that C has, \ for line continuations, ; for multiple statements on the same line, etc.
I meant to start. They may be pervasive throught the community but you don't need to know about them as you may not even see them for the first little while.
Decerators are something I am also not going to count as they aren't going to be the first thing, or even one of the most basic things, you will encounter. It's like counting "register" as a C keyword. It is buy you're likely to be able to go an entire lifetime without seeing it in a codebase.
In Python 2 True and False are not keywords. You can reassign their values. But I see what you mean and yes my list isn't comprehensive. It's an example.
The list would probably be more like (), {}, [], <, >, !, =, \, ',', :, ;, *, and @. For a basic programming experiance you you're probably not going to see or even care about a most of the nitty and gritty ones you describe in the contexts as you describe. You could even avoid using [] and {} by just writing "list()" and "dict()".
Basically I agree but again the point still stands. Python has far less clutter then what is demonstrated here. While python may have many really cool magic single-character operators most of them aren't really in your face. "!=" may be the most in your face one along side ":". In total the clutter is just not dumped all over your code or at least it doesn't seem like it is.
Sounds like what you want is clojure. Once you know what ()[]{}#'@ mean, you only need to basically understand the couple dozen "stdlib" functions and you're good to go.
Academically sure, in the real world I think Clojure has more advantages in terms of tooling, evolution potential and community/ecosystem.
Aside from the "nitty gritty" aspects related to being hosted on the jvm I find clj to be the superlative of simpleness.
As a counterpoint, APL was a very popular language in its day. Special symbols, very obtuse and concise syntax, heck, it even had a special keyboard. There are some niches where such choices can work.
KDB, a database built on a descendant of APL called K (which can be worked with through K and a slightly friendlier APL-like language called Q), is extremely popular in financial institutions.
I know of a company (Simcorp) that uses APL extensively. It is probably pretty rare that they hire someone who is already a proficient APL programmer, and most of their hires probably don't know it at all. So they train them. It's not that hard to learn. Also, most of the APL programmers are experts in some other domain, usually finance, so they don't have too many preconceptions of what programming is like.
Is J [0] one of those that gets lots of use? I have tried it a few times, and was impressed by its power [1] and compactness, but its rather cryptic syntax [2] put me off from going deeper into it. Might still try it more some day.
[1] It has some superb demos (which come with the basic install) of many kinds of apps, including up to the level of things like OpenGL graphics ones.
[2] Its succinctness [3] may be a virtue, though, once you get used to it, since programs in it are much smaller than in other languages (I'm guessing both due to its APL heritage and due to using a lot of symbols instead of words - based on what little I have read about it).
[3] That reminds me of PG's essay, Succinctness is Power:
> I think python is a good example of how to be simple.
I disagree. Python was a good example of that when it was Python 1.5.
Modern Python 3.5 is a Perl-style nightmare of special cases, weird sigils, ridiculous primitive types needed because of legacy reasons, inconsistent standard libraries and everything else that comes with being a 'serious' language.
Someone else has already observed that the motivation pretty much exactly matches Nim's. However, if you just decide that you don't need a compile to C language, Go or even Haskell matches the criteria...
What bothers me most about this language isn't the orphaned braces, or the case sensitive keywords or any of the other quirky decisions.
What bothers me most is the monkey mascot. What relevance does a monkey have to this programming language? Is the idea that it's so simple a monkey could do it? Is the monkey Zimbu? It isn't explained anywhere, and I'm betting it's just some random animal they chose without any thought because it's cute.
At least the Go gopher makes a little bit of sense (GOpher). This monkey seems like a completely nonsensical choice though.
>> No existing language really meets these demands, so let's create a new one that does!
What about lazarus/fpc?
I could easily drop a memo on a form and start giving it highlighting rules. I could easily connect to postgres and bring up a form with a grid and export it to excel. The pascal language itself is simple and works on multiple platforms.
As an aside, and from a non-CS person's perspective, what is the need for more programming languages? I find at least one new one every few days on HN. I've been learning Python since late 2015 and I find just mastering one language (and its libraries) overwhelming.
So, what is the incremental advantage to be gained by learning yet another new language?
54 comments
[ 4.0 ms ] story [ 131 ms ] threadFully capitalized keywords make my carpal tunnel syndrome self recoil. Probably inspired from Modula 2 or BASIC?
At least I give the creator credit for picking a name that will be easy to search :-)
1. Space { } are three characters like e n d and using the idiomatic do when needed is only one more character (and the editor types end for me)
2. It looks better than an orphaned }
Other solutions:
1) Erlang has , instead of ; and . instead of } A long list of .s is not idiomatic (doesn't happen) but it would be pointless (pun intended) in a language where it does.
2) swallow the pill and use both braces.
Going the Python way (I suggest not using the : ) would be a radical change.
I also don't like the shouted COBOLish keywords. Were they necessary?
Thumbs up for the new regexp switch statement.
Also, just like you, I find that closing cascade of ENDs in nested statements is visual noise.
Python has a solution to that problem but I think it's worse than the problem. end and } never gave me as many bugs in 30 years as having to reindent in Python did in one year.
I have written Python code since version 1.9 was first released, back in the 1990s, and I've worked on many large Python teams where we never ran into any issues with whitespace at all. We all set our tabs to 4 spaces, adhered to PEP8 formatting, and everything went as smoothly as any other language. I think it may just be what you're used to too.
I'm of the opposite opinion, but for similar reasons. I type using the Dvorak layout, and typing curly braces is a bigger pain in the nipple than typing "end." For me, "end" also makes reading code blocks easier, because it looks like the end of a paragraph. In other words, the fact that it does read like a sentence makes it stand out more for me than curly-braces do; especially when coders, who obviously have no style, put the opening curly-brace on the same line as the function definition or control loop. Hehe.
I think it is interesting to contemplate the subjective aspects of languages and syntax preferences. Probably not productive, but interesting none the less.
There are many other variants https://en.wikipedia.org/wiki/Indent_style#Placement_of_brac... and wars have been fought over them. There are pros and cons for most of them. My tradeoff is the K&R style.
I think editors can automatically convert among styles nowadays. The only thing that matters is consistency.
Although that only seems to be mentioned in the "Highlights" section and not in the language specification, so it's unclear if it's implemented...
https://en.wikibooks.org/wiki/Ada_Programming/Object_Orienta...
However, 2 improvements that could be made are:
1) being able to write the code as normal (if instead of IF, else instead of ELSE) and then using something like:
zu.fmt
To format the code (best of both worlds?)
2) Dropping the ending-brace. It will just lead to many errors that could otherwise be avoided
---
Also, if you are interested in a similar language, maybe Nim might be worth a look:
http://nim-lang.org/
The really ugly bit is the macro system: Nim macros are awful.
If I had a penny for every time I see you say that on HN... :)
In any case, I disagree with you. Nim macros are really easy to work with, the AST construction is a bit verbose but that can be easily remedied by writing functions which make the construction easier.
>that can be easily remedied by writing functions which make the construction easier.
That can only really go so far...
You can go look up the comments, if you like. I can't do another writeup on it at the moment, sorry to say.
Is that really true? An amazing amount of absolutely mission-critical infrastructure runs on code that was written once and probably never even code-reviewed.
There are so many symbols, special cases, if ands and buts. When do things get $? When do things get ;? When do things get capitalized?
Making words capitalized shouldn't be needed. If your language is being used and the syntax of the language encompases more of then the meaning you are attemping to convey then you've poorly designed the language.
I think python is a good example of how to be simple. There are (), :, and whitespace. You have if, elif, def, and class (I'm not counting pass). The syntax and semantics are simple (although I don't like the reliance of whitespace as a block segregation technique).
It's hard to see the logic under the language in Zimbu. In python the logic is the language. When you see really pythonic code, the code are just expressing the ideas in a simple way using the language's keywords is a way to make it even simpler. For example
As you can see, there is a syntax to this but it reads the same way as the program is meant to run. "For every account found in database that has outstanding_bills print the account name". The syntax is part of the meaning in this. In Zimbu..... I think work needs to be done. I'm just not getting it I don't think.Decerators are something I am also not going to count as they aren't going to be the first thing, or even one of the most basic things, you will encounter. It's like counting "register" as a C keyword. It is buy you're likely to be able to go an entire lifetime without seeing it in a codebase.
In Python 2 True and False are not keywords. You can reassign their values. But I see what you mean and yes my list isn't comprehensive. It's an example.
The list would probably be more like (), {}, [], <, >, !, =, \, ',', :, ;, *, and @. For a basic programming experiance you you're probably not going to see or even care about a most of the nitty and gritty ones you describe in the contexts as you describe. You could even avoid using [] and {} by just writing "list()" and "dict()".
Basically I agree but again the point still stands. Python has far less clutter then what is demonstrated here. While python may have many really cool magic single-character operators most of them aren't really in your face. "!=" may be the most in your face one along side ":". In total the clutter is just not dumped all over your code or at least it doesn't seem like it is.
[0] http://jsoftware.com/
[1] It has some superb demos (which come with the basic install) of many kinds of apps, including up to the level of things like OpenGL graphics ones.
[2] Its succinctness [3] may be a virtue, though, once you get used to it, since programs in it are much smaller than in other languages (I'm guessing both due to its APL heritage and due to using a lot of symbols instead of words - based on what little I have read about it).
[3] That reminds me of PG's essay, Succinctness is Power:
http://www.paulgraham.com/power.html
I disagree. Python was a good example of that when it was Python 1.5.
Modern Python 3.5 is a Perl-style nightmare of special cases, weird sigils, ridiculous primitive types needed because of legacy reasons, inconsistent standard libraries and everything else that comes with being a 'serious' language.
Shipping Lua as a first-class alternative to VimL also happens to be the primary goal for Neovim in 2017.
[1] https://news.ycombinator.com/item?id=895350
What bothers me most is the monkey mascot. What relevance does a monkey have to this programming language? Is the idea that it's so simple a monkey could do it? Is the monkey Zimbu? It isn't explained anywhere, and I'm betting it's just some random animal they chose without any thought because it's cute.
At least the Go gopher makes a little bit of sense (GOpher). This monkey seems like a completely nonsensical choice though.
Possibly:
http://dilbert.com/search_results?terms=Zimbu+The+Monkey
What about lazarus/fpc?
I could easily drop a memo on a form and start giving it highlighting rules. I could easily connect to postgres and bring up a form with a grid and export it to excel. The pascal language itself is simple and works on multiple platforms.
So, what is the incremental advantage to be gained by learning yet another new language?