I don't know about the "stuff Haskell people get excited about", but IMHO, Haskell is a mathematician's language and the language of mathematics isn't a natural language. Dijkstra himself was also a mathematician, and his positions regarding programming languages features like 1-based indexing [1] are already conflicting with practice, the famous case being Lua which receives mixed opinions about it. I find for instance 1-based indexing more "natural", and that's coming from someone whose second and third languages are assembly and C (the first being... Basic).

Yet the point about DSL is interesting, in particular internal/embedded DSLs [2]. I lied a little earlier, my third programming language was actually Forth. His creator said in 2001, "When you devised an application you wrote a hundred words [i.e. functions] or so that discussed the application and you used those hundred words to write a one line definition to solve the application" [3].

I've been trying to do that exactly that in other languages, make it so that the code expresses "naturally" what it does as much as possible. When you succeed, people call your code "beautiful" or "elegant" (nobody ever told me that :-) which, I think, subsumes "naturality".

This is of course harder to do in low-level languages such as the ones I mentioned (except Basic maybe) because you get caught in details such as memory management. But high-level languages are not exempt of these problems (and contrary to Forth or Lisp, their syntax is often written in stone). Then there's essential complexity [4], which can be "unnatural" no matter what, like thinking about things in a concurrent programming context, with languages that don't natively support it like they support automatic memory management (i.e. garbage collection).

The topic is dangerously close to "readability", which is known to be 80% subjective.

