You can say the same about Python. However, there the forces push in the opposite direction: Even when there are better pythony runtimes that provide almost identical behaviour (but better performance), everybody sticks to CPython.

I tried to use non-CPython just last week for the first time. The first thing I tried to install failed. When I looked up the error… I needed CPython.

In my limited experience, I can only assume people are sticking to CPython because it works. Speed doesn’t mean much if libraries and tools fail to function.

I've seen tons of non-cpython use, so I'm not really sure what claim you're trying to make. Aside from supporting "having a spec allows for many implementations that all work".

Well, the original comment was implying org mode had limited popularity because there is no specification. I'm claiming cpython is way more popular compared to fe pypy because it has no spec. The typical scenario is: people try pypy. it mostly works but because of some weird problem some library is broken and then they give up.

Is the claim that pypy has no spec, but cpython does? By that definition I think either both have a spec (they both use https://docs.python.org/3/reference/index.html and both are just "an implementation") or neither has one (since neither fully specifies all behavior and all modules, which is probably true for ~all languages).

No. The claim is cpython has no spec. The link you posted is about the language. The spec claim is about the behaviour of the runtime.

The underlying claim is hat pypy cannot succeed precisely because there's no clear definition of success/compatibility/compliance. The situation is completely different in the Java world. There there is a specification for the memory model, runtime, aso and you can be sure that when you switch between runtimes, it will just work.

Gotcha. Broadly agreed then (Java is a very good counter-example), though I think pypy might be succeeding quite a bit more than org-mode in terms of users... and org-mode doesn't have a language spec either afaict. It has a fairly good description of the current code's parsing behavior, but the closest I've seen to something rigorous is https://github.com/200ok-ch/org-parser and even that's still unfinished from the readme (and it seems probably abandoned).

I haven't looked into the actual current state of things though, my last check was a couple years ago. I'd be pretty happy if things have changed, I just haven't seen any sign of that.

you can unify database with write-ahead log using a persistent data structure. It also gives you cheap/free snapshots/checkpoints.

but... but... SSD/MVMes are not really block devices. Not wrangling them into a block device interface but using the full set of features can already yield major improvements. Two examples: metadata and indexes need smaller granularities compared to data and an NVMe can do this quite naturally. Another example is that the data can be sent directly from the device to the network, without the CPU being involved.

there's also "remand" or detention before trial. One example where this is common is when there's a flight risk, or a risk the subject will influence the investigation.

> As with most things, don’t be dogmatic.

It depends. If you want to learn faster, you should be dogmatic: "In der Beschränkung zeigt sich erst der Meister." If you want to become a better programmer, please do set extra challenges (fe pure lazy functional progamming only, pure literate programming, ...)

That’s true, I was mostly referring to it in a professional setting, not for educational purposes.

There's special place in hell for the inventor of drive names. IIRC, it's something that was nicked from CP/M.

Tim Patterson certainly copied it from CP/M and may not have been aware of anything predating it, but according to Wikipedia drive letters have quite a long history: https://en.wikipedia.org/wiki/Drive_letter_assignment

what if your IDE can show the type of any expression as a tooltip ? Would you still think the same?

In Haskell, type error messages are always like "types A and B should be equal, but they are not". The problem is that, without type annotations, the compiler cannot know if it is A or B that is wrong, which can result in confusing error messages.

For example, suppose that you have a bug in the body of a function, but did not provide a type annotation for it. The function might still compile but not with the type you want. The compiler will only notice something is amiss when you try to call the function and it turns out that the function's inferred type doesn't fit the call site.

Basically, global type inference in the absence of type annotations means that changes in one part of the file can affect inferred types very far away. In practice it's best to use type annotations to limit inference to small sections, so that type errors are reported close to what caused them.

Since Haskell is statically compiled, wouldn't it not compile at all?

That's all happening at compile time. I only meant to say that the function's inferred type isn't what you'd expect.

Yes absolutely. OCaml's VSCode extension is very good at that so that's the only way I've experienced it.

The problems are:

1. Type errors become much less localised and much harder to understand. Instead of "the function you're editing is supposed to return a string but it doesn't" you get "this other function three stack frames away that indirectly calls the function you're editing can't pass some value into println".

2. The inferred types are as generic as possible, which also means they are as hard to understand as possible.

I can't speak for the parent poster, but for global function declarations, yes, absolutely.

It's infuriating when a type error can "jump" across global functions just because you weren't clear about what types those functions should have had, even if those types are very abstract. So early adopters learned to sprinkle in type annotations at certain points until they discovered that the top-level was a good place. In OCaml this pain is somewhat lessened when you use module interface files, but without that... it's pain.

Ocaml has a garbage collector. It's less of a struggle than Rust.

I became a runner by elimination: I needed to do something for "cardiac hygiene". Swimming has a setup cost (you need to go to a pool). Cycling takes too long, so running it became. I run 40-50km/week, and honestly I do not like it. Anyway, I do enjoy the mental health side effects too.

what about a "Failed Concepts" course? Things that seemed like a good idea, but ultimately don't work. (fe, ORMs come to mind)