giornogiovanna

I know these are extremely common suggestions, but…

• 3Blue1Brown has great introductory series on linear algebra and calculus.

• Khan Academy covers pretty much all of US high school mathematics, and you can go through it at whatever pace you want.

• I can send you a few Australian high school textbooks if you want.

How does amb "in all its glory" handle an endless loop? Any solution I can think of seems prohibitively expensive.

Besides GC and the lightweight syntax (relative to Rust), what is it about OCaml that makes it so wonderful for implementing complicated algorithms?

Honestly, if you care about longevity, Rust simply isn't the language yet. I'd at least wait until there's a specification and a GCC frontend.

Anyway, C does have some benefits as a programming language.

• "Legacy" projects like Linux and CPython will keep it alive for decades to come.

• It's extremely portable. Rust is less portable, and even when Rust supports a niche platform, it's relatively clunky to get things started.

• C libraries are always very easy to call from other languages. Rust isn't quite there yet, and translating things like traits can be a bit of a pain.

I thought this was going to be about bounding the time complexity of your algorithms; I don't know if any language does that yet. I suppose this title has a lot of interpretations.

No one suggested that surveillance is as bad as cancer. All that was said is that blocking Facebook dating has a similar effect on surveillance (in kind, not in degree) as banning tobacco has on cancer.

› It's important to realise that variables in mathematics and variables in programming have a lot in common, but they are not the same thing!

I think the stated "differences" are actually similarities with programming languages.

› In mathematics, sometimes a "variable" is a place-holder for a value one may choose arbitrarily from a collection, and which is then used in some process,

That pretty much perfectly describes a function parameter: for a formal correspondence, universal quantification corresponds to dependent function types.

› In fact, sometimes we find that there is no value satisfying the requirements we have placed on the variable, so in a sense it doesn't exist at all!

That's what happens when your variable's type turns out to be uninhabited, like an empty enum.

› It seems to me, speculating idly and with no research to back me up, that recursion has similar conceptual challenges as Mathematical Induction and Proof By Contradiction.

The author used proof by contradiction as part of a proof that the well-ordering principle implies the principle of mathematical induction, but (1) that links recursion and proof by contradiction exactly as much as it links recursion and modus ponens, and (2) mathematical induction is usually taken to be the more fundamental rule anyway, so this bit doesn't make much sense to me.

› In mathematics a function doesn't even need to have a rule to tell you what it is,

It depends on your definition of a function. ;)

Related: the author lists rules such as "A finite path from an instance back to one of the simplest", which are formalized in the concept of a well-founded relation.

> But for numerical work 1-based indexing is usually easier to work with.

That's not really true in my experience, since all the nice properties of zero-based indexing transfer perfectly over to mathematics.

But you're right, this isn't anything to abandon an otherwise wonderful language over.

I'm getting some serious déjà vu here.

Anyway, pjmlp, if you have some time, could you please explain how WSL makes sense in a world where SPIR-V already exists?

Both are intended mainly to be compiler targets, and both will need verifiers for use in WebGPU. The main advantages of SPIR-V are that some tooling already exists (as opposed to none), most of the specification is already done, and it will end up being faster with Vulkan. The only advantage I've seen for WSL is that it's text-based, so you can cut and paste pieces of code together more easily. I don't know how that would even fit in with the idea that WSL is meant to be a compiler target, though.

> Sounds more like a problem with the team, rather than a problem with the language.

That's the same reply that people have to "C++ has too large a surface area". Granted, Swift isn't quite at C++ levels of complexity yet, but ideally, I shouldn't have to cordon off sections of the language I'm using just so my team can stay sane.

The two main cases when linked lists are better are (a) when you want to guarantee a low cost per insert, since vector insertion is only O(1) amortized, and (b) when you want to insert in the middle, but somehow found that middle without scanning the list.

Anyway, in this case, I guess they're using a free list because (1) it's simpler since you don't need an external collection keeping a list of unused stuff, and (2) reason (a) above.