You have to be explicit about which module you’re using at all times, even though 99% of the time only one could apply. When the type class resolution is unique, but complicated, there’s no mental overhead for the Haskell programmer but getting all the right modules is a lot of overhead for the OCaml programmer. It also lets us write functions that are polymorphic under a class constraint. In OCaml you have to explicitly take a module argument to do this. If you want to start composing such functions, it gets tedious extremely fast.

And then even once you’re using a module, you can’t overload a function name. See: + vs +.. Basically modules and type classes solve different problems. You can do some things with modules that you cannot ergonomically do with type classes, for example. create a bit-set representation of sets of integers, and a balanced search tree for sets of other types, and expose that interface uniformly from the same module functor. But Haskell has other ways to achieve that same functionality and more.

OCaml’s type system cannot replicate the things you can do with Haskell’s higher kinded types, type families, or data kinds at all (except for a fraction of Haskell’s GADTs).

Largely reasonable?

Haskell is not good for systems programming which sums up about 60-70% of that post. Laziness is lovely in theory but many industry uses of Haskell use stricthaskell for all or most of their code, so I certainly agree with that part too.

Their largest complaint about using Haskell for small non-systems programs seems to be the mental overhead induced by laziness. But for me, for small programs where performance isn’t a huge concern (think Advent of code or a script for daily life) laziness reduces my mental overhead. I think that author is just especially concerned about having a deep understanding of their programs’ performance because of their systems background. I worry about performance when it becomes relevant. Debugging Haskell performance issues is certainly harder than strict languages but still totally doable.

The lack of type classes or other form of ergonomic overloading in OCaml is easily the single “feature” most responsible for the language never taking off.

As a Haskell programmer, “OCaml has the nicest type features” hurts just a little bit.

I sometimes teach a course in OCaml. The students who are very engaged inevitably ask me about Haskell, I encourage them to try it, and then they spend the rest of the semester wondering why the course is taught in OCaml. Bizarre how different that is from when colleagues in industry want to try Haskell.

Is Printf.printf not a good generic print function? It’s even variadic!

Yeah, I like subleq.

• compiler is extremely fast, faster even than tinycc
• strongly statically typed: all values are ints. Since it’s all of them, you don’t even need to write it!
• memory safe: the entire (virtual) address space is guaranteed to be accessible at all times so there’s no way to leak any of it (can’t release it anyway) or to segfault (it’s all accessible).

Subleq is the obvious winner in my mind.

There is no official definition, in part because there isn’t any formal way to define the term that satisfies our intuition.

Most treatments will handle “transpiling” as a special case of “compiling” and some will even handle decompilation as a special case where the object language is higher level than the source. Of course, even defining “higher level” can be quite hard.

Plenty of languages “compile to C” and I see no issue with saying something “compiles to js,” especially given that js mostly lacks features of purescript rather than the other way around.

“Monadic type” has something like three meanings depending on context, and it’s not clear which one you mean. One of them is common in math, but not so common in programming, so probably not that. But neither “parametric types with a single argument” nor “types that encode a category-theoretic monad” have the property you say, as far as I know.

I imagine you’re probably referring to the latter, since the optional monad exists. That’s very different from returning null. The inhabitants of Integer in Java, for example, are the boxed machine ints and null. The inhabitants of Optional[Integer] (it won’t let me use angle brackets here) are Optional.of(i) for each machine int i, Optional.empty(), and null.

Optional.empty() is not null and should not be called a “Null object.” It’s also not of type Integer, so you’re not even allowed to return it unless the function type explicitly says so. Writing such function types is pretty uncommon to do in java programs but it’s more normal in kotlin. In languages like Haskell, which don’t have null at all, this is idiomatic.

I’m a computer scientist mainly but with a heavy focus/interest in computer architecture. My plan is to teach at a university at this point - but it seems to me like that would be a good place to create completely open standards technology from.^1Specifically because if the point isn’t to make money, there’s no reason to create walled gardens.

