dmpk2k

It's a JIT nowadays. Admittedly an extremely simple one, to minimize compile times and maintenance overhead.

You can get substantial performance improvements by using guards though. See what Wings3D does with is_float() everywhere in hot numeric-heavy code.

Maybe it's just a regional thing, but it's showing 78 euros for the paperback for me. Plus I bought the paperback recently at that price too.

You can get it direct from Elsevier for ~78 euros: https://shop.elsevier.com/books/risc-v-system-on-chip-design...

You're right, and yet it's also true that existing institutions have ossified. There is immense inertia.

You're right that a lot of material really does require a physical book. Anything even remotely technical.

That said, I would argue that a voice actor is far more significant than page formatting when it comes to novels. A good voice actor can turn a good story great, and sometimes a poor story to... acceptable.

I've read thousands of novels over the decades, both with and without audio, so I'm reasonably confident about the above.

The same Oman Trump was recently threatening to blow up? Heh.

It's weird for physicists to complain about nuclear weapons. They did it. Own it.

For all its faults, you won’t get a rug-pull like this with OSS CAD Suite and something like the ECP5, especially as a hobbyist.

Embedded developers often suffer under archaic toolchains. There's plenty of reasons for that, but one of them is UB: a newer version of the compiler can completely change an embedded program's behaviour.

I find your emotional language truly quite fascinating. I've heard people talk like that about drugs.

While true (beyond 30-50km/h), that assumes that cars are driving at a steady state. Obviously, cities with much more stop-and-go require more revving of engines.

Acoustic tyres are also gradually becoming the norm, primarily with EVs. This cuts noise by several decibels.

So it's not an unreasonable claim per se.

Huh, you're right.

Apparently it's still considered experimental (even though Google uses it in production) so it's not in the User Manual. There's this: https://github.com/sbcl/sbcl/blob/master/doc/internals-notes...

Vaguely related, but have you tried Alive? https://marketplace.visualstudio.com/items?itemName=rheller....

There's essentially no reason to prefer the aligned load/store commands over the unaligned ones - if the actual pointer is unaligned it will function correctly at half the throughput

Getting a fault instead of half the performance is actually a really good reason to prefer aligned load/store. To be fair, you're talking about a compiler here, but I never understood why people use the unaligned intrinsics...

The only decent Prolog book out there, IMNSHO, is "Clause and Effect" by Clocksin. Maybe some of the later chapters might help?

All the other books that I looked at were pretty awful, including the usual recommendations.

wistia.com

You're probably aware of it, but if not: Uiua is much easier to understand in this regard.

They added arenas to SBCL recently. SBCL has a moving GC, and the Common Lisp spec was finalized in the 1990s.

Okay, this is just Lisp being Lisp, but it's still an example...

I suppose there are worse things than my scribblings sounding like a late-night kitchen gizmo ad. :)

Similar with Babylon 5, although the CG has not aged as well.

That is how attrition war works. Until it doesn’t.

Some people don't, evidently. Other people do.

I like how this can be interpreted two ways, depending on whether you place loved ones above governance, or vice versa.

Pikuma.com has a good one.

Both can be true: over-regulation and bad regulation. And the West (especially the EU) is arguably suffering from both to various degrees.

At some point a regulation is no longer worth the weight in the overhead it imposes. Even if all regulation was effective, at some point the collective burden would be too high.

Sadly, this also means that some bad behaviour is inescapable at the margins. There are always a few people looking for an angle to make a quick buck in a certain way, yet not enough for a regulation to be supported.

Doing is a far better way to learn than just reading.

Could you elaborate on the model checking? You have two codebases then (model and C), or something more integrated?

It is slower, but a big cause of the slowness is a lot of copying (immutable data structures and separate heaps for every process). Nowadays the BEAM has a JIT.

If you use type guards correctly the performance can be surprisingly good. Not C/C++/Rust/Go/Java good, but not too far off either. This is definitely a corner-case though.

Crappy GC for most of them, but... fair point.

Maybe it's post-hoc?

I wanted to use OCaml since 2002, since it was a GC'd language with good performance, achieving a lot with relatively few lines of code. Being a language nerd, I was (am?) positively inclined to the language. Yet there was always something that made it notably less pleasant to solve my current problem in than in than some other language.

If it had trouble getting traction with me, that's bad news.

Meanwhile the mainstream has progressed a lot since 2000. GC is the standard, closures are normal, pattern matching and destructuring are increasingly so. While HM-style type inference is not mainstream, local type inference is (and I'm no longer convinced that global type inference is the way). Algebraic data types aren't unusual anymore.

A few years back I just threw in the towel and went with Rust; this happened after I volunteered to improve OCaml's gdb support (including DWARF hell), which went nowhere. I wish Rust compiled faster, and a GC'd language is usually more productive for my problems, but in every other regard it stole what should have been OCaml's thunder. And when popular successor languages eventually appear, they'll do it even better.

Alleged? Come now.

Beginners face the following problems: there's multiple standard libraries, many documents are barely more than type signatures, and data structures aren't printable by default. Experts also face the problem of a very tiny library ecosystem, and tooling that's often a decade behind more mainstream languages (proper gdb support when?). OCaml added multicore support recently, but now there is the whole Eio/Lwt/Async thing.

I used to be a language nerd long ago. Many a fine hour spent on LtU. But ultimately, the ecosystem's size dwarfs the importance of the language itself. I'm sympathetic, since I'm a Common Lisp man, but I don't kid myself either: Common Lisp isn't (e.g.) Rust. I like hacking with a relic of the past, and that's okay too.