[pdimitar]

Programming languages do matter but not as much as many people think f.ex. the HN crowd has a soft spot for LISP, and most of the don't even have proper parallel execution (and no I am not talking OS threads, having direct access to those should honestly be removed at one point). And sure, Racket and a few others are "Working on having an actor model". Wake me up when they achieve it. I am betting on somewhere in the 2030s, best case scenario.

A combination of a good and restrictive language compiler (Rust, OCaml, Haskell) and an amazing runtime (Erlang) is the sweet spot that everyone should be aiming at.

If anything, I am very tired of seeing yet another LISP dialect -- or any other language really, come to think of it now -- being announced. Many of us the programmers love to play and going to check on these languages is IMO taking away precious mind-share.

If anything, in my eyes it's exactly because programming languages matter is the reason why we should have less of them. We should start folding some languages inside others. (Or abandon them.)

[Chris_Newton]

If anything, in my eyes it's exactly because programming languages matter is the reason why we should have less of them. We should start folding some languages inside others. (Or abandon them.)

As a counterpoint, the programming industry is vast, so the opportunity cost of using tools that are not as good as they could be is also very high. If we don’t continue to explore new possibilities, how will we make those tools better? How can we learn what is worth keeping, what to combine, what to abandon?

I believe there is huge potential in finding better programming languages and better programming models for them to describe. We are still at the stage where we are worrying about whether our programs are even behaving correctly. Sometimes we get as far as worrying about performance. There is a lot of talk about productivity but it is relatively rare that we consider language design as a way of expressing our ideas more efficiently or making it easier for someone else to understand them later.

If we look at languages like Haskell or Erlang or Rust, these have certainly been used professionally, but in the long term their most important contribution might be the ideas they introduced to wider audiences rather than anything written in those languages themselves.

[pdimitar]

As a counter-counter point, I hear your sentiment a lot, I work for 22 years in the profession now -- and I am a fairly average programmer so I don't claim any credentials or anything.

...And I've never seen your sentiment work. Nobody is really learning anything, people just want to tinker with stuff and never read history or even best practices. All I see are people going in circles forever.

Maybe there's a smaller percentage of much clever programmers out there. I wouldn't know because I never (so far) attempted to do anything beyond web apps (though I do regret that a lot and might yet change it). And maybe these people are truly evolving the art. I mean we have Golang, Rust, WASM, and others so I know these people exist.

But somehow that almost never penetrates the broader programming community. Maybe Rust is the only true example because people started wanting to have sum types in their day-job languages -- which I view as a good thing. Such sentiments have the potential to gain enough critical mass to have language designers reconsider their initial choices (f.ex. Elixir is working on an optional type checker, one that's stricter and more descriptive and correct than the one coming with Erlang).

So I don't know. I wish you are correct but after 22 years in the sidelines the only true improvements I've seen are Elixir / Golang (in terms of transparent parallelism where Elixir wins over Golang but Golang is still much better than almost everything else out there as well) and Rust (for the aforementioned compile-time guarantees and other ones like memory safety).

Outside of that though? Nope. "Hey let's have one more JS framework, we didn't have a new one this month" is something I've seen a lot of, not to mention the eternally growing list LISP interpreters because apparently that's the peak of our collective intelligence and ambition. :(

I just get sad. HN is a place where a supposed intellectual elite gathers but they don't seem to be interested in anything beyond their pet language that will never have even 1% of the goodness that a much-derided language like Golang has. And I view that as a waste of energy and time, and as a very sad thing in general.

[Chris_Newton]

It’s easy to become disheartened, particularly in the world of web development. It looks like we’ve been around the industry for a similar amount of time, and I agree that the amount of wheel-reinventing in web development is shockingly bad for a part of the industry with so many resources poured into it by now. But have faith, my friend! Even in frontend web work, good ideas do break through from time to time. :-)

Not so long ago, there were plenty of FE people who would argue to the end of time that JavaScript was fine and building ever larger frontend applications wouldn’t benefit from static types that just take more work to write. Today, it seems TypeScript has almost entirely displaced JavaScript for that kind of work.

Not so long ago, we were trying to build those web frontends by manually tracking state implicit in HTML form elements and maybe doing a bit of automatic binding. Then React came along, the frontend world finally realised that immediate mode is a thing, and today building web UIs in a more declarative style from some kind of components is common to almost all of the popular libraries and frameworks.

Each of those changes must have saved millions of hours of developer effort already compared to how we did things before, as well as avoiding countless bugs. Now imagine what we could do if, just as a thought experiment, we could all use a language for frontend web work that didn’t have the legacy baggage that TS/JS have, did have a much more comprehensive and well-designed standard library, and provided better control over side effects and by extension safer and more readable code for all the interactions with remote APIs and state management and interactive DOM elements that modern web apps do all the time. I don’t know where such a language might come from today, but if we can shift such a large part of the industry to TypeScript and declarative/component-based rendering within a few years, it doesn’t seem an impossible dream.

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

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

[matheusmoreira]

I made my own lisp because it was the simplest, easiest language to parse and implement. Lisps are essentially frontends for C data structures. I wanted to get some ideas working and that was the easiest way. Still one of the most fulfilling projects I've made.

> We should start folding some languages inside others. (Or abandon them.)

Who's "we" though? No one decides what we work on unless they pay us for that privilege.

[pdimitar]

We who want to achieve stuff, not play all our careers. :/

[matheusmoreira]

What's the difference between play and achievement? Someone running the so called "toy" in the production server?

[pdimitar]

You can put a program with 50 lines and 10 bugs in production. :)

