Live data from Hacker News

The Tower Keeps Rising

lucumr.pocoo.org

241–250 of 280 posts

Re: The Tower Keeps Rising

#241

Earlier quoted context omitted.

I feel like with software, things have gotten way too complicated (just layer's upon layers upon layers). But to deal with that complexity, now we're using something that just creates WAY more complexity. I've been coding for a while, and I remember the 90s and early 00s where people could make pretty powerful applications with like visual basic or php with essentially no formal training. Those technologies weren't g…

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 infinitely. And I do think that tended to make things easier to fit into your head, because the number of distinct APIs and module interactions you needed to understand was much smaller.

But also none of it was integrated with Alexsirtanapilot, so everyday life was an endless misery.

Re: The Tower Keeps Rising

#242
This reminded me of Naur's "Programming as Theory Building" [1], the article's "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" is Naur's theory, and the author's "friction" is what teams build that theory.

I guess whether AI written code means you can't build a theory of a program is an open question - but I don't see why you can't have AI written code that keeps the system knowable and extendable, in the same way that any long lived program or system can be. It's _just_ a question of being disciplined in the same way you'd need to be with developing and maintaining any long lived artefact.

[1] https://pages.cs.wisc.edu/~remzi/Naur.pdf

Re: The Tower Keeps Rising

#243

Earlier quoted context omitted.

I have a vaguely-relevant war story. 1998 - Huge business, re-writing some vital piece of the platform in the middle of Y2K. Contract coders are expensive but also the only available people to throw at this. The architect had mapped out the entire system down to class/method level. They'd produced a huge list of classes and methods that needed to be built. So the company hired a bunch of contract coders to build said…

Crazy to think that if it was specced out so well, a modern LLM would make short work of the whole thing. The things we used to get paid for!

lolol you're joking right? as a joke it's funny. If you think thats really what it sounds like when a project's design is well-understood... ... ...

Re: The Tower Keeps Rising

#244

Earlier quoted context omitted.

Why don't you do that, since you're the one who has no idea what will happen?

I was referring to you referencing “my toddler” but I suppose if reading is not your forte suggesting you use an LLM isn’t helpful. My mistake.

If that's what you consider a reasonable argument for a rationally-held position, then other sites beckon.

But then it's hardly a rationally-held position, unless you have had no exposure to LLMs in the past year or two.

Re: The Tower Keeps Rising

#245
I love the line “This friction synchronizes people.”

Part of the understanding that is missed being learned by the team are the failure modes: how can this system fail and how catastrophic is it?

Now I fear only the users will learn via data loss, leaks, and hacks.

Re: The Tower Keeps Rising

#246

Earlier quoted context omitted.

But if all the tests pass, does it matter what's inside?

Unfortunately the tests can't (usually) cover all behaviours. And perhaps more importantly, they don't capture more abstract properties of the code like maintainability. AI works best in well maintained code, but unless care is taken, the AI will (today, anyway) make the code less well maintained as it goes. If the AI is allowed to introduce mess into the codebase faster than its ability to deal with the mess increas…

And that's kind of the point, some manual testing is always needed - even when humans write the code.

But you can test things and behaviours to a sufficient degree. Nobody really does 100% test coverage on real world code (outside of medical, airplanes and space of course).

Re: The Tower Keeps Rising

#247

Earlier quoted context omitted.

But if all the tests pass, does it matter what's inside?

Yes, of course it does. It's strange to me that this can be asked.

Why? How far do you take this, do you inspect the inside of every single thing and program you use?

Your microwave promises to heat your food at 800W for 1 minute, do you open it up and measure the magnetometer strength? Do you double-check the timer that it's accurate?

You want a program that takes in A and returns B within X milliseconds, I deliver it to you. Do you spend the time going through the whole program line by line to see how it was made or do you trust it?

Or when you buy a car do you take it to a garage and dismantle it to see whether it was correctly assembled in the factory? Or do you trust them?

Re: The Tower Keeps Rising

#248

Earlier quoted context omitted.

Actually now we care even more. The reason people didn't write extensive test suites was was because it's super fucking boring to do so. AIs don't care, they'll happily write 50 unit tests with slight variations and pair them with a full dockerized end to end test suite. Now we have at least SOME tests. Are they good? Maybe, maybe not - but we have them. If one of them fails later on, we can check if it's an actual i…

Having slop tests instead of no tests is definitely not the same thing as actually caring about avoiding bugs.

This is not about caring. This is about the real world where actual human programmers usually don't want to spend any extra time writing test suites or management doesn't give them the time to do so.

So if the starting point is "no tests", having a bunch of "slop tests" is better, right?

Re: The Tower Keeps Rising

#249

Earlier quoted context omitted.

I was referring to you referencing “my toddler” but I suppose if reading is not your forte suggesting you use an LLM isn’t helpful. My mistake.

If that's what you consider a reasonable argument for a rationally-held position, then other sites beckon. But then it's hardly a rationally-held position, unless you have had no exposure to LLMs in the past year or two.

I run them locally. You never addressed personally attacking a toddler you assume I have. As you put it, other sites beckon. Take care

Re: The Tower Keeps Rising

#250

Earlier quoted context omitted.

I can't prove it but I have strong beliefs that the logic and intuition required for abstracting for future changes is not possible in a stream of predicted tokens. Mental models aren't built from text. Something's missing that can't be measured.

I believe similar. Maybe not exactly the same thing, but I think one related representation of this in any good codebase is documentations in the code: Good documentation always focuses on the why and not the what. i.e. things that are not represented by or representable in code. It may describe not only why a certain choice was made, but also why not something else. In general, the whole point of these documentation…

I can't really explain it but when I am working with a system in my head it's not represented as text. It has an almost physical dimension to it similar to imagining how an engine works or what have you. This is obviously beyond the grasp of an LLM.
Post reply on HN