> There is the appealing idea that AI-assisted programming means better tools which lets us build more ambitious software. That is certainly true at the level of the individual and without doubt a developer with an agent will be dramatically more capable of changing a codebase. But large software projects have never been limited only by how quickly an individual can produce code. They are limited by how well people c…
> They are limited by how well people can coordinate their understanding of the system they are changing. It's not really news, though. Programming as Theory Building (Peter Naur) was published in the 80s, I think? Maybe the younger entrants to this field never came across it, but even if you never came across it, it was common knowledge amongst experienced devs that understanding of the system you are about to chang…
The Tower Keeps Rising
161–170 of 280 posts
Re: The Tower Keeps Rising
#162Re: The Tower Keeps Rising
#163Really surprised not to see Pope Leo's recent encyclical on AI/tech mentioned here. https://www.vatican.va/content/leo-xiv/en/encyclicals/docume...
Comparing AI adoption to the Tower of Babel is a central theme to Magnifica Humanitas, but written by someone with a much deeper understanding of the Biblical narrative.
Re: The Tower Keeps Rising
#164I'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…
Re: The Tower Keeps Rising
#165> the people is one, ... one language, ..., nothing will be restrained from them Why being one (I see as collaborative) was it not desired? Interpretations? Why is it seemed *more* harmful rather than good?
https://www.vatican.va/content/leo-xiv/en/encyclicals/docume...
It's odd that TFA doesn't acknowledge this.
Re: The Tower Keeps Rising
#166The 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…
> 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…
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 special relativity, or phenomena in quantum physics, who don't actually know anything about physics; 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.
For those of us sticking with the Lisp program, in one way or another, it was more of a sequence of small revelations in a progression of topics. Oh, that's a good way of representing that; that is pretty nicely thought out; that fits well with that; they had that how many decades ago? Sheesh; ...
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.
Re: The Tower Keeps Rising
#167Earlier quoted context omitted.
Do you believe "micro services" can make a comeback? local daemons with an exposed API, each daemon vibe coded?
Microservices don’t reduce complexity, they just move it to the interactions between services. You have the same fundamental design problem. In other words, if you can’t design a modular monolith, you can’t design a set of microservices.
I somewhat disagree:
Yes, it is possible to design a modular monolith, but thinking about the system in terms of a "minimum viable service" (but keep an eye on "viable", otherwise you can easily get into the "interaction problem") makes it much easier.
This is very similar to how you can write programs with no implicit state in a imperative programming language, but doing this in a pure functional programming language such as Haskell is much easier.
Re: The Tower Keeps Rising
#168Earlier quoted context omitted.
Every time I think the past was better, I think about how terrible ksh scripting was in 1995. And look at how great peoples' bash scripting is now compared to when we though bash had reached its apex in like 2009.
Conversely, Rexx scripting on the desktop was glorious in 1995.
I mean, yeah, hobby coding is not going away, but the feeling of exploration for me is totally gone. I don't dislike tech, I just don't see anyone being the way they used to be. People in tech are different and too many people are in tech.
Probably only part of the joy will ever be there, now. Which is weird because I did my own thing with computers til college, and don't consider myself a super sociable person. I just used to know that it was there, and now it isn't.
Re: The Tower Keeps Rising
#169Earlier quoted context omitted.
I have a theory (armchair take here lmao) that AIs are trained on public code, but the biggest codebases are not public. Although I suspect models from Google, Facebook and Microsoft can be trained on their massive internal codebases. Whether they are is another question.
I’m not sure you’d see that big of a difference in quality. There is quite a bit of cruft that can accumulate when you know the code will never be public. But, you would probably see a difference of scale and architecture. Larger projects that need better organization are probably more likely to be in private codebases (Linux excluded). So you might be right about the lack of private code in LLM being an issue.
At least in the past (before LLM-based code contributions got socially acceptable in some circles), in open-source project you often got very direct comments on code that was of bad quality. Yes, this was always a little bit abrasive, but it did a lot for the code quality.
For internal applications used at companies, such an abrasive behaviour is typically not accepted ("not a team player" (as if this is something bad), offended snowflakes, "not socially adept" etc.). Thus the code quality suffers quite a lot for internal applications.
Have you ever thought why salespeople have such an easy time selling some LLM for coding to big companies? Because the code quality of many internal applications is so bad, which makes even shitty LLM slop code often better than what is there.