Full Width 
FOCUS MODE
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from pcloadletter
I write this blog because I enjoy writing. Some people enjoy reading what I write, which makes me feel really great! Recently, I took down a post and stopped writing for a few months because I didn't love the reaction I was getting on social media sites like Reddit and Hacker News. On these social networks, there seems to be an epidemic of "gotcha" commenters, contrarians, and know-it-alls. No matter what you post, you can be sure that folks will come with their sharpest pitchforks to try to skewer you. I'm not sure exactly what it is about those two websites in particular. I suspect it's the gamification of the comment system (more upvotes = more points = dopamine hit). Unfortunately, it seems the easiest way to win points on these sites is to tear down the original content. At any rate, I really don't enjoy bad faith Internet comments and I have a decent-enough following outside of these social networks that I don't really have to endure them. Some might argue I need thicker skin. I don't think that's really true: your experience on the Internet is what you make of it. You don't have to participate in parts of it if you don't want. Also, I know many of you reading this post (likely RSS subscribers at this point) came from Reddit or Hacker News in the first place. I don't mean to insult you or suggest by any means that everyone, or even the majority of users, on these sites are acting in bad faith. Still, I have taken a page from Tom MacWright's playbook and decided to add a bit of javascript to my website that helpfully redirects users from these two sites elsewhere: try { const bannedReferrers = [/news\.ycombinator\.com/i, /reddit\.com/i]; if (document.referrer) { const ref = new URL(document.referrer); if (bannedReferrers.some((r) => r.test(ref.host))) { window.location.href = "https://google.com/"; } } } catch (e) {} After implementing this redirect, I feel a lot more energized to write! I'm no longer worried about having to endlessly caveat my work for fear of getting bludgeoned on social media. I'm writing what I want to write and, if for those of you here to join me, I say thank you!
The older I get, the more I dislike clever code. This is not a controversial take; it is pretty-well agreed upon that clever code is bad. But I particularly like the on-call responsiblity framing: write code that you can understand when you get paged at 2am. If you have never been lucky enough to get paged a 2am, I'll paint the picture for you: A critical part of the app is down. Your phone starts dinging on your nightstand next to you. You wake up with a start, not quite sure who you are or where you are. You put on your glasses and squint at the way-too-bright screen of your phone. It's PagerDuty. "Oh shit," you think. You pop open your laptop, open the PagerDuty web app, and read the alert. You go to your telemetry and logging systems and figure out approximate whereabouts in the codebase the issue is. You open your IDE and start sweating: "I have no idea what the hell any of this code means." The git blame shows you wrote the code 2 years ago. You thought that abstraction was pretty clever at the time, but now you're paying a price: your code is inscrutable to an exhausted, stressed version of yourself who just wants to get the app back online. Reasons for clever code # There are a few reasons for clever code that I have seen over my career. Thinking clever code is inherently good # I think at some point a lot of engineers end up in a place where they become very skilled in a language before they understand the importance of writing clean, readable code. Consider the following two javascript snippets: snippet 1 const sum = items.reduce( (acc, el) => (typeof el === "number" ? acc + el : acc), 0 ); snippet 2 let sum = 0; for (const item of items) { if (typeof item === "number") { sum = sum + item; } } At one point in my career, I would have assumed the first snippet was superior: fewer lines and uses the reduce method! But I promise far more engineers can very quickly and easily understand what's going on in the second snippet. I would much rather the second snippet in my codebase any day. Premature abstraction # Premature abstractions tend to be pretty common in object-oriented languages. This stackexchange answer made me laugh quite a bit, so I'll use it as an example. Let's say you have a system with employee information. Well perhaps you decide employees are types of humans, so we'd better have a human class, and humans are a type of mammal, so we'd better have a mammal class, and so on. All of a sudden, you might have to navigate several layers up to the animal class to see an employee's properties and methods. As the stackexchange answer succinctly put it: As a result, we ended up with code that really only needed to deal with, say, records of employees, but were carefully written to be ready if you ever hired an arachnid or maybe a crustacean. DRY dogma # Don't Repeat Yourself (DRY) is a coding philosophy where you try to minimize the amount of code repeated in your software. In theory, even repeating code once results in an increased chance that you'll miss updating the code in both places or having inconsistent behavior when you have to implement the code somewhere else. In practice, DRYing up code can sometimes be complex. Perhaps there is a little repeated code shared between client and server. Do we need to create a way to share this logic? If it's only one small instance, it simply may not be worth the complexity of sharing logic. If this is going to be a common issue in the codebase, then perhaps centralizing the logic is worth it. But importantly we can't just assume that one instance of repeated code means we must eliminate the redundancy. What should we aim for instead? # There's definitely a balance to be struck. We can't have purely dumb code with no abstractions: that ends up being pretty error prone. Imagine you're working with an API that has some set of required headers. Forcing all engineers to remember to include those headers with every API call is error-prone. file1 fetch("/api/users", { headers: { Authorization: `Bearer ${token}`, AppVersion: version, XsrfToken: xsrfToken, }, }); fetch(`/api/users/${userId}`, { headers: { Authorization: `Bearer ${token}`, AppVersion: version, XsrfToken: xsrfToken, }, }); file2 fetch("/api/transactions", { headers: { Authorization: `Bearer ${token}`, AppVersion: version, XsrfToken: xsrfToken, }, }); file3 fetch("/api/settings", { headers: { Authorization: `Bearer ${token}`, AppVersion: version, XsrfToken: xsrfToken, }, }); Furthermore, having to track down every instance of that API call to update the headers (or any other required info) could be challenging. In this instance, it makes a lot of sense to create some kind of API service that encapsulates the header logic: service function apiRequest(...args) { const [url, headers, ...rest] = args; return fetch( url, { ...headers, Authorization: `Bearer ${token}`, AppVersion: version, XsrfToken: xsrfToken, }, ...rest ); } file1 apiRequest("/api/users"); apiRequest(`/api/users/${userId}`); file2 apiRequest("/api/transactions"); file3 apiRequest("/api/settings"); The apiRequest function is a pretty helpful abstraction. It helps that it is a very minimal abstraction: just enough to prevent future engineers from making mistakes but not so much that it's confusing. These kinds of abstractions, however, can get out of hand. I have see code where making a request looks something like this: const API_PATH = "api"; const USER_PATH = "user"; const TRANSACTIONS_PATH = "transactions"; const SETTINGS_PATH = "settings"; createRequest( endpointGenerationFn, [API_PATH, USER_PATH], getHeaderOverrides("authenticated") ); createRequest( endpointGenerationFn, [API_PATH, USER_PATH, userId], getHeaderOverrides("authenticated") ); There's really no need for this. You're not saving all that much for making variables instead of using strings for paths. In fact, this ends up making it really hard for someone debugging the code to search! Typically, I'd lok for the string "api/user" in my IDE to try to find the location of the request. Would I be able to find it with this abstraction? Would I be able to find it at 2am? Furthermore, passing an endpoint-generation function that consumes the path parts seems like overkill and may be inscrutable to more junior engineers (or, again, 2am you). Keep it as simple as possible # So I think in the end my message is to keep your code as simple as possible. Don't create some abstraction that may or may not be needed eventually. Weigh the maintenance value of DRYing up parts of your codebase versus readability.
Here we go again: I'm so tired of crypto web3 LLMs. I'm positive there are wonderful applications for LLMs. The ChatGPT web UI seems great for summarizing information from various online sources (as long as you're willing to verify the things that you learn). But a lot fo the "AI businesses" coming out right now are just lightweight wrappers around ChatGPT. It's lazy and unhelpful. Probably the worst offenders are in the content marketing space. We didn't know how lucky we were back in the "This one weird trick for saving money" days. Now, rather than a human writing that junk, we have every article sounding like the writing voice equivalent of the dad from Cocomelon. Here's an approximate technical diagram of how these businesses work: Part 1 is what I like to call the "bilking process." Basically, you put up a flashy landing page promising content generation in exchange for a monthly subscription fee (or discounted annual fee, of course!). No more paying pesky writers! Once the husk of a company has secured the bag, part 2, the "bullshit process," kicks in. Customers provide their niches and the service happily passes queries over to the ChatGPT (or similar) API. Customers are rewarded with stinky garbage articles that sound like they're being narrated by HAL on Prozac in return. Success! I suppose we should have expected as much. With every new tech trend comes a deluge of tech investors trying to find the next great thing. And when this happens, it's a gold rush every time. I will say I'm more optimistic about "AI" (aka machine learning, aka statistics). There are going to be some pretty cool applications of this tech eventually—but your ChatGPT wrapper ain't it.
I have noticed a trend in a handful of products I've worked on at big tech companies. I have friends at other big tech companies that have noticed a similar trend: The products are kind of crummy. Here are some experiences that I have often encountered: the UI is flakey and/or unintuitive there is a lot of cruft in the codebase that has never been cleaned up bugs that have "acceptable" workarounds that never get fixed packages/dependencies are badly out of date the developer experience is crummy (bad build times, easily breakable processes) One of the reasons I have found for these issues is that we simply aren't investing enough time to increase product quality: we have poorly or nonexistent quality metrics, invest minimally in testing infrastructure (and actually writing tests), and don't invest in improving the inner loop. But why is this? My experience has been that quality is simply a hard sell in bigh tech. Let's first talk about something that's an easy sell right now: AI everything. Why is this an easy sell? Well, Microsoft could announce they put ChatGPT in a toaster and their stock price would jump $5/share. The sad truth is that big tech is hyper-focused on doing the things that make their stock prices go up in the short-term. It's hard to make this connection with quality initiatives. If your software is slightly less shitty, the stock price won't jump next week. So instead of being able to sell the obvious benefit of shiny new features, you need to have an Engineering Manager willing to risk having lower impact for the sake of having a better product. Even if there is broad consensus in your team, group, org that these quality improvements are necessary, there's a point up the corporate hierarchy where it simply doesn't matter to them. Certainly not as much as shipping some feature to great fanfare. Part of a bigger strategy? # Cory Doctorow has said some interesting things about enshittification in big tech: "enshittification is a three-stage process: first, surpluses are allocated to users until they are locked in. Then they are withdrawn and given to business-customers until they are locked in. Then all the value is harvested for the company's shareholders, leaving just enough residual value in the service to keep both end-users and business-customers glued to the platform." At a macro level, it's possible this is the strategy: hook users initially, make them dependent on your product, and then cram in superficial features that make the stock go up but don't offer real value, and keep the customers simply because they really have no choice but to use your product (an enterprise Office 365 customer probably isn't switching anytime soon). This does seem to have been a good strategy in the short-term: look at Microsoft's stock ever since they started cranking out AI everything. But how can the quality corner-cutting work long-term? I hope the hubris will backfire # Something will have to give. Big tech products can't just keep getting shittier—can they? I'd like to think some smaller competitors will come eat their lunch, but I'm not sure. Hopefully we're not all too entrenched in the big tech ecosystem for this to happen.
More in science
In the village of Bellewstown, about 15 miles north of Dublin, Ireland, they still talk about what Barney Curley did back in 1975. It all happened during a horse race on the Hill of Crockafotha. It was just an amateur jockey race on a lazy summer day in a sleepy, remote town; it wasn’t meant to be anything special. The last thing anyone expected was to witness the making of history. The race in question occurred on 26 June 1975. Barney Curley–our protagonist, if you could call him that–owned one of the horses running later that day. But at the racecourse, as preparations were being made, Curley was nowhere to be seen. And not because he wasn’t in attendance–it was because he was taking great pains to stay out of sight. If the trackside bookmakers caught wind that he was at Bellewstown that day, or if they discovered that he was the owner of one of the horses, they would be on full alert, and take precautions with the wagers and odds. Curley had earned a reputation in horse racing circles–he was known to engage in some gambling shenanigans from time to time. But the shenanigan he was planning that day was his most ambitious to date, hands-down. As the spectators placed their wagers and settled in around the edge of the track for a pleasant afternoon of laid back horse racing, Curley was concealed in the thicket of gorse shrubs in the center section of the oval-shaped track. This particular infield wasn’t ideal for human occupation, it was all dust and thorns. Nevertheless he stood in his trademark felt fedora, shrouded by tall shrubbery, far from the other spectators, a pair of binoculars pressed to his eyes. In the distance the loudspeaker announced, “They’re off!” Curley tugged his hat down tight over his bald head as if he could hide inside of it, and peered through his field glasses toward the rumble of horse hooves. In the next five minutes, if everything went according to plan, all of Barney Curley’s considerable money troubles would be over. If the plan went sideways–if his animal was not up to the task, or there was one inopportune stumble–he would be utterly ruined. Continue reading ▶
Recent progress on both analog and digital simulations of quantum fields foreshadows a future in which quantum computers could illuminate phenomena that are far too complex for even the most powerful supercomputers. The post Analog vs. Digital: The Race Is On To Simulate Our Quantum Universe first appeared on Quanta Magazine
Do these ideas give you the ick? Or is there something interesting here
Have you ever tried programming with a language that uses musical notation? What about a language that never runs programs the same way? What about a language where you write code with photographs? All exist, among many others, in the world of esoteric programming languages, and Daniel Temkin has written a forthcoming book covering 44 of them, some of which exist and are usable to some interpretation of the word “usable.” The book, Forty-Four Esolangs: The Art of Esoteric Code, is out on 23 September, published by MIT Press. I was introduced to Temkin’s work at the yearly Free and Open source Software Developer’s European Meeting (FOSDEM) event in Brussels in February. FOSDEM is typically full of strange and wonderful talks, where the open-source world gets to show its more unusual side. In Temkin’s talk, which I later described to a friend as “the most FOSDEM talk of 2025,” he demonstrated Valence, a programming language that uses eight ancient Greek measuring and numeric symbols. Temkin’s intention with Valence was to emulate the same ambiguity that human language has. This is the complete opposite of most programming languages, where syntax typically tries to be explicit and unambiguous. “Just as you could create an English sentence like, ‘Bob saw the group with the telescope,’ and you can’t quite be sure of whether it’s Bob who has the telescope and he’s seeing the group through it, or if it’s the group that has the telescope,” he says. “What if we wrote code that way so you could write something, and now you have two potential programs? One where Bob has a telescope and one where the group has a telescope.” How Esoteric Languages Spark Creativity Creating a language or an interpreter has often been the proving ground of many engineers and programmers, and esoteric languages are almost as old as non-esoteric ones. Temkin says his current effort has a lot to do with AI-generated code that seeks to do nothing but provide seemingly straight solutions to problems, removing any sense of creativity. Esoteric languages inherently make little sense and frequently serve little purpose, making them conceptually completely counter to AI-generated code and thus often not even understood by them—almost the code equivalent of wearing clothing to confuse facial recognition software. While the syntax of esoteric languages may be hard to understand, the actual programming stack is often wonderfully simple. Temkin believes that part of the appeal is also to explore the complexity of modern programming. “I come back a lot to an essay by Joseph Weizenbaum, the creator of the Eliza Chatbot, about compulsiveness and code,” he says. “He described ‘the computer bomb,’ the person who writes code and becomes obsessed with getting everything perfect, but it doesn’t work the way they want. The computer is under their control. It’s doing what they’re telling it to do, but it’s not doing what they actually want it to do.” “So they make it more complicated, and then it works the way they want,” Temkin adds. “This is the classic bind in programming. We command the machine when we’re writing code, but how much control do we really have over what happens? I think that we’re now all used to the idea that much of what’s out there in terms of code is broken in some way.” Temkin explored the idea of control in his language Olympus, where the interpreter consists of a series of Greek gods, each of which will do specific things, but only if asked the right way. Temkin’s Olympus language includes an interpreter consisting of Greek gods, which must be asked to do things in the proper way.Daniel Temkin “One example regarding complicating our relationship with the machine and how much we’re in control is my language, Olympus, where code is written to please different Greek gods,” says Temkin. “The basic idea of the language is that you write in pseudo-natural language style, asking various Greek gods to construct code the way that you want it to be. It’s almost as if there’s a layer behind the code, which is the actual code. “You’re not actually writing the code,” Temkin adds. “You’re writing pleas to create that code, and you have to ask nicely. For example, if you call Zeus father of the gods, you can’t call him that again immediately because he doesn’t think you’re trying very hard.” “And then of course, to end a block of code, you have to call on Hades to collect the souls of all the unused variables. And so on,” Temkin says. The History of Esoteric Programming Languages Temkin continues a long-running tradition: esoteric languages date back to the early days of computing, with examples such as INTERCAL (1972), which had cryptic syntax, meaning coders often needed to plead with the compiler to run it. The scene gained momentum in 1993, with Wouter van Oortmerssen’s FALSE, in which most syntax maps to a single character. Despite this, FALSE is a Turing-complete language that allows creating programs as complex as any contemporary programming language. Its syntactical restrictions meant the compiler (which translates the syntax to machine-readable instructions) is only 1 kilobyte, compared to C++ compilers, which were generally hundreds of kilobytes. Exploring further, Chris Pressey wondered why code always had to be written from left to right and created Befunge in 1993. “It took the idea of the single-character commands and said if you’re going to have commands that are only one letter, why do we need to read it left to right?” says Temkin. “Why can’t we have code move a little bit to the right, then turn up, and then go off the page and come up off the bottom and so on?“ So Pressey decided to create a language that would be the most difficult language to build a compiler for,” Temkin continues. “I believe that was the original idea, allowing the code to turn in different directions and flow across the space.” Much of the mid-90s trend coincided with the rise of shareware, the demo scene, and the nascent days of the Internet, when it was necessary to program everything to be as small as possible to share it. “There’s definitely a lot of crossover between these things because they involve this kind of artistry, but also a kind of technical wizardry in showing, ‘Look how much I can do with this really minimal program,’” Temkin says. “What really interested me in esoteric languages specifically is the way that it’s community-based,” Temkin says. “If you make a language, it’s an invitation for other people to use the language. And when you make a language and somebody else shows you what’s possible to do with your language or discovers something new about it that you couldn’t have foreseen on your own.” One of Temkin’s esoteric languages uses a cuneiform script.Daniel Temkin You can play with many of Daniel’s languages on his website, as well as the Esoteric Languages Wiki, which raises the question: In the modern connected age, how does one create a shareable esoteric language? “It’s something that I’ve changed my attitude about over the years,” says Temkin. “Early on, I thought I had to write a serious compiler for my language. But now I think what’s really important is that people across different platforms and spaces can use it. So in general, I try to write everything in JavaScript when I can and have it run in the browser. If I don’t, then I tend to stick with Python as it has the largest user base. But I do get a little bored with those two languages.” “I realize there’s a certain irony there,” Temkin adds.
France built forty nuclear reactors in a decade. Here's what the world can learn from it.
