Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tower Keeps Rising

lucumr.pocoo.org

Post reply on HN
Print view View original

231–240 of 280 posts

Re: The Tower Keeps Rising

#231

Post by timothycoleman »

theshrike79 wrote: post #229
Cthulhu_ wrote: post #206

Earlier quoted context omitted.

If the "soul" of a program (which is a vague term but I think I get what you mean) changes daily, that's indicative of a lot of churn, and a lot of churn is not a good idea in any project. it's like changing how the tower of babel should be built daily. Just because you can doesn't mean you should.

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 increases, the codebase will eventually run into a problem that it's hard to recover from.

Re: The Tower Keeps Rising

#232

Post by timothycoleman »

peter_retief wrote: post #210

It is a great analogy. Also quite like Linus Torvalds likening of AI to a compiler. He argues that calling AI the "author" of code is the equivalent of saying a compiler wrote your code. He views AI as an incredibly powerful productivity layer, much like the historic progression from machine code to assemblers, and then to higher-level compilers!

An important difference is the code precisely expresses many behaviours of the program, and a correct compiler guarantees to respect those behaviours.

An AI prompt is not so precise, and an AI offers no such guarantees to respect the behaviours expressed.

This is why the primary artifact of the development process, which we review and version control, is still the code, and not the prompt.

That said, I do think there's a lot of value to be gained by recording and analysing the prompt/response loop behind the code that ends up in a codebase

Re: The Tower Keeps Rising

#233

Post by timothycoleman »

permalac wrote: post #213
peter_retief wrote: post #210

It is a great analogy. Also quite like Linus Torvalds likening of AI to a compiler. He argues that calling AI the "author" of code is the equivalent of saying a compiler wrote your code. He views AI as an incredibly powerful productivity layer, much like the historic progression from machine code to assemblers, and then to higher-level compilers!

Shall we be concerned that not many are even able to read assembler code? I'm not talking about reading machine code, produced by the assembler, but the assembler code itself. Machine code was hard, but one could make it pretty efficient. Not efficiently. Assembler was still pretty performant, for today's standard it is tip top. So, moving on 10, 20 years from now, can someone read c++? Even html?

I think whoever is responsible for the correct operation of a software system will still need to read something that precisely describes the behaviours that they care about.

Today, for most devs, thats the code. We usually don't need to look at compiled output, because the code is enough. We can't just look at the prompts, because they aren't precise enough.

Re: The Tower Keeps Rising

#234

Post by zahlman »

theshrike79 wrote: post #228
Xirdus wrote: post #14

Earlier quoted context omitted.

The biggest obstacle to huge refactoring has always been minimizing the risk of bugs, not losing any features, and ensuring compatibility with the existing ecosystem. The reason it's become easier in the age of AI is because we stopped caring about these things.

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.

Re: The Tower Keeps Rising

#235

Post by zahlman »

theshrike79 wrote: post #229
Cthulhu_ wrote: post #206

Earlier quoted context omitted.

If the "soul" of a program (which is a vague term but I think I get what you mean) changes daily, that's indicative of a lot of churn, and a lot of churn is not a good idea in any project. it's like changing how the tower of babel should be built daily. Just because you can doesn't mean you should.

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.

Re: The Tower Keeps Rising

#236

Post by baq »

sroerick wrote: post #189
Aeolos wrote: post #154

Earlier quoted context omitted.

This sounds super interesting. Do you have any blog or pointers where I could read more about this?

https://pricklypear.rocks/welcome https://pricklypear.rocks/code Just to be clear this is not a release, lol, I just made it to show a couple buddies. My one friend was saying he learned a lot just by reading code and pointing Claude at it and asking questions about what he didn't understand. It is provided as-is with no warranty, or installation instructions. If you really get stoked about it I could probably clean…

If you got it popular you could license it to AWS and sell it as an Elastic Lisp Machine or something

Re: The Tower Keeps Rising

#237

Post by conartist6 »

psychoslave wrote: post #218
conartist6 wrote: post #157

