Vaporware

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

Knowlege gets taught in specific institutions exactly because street knowledge is quite often incorrect, like in this case, spreading urban myths based in shaky foundations.

> they either must be bought at an increasing steep price

Right, what I was getting at is -- that isn't a fatal problem in practice, the price stays affordable.

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

> 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

Rust tried that in the early days, the problem is no-one can agree on exactly what side effects make a function non-pure. You pay almost all the costs of a full effect system (and even have to add an extra language keyword) but get only some of the benefits.

The definition I’ve used for my own projects is that anything that touches anything outside the function or in any way outlives the function is impure. It works pretty well for me. That is, no i/o, mutability of a function-local variable is okay but no touching other memory state (and that variable cannot outlive the return), the same function on the same input always produces the same output, and there’s no calling of impure code from within pure code. Notice this makes closures and currying impure unless done explicitly during function instantiation, making those things at least nominally part of the input syntactically. YMMV.

nim does that. and they are called that.

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

yeah, most times its solved by side-stepping the strict type system and making an exception for debug prints. but this is not a real practical solution, this is a stupid workaround born from overinsistence on "beautiful" design choices.

It seems to me like a pragmatic compromise and very much a real solution. What would you consider a real solution that isn’t overinsisting on beautiful design choices?

putting strong static type system into optional compiler pass. yes, I know this may be null is some cases, let me run my program for now, I know what I am doing. yes, there are unhandled effects or wrong signature, just let me run my test. yes, that type is too generic, i will fix it later, let me run my god damn program.

This puts a lot of extra conditions on the runtime; you basically have to implement a "dynamically typed" runtime like Javascript. In doing so you lose a lot of performance. Google have invested something like a century of man-hours into V8 and on typical benchmarks the performance is about half of Java's, which in turn is typically about half of C / Rust's performance. That's a pretty big compromise for some.

Well, you can reuse all that man-hours that went into the JVM - this is what Flix does!

This is basically what we already have in Haskell. Debug functions that sidestep the typing system can be annotated with a warning and you can make this one an error while compiling for production.

And in a more general sense, you can ask the compiler to forbid escape hatches altogether.

We already have a pragmatic, reliable solution.