[gumby]

It’s simply a reflection of the immaturity and terribleness of the state of the art in programming languages.

People eventually got around to things like restricting bytes to be eight bits, using a standard character set, and so on. Eventually we will find some language factors that “stick” (e.g. abandon the stupid distinction between statements and expressions) which will become baseline and the space of variation will diminish.

[pdimitar]

Yeah, your comment is likely the answer. I am just bitter why is all that happening so darned slow. I really hoped that 22 years in my career I would've seen certain problems disappear forever (as in, be solved, formalized, nailed, and never ever discussed again). But alas, nope.

[tubthumper8]

Would you not consider "null" to be a problem that has been solved? That's the most obvious example to me, it's a problem that used to be extremely prevalent but is now a completely solved problem.

I'm not saying that every existing language has solved it, I mean that it's been shown by modern non-research languages (ex. Rust) that the problem need not exist. Something to be excited about, not bitter

[pdimitar]

Oh I do like that for sure, but as you said it's a solved problem in very few languages.

But in general, very few such unquestionably good practices are adopted.

[tubthumper8]

> but as you said it's a solved problem in very few languages.

That's not what I said. What I said was "I'm not saying that every existing language has solved it". TypeScript, C#, Kotlin, Dart are all examples of popular languages that have solved this problem.

Another problem that's currently being solved is the inability to do basic data modeling. In particular, the inability to say "it's A or B". That has been solved in some languages for a long time but is now solved in a number of popular languages too.

There really have been quite a number of advancements in the last 22 years, but sometimes it feels like it's just the bare minimum (ex. being able to do basic data modeling, not having everything be surprise null, etc.). It does seem like it takes a long time for good ideas to propagate into the languages that most people are using. The field is young and it's going to take time for things to mature.

The next big thing is going to be effect/capability systems (tracking which functions do I/O, access the filesystem, etc.). That might take another 22 years to go mainstream, but that doesn't mean progress isn't being made, it just means that we need more new languages that try new things, evaluate new concepts, and establish techniques to be adopted by other languages.

[Nevermark]

Yes, “solved” can mean multiple things.

1. We have a describable or demonstrable solution Y for problem X.

2. We have a language that uses Y to solve X.

3. We have several languages that use Y to solve X.

4. Most languages use Y to solve X, and popular languages that don’t are anticipated to do so soon so they can.

5. Any sensible language uses Y to solve X.

> I really hoped that 22 years in my career I would've seen certain problems disappear forever (as in, be solved, formalized, nailed, and never ever discussed again). But alas, nope.

I interpret this comment as referring to “solved number 5”.

And I also find it disheartening that that level of solution, for well known problems, seems so rare.

[pdimitar]

> I interpret this comment as referring to “solved number 5”.

Yep, that's what I meant, thank you.

It breaks my heart seeing e.g. Python and JS still being the same terrible monstrosities that they always were, and what's even worse is all the post-hoc rationalization that people do to justify their favorite language. Instead of, you know, just say "yeah it's bad that we don't have that, choose another language if it bothers you" but no, it has to be BS like "almost everyone uses Python, have you considered that you might be wrong?". The good old appeal to popularity and tradition, and one of the well-documented logical fallacies that's being done every day and every hour. But hey, who's counting, right.

I wish that our work area -- the programming -- had more balls. More courage. "Alright guys, sum types are unequivocally better than having NULL, let's start changing our language" probably followed by an announcement "Sorry we couldn't fit sum types in Python, we're forking the language with a small list of incompatibilities and a tool to rewrite your old Python to the new one, please migrate". Or something along the lines.

But no, of course not. Let's pretend everything is okay. :/

[gumby]

the idea that a byte was 8 bits and not some dynamic length bitstream took at least 20 years, so don't get too excited.

So many ideas from Lisp have slowly become mainstream (lambdas, closures, GC, interpreters with dynamic typing, languages both interpreted and compiled...) that I feel like any convergence is far off.

[medo-bear]

repl based development, or until people see how cool structural editing really is

[gumby]

Agree on the REPL and exploratory programming!

But can’t agree on the structured editing side.

I used to do use structured editing (D-Edit on the Interlisp-D machines) and found it annoying, but perhaps that was due to the mandatory mouse use. The structured editing built into emacs is pretty good mainly because it’s an option you can use at any time rather than a single paradigm.

Also the only way to use comments in a structure-based system is to extend the syntax of the language, and that is awful IMHO.

[medo-bear]

I use the paredit emacs package (not a builtin). The issues you mention are not present.