GrumpySloth

Maybe I don’t understand what those headers in newspapers mean then.

The Go compiler being written from scratch based on the Plan9 C compiler is a huge advantage.

Previously, not originally. In ancient Greece it was a state matter: <https://en.wikipedia.org/wiki/Marriage_in_ancient_Greece>

But let’s now take something that is actually widespread: angular degrees. Before high school, I used only degrees at school and everywhere else. In high school I was taught about radians. Radians are a lot less used by random people than degrees. But since I learned them, as I later went through uni, then job etc, I’ve completely stopped thinking in degrees and use only radians, both professionally and in everyday life. That’s because their benefits justify the switch. So even when something is actually widespread, we can still find good reasons to switch to something that provides material benefits. I claim that the notation of array languages is beneficial enough (at least in the case of BQN).

As for Lisp:

1) Most languages offer a hash table as the default associative data structure. In Lisp culture alists are the default. Books about lisp also focus pn data structures built out of cons cells disproportionally more than any other data structures.

2) They do. But then you read actual programs available on the web and they still default to using alists. There is an impedance mismatch, if you’re more array/stack/hashtable-minded, which isn’t there in most mainstream languages. FTR I’m a big fan of SML too, but even in SML using the best data structures is very much going against the grain, when the language tries to steer you so much towards linked lists and away from arrays. I swear my SML programs look nothing like the things I find on GitHub.

It demonstrates that your criticism of the syntax of array languages boils down to “it’s different than the things I already know” and that not using words in a programming language isn’t a meaningful barrier to most people, given that most programmers in the world overcame this obstacle with no sweat. There is a meaningful criticism to be had in the area of syntax, but this is not it IMO. One valid criticism I know of is that most array languages have a context-sensitive syntax: you need to maintain a symbol table in your head to know how to parenthesise a line of code. Fortunately, BQN fixes this issue by using a context-free grammar.

Lisp is defined by much more than syntax. I certainly see many flaws in it (starting with the cons cell), which are total deal-breakers for me and have nothing to do with syntax. I think your view that syntax is the biggest obstacle to Lisp’s popularity isn’t as evident as you claim. There are too many other, IMO bigger obstacles.

I think this assumption is wrong. Journalists are known to try to get the most shocking photos and reports. I would expect their rates of injury compared to random Joes in similar situations to be similar to that of people doing extreme sports compared to people doing recreational sports.

When I was learning programming back then, those keywords could just as well have been single letters. It wouldn’t have made a difference.

Also, I went up to my printer and there is no “WTF” there. Surely, this program doesn’t work! More seriously, this just illustrates that convention and idioms are much more powerful carriers of meaning than dictionary words. Array languages rely heavily on conventions/idioms.

FWIW you can enable bounds checks for the bracket operator by default for STL types in GCC and Clang. So for interfacing with Rust it is both obvious how to translate between slices in Rust and std::span in C++, and you can verify to a degree that this std::span isn’t corrupted on C++ side (to a degree).

C++ already has a slice type. It’s called std::span<T>. Porting it to C would probably require something similar to atomics. At which point I guess you may just as well get on with it and switch to C++.

In Rust on the other hand, even though ref cells are a thing as well, the main approach to mutation is through mutable bindings and mutable references, which preserve const-correctness (inspired by C++), i.e. there is a certain degree of transitivity in the guarantees around immutability. When I see an immutable reference in Rust and pass it to a function (or a method), then, outside of few special cases, I can reasonably expect it to stay unmodified. In ML I can’t, unless the code is written in a very unoptimal way, i.e. with persistent data structures anywhere and everywhere, and still the type system won’t give me any hints about that.

[1]: The CVE database has to have the worst search out of all bug trackers I’ve ever used.

(I think using older versions of Windows is fine. But under no circumstances would I connect them to the internet.)

Outside of Asia, which is more rice-based than potato-based, potatoes have a hard-earned centuries-old reputation of food for poor people (cheap to farm, not much nutritional value). But even after checking the prices in Japan, tomatoes are several times more expensive.

Maybe you’re not looking at the price per kilogram, but price of package for packaged vegetables?