Hacker News Reader

Comment by Teckla | Hacker News Reader

I often feel like I'm the only software developer in the world that thinks most programming languages are evolving in the wrong direction.

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.

View on HN

> 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'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.

It's a trade-off. Obviously Javascript's main problem is that it is too dynamic, classes or not. Class can make code more readable though, but Javascript still lacks of ways to declare private members explicitly. They should fix that ASAP.

JavaScript's OO problem was never syntax or verbosity, it was that it's a prototype-oriented language. Any language like that will invite conflicting ways of doing OO. The new ES6 class stuff adds yet another way -- but one that at least corrals developers into following a single official convention. The underlying object model is, for better or worse, the same.

Ada and Dylan are good arguments against the notion that verbosity is harmful.

I'm really sad to see this misconseption over and over on HN.

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.

Use of prototypes, excessive falsy values, function scope, for each loping over object properties vs. arrays, and undefined vs. null are just a few things that will confuse people who see Java-like name and syntax and expect Java-like behavior. Maybe if you learn JavaScript first, it makes sense, but for everybody coming from other languages with C-like syntax, it is just too surprising.

> 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.

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.

> 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.

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.

Have a read of the rust release notes [0] to see why the ? operator actually improves code readability.

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.

0: https://blog.rust-lang.org/2016/11/10/Rust-1.13.html

Keep it as simple as possible but don't try to make it simpler than it really is.

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.

Is that a language thing or a culture thing?

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 certainly newer domain specific languages that fit your criteria such as Go. It can be verbose due to its lack of expressivity and its syntax. But simplicity to me is more about semantics. Should a successor to Javascript or PHP feature the same equality table or even be Turing complete?

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.

> you can actually read and understand the code without even any formal training in the language.

Forgive my youth, which languages are these?

I taught myself HyperTalk with no formal programming training by reading the source code embedded in scripts.

Some examples might be COBOL, Java, BASIC, and Logo.

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.

I can't speak for COBOL and Logo... but Java, really? When you're looking at a hello world program in it, 80% of it doesn't make sense to someone not familiar with the concept - import? class? static? void?

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.

No you are not the only programmer who thinks that languages are going in the wrong direction. For example, the lambda operator of Java 8. All it does is hide the (very useful) name of the method being called. I'm forever having to look up the definition of some arcane single method interface to ascertain the method name so I can have a clue as to what the -> operator is doing/calling. :(

Wait what? In context of the typical usage of lambda expressions, the method name does not matter at all. I mean, what difference does it make to you that if it's a Runnable the method is called run(), if it's a Consumer the method is called accept(), and if it's a Function the method is called apply()?

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...

We're going to be agreeing to disagree here. I think there are languages that do what you want: Go seems like a good recent example, but in general terms I find keeping the "reading age" of code low to make comprehension in the large more difficult. Why, for instance, do I keep reading a for loop followed by an if followed by a continue when filter/where exists?

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.

I have to agree with you and couldn't have said it any better. Wholeheartedly agree with the "increasingly terse" comment.

I think you can let your fears go :) See - science is more and more complicated every decade. It's much more difficult to learn math completely today than in middle ages. But we are not buried under all of these new researches.

Reply on news.ycombinator.com