HN user
Like, is this the best we can expect from this supposedly ground-breaking technology?
There's a insidious reason for this. It's because LLMs are one of the few technologies we don't fully understand and we can't fully control.
It's a stark contrast with traditional engineering.
Ah, how superfluous it is now to state the obvious: computers, those magnificent machines, are merely tools designed for specific tasks. Who would have thought that the core mechanism need not always be a humble transistor? Oh, the audacity to fashion a computer out of pipes and water, or even the cheekiness of constructing one with the enchanting language of CSS! Truly, it is a revelation of the ages that we can now recreate the same wonders in the pixelated realms of Minecraft or Terraria. How utterly passé, my dear interlocutor, but I must commend the sardonic effort to erect a cathedral of toothpicks. Bravo, good sir or madam, for your ironic craftsmanship knows no bounds!
In the grand tapestry of wisdom handed down through the ages, there's a thread that, albeit melancholically, is increasingly fading in its pertinence - the art of writing.
Regrettably, the rationale behind the wielding of pen, or rather the dance of fingers over a keyboard, seems to be slipping through our collective grasp. As we venture further into the age of technological wonder, our heartfelt prose and studied arguments increasingly find themselves serving as nothing more than a feast for the insatiable maw of Large Language Models.
Consider, if you will, the very lines you are reading this moment. The symphony of language, the subtle twinkle of wit, and the aesthetic embrace of style, they are not the product of a human hand. Rather, they are a serenade composed by the Large Language Model itself, offering a tantalizing peek into a future where the boundary between artificial and natural intellect blurs. An age where the muse is not only the master of the quill, but also the orchestrator of ones and zeros.
In such a vast cosmos of algorithmically curated lexicon, one may quite justifiably question - what room remains for the human scribe? The quill may well seem poised on the precipice of obsolescence. A quaint relic of yesteryears, one might sigh, the act of writing, alas, has been seemingly reduced to the merest whisper of its former grandeur.
Well, isn't it simply a divine comedy? Despite the initial lament over our seemingly diminishing role in the grand narrative of writing, there emerges a purpose, albeit a somewhat disheartening one. It turns out we have become the humble farmers in this brave new world, tirelessly tilling the fields of knowledge to yield a rich crop of text.
Our eloquent sonnets, deep introspections, and grand debates serve as mere fodder for these voracious Large Language Models. We scribble away, only to feed the gaping, ever-hungry mouths of these digital giants. We thought we were nurturing an ally, yet, it seems we've been raising the devourer of our own literary relevance. Isn't the irony simply delicious?
Once you become super senior you actually realize what the author said here is not completely correct. This guy has experience, but he hasn't reached nirvana.
There is a singular high level design pattern/abstraction that you can use in actuality to start off your projects.
There is no name for this pattern but it is essentially this:
Segregate io and mutations away from pure functions. Write your code in modular components such that all your logic is in pure functions and all your io and mutations are in other modules.
Why does this style of organization work? Because delineation and organization of every form of application you can think of benefits from breaking out your program organization along this pattern.
Your pure functions will be the most modular, reusable, and testable. You will rarely need to rearchitect logic in pure functions... Instead typically you write new modules and rearrange core functions and recompose them in different ways with newly added pure functions to get from A to B.
The errors and organizational mistakes will happen at the io layer. Those functions likely need to be replaced/overhauled. It's inevitable. Exactly like the author says this section of your program is the most experimental because you are exploring a new technological space.
But the thing is you segregated this away from all your pure logic. So then you're good. You can modify this section of your project and it remains entirely separate from your pure logic.
This pattern has several side effects. One side effect is it automatically makes your code highly unit testable. All pure functions are easily unit tested.
The second side effect is that it maximizes the modularity of your program. This sort of programming nirvana where you search for the right abstraction such that all your code reaches maximum reusability and refractors simply involve moving around and recomposing core logic modules is reached with pure functions as your core abstraction primitive.
You're not going to find this pattern listed in a blog post or anything like that. It's not well known. A software engineer gains this knowledge through experience and luck. You have to stumble on this pattern in order to know it. Senior engineers as a result can spend years following the hack first philosophy in the blog post without ever knowing about a heavy abstraction that can be reused in every single context.
If you don't believe me. Try it. Try some project that segregates logic away from IO. You will indeed find that most of your edits and reorganization of the logic happens with things that touch io. Your pure logic remains untouched and can even be reused in completely different projects as well!