Madra Teanga - Open Source Irish Language Programming
An open source project that has already produced a great app for learning Irish—programmed in a language called Draíocht (sin “magic” as Béarla)!
I’m supporting this on Open Collective.
An open source project that has already produced a great app for learning Irish—programmed in a language called Draíocht (sin “magic” as Béarla)!
I’m supporting this on Open Collective.
Large language models help you build the thing faster, which is the primary end goal for your company but only sometimes for you. My primary goal might be to build the thing faster, but it also might be to learn something durably, to enjoy the work, to look forward to Monday.
I don’t like the mental fragility of not fully understanding how my own code works, where AI-generated code is “mine” in that it’s attributed to me in the git blame and I’m its maintainer going forward.
You know my thoughts on generative tools based on large language models, but this example of personal empowerment is undeniably liberating.
I’ve had a lot of people recently tell me AI is “inevitable.” That this is “the future” and “we all better get used to it.”
For the last decade, I’ve had a lot of people tell me the same thing about React.
And over that decade of React being “the future” and “inevitable,” I worked on many, many projects without it. I’ve built a thriving career.
AI feels like that in many ways. It also feels different in that non-technical people also won’t shut the fuck about it.
We value learning. We value the merits of language design, type systems, software maintenance, levels of abstraction, and yeah, if I’m honest, minute syntactical differences, the color of the bike shed, and the best way to get that perfectly smooth shave on a yak. I’m not sure what we’re called now, “heirloom programmers”?
Do I sound like a machine code programmer in the 1950s refusing to learn structured programming and compiled languages? I reject that comparison. I love a beautiful abstraction just as much as I love a good low-level trick.
If the problem is that we’ve painted our development environments into a corner that requires tons of boilerplate, then that is the problem. We should have been chopping the cruft away and replacing it with deterministic abstractions like we’ve always done. That’s what that Larry Wall quote about good programmers being lazy was about. It did not mean that we would be okay with pulling a damn slot machine lever a couple times to generate the boilerplate.
My social networks are currently awash with Deep Blue:
…the sense of psychological ennui leading into existential dread that many software developers are feeling thanks to the encroachment of generative AI into their field of work.
The issue isn’t with the code itself, but with the understanding of the code.
That’s the difference between technical debt and cognitive debt.
There are two wolves inside you…
My Builder side won’t let me just sit and think about unsolved problems, and my Thinker side is starving while I vibe-code. I am not sure if there will ever be a time again when both needs can be met at once.
The hard part of computer programming isn’t expressing what we want the machine to do in code. The hard part is turning human thinking – with all its wooliness and ambiguity and contradictions – into computational thinking that is logically precise and unambiguous, and that can then be expressed formally in the syntax of a programming language.
That was the hard part when programmers were punching holes in cards. It was the hard part when they were typing COBOL code. It was the hard part when they were bringing Visual Basic GUIs to life (presumably to track the killer’s IP address). And it’s the hard part when they’re prompting language models to predict plausible-looking Python.
The hard part has always been – and likely will continue to be for many years to come – knowing exactly what to ask for.
’80s BASIC type-in mags are back, but this time for HTML!
10 wonderful web apps, including games, toys, puzzles and utilities
No coding knowledge needed, you just type
I prefer my tools to help me with repetitive tasks (and there are many of those in programming), understanding codebases, and authoring correct programs. I take offense at products that are designed to think for me. To remove the agency of my own understanding of the software I produce, and to cut connections with my coworkers. Even if LLMs lived up to the hype, we would still stand to lose all of that and our craft.
When you vibe code, you are incurring tech debt as fast as the LLM can spit it out. Which is why vibe coding is perfect for prototypes and throwaway projects: It’s only legacy code if you have to maintain it!
The worst possible situation is to have a non-programmer vibe code a large project that they intend to maintain. This would be the equivalent of giving a credit card to a child without first explaining the concept of debt.
If you don’t understand the code, your only recourse is to ask AI to fix it for you, which is like paying off credit card debt with another credit card.
- Install Stuff Indiscriminately From npm
- Pick a Framework Before You Know You Need One
- Always, Always Require a Compilation Step
The short version of what I want to say is: vibe coding seems to live very squarely in the land of prototypes and toys. Promoting software that’s been built entirely using this method would be akin to sending a hacked weekend prototype to production and expecting it to be stable.
Remy is taking a very sensible approach here:
I’ve used it myself to solve really bespoke problems where the user count is one.
Would I put this out to production: absolutely not.
This is a really thoughtful look at the evolution of CSS and the ever-present need to balance power with learnability.
I really like the thinking behind this project:
We believe computers should work for people, and dream of a future where computing, like cooking or word processing, is available to everyone. Where you can solve your own small, unique problems with small, unique apps. Where you don’t just rely on mass-market apps made by expert programmers. Where you share home-made little apps with family and friends.
Scrappy is our contribution to this dream.
We’re at a point in the most ecosystems where pulling in libraries is not just the default action, it’s seen positively: “Look how modular and composable my code is!” Actually, it might just be a symptom of never wanting to type out more than a few lines.
It always amazes me when people don’t view dependencies as liabilities. To me it feels like the coding equivalent of going to a loan shark. You are asking for technical debt.
There are entire companies who are making a living of supplying you with the tools needed to deal with your dependency mess. In the name of security, we’re pushed to having dependencies and keeping them up to date, despite most of those dependencies being the primary source of security problems.
But there is a simpler path. You write code yourself. Sure, it’s more work up front, but once it’s written, it’s done.
The moment you run LLM generated code, any hallucinated methods will be instantly obvious: you’ll get an error. You can fix that yourself or you can feed the error back into the LLM and watch it correct itself.
Compare this to hallucinations in regular prose, where you need a critical eye, strong intuitions and well developed fact checking skills to avoid sharing information that’s incorrect and directly harmful to your reputation.
With code you get a powerful form of fact checking for free. Run the code, see if it works.
Working on this project is great but ten minutes into it and I already miss the resilience of the web. I miss how you have to really fuck things up to make a browser yell at you or implode.
Detective stories and tales of bughunting in software and hardware.
Sometimes bugs have symptoms beyond belief. This is a collection of such stories from around the web.