[ezy]

This is, of course, an argument against a strawman. I wish the author had not mentioned certain folks by name, because the analysis is interesting on its own, and makes some good points about apparent simplicity. However, by mentioning a specific person, and then restating that person's opinion poorly, it does a disservice to the material, and basically it just devolves the whole thing.

My understanding of Jon Blow's argument is not that he is against certain classes of "safe" languages, or even formal verification. It is that software, self-evidently, does not work well -- or at least not as well as it should. And a big reason for that is indeed layers of unnecessary complexity that allow people to pretend they are being thoughtful, but serve no useful purpose in the end. The meta-reason being that there is a distinct lack of care in the industry -- that the kind of meticulousness one would associate with something like formal verification (or more visibly, UI design and performance) isn't present in most software. It is, in fact, this kind of care and dedication that he is arguing for.

His language is an attempt to express that. That said, I'm not so sure it will be successful at it. I have some reservations that are sort of similar to the authors of this piece -- but I do appreciate how it makes an attempt, and I think is successful in certain parts, that I hope others borrow from (and I think some already have).

[benreesman]

I endorse your much more thoughtful and well-argued post than my knee-jerk response down in the gray-colored section below.

John isn’t right about everything: he criticizes LSP in the cited talk, and I think the jury is in that we’re living in a golden age of rich language support (largely thanks to the huge success of VSCode). I think he was wrong on that.

But the guy takes his craft seriously, he demonstrably builds high-quality software that many, many people happily pay money for, and generally knows his stuff.

Even Rust gives up some developer affordances for performance, and while it’s quite fast used properly, there are still places where you want to go to a less-safe language because you’re counting every clock. Rust strikes a good balance, and some of my favorite software is written in it, but C++ isn’t obsolete.

I think Jai is looking like kind of what golang is advertised as: a modern C benefitting from decades of both experience and a new hardware landscape. I have no idea if it’s going to work out, but it bothers me when people dismiss ambitious projects from what sounds like a fairly uninformed perspective.

HN can’t make up its mind right now: is the hero the founder of the big YC-funded company that cuts some corners? Is it the lone contrarian self-funding ambitious software long after he didn’t need to work anymore?

[mrtranscendence]

> But the guy takes his craft seriously, he demonstrably builds high-quality software that many, many people happily pay money for, and generally knows his stuff.

He has made a few good games, but how has he done anything that would paint him as a competent language designer? Frankly, Blow has done very little (up to and including being a non-asshole) that would make me terribly interested in what he's up to.

[avgcorrection]

With regards to language design, Blow is a guy with a series of YouTube videos.

The common thing in PL is to publish something written or code. So don’t be surprised when some people don’t feel like they have the time to go through an unconventional format.

[tialaramex]

> [...] counting every clock. Rust strikes a good balance, and some of my favorite software is written in it, but C++ isn’t obsolete.

This isn't a good argument for C++. If you can't get where you need to go in Rust because you are "counting every clock" you need to go down, which means writing assembler -- not sideways to C++. Once you're counting every clock, none of the high level languages can help you, because you're at the mercy of their compiler's internal representation of your program and their optimisers. If you care whether we use CPU instruction A or CPU instruction B, you need the assembler, which likewise cares, and not a high level language.

Both C++ and Rust provide inline assembler if that's what you resort to.

There are things to like about C++ but "counting every clock" isn't one of them.

[mrtranscendence]

I don't think it's as much of a strawman as you're making it out to be. In his talk, Blow says that higher-level abstractions haven't made programmers more productive than they used to be, and appears to use this as an argument against abstraction. He doesn't say (as far as I recall) that we shouldn't use something like formal verification, but he does put the blame for bad software at the feet of abstraction rather than "unnecessary complexity". Or at least if that were his point he wasn't particularly clear about it.

[yakubin]

Particularly since the article spends such a big chunk of its text talking about bounds-checks and criticising Blow for being against them, when in fact in his language Jai, as far as I know, bounds-checks are enabled by default, although you can disable them selectively when they are e.g. in hot loops. So it's not any different than say Rust in this regard. It's the strawman of strawmen.

[anothernewdude]

If it had been anyone else I'd agree. But Blow is very much the strawman depicted.

[arexxbifs]

Blow's talk does raise a few valid questions but is so full of factually incorrect statements, cherry picking and contradictions[0] I'm surprised anyone can take it seriously.

It's also very hard, for me at least, to interpret the sum of his arguments in the talk as anything except "If you're not managing memory, you're not a real programmer."

[0] https://datagubbe.se/endofciv/