To me "production" also means "runs reliably over long periods of time, does not fall over under load, and has no unexpected panics". Well, and also "makes full use of the available computing resources and prevents lag as much as possible".

"Toy" is basically "I am such a huge fan of LISP, I am convinced that the world absolutely needs one more interpreter!".

[stellalo]

> Programming languages do matter but not as much as many people think f.ex. the HN crowd has a soft spot for LISP, and most of the don't even have proper parallel execution

I don’t understand how the argument about LISP would imply that programming languages matter “not as much as many people think”

[pdimitar]

I mean that people over-fixate on syntax or language quirks, but when you start writing for (and deploying for) production then it turns out that many others things are much more important. And I wish people were more practical in our area and they are often not, they are like kids who only want to play even.

And even though I am eating down votes I will keep saying it: fangirling over LISP I view as a collective drag and to the detriment of the entire programming area.

Obviously I am not a world dictator saying what should people spend their time on. I am saying that if you want to truly move the art forward, well, we have 5000 other problems that are at least 100x more important than "oh look I can code a basic LISP interpreter".

My opinion, obviously, but it's also one that I would not be easily dissuaded from.

[spit2wind]

> I am saying that if you want to truly move the art forward, well, we have 5000 other problems that are at least 100x more important than "oh look I can code a basic LISP interpreter".

How does one "move the art forward" without understanding the landscape first? That is, an individual can't know what "forward" means without understanding where they currently are. There isn't a finite number of people over a fixed period of time doing all this. Just because something "is known" to humanity doesn't mean it's known by every individual presently. Each generation must rediscover what previous generations knew, either through raw insight or by knowledge transfer. People aren't born with computing knowledge :)

Viewed this way, how many people in the world, presently, have sufficient knowledge to "move the art forward"? How many have the means? I'd put it at a few hundred. Maybe you're one of them?

You explicitly say you can't be easily disuaded from your opinion, so maybe I'm just spitting into the wind. However, rather than talk down on people doing the hard work of learning where they're at in history, being excited my genuinely exciting things, and taking the necessary steps to "move the art forward", maybe you could assist them by sharing your experience? Or, simply move the art forward yourself :)

PS: Play is exactly what's needed. That's how humans learn and discover :) But maybe we need to play more efficiently? ;)

[pdimitar]

> How does one "move the art forward" without understanding the landscape first?

Practice data structures, make complex algorithms described in books (most of which are free, and the rest are maximum $35), code a small program for an embedded controller for once to see how the sausage is made first-hand, participate in different kinds of open-source. There are plenty of ways outside of "the world needs one more LISP interpreter".

> Just because something "is known" to humanity doesn't mean it's known by every individual presently.

