I think a lot of people that don't really understand what they're doing obsess over LLMs for the same reason that they might have obsessed over visual programming or Plain-English-programming a generation ago.
In their mind, programming works like this:
1) A clever person designs the system/app/website/game in their mind.
2) The person uses whatever tools available to wrangle the computer into reproducing that vision.
(1/...)
In this model, the bottleneck is (2) and anything that isn't the native tongue of the designer is actively getting in the way of the manifestation of that vision.
THIS IS NOT HOW PROGRAMMING WORKS.
In reality, programming is an eclectic back and forth conversation between developer and machine where the former explores the possibility space and the machine pushes back by unveiling its constraints.
No 'vision' survives this process unscathed, and this is a good thing.
Those that obsess over LLMs like to believe that Plain English sits at the top of the abstraction pile, that it is the thing that a programming environment should seek to model. From this point of view, an LLM seems perfect: type in words, program comes out.
But Plain English is not the top of the pile, not even close. It's an imprecise and clumsy lingo. The process of development is about throwing away that imprecision and engaging with the reality of the possibility space.
It can be hard for those that don't do a lot of programming to understand, but programmers do not think in Plain English (or whatever their native tongue is). They do not, for the most part, spend their time wrangling & getting frustrated at their tools.
Instead, programmers think in abstractions that sit beyond the realm of natural language, and those abstractions are carved through dialect with the machine. The machine pushes back, the chisel strikes the marble, and the abstraction evolves.
LLMs promise something enticing, but ultimately hollow: the ability to skip the dialectic and impose one's will on the machine by force. They are appealing because they do not allow space for their user to be wrong, or to be forced to encounter the consequences of their unrefined ideas.
This is why code written by LLMs is often buggy, insecure, and aimless: it is written to appease a master that does not understand the conflict between their ideas, nor the compromises necessary to resolve them.
If you're an LLM fan, it might initially appear confusing that a programmer might choose a statically typed language, and more confusing still that those with experience *yearn* for static typing. Why limit yourself?
But the reality is that the development of good software requires the dialectic between developer and machine to take place, and type systems accelerate this process by allowing a skilled programmer to refine their mental model much earlier in the development process.
@jsbarretto I feel like the real problem AI solves is speeding up the literal writing of code and management doesn't understand that it's the easiest part of the process.
Good design, expert supervision, iterative, programmatic, and critical thinking are all still very much needed.
CoPilot isn't a substitute for a programmer, it's just super-intellisense.
@jsbarretto wonderfully said!
To add to that, "the machine" does not only reveal its own constraints in that process, but also the inherent flaws in the design you came up with. (Unless of course we view "logic" as an inconvenience imposed onto us by machines)
@jsbarretto Nice! You've managed to capture into words the ideas about design that have been bouncing around my head for some time now.
Namely: I can't design a system just in my head. I have to design it with the help of a compiler. I need some way to discover the constraints of my design space * before I can design the system * and the fastest and most reliable way I've found to do that so far is to throw things at a compiler or into a prototype and see what walls I bump into.
@gadgetoid @jsbarretto we bounced off of normal autocomplete really hard back in the 90s when it was new (at least, new to us)
it slows us down, it always has, it breaks our brain's pipelining. besides, it's trying to get us to not know our codebase as well; why would we want that?
with the benefit of our labor vocabulary that we have today, it was always at least partially motivated by deskilling, though we know that some people like it and are glad they have the choice
@jsbarretto This coincides with my personal evolution as a developer. Around the 7 year mark of being a Python dev I started leaning more and more towards static typed langs.
at this point if I have to use python it's gonna be with pydantic.
@jsbarretto The Pydantic library is better than nothing but I don't think it means the lang as a whole is moving in that direction.
I know this is probably cliche, but Rust's borrow checker is to memory management what static typing is to type management. Sure, it may *feel* restrictive, but there's as an odd sort of freedom in those constraints.
It's almost as though what you lose in syntactic freedom you gain in semantic reliability.
@jsbarretto
I think we are still missing something important: The ability to constrain our data types further.
A lot of algorithms that work fine for e.g. integers up to 1000, or maybe 10000, completely fall apart at "insert large number here".
Because we fallible, human programmers assume that an algorithm that works fine for those low numbers will work equally well for large numbers. Which it often doesn't.
Speaking as a practicing engineer, i've had many managers/customers that do not understand the laws of physics... 🤣
Edit: cRsp tYpong... 🤦♂️ 🤣
@jsbarretto hollow is a great way to put it.
Honestly I love tapping AI on the shoulder for quick questions or debugging an error message. But I've not really enjoyed the code output from any LLM honestly.
@jsbarretto
> written to appease a master that does not understand the conflict between their ideas, nor the compromises necessary to resolve them.
This sounds like a lot of code-for-hire gigs
@jsbarretto A programming language and computer hardware dictate software architecture, much like building materials and the laws of physics dictate regular architecture. One is not generally allowed to build things for other people without demonstrating an understanding of how these constraints work.
LLMs understand nothing; they aren't *capable* of understanding. They replicate the results of comprehension, but can never develop their own.
@jsbarretto I agree with your wider point, but I wouldn't go so far as "they do not, for the most part, spend their time wrangling & getting frustrated at their tools"! 😅
Not while you're deep in the flow, sure. But I can't be alone in spending a good fraction of the time wrangling tools and configuration. Which makes me wonder if I should be leaning on LLMs much more for that side of things, hmm.
@jsbarretto Good points, but not entirely true, I am wrangling and getting frustrated with my tools right now. Your vision of programming as deep abstract thought followed by a few masterfull key strokes is appealing, but it's an unachievable ideal to have it like that all the time.
Does it mean the tools are bad, that I should git gud, or that I shouldn't be doing this at all and instead contact somebody experienced with the tools?
Or use LLM to actually reduce the wrangling and frustration?
@janbogar You're not wrangling! Wranging is when you fight tools while learning nothing of their workings. You might spend a lot of your time fighting bad tools, bugs, obscure APIs, strange building systems, etc. (I know I do) but it's a process of discovery that ups the chance of success next time you attempt something similar. That's fundamentally different to asking an LLM to spit out an answer.
Using an LLM to more easily access information? That's fine, I'm not arguing against that.
Joshua Barretto
Glyph
Urzl
gaytabase
guenther
Jeff Martin
nerdinand
Will Hopkins 🌈📸
Irenes (many)
gadgetoid
Analog AI
Neal
Grendel
Not a Spring Onion
Pavel A. Samsonov
beaumains
Billy Smith
Mike 
aloe
Lykso
Brie (
)
Toni Aittoniemi
Jeremy Kahn
pandabutter
TheZoq2
Light
Softwarewolf
Sasha Akhavi
Colin Watson
Iain Merrick
Ján Bogár