There’s certainly enough interest from people who want to be able to build their own systems. What would actually worry me isn’t the ability to make a new open standard or any of that. It’s that AMD64 is very hard to compete with in this space, because the processors are just faster, and there is so much x86 software that people who build PCs usually want access to.

AMD64’s performance is the result of years and years of optimizations and patenting new hardware techniques, followed by aggressively litigating people trying to compete. ARM performance is catching up but ARM prefers licensing their core IP over making their own systems, making it harder for them to break into the PC space even if they want to.

A new player would be in for a long, long time of unprofitable work just to compete with AMD64 - which most people are still happy with anyway.

^1 some others and I are actually working on some new ISA / open soft processors for it. However it is focused at an educational setting and unlikely to ever be used outside of embedded devices at most.

Neither spectre nor meltdown are specific to Intel. They may have been discovered on Intel hardware but the same attacks work against any system with branch prediction or load speculation. The security flaw is inherent to those techniques. We can mitigate them with better address space separation and address layout randomization. That is, we can prevent one process from reading another process’s data (which was possible with the original attacks), but we can’t guarantee a way to prevent malicious browser tab from reading data from a different tab (for example), even if they are both sandboxed. We also have some pretty cool ways to detect it using on-chip neural networks, which is a very fancy mitigation. Once it’s detected, a countermeasure can start screwing with the side channel to prevent leakage at a temporary performance cost.

Also, disabling hyper threading won’t cut your performance in half. If the programs that are running can keep the processor backend saturated, it wouldn’t make any noticeable difference. Most programs can only maintain about 70-80% saturation, and hyper threading fills in the gaps. However the result is that intensive, inherently parallelizable programs are actually penalized by hyper threading, which is why you occasionally see advice to disable it from people who are trying to squeeze performance out of gaming systems. For someone maintaining a server with critically sensitive data, that was probably good advice. For your home PC, which is low risk… you’re probably not worried about exposure in the first place. If you have a Linux computer you can probably even disable the default mitigations if you wanted.

These would be performance regressions, not correctness errors. Specifically, some false dependencies between instructions. The result of that is that some instructions which could be executed immediately may instead have to wait for a previous instruction to finish, even though they don’t actually need its result. In the worst case, this can be really bad for performance, but it doesn’t look like the affected instructions are too likely to be bottlenecks. I could definitely be wrong though; I’d want to see some actual data.

The pentium fdiv bug, on the other hand, was a correctness bug and was a catastrophic problem for some workloads.

I think the mitigations are acceptable, but for people who don’t want to worry about that, yes, it could put them off choosing AMD.

To reiterate what Tavis Ormandy (who found the bug) and other hardware engineers/enthusiasts say, getting these things right is very hard. Modern CPUs apply tons of tricks and techniques to go fast, and some of them are so beneficial that we accept that they lead to security risks (see Spectre and Hertzbleed for example). We can fully disable those features if needed, but the performance cost can be extreme. In this case, the cost is not so huge.

Plus, even if someone were to attack your home computer specifically, they’d have to know how to interpret the garbage data that they are reading. Sure, there might be an encryption key in there, but they’d have to know where (and when) to look*. Indeed, mitigations for attacks like spectre and hertzbleed typically include address space randomization, so that an attacker can’t know exactly where to look.

With Zenbleed, the problem is caused by something relatively simple, which amounts to a use-after-free of an internal processor resource. The recommended mitigation at the moment is to set a “chicken bit,” which makes the processor “chicken out” of the optimization that allocates that resource in the first place. I took a look at one of AMD’s manuals and I’d guess for most code, setting the chicken bit will have almost no impact. For some floating-point heavy code, it could potentially be major, but not catastrophic. I’m simplifying by ignoring the specifics but the concept is actually entirely accurate.

* If they are attacking a specific encrypted channel, they can just try every value they read, but this requires the attack to be targeted at you specifically. This is obviously more important for server maintainers than for someone buying a processor for their new gaming PC.

Only the number of shuffles is linear. Shuffling an array and marking/deleting correctly-placed elements still take linear time even with a “placement oracle.” It’s at best O(n^2) so the algorithm still wouldn’t be a good sorting algorithm.

