Taking the child on a tour through punctuation, Mr. Stops introduces him to a cast of literal “characters”: there is Counsellor Comma, who knows “neither guile nor repentance” in his pursuit of “dividing short parts of a sentence”; Ensign Semicolon struts with militaristic pride, for “into two or more parts he’ll a sentence divide”; and The Exclamation Point is “struck with admiration”, his face “so long, and thin and pale”.
Picture someone tediously going through a spreadsheet that someone else has filled in by hand and finding yet another error.
“I wish to God these calculations had been executed by steam!” they cry.
The year was 1821 and technically the spreadsheet was a book of logarithmic tables. The frustrated cry came from Charles Babbage, who channeled his frustration into a scheme to create the world’s first computer.
His difference engine didn’t work out. Neither did his analytical engine. He’d spend his later years taking his frustrations out on street musicians, which—as a former busker myself—earns him a hairy eyeball from me.
But we’ve all been there, right? Some tedious task that feels soul-destroying in its monotony. Surely this is exactly what machines should be doing?
I have a hunch that this is where machine learning and large language models might turn out to be most useful. Not in creating breathtaking works of creativity, but in menial tasks that nobody enjoys.
Someone was telling me earlier today about how they took a bunch of haphazard notes in a client meeting. When the meeting was done, they needed to organise those notes into a coherent summary. Boring! But ChatGPT handled it just fine.
I don’t think that use-case is going to appear on the cover of Wired magazine anytime soon but it might be a truer glimpse of the future than any of the breathless claims being eagerly bandied about in Silicon Valley.
You know the way we no longer remember phone numbers, because, well, why would we now that we have machines to remember them for us? I’d be quite happy if machines did that for the annoying little repetitive tasks that nobody enjoys.
I’ll give you an example based on my own experience.
Regular expressions are my kryptonite. I’m rubbish at them. Any time I have to figure one out, the knowledge seeps out of my brain before long. I think that’s because I kind of resent having to internalise that knowledge. It doesn’t feel like something a human should have to know. “I wish to God these regular expressions had been calculated by steam!”
Now I can get a chatbot with a large language model to write the regular expression for me. I still need to describe what I want, so I need to write the instructions clearly. But all the gobbledygook that I’m writing for a machine now gets written by a machine. That seems fair.
Mind you, I wouldn’t blindly trust the output. I’d take that regular expression and run it through a chatbot, maybe a different chatbot running on a different large language model. “Explain what this regular expression does,” would be my prompt. If my input into the first chatbot matches the output of the second, I’d have some confidence in using the regular expression.
A friend of mine told me about using a large language model to help write SQL statements. He described his database structure to the chatbot, and then described what he wanted to select.
Again, I wouldn’t use that output without checking it first. But again, I might use another chatbot to do that checking. “Explain what this SQL statement does.”
Playing chatbots off against each other like this is kinda how machine learning works under the hood: generative adverserial networks.
Of course, the task of having to validate the output of a chatbot by checking it with another chatbot could get quite tedious. “I wish to God these large language model outputs had been validated by steam!”
Sounds like a job for machines.
This is a great step-by-step guide to HTML by Estelle.
The interactive widgets embedded in this article are excellent teaching tools!
All twelve are out, and all twelve are excellent deep dives into exciting web technologies landing in browsers now.
This is a superb explanation of flexbox—the interactive widgets sprinkled throughout are such a great aid to learning!
An internet-enabled kettle sounds stupid, but this is a genuinely thoughtful piece of hardware.
New from Mr. Vanilla JS himself, Chris Ferdinandi:
A learning space for people who hate the complexity of modern web development.
It’ll be $29 a month or $299 a year (giving you two months worth for free).
A personal site, or a blog, is more than just a collection of writing. It’s a kind of place - something that feels like home among the streams. Home is a very strong mental model.
I’d recommend going in the order HTML, CSS, JS. That way, you can build something in HTML, add CSS to it as you learn it, and finally soup it up with your new-found JS knowledge.
Excellent advice for anyone new to web develoment.
Once you start getting into interactive website territory, with API calls and fancy stuff, that’s where you need JavaScript (JS) knowledge. More specifically, vanilla JS: plain JS with no additional frameworks or plugins. The JS that your browser understands without having to do any pre-processing. It makes working with frameworks a whole lot easier, and it’ll help you to know when not to use a framework (and avoid making users download massive JS bundles when all you need is a tiny bit of code).
I like the split-screen animated format for explaining this topic.
This is a great tutorial—I just love the interactive parts that really help make things click.
A very handy collection of organised notes on all things JavaScript.
In a break with Betteridge’s law, I think the answer here is “yes.”
This is a great (free!) course on learning CSS from the basics up. Nicely-pitched explanations with plenty of examples.
I don’t think I agree with Don Knuth’s argument here from a 2014 lecture, but I do like how he sets out his table:
Why do I, as a scientist, get so much out of reading the history of science? Let me count the ways:
- To understand the process of discovery—not so much what was discovered, but how it was discovered.
- To understand the process of failure.
- To celebrate the contributions of many cultures.
- Telling historical stories is the best way to teach.
- To learn how to cope with life.
- To become more familiar with the world, and to know how science fits into the overall history of mankind.
Here’s a seven-year old post by Snook—this design engineer thing is not new.
This is a truly wonderful web page! It’s an explanation from first principles of how cameras and lenses work.
At its most basic, it uses words which you can read in any browser. It also uses images so if your browser supports images, you get that enhancement. And it uses interactive JavaScript widgets so that you get that layer of richness if your browser supports the technology.
Then you realise that every post ever published on this personal site is equally in-depth and uses the same content-first progressive enhancement approach.
I’ll be moderating this online panel next week with Emma Boulton, Holly Habstritt Gaal, Jean Laleuf, and Lola Oyelayo-Pearson.
There are still some spots available—it’s free to register. The discussion won’t be made public; the Chatham House Rule applies.
I’m looking forward to it! Come along if you’re interested in the future of design teams.
What will the near-future look like for design teams? Join us as we explore how processes, team structures and culture might change as our industry matures and grows.
This is a nifty visual interactive explainer for the language of CSS—could be very handy for Codebar students.