[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...

[2] https://en.wikipedia.org/wiki/Domain-specific_language#Domai...

[3] https://www.ultratechnology.com/1xforth.htm

[4] https://en.wikipedia.org/wiki/No_Silver_Bullet

Dijkstra's personal language design (GCL) actually used anything-based indexing -- you specify the lower bound explicitly when you declare the array, so even if indexing starting from some runtime value k (e.g. k=7, k=b.lower-bound for some existing array b, etc.) is most natural, you provide that as the lower bound. Then a(i) would be translated to e.g. a[i-k] in compilation.

The same method is used to block sites that don't respect the decisions the French people have made regarding the limits of the freedom of speech (no hate speech, no terrorist proselytism, no pedo, etc.).

Granted, that's the theory.

When the demands come from a company on the basis of copyright/intellectual property (that is, exclusive broadcasting rights), one can feel less comfortable about this affair; even thought the judgement mentions that the case is backed by the ARCOM, the french authority for broadcasting, which should instead IMHO deal with a couple or two of private TV channels that are obvious vectors of fake news.

But, this is the same copyright that can protect you when you publish programs, source code, images, etc., even when you use a free and open license; the licence has meaning thanks to the copyright.

You raise good, classic points when defending copyright. I would argue that your first examples are for the good of society, and the individual copyright protections are for the good of small creators.

Copyright enforced at this scale, for the profit of a corporation that streams their content off the infrastructure paid for by the public, does make one less comfortable.

And exclusive broadcasting rights… why is that a thing and conflated with copyright regulations? Why would the public regulator charge, say, 1M€ for the steaming right to something that will net 20M€ in advertising? That’s not really about copyright, I’d argue that it’s actually the job of the public channels to stream this content that takes place on stadiums built with public funds, streamed via a largely public TV system, etc.

I suppose the work against sports piracy is profitable enough to continue. Canal+ makes quite a lot of money, and their subscription in France is pricey compared to most other services.

They could, for starters, split the sports bundle and lower its price. Lots of people would probably pay a little bit to watch sports in 4K, instead of hunting for shady streaming websites that do 720p at best.

It's funny to see LLMs being mentioned, because this is yet another case where "good enough" is, after all, not good enough once you know how "good enough" should be.

Including development of AI models?

Possibly. But even if not, how many AI model developers do we need? We will likely need a nonzero number, but it could be very few compared to the total number of software developers we have today.

Called "recursive self-improvement"

AIs cannot invent things like cubism, surrealism or hip-hop.

Or maybe it can; the early image generators famously did output horrific images sometimes because of their limitations, but these outputs qualify nonetheless creations.

Now the interesting thing is that it is humans who evaluate them as horrific, worthless or interesting.

Certainly AIs could pretend they have that sort of opinions and judgement, but hopefully humans will remain more interested in the opinions of other humans.

> Certainly AIs could pretend they have that sort of opinions and judgement, but hopefully humans will remain more interested in the opinions of other humans.

Online, how would they even know? Offline -- either we give up on the internet, or the offline discussion will be heavily influenced by what AI said online.

Amusingly, LLMs are good at detecting patterns because they are modelled after the human brain, which is very good at detecting patterns (this e.g. is annoying when you are a game developer who wants to reuse assets). People are still able to tell if the source of an artwork (or text) because LLMs tend to output "patterned" text (like the famous "load bearing"). That being said, the false positive/negative rate of humans for this task has yet to be measured.

I think the answer is that they don't, indeed, need source control but just a way to let their agents resolve editing conflicts. It's basically yet another message board.

I don't disagree, but having remote monitoring capabilities on a professional fridge is most likely not a hipster feature. Even mid-size supermarkets have dozens of them, with different temperature settings; they can fail, customers can block the doors, etc. You do want to receive an alert when something is wrong.

Those devices should be connected to air-gapped local network and not to manufacturer.

You don't seem to understand what these systems do at all. Air gapped takes about 80% of the usefulness away.

GP might realize sooner or later that they need larger security margins, for when unexpected things happen; like really having to go to the toilets, spilling the coffee they just made, etc.

They can shift their daily schedule e.g. 30 minutes earlier and peacefully drink their coffee at home. They also should eat something at home or on their way, because hurrying in a cold morning with an empty stomach is not good. Source: personal experience. I did that for months as a student until I passed out one day in class.

If they don't like waiting for the train in the cold, they probably can find a warm place near the station, and wait there a little.

Or: Maybe they should live their life in the manner that bets suits them.

Is that really that much of a big deal, though? Before stdint, if one needed that level of accuracy, one would do your own equivalent of stdinit by hand, and adjust those definitions when porting to another compiler/platform. The same goes for your local boolean type.

I think the only real annoyance is that each programmer/team did it with their own convention (I32, INT32, i32, int32, WORD, Word bool, BOOL, Bool, etc., etc.); standardizing helps with putting everyone on the same page more than it helps porting. It doesn't prevent people from reverse-typedef-ing standard names to local "dialectal" names, though.

But I also think that one should only rarely use raw integer types, in an ideal world; the elephant in the room is that typedef is kind of the second "billion dollars mistake" [1]. C is a weakly typed language and there's no practical way to undo it (besides transpilation), so there's double no point to leave behind raw types.

[1] For those not too familiar with C, typedef defines a "type alias", not a type: https://en.cppreference.com/cpp/language/typedef

The deal was dealing with #ifdef spaghetti to define all of those, especially when mixing libraries across platforms.

Ifdef soup is still horrible, so those times (which I didn't experience firsthand) must have been abysmal.

If you want to know how bad it can be, only need to take a look at GCC's implementation of `stddef.h` for `size_t` and `ptrdiff_t` etc.

https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/s...

There's a simpler way to define these types in newer versions of C which have `typeof`, we can take advantage of the fact that `sizeof()` always returns a `size_t`, `ptr - ptr` always returns a `ptrdiff_t`, and a literal L'c' has type `wchar_t`, etc.

    typedef typeof(sizeof(0)) size_t;
    typedef typeof(nullptr) nullptr_t;
    typedef typeof((void*)0-(void*)0) ptrdiff_t;
    typedef typeof(L'\0') wchar_t;
    typedef typeof(u8'\0') char8_t;
    typedef typeof(u'\0') char16_t;
    typedef typeof(U'\0') char32_t;

Don't need ifdef soup to test what the sizes of things are on different architectures - we just utilize the compiler's implementation of those types.

Assuming that you don't need to target older compilers without C23 support, or where that isn't available as language extension.

Traditionally your compiler supported one type of computer and just defined them to what they were on that computer.

I've always believed that they kept 32 bits ints on 64 bits CPU as a default because going full 64 bits would make the code and data structures bigger for "no reason" (it's not often that one hits the 4.10^9 limit in system code (if you don't count timestamps, that is)). For instance, a load-register-with-immediate instruction would normally take 5 bytes (opcode+value) on 32 bits, but 9 bytes on 64.

> would make... data structures bigger for "no reason"

This was the main reason that in stayed 32 bits. Not because larger footprint of structs would be catastrophic — it wouldn't: the 64-bit migration was motivated mainly by the fact that the 32-bit architectures couldn't easily address all that actually existing physical memory past 4 GiB (and virtual memory as well) — but because lots and I mean lots of on-disk data structures were defined in terms of char/short/int, people routinely dumped/gulped their data structures as-is, with no marshalling, so changing the size of int would break literally everything that worked with on-disk data, starting with the filesystem implementations themselves.

I think backward compatibility was the main aim. Intel tried redesigning the architecture as 64-bit native (Itanium), but AMD done a better job at backward compatibility - and intel eventually adopted it as x86-64.

The amd64 design could run most 32-bit code with minimal changes. All the 32-bit instructions had the same encoding, besides push/pop which instead acted on 64-bits. The 64-bit instructions were basically opt-in, though a few opcodes (0x40..0x4F) had to be deprecated for the REX prefix.