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.
Manufactured inevitability a.k.a bullshit:
There’s a standard trope that tech evangelists deploy when they talk about the latest fad. It goes something like this:
- Technology XYZ is arriving. It will be incredible for everyone. It is basically inevitable.
- The only thing that can stop it is regulators and/or incumbent industries. If they are so foolish as to stand in its way, then we won’t be rewarded with the glorious future that I am promising.
We can think of this rhetorical move as a Reverse Scooby-Doo. It’s as though Silicon Valley has assumed the role of a Scooby-Doo villain — but decided in this case that he’s actually the hero. (“We would’ve gotten away with it, too, if it wasn’t for those meddling regulators!”)
The critical point is that their faith in the promise of the technology is balanced against a revulsion towards existing institutions. (The future is bright! Unless they make it dim.) If the future doesn’t turn out as predicted, those meddlers are to blame. It builds a safety valve into their model of the future, rendering all predictions unfalsifiable.
I hadn’t come across this before: a barebones blogging tool with built-in fediverse support—neat!
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!
I’ve come to believe the best way to look at our Mars program is as a faith-based initiative. There is a small cohort of people who really believe in going to Mars, the way some people believe in ghosts or cryptocurrency, and this group has an outsize effect on our space program.
Maciej lays out the case against a crewed mission to Mars.
Like George Lucas preparing to release another awful prequel, NASA is hoping that cool spaceships and nostalgia will be enough to keep everyone from noticing that their story makes no sense. But you can’t lie your way to Mars, no matter how sincerely you believe in what you’re doing.
And don’t skip the footnotes:
Fourth graders writing to Santa make a stronger case for an X-Box than NASA has been able to put together for a Mars landing.
AI becomes a stand-in term for whatever technologies and techniques are new, shiny, and just beyond the grasp of our understanding. We use it to gesture at a future we cannot fully comprehend or currently realise. As soon as we do, it will no longer be “AI.”
James describes his process for designing fluid grid layouts, which very much involves working with the grain of the web but against the grain of our design tools:
In 2022 our design tools are still based around fixed-size artboards, while we’re trying to design products which scale gracefully to suit any screen.
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
Stuart writes up the process up making a mobile game as a web app—not a native app. The Wordle effect reverberates.
It’s a web app. Works for everyone. And I thought it would be useful to explain why it is, why I think that’s the way to do things, and some of the interesting parts of building an app for everyone to play which is delivered over the web rather than via app stores and downloads.
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.
My talk, Building, was about the metaphors we use to talk about the work we do on the web. So I’m interested in this analysis of the metaphors used to talk about markup:
- Data is documents, processing data is clerking
- Data is trees, processing data is forestry
- Data is buildings, processing data is construction
- Data is a place, processing data is a journey
- Data is a fluid, processing data is plumbing
- Data is a textile, processing data is weaving
- Data is music, processing data is performing
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.
Here’s a really nice little tool inspired by Utopia for generating one-off clamp() values for fluid type or spacing.
The result of adding more constraints means that the products have a broader appeal due to their simple interface. It reminds me of a Jeremy Keith talk I heard last month about programming languages like CSS which have a simple interface pattern:
selector { property: value }. Simple enough anyone can learn. But simple doesn’t mean it’s simplistic, which gives me a lot to think about.