Hacker News Reader

I think you're just not thinking hard enough of ways to use it -- use cases where "close enough" can be augmented by deterministic validation, cleanup and iteration to perform real-world work that is "all the way".

I'm currently littering my platform with small, server-side decisions made by LLM prompts and it's doing real work that is working. There are a ton of other people doing this right now. You can be as angry as you want about it, but in a year or two you'll be using the result of this work every day.

Eh, it can be as easily said that you can promote “good enough” all you like, but “good enough” is never going to cut it for critical applications where large money or real lives are at stake. Programming languages need to accommodate such large-scale scenarios, and not only the individual-level use cases that make exactly zero money such as scripts for self-hosted servers that some Joe has in his mom’s basement.

Fair. I don't mean to suggest LLMs have no use, but I do mean to suggest that we are in a period of gross overfitting.

At the end of this all, I think they'll be best suited as massive noise generators. Human beings already generate waaaaaay more data than we know what to do with. With LLMs at our disposal, we'll be able to do so to the Nth degree. It will be the age of spam.

As for real applications, sure it can get you started, but you still have to review and massage the output. In some cases this may help you get past the "fear of the blank page" but in others just doing it yourself to begin with instead of finding clever ways to prompt the LLM to get what you really want would have been more efficient in the long run anyway when you factor in output reworking.

Yeah, I agree with you on the overfitting, but I think when the dust settles the working uses for it will emerge and the rest will be trashed. To your point, I think its fully open-ended uses such as a chatbot will relatively fade. I predict the real value will come out in converting user-intent in some subdomain into a deterministic set of options. The schedule conversion in the article is a common example of this.

If you build these small, domain-specific use cases into a user interface, things just get easier for the user. A big benefit of this is that you already have a ton of context, so the user doesn't have that burden.

Relevant video. I agree with your observations I think they are pretty interesting. Chomsky has an interesting bit here about how the epistemic implications of statistical models like these imply a shift in our values apropos to science and it's aims. For instance, as I understand it he communicates how before we would have considered some theory that made an accurate predictions as satisfying some standard of validity, now it seems people are aiming to see who can simulate the whole thing to the highest precision even if they do it black box style. I also like seeing Steven Pinker squirm a bit, so here's the vid.

[0] https://www.youtube.com/watch?v=92GOS1VIGxY&t=10s

