Live data from Hacker News

The Tower Keeps Rising

lucumr.pocoo.org

271–280 of 280 posts

Re: The Tower Keeps Rising

#272
post #188
post #6

I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear. I feel like that gives an even more literal tower-rising metaphor, and that's what it feels like people using agents naively (and software engineers of lower skill or earlier-career), end up violating. Agents are getting better at folding things into themselves, especially if you direct them to... but unfor…

> I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear. Great metaphor. When I hear people claim 20x productivity with AI assistance, I imagine a Tetris game where pieces fall 20x faster. As you say, those lines still have to clear.

Also through LLMs we now have pieces that are strangely-shaped and are 20x larger...

That probably would not be a fun game to play lol

Re: The Tower Keeps Rising

#273
post #27

The core thesis of this essay is reminiscent of the Lisp Curse [1] / Bipolar Lisp Programmer [2]. It's been a few years since I read these, but if I recall the argument there, it was that Lisp makes it so easy to build stuff and scratch exactly your own itch, that there's no real strong push for lisp programmers to come together and collaborate to build non-trivial and general purpose artifacts. And that is why the l…

I felt the same on Feb. Wrote a blog about it

https://blog.est.im/2026/stderr-06

https://news.ycombinator.com/item?id=46669591

Re: The Tower Keeps Rising

#274
post #6

I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear. I feel like that gives an even more literal tower-rising metaphor, and that's what it feels like people using agents naively (and software engineers of lower skill or earlier-career), end up violating. Agents are getting better at folding things into themselves, especially if you direct them to... but unfor…

> I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear.

I love this analogy, and I find it darkly hilarious that most sibling commenters don't seem to understand. Maybe you need to have worked within a million-line codebase to get it.

The only way to "clear the lines" in software is to eject them from the main codebase and into imported libraries with stable, well-documented, well-tested APIs that you very rarely if ever (security vulnerabilities?) need to touch after "stabilizing" them. Great public examples: the Go standard library, https://github.com/spf13/viper , https://github.com/uber-go/zap . Viper and zap combined are more than 20,000 lines of code (according to cloc) that I don't need to read or understand how they work - their lines have been "cleared" and all I need to know is the abstraction.

Half the joy to be found when working within massive codebases is successfully clearing lines.

Re: The Tower Keeps Rising

#275

Earlier quoted context omitted.

And what's ironic is that a lot of those layers and complexity were added with the stated goal of making it easier for average developers to build applications.

That is the nominal motive, but I think that the real motive is that it makes it easier for average developers to pile on more complexity. Back in the day we just accepted technical constraints that didn’t prevent us from doing anything mission critical. So the UIs weren’t paragons of personal expression, probably there was only one database which didn’t have any scale out features at all, and nothing scrolled infini…

Yeah, I think a lot of what web tech makes possible/standard in a UI is actually frequently things that add a lot of complexity with little actual value. Animations, a widget that looks different from the thousands of other widgets you use daily that do the same thing, non-standard behavior, etc. Computers are ironically much harder to use now than they were in like 2000, and it's not that they're doing things that are fundamentally way more complicated, it's just a lot of bullshit that isn't entirely neccessary

Re: The Tower Keeps Rising

#278

Earlier quoted context omitted.

That is the nominal motive, but I think that the real motive is that it makes it easier for average developers to pile on more complexity. Back in the day we just accepted technical constraints that didn’t prevent us from doing anything mission critical. So the UIs weren’t paragons of personal expression, probably there was only one database which didn’t have any scale out features at all, and nothing scrolled infini…

Yeah, I think a lot of what web tech makes possible/standard in a UI is actually frequently things that add a lot of complexity with little actual value. Animations, a widget that looks different from the thousands of other widgets you use daily that do the same thing, non-standard behavior, etc. Computers are ironically much harder to use now than they were in like 2000, and it's not that they're doing things that a…

Yes. Just this evening I had to help my mom. She was convinced a web form she needed to fill out was broken.

The problem was a required input control was so heavily styled that it was genuinely difficult to recognize it as interactive. Possibly impossible for my mom, whose eyes aren’t what they used to be.

And, in place of traditional validation design language, they decided to just make the submit button invisible until the input validated.

The worst part is, someone is probably quite proud of the extra day or two they spent making sure that UI was broken.

Re: The Tower Keeps Rising

#279
post #269

Earlier quoted context omitted.

And it shows!

Yeah? It's not polished enough for you? Please show me the level of polish of your two-day projects.

You’re the one claiming a 10x-100x productivity boost. Does that boost not apply when it comes time to polish?

Re: The Tower Keeps Rising

#280

> The shared language of a software project is not English or Python but it is the common understanding of what its concepts mean, where the boundaries are, which invariants matter, who owns what, and why the system has the shape it does. This language is rarely written down in one place. It lives partly in documentation and code, but also in code review, conversations, arguments, and the experience of having to expl…

Here is the “internal” pattern language I started on “patterns for building software projects with AI”: https://github.com/apinstein/pattern-language-building-with-...

It’s mostly AI-written patterns based on my personal prompts/observations.

And here is the skill for organizing the pattern languages for a single project:

https://github.com/apinstein/skills/tree/main/skills/pattern...

I haven’t really battle tested these so hard yet but it’s a fun concept and really should get back to organizing them more intentionally. Happy to share this early phase just cause it’s cool to see the interest.

Post reply on HN