> For any practical application, you are only interested in finite set of concrete identities

I do a lot of numerical work in settings where computational efficiency is useful.

In my work, most cases you can do numerically using integration or Monte Carlo sampling or whatever.

It’s slow. It often pays to find a closed-form solution. Even if it’s just a starting point that needs refinement.

To put in terms of the Pythagorean theorem: Proving the Pythagorean theorem gives you a relationship that’s reliable, fast to evaluate, and general. Proving individual tuples gives you none of this.

That doesn’t even touch on how theorems give us a glimpse at deeper structure and truths. Proving a bunch of right-triangle tuples will probably never lead you to the rest of the identities in trig.

The tcl syntax is fine. And modern tcl is fine.

But tcl 7.x and before was a pure string-based language. Everything was essentially a eval(). People would hit syntax errors on production code.

Fun, painful times.

The flip side: the interpreter is super simple and fun to write.

Tcl is still entirely stringly typed. That's never changed.

There are under-the-hood optimisations to make it less insanely slow but that only affects performance.

Tcl is a cool hack (the interpret is simple to write) but it's insane to actually use it. I wish the EDA industry would realise that.

Tcl 8 introduced dual-ported objects. Everything can exist as a typed object that is convertible back to a string in certain cases (some form of string operation typically). That plus the bytecode engine makes it work completely different than prior releases.

That's just a performance optimisation. It doesn't change the semantics at all. From the changelog:

> Tcl automatically manages these values so their type is transparent to the Tcl script writer.

https://www.tcl-lang.org/software/tcltk/whatsnew.tml

Saying it's "just strings" is disingenuous. You could make a js interpreter that uses strings internally too.

No. Tcl is all strings from a language point of view. To your Tcl code, everything is a string.

Internally in the main Tcl implementation, it isn't just strings. It's a bit cleverer so it can be faster. But that is completely invisible to the Tcl programmer.

JavaScript is not just strings. It has real types (even if it is happy to coerce them to strings at the drop of a hat).

To put it another way, JavaScript has `typeof` which returns the type of an object. Tcl doesn't have that because the answer would always be "string".

tcl::unsupported::representation will expose the actual internal type.

> ::tcl::unsupported is a namespace that contains bits and pieces of Tcl that are experimental, not intended for production code, perhaps useful for debugging and introspecting Tcl, and liable to change or removal without warning.

Why the negativity?

If someone wants to have fun in COBOL, let them have fun in COBOL.

If it’s agentic fun, that’s cool. If it’s an interest in the language, that’s cool. It’s not like you have to have an ROI for a fun side project.

It’s also OK to be turned off by AI use in hobby projects and it is also OK to prefer disclosure of the use of AI in projects so I can make that choice.

You bring in contractors.

Ideally contractors that benefit you personally (eg: your buddy who now owes you one), but definitely contractors that let you outsource the responsibility.

Even better if you get some management consultant to suggest the idea and/or do the subcontracting.

Definitely buys you a few quarters of bonus and some time to land your next gig.

Sometimes you get lucky and it both looks up the documentation and then ignores it and makes stuff up.

This more or less agrees with my assessment of recent changes in Claude Code where a lot of new features are either:

- A lot of half-baked features or half-done features. - Or have significant overlap with existing features, and aren’t clearly an improvement.

More code is not better. More features are not better. It would be lovely to see more intentional design than just more.

I know they’re dog fooding this. I have to believe they have some people with taste. So it makes me wonder if anyone has the time to think or if they’re just shoveling prompts as fast as possible.

It's like the AI created a method add(a b) return a+a+a+a-b-b-b-b But then much bigger and complex features. Totally useless nothing methods. But still interesting to see occasional exceptions that are better.

Marc Andreessen has a strong financial incentive to feel this way and to convince others to feel this way.

I also think it’s easy to think that AI gives good answers if you don’t know the field well. In fields where I know the material, the answers are pretty variable and can be quite bad.

HNers have strong incentive to feel the opposite. Humanity in general has strong incentive to feel the opposite.

AI is not only replacing programmers, but art and the meaning of being human itself. It's showing us how trivial all of human creation is as it's just patterns from an algorithm.

Seems like there should be a market for a no-Elon/OpenAI/Anthropic ETF out there.

Or one that just imposes a reasonable waiting period on adding newly-IPO’d listings.

The price of SSDs is similarly depressing.

I didn’t see anything about LLMs here.

If you’ve never written or worked in a Forth-like language, it’s not a hard system to bootstrap up. If you’ve done it before and know assembly, you can even get something that compiles to (stack-heavy and pretty unoptimized) native code in essentially a weekend. No LLM needed.

Forth-likes are almost magical in ways that are hard to describe. You start with primitives and literally build the language out of them. The interpreter and compiler are two different modes of the same REPL loop.

It’s just a very different paradigm than most programmers know.