It’s like doing selection sort, except we’re selecting a random set of elements (from that poisson distribution) instead of the smallest one.

I’m not sure the median is what you want. The worst case behavior is unbounded. There is no guarantee that such an algorithm ever actually terminates, and in fact (with very low probability) it may not! But that means there is no well-defined median; we can’t enumerate the space.

So let’s instead ask about the average, which is meaningful, as the increasingly high iteration-count datapoints are also decreasingly likely, in a way that we can compute without trying to enumerate all possible sequences of shuffles.

Consider the problem like this: at every iteration, remove the elements that are in the correct positions and continue sorting a shorter list. As long as we keep getting shuffles where nothing is in the correct position, we can go forever. Such shuffles are called derangements, and the probability of getting one is 1/e. That is, the number of derangements of n items is the nearest integer to n!/e, so the probability of a derangement would be 1/n! * [n!/e]. This number converges to 1/e incredibly quickly as n grows - unsurprisingly, the number of correct digits is on the order of the factorial of n.

We’re now interested in partial derangements D_{n,k}; the number of permutations of n elements which have k fixed points. D_{n,0} is the number of derangements, as established that is [n!/e]. Suppose k isn’t 0. Then we can pick k points to be correctly sorted, and multiply by the number of derangements of the others, for a total of nCk * [(n-k)!/e]. Note that [1/e] is 0, indeed, it’s not possible for exactly one element to be out of place.

So what’s the probability of a particular partial derangement? Well now we’re asking for D_{n,k}/n!. That would be nCk/n! * [(n-k)!/e]. Let’s drop the nearest integer bit and call it an approximation, then (nCk * (n-k)!)/(n! * e) = 1/(k!*e). Look familiar? That’s a Poisson distribution with λ = 1!

But if we have a Poisson distribution with λ = 1, then that means that on average we expect one new sorted element per shuffle, and hence we expect to take n shuffles. I’ll admit, I was not expecting that when I started working this out. I wrote a quick program to average some trials as a sanity check and it seems to hold.

Invidious does use a YouTube API. FreeTube uses Invidious, so probably same story there. I don’t know about the others.

I recently had a back and forth with one of invidious’s developers. Judge for yourself.

I’ve used it to fix regressions, most recently in a register allocator for a compiler. There’s pretty much no chance I would’ve found that particular bug otherwise; it was caused by an innocuous change (one of those “this shouldn’t matter” things) clashing badly with an incorrect assumption baked into a completely different part of the allocator.

I had seen the same effect from an unrelated bug on a different program. When I added a new test and saw the same effect, I had a “didn’t I fix this already?” moment. When I saw that the previous fix was still there, I checked if an older version of the allocator exhibited the same bug on the new test, and it did not. Bisecting found the offending change relatively quickly and further conventional testing exposed the incorrect assumption.

Learning how to program in any language will make it easier to pick up any other language, because the main burden for a beginner is how to think programmatically. However once you’re enough past that wall, being an expert on one language will mostly only help pick up languages that are similar. So if you knew C++, you could pick up the syntax and probably most of the semantics of the others very quickly, because they are similar in that regard. But you’d still probably struggle to actually program in C, because C is lower level (has way fewer features) than C++.

Technically speaking, C is a subset of C++. But that doesn’t mean being a good C++ programmer automatically makes you a good C programmer.

C# is similar to the other two in syntax as well, but it’s much more like Java than either of them.

If you want to make simpler games, you could start with scratch or stencyl. These tools aren’t really programming languages per se but they let you build programs out of blocks that are much easier to visualize and play around with. There’s some research that suggests they are good entry languages and some research that suggests they aren’t, so ymmv. I’ve used both, but I knew how to program already.

For the record you shouldn’t let “usually made with” drive your decisions. Java is still popular for some games. Slay the spire, a very popular deck building game, was written in Java, which is a decently popular choice if you want to support modding. But C++ and C# are more popular simply because that’s what you use if you’re using engines like unity or unreal.

side note: C, C++, and C# are all different languages.