https://www.petemillspaugh.com/
Classic from my old Haskell professor: https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...
HN user
Spreading the joy of programming
val.town | stevekrouse.com
https://www.petemillspaugh.com/
Classic from my old Haskell professor: https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...
Ah damn, sorry about that. I removed my footer "ads" in response to this feedback. Appreciate it.
back online!
I don't disagree with anything you just said
Isaac!!!!! I had no idea that was you! Too funny! Emily and I are dying
Yes, we'd love to visit!
I think we're in agreement. My Dijkstra quote is the perfect rejoinder to your Wittgenstein:
The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.
— Edsger Dijkstra
Such a perfect quote! Thank you! Will add it to my collection
Genuine!
That's not my argument at all! Though I can see why you took that away; my bad for not making my argument clearer.
I believe that even when we have AGI, code will still be super valuable because it'll be how we get precise abstractions into human heads, which is necessary for humans to be able to bring informed opinions to bear.
Fair! I appreciate the reply.
Sick!!! Great example! I'm actually a longtime friend and angel investor in Dustin but I hadn't seen this
Any writer who admits that they are actively working towards having a machine write their material has lost me as a potential reader.
I partly understand this perspective. I think it gets at 'proof of work' – if you can forgive me borrowing a concept from crypto. Nobody wants to be on the receiving end of a low-effort output. That's just embarrassing.
For example, I am constantly getting fairly decent spam emails, but I literally never respond because that would be so lame. No matter how good spam emails get, I won't reply.
My investor Dan Levine says that in order to get a reply for a cold email you have to pass a mini Turing Test embedded in the email. This is increasingly hard as we approach AGI, defined as the point at which machine intelligence becomes indistinguishable from human intelligence. But I still think it's possible, but hard work and definitionally unscalable. (If you find a way to scale it, readers will learn to build up defenses against it. It's a never-ending arms race.)
But relying on human-written writing as the proof-of-work is limited in two ways:
1. When we do reach AGI, it will, definitionally, no longer be possible. CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) definitionally don't make sense in a world where you can't tell humans and machines apart. 2. It's a limited way to measure 'proof of work'.
There should be other ways to show 'proof of work'. The easiest example is money. Imagine if there was a frictionless way to pay $10 or $100 to send someone an email. Or attach $10 or $100 in cash to an email as a thank-you to the recipient for reading it. This kinda already exists in that you can buy time with famous people on various marketplaces or pay $1m to charity to get lunch with Warren Buffett. (Buffett ended up hiring one guy who did this!)
So yes, nobody wants to be a dupe, and if I mass produce a lot of writing (even if it's super high quality), I would deserve to lose readers. So I'd never do that.
Instead, if I had AI that could write in my voice as well as me, I'd use it to help me dramatically improve the quality of my writing. I'd keep my effort constant, and the quality bar would go way up. Ideally, it'd be a gift to you, my potential reader.
How does that land?
The important part of MCP (that this misses) is that it's a machine interface you can quickly iterate on. In other words, an API is too slow-moving. You can't break it; it's a promise. A UI is too annoying for an LLM to deal with. An MCP is the perfect middleground: speaks JSON, but there's inference involved, so if you change the tools, the LLM will be just fine. (Just like how you can change your UI much faster than you change your API, because there's inference at runtime, ie in the human brain.)
For example, at my startup val.town, our MCP server is way more powerful than our API, because we added a bunch of tools to it willynilly because we're not worried about having to be stuck with those tools forever. We can remove them and nobody's code will break. (Just like we could remove buttons in our UI.) But an API change needs to be thought-through.
Cool!!
Val Town | https://val.town | NYC | Full time | ONSITE
Do you love programming? Do you love developers tools?
Consider working at Val Town. We're a small startup (currently three people) building a developer tool that makes programming as simple and fun as possible.
I still can't find it him! More help would be very appreciated
Helpful!
https://minecraft.wiki/w/Diamond_Pickaxe
Also useful to know you need to arrange them in that order
The people behind KSON are geniuses. No joke. I worked with Daniel. And he's an amazing human too. Congrats on launching!!!
Yeah I definitely agree. I'm specifically talking about things you're not shipping or charging money for. Just little personal apps for you and friends or you and work colleagues. Internal tools, etc.
Strong agree! For example, we at Val Town just invested very heavily in getting a good ol' fashioned language server to work in our product to power hover-overs and type information in our web editor. That'll likely be our next company blog post...
The argument is that if you intent to maintain the code you should keep the AI on a very tight leash, and at least understand the architecture of the code, if not every line.
Vibe coding is allowing everyone (including me!) to make way more apps in my personal life that are very throwaway. I think some folks are doing this in business contexts too. But this is a real game-changer for non-technical folks
Thanks Simon!!
Fair! I agree that we want as little code as we can get away with. We love pull requests with a lot of red (deleted lines).
Like you say about libraries, it is possible to have code that isn't your problem. It's all about how leaky the abstraction is. Right now LLMs write terrible abstractions, and it's unclear how long it'll take for them to get good at writing good code.
I am excited to invest more in tools to make the understanding of code easier, cheaper, and more fun. My friend Glen pointed one way in this direction: https://glench.github.io/fuzzyset.js/ui/
As Geoffrey Litt likes to say, LLMs can help with this by building us throwaway visualizers and debuggers to help us understand our code.
Author here - very excited to chat with you all about this :)
Such a great essay! Peter Naur's thesis is also the central point in my talk about vibe coding from last month: https://www.youtube.com/watch?v=1WC8dxMC4Xw
I'm spending an inordinate amount of time turning that video into an essay, but I feel like I'm being scooped already, so here's my current draft in case anyone wants to get a sneak preview: https://valdottown--89ed76076a6544019f981f7d4397d736.web.val...
Feedback appreciated :)
My top choice for this kind of thing in 2025 is GitHub, using GitHub Pages. It's free for public repositories and I haven't seen GitHub break a working URL that they have hosted in the 17+ years since they first launched.
A few years ago I'd have recommended Heroku on the basis that their free plan had stayed reliable for more than a decade, but Salesforce took that accumulated goodwill and incinerated it in 2022.
As someone building a new hosting provider with a free tier (https://val.town) it's so lovely to see folks like Simon value long-term stability. It makes it easier to make the business case to invest in it. At the end of the day, it's all about trust.
There's a val (hosted function) that does this too!
Thanks!
Thanks!