Warwolt

How would you do layouting without a tree structure in place? Not really sure what you're getting at here

Nice article! Having little interactive examples I think is fantastic, and makes the text really utilize it's medium well.

The text was mostly a refresher for me who already knew the subject, but I would heartily recommend it to colleagues with less hardware know-how

Can someone give a tl;dr? Feels like a whole lot of preamble in the article

That's not a good analogy. A good mathematician isn't necessarily dealing with calculations, i.e. long division, but rather with proof.

No-ones becomes a good mathematician without first learning to write simple proofs, and then later on more complex proof. It's the very stuff of the field itself.

Actually, I think this is a case where LLMS _can_ be useful. If we're prompting for small enough outputs, for examples around things we can already sort of reason about it, we're able to judge whether or not what's presented to use makes sense.

Presumably you're also reading some kind of learning text about the Chinese language, so the sole source isn't just the LLM?

In my experience, asking an LLM to produce small examples of well-known things (or rather, things that are going to be talked about frequently in the training data, so generally basic or fundamental topics) tend to work fine, and is going to be at a level where you yourself can judge what's presented.

I think the real danger is when a person is prompting things they don't know how to verify for themselves, since then we're basically just rolling dice and hoping

Unfortunately in the majority of organizations, the idiots are at the wheels. It's not people with actual experience of how engineers do things, that dictates what those engineers should do.

But common, collouqialy "Garbage Collection" as a language feature refers to a run time garbage collector.

Saying that the language has GC just because it has opt-in reference counting is needlessly pedantic

> they either must be bought at an increasing steep price

It's a variable simply because it doesn't refer to a specific object, but any object assigned to it as either function argument or by result of a computation.

It's in fact us programmers who are the odd ones out compared to how the word variable has been used by mathematics and logicians for a long time

Making a distinction between pure and effectful functions doesnt require any kind of effect system though.

Having a language where "func" defines a pure function and "proc" defines a procedure that can performed arbitrary side effects (as in any imperative language really) would still be really useful, I think

Who cares? That's just semantics. If we define science as the systematic search for truths, then mathematics and logic are the paradigmic sciences. If we define it as only empirical search for truth then perhaps that excludes mathematics, but it's an entirely unintersting point, since it says nothing.

To be fair, presumably debug printig could be "escaped" from the effect type checking if the designer of an effect system would want it. For instance, debug printig in Haskell completely sidesteps the need for the IO Monad and just prints in whatever context

Ease of definition doesn't equate ease of measurement..

My issues stems from me feeling like a lot of terminology introduced by the author ending up being used in different ways in different paragraphs.

It didn't feel like a thought through whole, and I felt somewhat punished for trying to read along attentively.

I also found there to be a frequent conflation of e.g. the notion of modules and a classic OOP-class, to me it seemed like the author thought of them interchangeably.

To me there's enough theoretical computer science that can be used to help ground the terminology, even if it's just introduced cursory and with a reference for further reading. But at least then there'd be more consistency.

I'm not sure I think the book is invaluable, but I think it's a good contribution to the subject.

While the tools you talk about sound interesting, to me this was more about an in-principle possible measurement rather than something we'd actually carry out.

I think stating that "more stuff" in the program code and in the spec leads to more stuff to keep track of, and so we want to minimize complexity to maintain tractability?