Ingesting every piece of art ever into a machine which lovelessly boils them down to some approximated median result isn’t artistic expression. It may be a neat parlour trick, a fun novelty, but an AI is only able to produce semi-convincing knock-offs of our creations precisely because real, actual people once had the thought, skill and will to create them.
In some ways, the fervor around AI is reminiscent of blockchain hype, which has steadily cooled since its 2021 peak. In almost all cases, blockchain technology serves no purpose but to make software slower, more difficult to fix, and a bigger target for scammers. AI isn’t nearly as frivolous—it has several novel use cases—but many are rightly wary of the resemblance. And there are concerns to be had; AI bears the deceptive appearance of a free lunch and, predictably, has non-obvious downsides that some founders and VCs will insist on learning the hard way.
This is a good level-headed overview of how generative language model tools work.
If something can be reduced to patterns, however elaborate they may be, AI can probably mimic it. That’s what AI does. That’s the whole story.
There’s very practical advice on deciding where and when these tools make sense:
The sweet spot for AI is a context where its choices are limited, transparent, and safe. We should be giving it an API, not an output box.
I don’t agree with all of these takes-of-varying-spiciness, but Rich Harris is always worth paying attention to.
I’ve been using Copilot for over a year now, and this is more or less how I use it: To help me quickly blast through boilerplate code so I can more quickly get to the tricky bits.
There’s a more subtle problem with ChatGPT’s code generation, which is that it suffers from ChatGPT’s general “bullshit” problem.
If you’ve made a computer do something - anything - in a logical fashion, you’re a programmer. Scratch? Programmer! CSS? Programmer? Conditional formatting in Excel? Programmer!
This extract from Baldur’s new book is particularly timely in light of the twipocalypse.
Here’s a remarkably in-depth timeline of the web’s finest programming language, from before it existed to today’s thriving ecosystem. And the timeline is repsonsive too—lovely!
A beautiful meditation on Christopher Alexander by Claire L. Evans.
A terrific piece by Maggie Appleton that starts with a comparison of graphical user interfaces and command line tools—which reminds me of the trade-offs between seamless and seamful design—and then moves into a proposed paradigm for declarative design tools:
Small, scoped areas within a graphical interface that allow users to read and write simple programmes
Folk creations fill a gap. They solve problems for individuals and small communities in a way that that centralised, top-down, industrial creations never can. They are informal, distributed practices that emerge from real world contexts. Contexts where individuals have little or no control over the “official” means of production – of furniture, urban architecture, crockery, artwork, media stories, or taxonomies. In response people develop their own unpolished, unofficial, and deeply practical creations.
Now apply that to software:
Only professional programmers and designers get to decide what buttons go on the interface, what features get prioritised, and what affordances users have access to. Subverting that dynamic is the only way people can get their needs met with the computational tools they have at hand.
A new programming language where you pray to Greek gods.
An invocation has three parts: the god’s name and adoration (praising of that god), supplication to show the humbleness of the asker, followed by a request to add one or several of what we ordinarily call “commands” to the program.
Here’s the source code for “99 bottles of beer” in Olympus and here it is transpiled into JavaScript.
A fascinating account of the history of JAWS and NVDA.
If only all thinkpieces on complexity in software development were written in such an entertaining style! (Although, admittedly, that would get very old very fast.)
A layman’s guide to thinking like the self-aware smol brained
I believe that we haven’t figured out when and how to give a developer access to an abstraction or how to evaluate when an abstraction is worth using. Abstractions are usually designed for a set of specific use-cases. The problems, however, start when a developer wants to do something that the abstraction did not anticipate.
Smart thoughts from Surma on the design of libraries, frameworks, and other abstractions:
Abstractions that take work off of developers are valuable! Of course, they are. The problems only occur when a developer feels chained to the abstractions in a situation where they’d rather do something differently. The important part is to not force patterns onto them.
This really resonated with parts of my recent talk at CSS Day when I was talking about Sass and jQuery:
If you care about DX and the adoption of your abstraction, it is much more beneficial to let developers use as much of their existing skills as possible and introduce new concepts one at a time.
Time and again, organizations have sought to contain software’s most troublesome tendencies—its habit of sprawling beyond timelines and measurable goals—by introducing new management styles. And for a time, it looked as though companies had found in Agile the solution to keeping developers happily on task while also working at a feverish pace. Recently, though, some signs are emerging that Agile’s power may be fading. A new moment of reckoning is in the making, one that may end up knocking Agile off its perch.
I’m glad that Heydon has answered this question once and for all.
I’m sure that’ll be the end of it now.
This is a wonderful piece of writing by Marcin, ostensibly about bug-fixing but really an almost existential examination of the nature of coding.
Bugs are, by definition, a look backward—at past behavior, at code that already exists, at the old work of engineers whom you’ve never met. It can feel more fun to write new code, chart new territories, add new functionality.
But the past can be fun, too. A good bug is a puzzle. A mystery. A whodunit. To solve a bug, sometimes you have to be a scientist: observe and measure, chart out the logic, follow the math. But then, two minutes later, you need to wear a hat of a very particular detective—take your flip notepad and interview different pieces of code to understand not what they claim they do, but what they actually do.
Ah, this brings back memories of hacking on the WorldWideWeb project at CERN!
(Not the original one. I’m not that old. I mean the recreation.)
The paradox of performance:
This era of incredibly fast hardware is also the era of programs that take tens of seconds to start from an SSD or NVMe disk; of bloated web applications that take many seconds to show a simple list, even on a broadband connection; of programs that process data at a thousandth of the speed we should expect. Software is laggy and sluggish — and the situation shows little signs of improvement. Why is that?
Because we prioritise the developer experience over the user experience, that’s why:
Although our job is ostensibly to create programs that let users do stuff with their computers, we place a greater emphasis on the development process and dev-oriented concerns than on the final user product.
We would do well to heed Craig’s observations on Fast Software, the Best Software.
If you employ a hack, don’t be so ashamed. Don’t be too proud, either. Above all, don’t be lazy—be certain and deliberate about why you’re using a hack.
I agree that hacks for prototyping are a-okay:
When it comes to prototypes, A/B tests, and confirming hypotheses about your product the best way to effectively deliver is actually by writing the fastest, shittiest code you can.
I’m not so sure about production code though.