For the record, I mostly agree with you. I think asking ChatGPT to write apps or large nontrivial programs for the most part is silly and you're going to have a bad time. I hate the weird wide-eyed fanaticism with which people approach this stuff and how people will reach for ChatGPT before they reach for actual documentation.
But even if its expertise mainly opens the door to trivial stuff, that alone is a huge boon for accessibility for a lot of folks.
> I spent a month with an LLM and build a new programming language
For the past few months I've more or less been doing this. I'm self-taught, so my CS knowledge is sketchy and has lots of holes. I never took a compilers or programming languages course. I've done lots of reading but it never fully clicked for me. Having an LLM outline the process for me at a high level, provide pseudocode or even code snippets for less clear bits, and also (try to) answer whatever questions I throw at it related to my external reading has been pretty incredible -- things suddenly clicked. Another way I use it is to ask for important introductory texts or papers when exploring a new area
Yes, occasionally it spouts nonsense -- you have to evaluate its responses critically. If you ask it to do anything complicated or involving fast-moving APIs or less well known languages or frameworks, it will straight up make shit up. But we shouldn't throw the baby out with the bathwater here
A snippet of a conversation from earlier this summer:
Me
In Pierce's types and programming languages, he describes the untyped arithmetic expression language.
In one of the definitions by inference rules, he defines the language as the minimal set T such that
- 0 is in T, true is in T, and false is in T
- If t is in T, then succ(t) in T
- pred(t) is in T, and iszero(t) is in T.
That makes sense if t is numeric but how are these defined if t is Boolean?
For example, true is in T, but I don't see how this definition can work
if T is to also allow boolean values, like how is succ(true) well-defined?
GPT
In Pierce's presentation in "Types and Programming Languages", the untyped arithmetic language allows you to form terms like succ(true), even though they don't have a meaningful interpretation in "everyday arithmetic". When we say the term succ(t) is in T, we're referring to the syntactic formation of terms, not their semantic meaning.
The language defines the syntax of valid terms, but it doesn't give them any inherent meaning at this stage. This is why we can syntactically form terms that don't make sense semantically. When we actually evaluate these terms (if we were to interpret them), many of them would result in "stuck" states, where we can't proceed with evaluation. For example, while we can form the term succ(true), there's no evaluation rule that tells us what this term evaluates to.
The definition you cited doesn't discriminate based on the nature of t. All it says is: if t is a term in T, then succ(t), pred(t), and iszero(t) are also terms in T.
Remember, this untyped language serves as a stepping stone. It illustrates what can go wrong without types. The oddities you're pointing out motivate the introduction of more refined, typed systems later in the book, where such nonsensical combinations are explicitly prohibited by the type system.