Earlier quoted context omitted.

I built a web-OS, a graphical IDE, and a version control system to replace git, all in about 40,000 lines of highly abstracted Javascript. If you're thinking about how important it is to be able to maintain million-line codebases, I suspect you might have substituted a metric for the actual end goal.

That looks like a nice feat, can you share a repo? That said, reality at scale always come with details that will break the model, and the main roads when it happens are to ignore/reject any change proposal in the model, go in the mystic quest to reach a model that will fit it all including these new cases with an elegant simple solution, or accommodate special cases on the side until it grows too big or just percola…

It's a GitHub org: https://github.com/bablr-lang

Basically we've taken the "mystic quest" route, but we now have a pretty damn good data model

Re: The Tower Keeps Rising

#238

Post by ryan_n »

ozozozd wrote: post #197
mattmatheus wrote: post #120

Earlier quoted context omitted.

Assembly programmers made the same argument. It seems that we revisit this same trope each time the practice of software engineering undergoes a paradigm shift. Some have a harder time with the transition than others.

Are you implying the author of one of the best, if not the best performing agentic coding harness is having a hard time with vibecoding as a new paradigm? I’d look him up.

Someone could make the best agentic coding harness in the world and still have a hard time with the drastic changes that are happening in their profession. The two aren't mutually exclusive.

Re: The Tower Keeps Rising

#239

Post by zephen »

nico wrote: post #150
zephen wrote: post #69

Earlier quoted context omitted.

> compared to languages which demand much more effort to get anything substantial done. It is not clear at all to me that other languages "demand much more effort" for the same end result. It is clear that many non-lisp programmers value syntax, and many lisp programmers don't. Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp. I'm still awaiting ps…

> Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp If you then optimize for employability, which I assume most developers do (not all, but a large percentage), you might end up with not that many people practicing l…

> For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp

Certainly. But why would that be? It couldn't possibly be that the programmers already there built a system using the tools of their choice, and that system is now running well and deemed maintainable enough they require additional developers for the same language, could it?

Sometimes, of course, companies change their implementation language. The most famous cases I know of this are Viaweb and reddit, where the companies moved away from lisp. The company's main motive in this, of course, is making money. If they have a good product that is deemed maintainable, why would they piss off the original team, who probably chose the language, by switching languages?

Many programmers have worked in lisp. Studies have shown that programmers routinely learn new languages and somewhat forget old ones; older programmers are typically only currently proficient in as many languages as younger ones.

A company with a successful product is going to attempt to leverage that success. Whether leveraging it looks like incrementally improving it, or like treating it as a prototype and throw it out, will typically be a long conversation between developers and management. Typically incremental improvements are greatly preferred; it is only when all stakeholders become convinced that a fresh start is required that massive changes like implementation language will take place.

The calculus, of course is changing with LLMs. See, for example, the recent migration of bun away from zig. That rewrite was spearheaded by a massively effective lone developer, the exact persona that is claimed to always prefer lisp. Sadly, he chose rust.

Re: The Tower Keeps Rising

#240

Post by zephen »

kazinator wrote: post #166
zephen wrote: post #69

Earlier quoted context omitted.

> compared to languages which demand much more effort to get anything substantial done. It is not clear at all to me that other languages "demand much more effort" for the same end result. It is clear that many non-lisp programmers value syntax, and many lisp programmers don't. Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp. I'm still awaiting ps…

> Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp. I can guarantee you that most of these simply didn't go far enough; they had their "minds blown" with too little. They latched onto a highlight or two, found a way of sort doing that in C++ or Javascript and moved on. There are people who have had their "minds blown" by time/mass dilation of speci…

> I can guarantee you that most of these simply didn't go far enough;

And I can guarantee that I knew, when I wrote my comment, that I was summoning this very "No true Scotsman" argument.

> they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.

It always superciliously starts with how true lisp people are the most brilliant ever.

> Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.

And is eventually undermined by an admission of cognitive inflexibility, although not usually so quickly or in the same comment. Good job!

Post reply on HN