Walter Bright: > D is full of syntax, at some point adding more and more syntax to deal with > more > and more obscure cases is not a net improvement. There's a point of > diminishing > returns.
On this I can add another general note about language design :-) Lisp/Scheme programmers think that minimizing the syntax allows an usable form of macros, and they seem to even think minimizing the syntax is good in general too. A language like Dylan has Algol-like syntax and Lisp-like syntax and macros, but its macros can be harder to write. So I agree with them that a S-expression-based language allows for simpler to use macros, but I don't agree with them that removing most syntax helps normal programming too. The recent very Lisp-like Clojure language adds a little amount of special syntax for some collections, etc. >From the languages I have learnt I have seen that learning the syntax takes >just a certain amount of time in the beginning. For me programming in >languages like C# and D that are full of syntax is not hard because of their >syntax I have had to learn. For me it's less easy to keep in memory special >cases, special cases of special cases, a long number of language traps, >possible run-time bugs that the compiler&runtime are not able to catch for me, >etc. Python has ten times the syntax of Scheme, but for me learning Python >didn't take much more than than learning to write programs in Scheme. That's why more keywords is not a disaster. What's bad is when the same keyword is used for subtly different purposes in similar contexts :-) This can cause bugs and troubles. So I think language designers have to minimize not just the total amount of syntax but the amount of traps, special cases, special cases of special cases, implicit behaviours, bug-prone syntaxes, unnatural syntaxes, or names that are subtly different in both their letters and semantics (like for example the chomp() and chop() functions of std.string). When I have a clean syntax, easy to read and explicit, that has a single purpose and it offers no common traps, then I can learn to use it and use it reliably even if it's not so common in programs and even if there's lot of other syntax in the language. There is of course a limit in the amount of syntaxes that we can accept. In this case of static arrays I agree that I can live without the [$] syntax, even if it's not hard to understand what its purpose is, but I can accept this missing feature much better if the language enforces the length of the literal to be the same as the the specified length in the type :-) Bye, bearophile