Sadly. I wish I belonged to another species where this assertion was not true. Sigh.

> Viewed this way, how many people in the world, presently, have sufficient knowledge to "move the art forward"? How many have the means? I'd put it at a few hundred. Maybe you're one of them?

Me? Absolutely not, I am 43 and at this point I am severely burned out. I had so many ideas and ambitions but working for the man for 22 years has crushed me. Maybe if I get a bag of money in the upper 7 digits I'll be able to reignite my tinkering spirit but we don't live in fairly land and this is not happening so nope. You're looking at one more person who was crushed by the free market forces.

That being said, you have people working on e.g. the Rust compiler or OCaml in general. Likely a bunch of geniuses and I love it that they are actually funded and are keeping up the good fight. Gives me some hope.

> maybe you could assist them by sharing your experience?

Yes, that's the best idea really: education. But as we all know (1) younger people never listen to advice, and (2) I probably never found the right audience (though thinking of it I am starting to see some lectures popping up lately in my city again, maybe I should try to go). I've been told I am excellent mentor (as recently as 3 months ago) but my health and time constraints prevent me from doing it more.

But how do you educate people to be unhappy with the status quo? I seriously don't know. The human brain is kind of like this: "Hey I am not hungry, I have where to sleep and most of my basic needs are covered, I guess the world is perfect and I don't need to change anything at all anywhere". Observed it thousands of times in my life and I am bitter about it to this day, likely to my grave.

> But maybe we need to play more efficiently?

Yep, I would not be against some central "authority" website / app that distributes "play" tasks to whoever is willing to do them (obviously with plenty of repetition and redundancy, you can't have 10 people agree to tackle on 10 different tasks and then they never show up again). And this does not remove choice, you can still present people with like 50 choices and they surely will identify with at least one of them.

All this free energy, wasted all the time. [sighs deeply] I wish we had more structure and direction is what I am saying all along.

[PartiallyTyped]

I support abandoning dynamic typing.

[pdimitar]

Same. The dynamic typing helps with prototyping but all MBAs have consistently proven they are NOT willing to have the prototype rewritten in something better later.

[PartiallyTyped]

I found that it is better to ask for forgiveness than permission.

[pdimitar]

Same, by the way. I am ashamed that I didn't do it more often over the course of a 22-year long career. I really should change that.

[8n4vidtmkvmk]

I just launched 2 experiments to production this week without going through the launch approval process. I'm such a rebel.

[Tarq0n]

I don't think static typing is the right way to go for every kind of application (imagine doing data analysis without dynamic typing), but every dynamic programming language should ideally support progressively adding types to a codebase.

[nick_]

Just FYI: Swift has actor model. Pony is built around actor model.

[pdimitar]

Sure. But now we get to the really hairy problem: library coverage and community support. That's why I think most languages should start converging together already.

IMO we the programmers scatter ourselves too much.

[nick_]

On that I totally agree.

[pdimitar]

Then my apologies to you and everyone else who replied to me: I really should have just said "I feel we scatter our attention and energy too much and we don't collectively evolve our craft as much as I believe we are capable of".

[nick_]

No worries! Apologies for being overly curt.

[medo-bear]

> Wake me up when they achieve it. I am betting on somewhere in the 2030s, best case scenario

(slap)

(wake-up sleepy)

common lisp has actors for a while now

[gumby]

Actors were developed in MACLISP, Commonlisp’s parent.

[pdimitar]

Oh? Nice, missed that. Is it on the level of Erlang's VM or at least Go's goroutines?

[dannyobrien]

what would "proper parallel execution" look like in a Lisp? A library or a more fundamental form? Something with the GC?

[samsquire]

There's a language called PARLANSE which is a parallel LISP.

http://www.semdesigns.com/products/parlanse/index.html

[Jtsummers]

Also MultiLisp, QLisp, *Lisp, and others. Parallel lisps are not a new concept, though they were often written with specific machines in mind (*Lisp for instance).

[pdimitar]

It's not about them being a new concept. Do we have Erlang actors or Golang goroutines there? Are they fully safe like Erlang's actors or Rust's futures would be (provided you don't use escape hatches)?

If not, they remain toys.