I'm really sad to see this misconseption over and over on HN. Verbosity is so much worst than syntax complexity because you ends up having dozens of different patterns that do the same thing overall but with subtile differences on edge cases.
If you look at JavaScript pre-ES6, you had at least 10 ways of doing OOP with really different behaviors when it came to inheritence or encapsulation. This makes the code so hard to understand.
ES6 formalizing a specific semantic for OOP was godsend.
As long as you introduce syntax to help with what people are actually doing (and not juste because it looks cool) syntax addition enhance the code readability.
Ada and Dylan are good arguments against the notion that verbosity is harmful.
Please don't be rude.
Verbosity is so much worst than syntax complexity because you ends up having dozens of different patterns that do the same thing overall but with subtile differences on edge cases.
There's a level of verbosity/terseness that's ideal for (your average) human. I don't know precisely what that level is, but I think many programming languages, such as C++ and Rust, have stepped way past that line.
If you look at JavaScript pre-ES6, you had at least 10 ways of doing OOP with really different behaviors when it came to inheritence or encapsulation. This makes the code so hard to understand.
The problem with JavaScript OO was, in my opinion, the use of prototypes.
As long as you introduce syntax to help with what people are actually doing (and not juste because it looks cool) syntax addition enhance the code readability.
This is simply an unsupported claim.
There are no languages in the same domain that don't have a comparable level of syntax and semantic complexity given the intrinsic nature of the information they want to encode.
And I would make rather take sigils than using a bunch of different keywords every time I need to talk about lifetimes and pointers.
To date I have not seen languages with comparable complexity expressed with more elegant syntax. Some domains just have irreducible complexity.
So vague.
> As long as you introduce syntax to help with what people are actually doing (and not juste because it looks cool) syntax addition enhance the code readability.
So you are saying Rust's syntax is doing just right. But this has nothing to do with other language design. Just open your mind.
It's not obvious from the simple example given the original article, but as the release notes mention it makes things like the following:
try!(try!(try!(foo()).bar()).baz())
much more readable:
foo()?.bar()?.baz()?
If the main concern is readability of code, the latter wins hand down.
Programming languages can make things more complicated and having worked in C++14, python and VBA i can tell you that VBA does not come out on top even though it is seemingly simple. Compared to python VBA lacks so much ecosystem and language features that you will have a hard time to even parse XML, process loosely structured data and serve it via HTTP.
Looking at python vs. VBA and C++11 vs. C++03, I'd say that programming languages have generally been moving in the right direction.
When I was young, it was all about the "next guy." You iterate on it to make it clean, make it simple, make the docs right, etc because you wanted to set up the next guy for success debugging your shit. It was a code of honor, we are all the next guy in a way. You don't hear about it as much any more. Working and getting it done quick seem to outweigh real craftsmanship.
There are general purpose languages that enable people to author complex programs because they have terse syntax and are highly expressive. In such cases the programs are complex but the languages are often semantically simple and consistent (e.g. Haskell).
I certainly do not agree in languages like C++, where for example they are attempting to combine the semantics of runtime memory management with the lambda calculus.
Forgive my youth, which languages are these?
Of course reading any program still requires a mind accustomed to logical thought. A subsistence farmer has a different sort of "no formal training" than an 18 year old taking Chemisty courses.
In any case there is no need to worry...the important thing is the ideas not the syntax. And the useful ideas tend to be conveyed through time in multiple languages.
BASIC is even worse in many respects. It starts being deceptively simple, but do you think that someone looking at these two lines:
PRINT a, b;
PRINT a; b
would be able to tell the difference? Or, say, what does this do? LINE (0, 0) - (100, 100),, BF
(no, it doesn't draw a line)And then if we're talking about classic BASIC, you have to remember that A% is integer while A$ is string etc. None of that is at all obvious.
Or, say, you see this:
NAME x AS y
A reasonable guess would be that it renames a variable, or maybe creates an alias, right? But no - it actually renames a file with a name corresponding to a value in variable x, to a new name corresponding to a value in variable y. And many BASIC dialects will even helpfully stringize it for you, if the variables were, say, integers.OTOH the usual, pre-Java-8 way of allocating anonymous subclasses when you mean to pass a function is at best obscuring the meaning of your code...
Again, this is just a difference in attitude, but I find verbosity in general just cognitive noise that would be better spent with precise, higher-level constructs.
Our civilization is going to end up with countless dead languages -- dead programming languages, that is -- because future generations won't know how to read the increasingly terse and arcane syntax that is all the rage these days. Either that, or the investment necessary to read these crazy languages will be considered an ill advised investment in resources. We'll end up recreating the wheel indefinitely, but in different languages.
I would like to see much, much simpler programming languages, even if they're more verbose, as long as the result is improved readability and longevity of the code written in said languages. I think some of the older languages are far superior in many ways, if only because, with some of them, you can actually read and understand the code without even any formal training in the language.