buildless evergreen

How One Programmer Broke the Internet By Deleting a Tiny Piece of Code - an article on the history that led to the trivial "left-pad" module being removed and causing all those problems by the removal a while back. Obviously raising the question, how much is too much when it comes to depending on modules and additional libraries to do all the heavy lifting?

I'm getting better at framing the divide between my work for Enterprise, and my personal project work. That rift of technologies used has grown wider over the years, though my personal project stuff - having to take on the full stack and the complete UX/UI experience - is still a huge boon to what I bring to the table for "real jobs"

Two buzzwords for one-person-shop, long term side project works that don't apply to most enterprise efforts: "buildless" and "evergreen". Sticking with tech that is likely to stay well-supported, you minimize dependencies on third parties. For me, that means - HTML/CSS/JS that the browser supports natively (browsers are truly impressive in advancing in power at a stately pace while maintaining brilliant backwards compatibility), often it means static HTML or PHP - while some people scoff, sticking with core PHP allows me to keep just one business relationship for deploying my code and maintaining my legacy sites, and the scripting paradigm PHP uses - a clean start every time - is very amenable to thinking in terms of functional programming, despite the ugliness of its APIs.

Again, Enterprise usually finds it better to invest in good toolkits and libraries and build systems, they can take on the cost of hiring people to make a code base an ongoing concern, and it's generally worth the complexity to make sure developers are meeting the company's needs by answering the basic problems in idiomatic ways. But when I want to write code that just works for my needs reliably over years and is usually pretty easy to edit when it some functionality needs to be added, the rules of "KISS" really apply.

bugs bugs bugs

Fun, fast pasted overview of some infamous software bugs, going into details as to the logic that caused the error when possible.

SPOILER for the video's ending joke:

"There are two ways to write error-free programs; only the third one works."

--Alan J. Perlis

That reminds me of how there is a divide on how much emphasis should be put on units-in-isolation testing vs holistic, parts-communicating-in-their-contexts. Both are needed. The former is usually cheaper to put into automated systems, but the "test all hundred trees and have confidence that the forest is sound" alone idea misses the concept of emergent properties of interconnected systems...

on buildless testing

On Buildless Testing - so i don't know if "buildless" will ever make a lot of waves in enterprise - but for hobbyist coding, or any time when you need to have some thing last for years but may need to come back to it later - it has real merit. Very interesting piece on how to get testing going under that (along with another seeimingly unpopular view I share, that sometimes too much emphasis is placed on unit testing, which so often is just a redundant test of implementation (or of mocks!) rather than of functionality in a meaningful context...)

 

Is ChatGPT the Coke of LLM?

Interesting article on the likely future marketing landscape for LLMs. Cal Peterson argues it's more like airlines - severe supplier seller's market (NVIDIA), low barrier of entry for new competitors, weak brand loyalty - than it is like Coke, which is just a flavor/branding play.

I wonder if there's a way for an LLM to stand out and attract specific Coke-brand loyalties via virtual personality, and/or a clear difference in what level of problem it can solve? I'm a little loyal to ChatGPT, in part because I started paying for it early, and also early I realize I prefer LLMs to be in their little sandboxes vs deeply coupled and nested in my editor. (In one case, trying to override its code suggestions for a simple import in VS Code, overwhelming where the old auto-complete was trying to do the job, left a very bad taste in my mouth.))

I guess with LLMs too... it's always tough to be sure there's no unseemly corporate agenda for any given one. Especially since most often the processing is remote anyway, you can never have that sense of "I know this AI is just working for me."