Totally, I think one of the major dynamics of our age has been a general shift toward a new "epistemic regime" in which the vast majority of "truth making" procedures have become statistical in nature. If you look at history, we tend to move through different dominant modes of reasoning about the world: deduction, induction....I think our particular contemporary experience is one in which the new dominant mode of reasoning about everything is statistical and probabilistic. In many areas it's a boon, in others it's tragic. (the statistical treatment of human beings is one obvious case; trying to orient education psychological problems according to what the mean demands pretty much ensures everyone loses (gold star students lose out on opportunities, less gifted students start to get some help, but not nearly the case-based, customized help they really ought to)

Deterministic processes are great at dealing with objective data, but less great at dealing with free-form text produced by humans.

Each tool should be used for the right job. Until now, we had only cheap plastic tools for language processing. Suddenly, we have a turbo power tool that can parse through pages of English like a hot knife through butter.

We’re all excited by the shiny new tool in the workshop, and we’re putting everything through it just to see what it can do. Eventually the exuberance will subside and we’ll put it to work where it is the most applicable.

That doesn’t mean we’ll abandon other tools and methods.

It is precisely because “each tool should be used for the right job” that natural language should not be used for writing computer programs.

I've got some bad news for you: natural language has been used to specify programs since before there were computers to run them on.

Design documents, for one. Specifications. Standards documents. Business requests in emails, bug tickets, etc...

It goes on and on. Fundamentally, the process of programming is to convert something from a squishy human language into a purely mathematical one. Right now, programmers perform this task, essentially as "manual labour". Until now , they've had no power tools. That's what LLMs are. They're not autonomous robots -- not yet. Right now, they're levers for the mind, industrial machinery for developers to let them spit out more lines of code per day.

PS: Just as industrial machinery improved product quality, I'm starting to suspect LLMs will be used in the same way. Imagine a coding-specific variant of GPT 4 as a "pair programmer" constantly reading your code and looking for correctness issues, security vulnerabilities, unexpected gotchas, etc...

Yeah well I’ve got bad news for you too: design documents are not computer programs, and even as they exist today, they are prone to misinterpretation and somewhere in the world there’s always a programmer who’s misunderstanding the meaning of a requirement. Plus, the fact that “prompt engineering” is an emerging topic in HN discourse suggests that you need to structure your prompts in a more rigid way so that LLMs can parse them better and potentially faster, which, again, is what programming languages are: constrained and structured means of communicating logic from human to machine.

> Where have the lovers of certainty and deduction gone? I can't help but think our general laziness and acceptance of "close enough" fast solutions is going to bite us in the end.

They've always been a small group and naturally they congregate in spaces that value certainty and deduction, such as computing.

If we look backward at the history of the sciences, we'll see physics and math figuring prominently. Physics was and still is all about making mathematical models about messy, inconsistent phenomena. Math is certainly "correct" but not deterministic in the same way that computing is and proofs are still largely (but not always anymore) human endeavors of creatively applying theorems, lemmas, and factorings to mathematical objects and relations. The theory and practice of statistics predates computing and is all about reasoning under uncertainty. Underneath all the "1s and 0s" in your computer are very real analog voltages that gates are reacting to to process your logic.

It's pretty much just computing and logics that really value certainty and deduction. So really it's the opposite: the computing craze added value to certainty and deduction when there really wasn't much before.

> It's like the world has suddenly shifted from valuing deterministic, precise, behaviors to preferring this sort of "close enough, good enough" cavalier attitude to everything.

Framing this as a tradeoff is a mistake rather than having two different tools for two different jobs. For ex: there are scenarios where can do part of Google's job or Wikipedia's job sufficiently well, but when being deterministic is what matters then obviously we still have Google and other manual knowledge bank processes.

They aren't going away or being abandoned. They are being supplemented. And since LLMs are so new it's mostly just a matter of the market figuring out where each tool fits into our lives. It's mostly a misconception/marketing that it is a replacement for stuff like search engines or human-backed processes.

But even doing 25% of what Google can do but better + another 25-50% it couldn't do before is a massive business and a huge boon for society.

When the mysterious black box is sufficiently intelligent and its output domain is _also_ natural language, precision and even correctness of the input carries less importance.

You can give an LLM a barely comprehensible query and you stand a decent chance of getting something useful back. Try the same in any conventional programming language and chances are it would not even have a valid AST and thus fail to compile.

So it's a question of necessity--there wasn't one. LLMs are capable enough to deal with the ambiguities of natural language.

That said I've seen some forms of DSL used to program LLMs in the chatbot character.ai scene, so I wouldn't be surprised if a more general DSL purpose built for efficient prompt engineering is discovered (efficient use of tokens, standardized forms, etc).

(I say discovered because at the moment you can for example literally make up your own DSL if you so desire, and the LLM will just roll with it and mostly do what you intend)

Follow the trajectory from manually keying in machine code instructions, to punchcards with ASM, terminals with C, GUIs with Smalltalk… have we not been watching the progression towards natural language?

Formalization of requirements will always be necessary. But allowing for an errant semicolon or misspelled word seems to be the direction we’re headed. That is, explicitly cover all cases and requirements, just don’t worry about exact machine syntax or function names.

I see your point but it's a difference in kind. The general trend in the development of higher level languages has been to allow user to encode common patterns in ever terser sequences of symbols (e.g. no need to write your own iterator, the compiler will do it for you). However, these terse descriptions of a pattern are still deterministic and precise.

This isn't quite the same as using natural languages to try and get a machine to guess at the program you want. I think it'd be a shame if we abandoned the trajectory of ever-higher programming languages in favor of relying on LLM's to generate roughly what we want in existing, "boilerplate heavy" languages. There are quite literally lines of research in programming languages right now that formally and in an incredibly terse fashion, allow you to generate provably correct software from a short, formal meta-specification. To abandon that in favor of LLM generation strategies would be a clear loss in my opinion.

LLM's have their uses of course, but at the moment we're definitely in a period of major overfitting and absolute lack of reason when it comes to the application and development of these tools.