> I read a vanishingly small amount of the actual code.
This sentiment kind of saddens me. I'm all for burning tokens to write throwaway code just to prototype a solution, but I don't get not reading (or at least familiarizing yourself with) the code that you will deploy to prod.
maybe they're betting on improvement in models to plateau, and that having a fairly stablized capable model that is orders of magnitude faster than running on GPU's can be valuable in the future?
I think this is showing the difference between people who like to /make/ things and those that like to make /things/. People that write software because they see a solution for a problem that can be fixed with software seem to benefit the most of LLM technology. It's almost the inverse for the people that write software because they like the process of writing software.
Surely there has to be some level of "getting stuff done"/"achieving a goal" when /making/ things, otherwise you'd be foregoing for-loops because writing each iteration manually is more fun.
I think you misunderstand the perspective of someone who likes writing code. It's not the pressing of keys on the keyboard. It's figuring out which keys to press. Setting aside for the moment that most loops have a dynamic iteration count, typing out the second loop body is not fun if it's the same as the first.
I do code golf for fun. My favorite kind of code to write is code I'll never have to support. LLMs are not sparking joy. I wish I was old enough to retire.
I have a 10-year-old side project that I've dumped tens of thousands of hours into. "Ship the game" was an explicit non-goal of the project for the vast majority of that time.
Sure, but, in the real world, for the software to deliver a solution, it doesn't really matter if something is modelled in beautiful objects and concise packages, or if it's written in one big method. So for those that are more on the making /things/ side of the spectrum, I guess they wouldn't care if the LLM outputs code that has each iteration written separately.
It's just that if you really like to work on your craftsmanship, you spend most of the time rewriting/remodelling because that's where the fun is if you're more on the /making/ things side of the spectrum, and LLMs don't really assist in that part (yet?). Maybe LLMs could be used to discuss ways to model a problem space?
I like both the process and the product, and I like using LLMs.
You can use LLMs in whatever way works for you. Objections like the ones in this thread seem to assume that the LLM determines the process, but that’s not true at present.
Perhaps they’re worrying about what might happen in future, but more likely they’re just resisting change in the usual way of inventing objections against something they haven’t seriously tried. These objections serve more as emotional justifications to avoid changing, than rational positions.
If anyone is interested in the cryptography mistake that Sony made I recommend watching the Console Hacking talk at 27c3 by the fail0verflow team: https://youtu.be/DUGGJpn2_zY?t=2096
Interesting to read that the complexity in his music is praised and seen as speaking to the intellect, whereas that is not the case when it comes to complexity in software.
complexity in software is invisibly-preceded with "unnecessary", and usually indicates software that is difficult to maintain or even to verify its behavior. A really cool software architecture can scratch a similar itch as a good fugue, but that's not its typical function nor is it the way we usually engage with software professionally.
Bach's complexity, incidentally, is seldom "for its own sake" - the pieces all fit together beautifully and without extraneous movement. Contrast that with some lesser works by later composers like Liszt, where you often get the sense that a given passage could be reduced or removed without harming the work.
That kind of complexity, which means attention to detail, quality, concordance and consonance between different components, is also praised in software. This is however not what we mostly think of when talking about complexity in software.
There's already more recorded music in existence than you could listen to in a lifetime. There is also a vast amount of music being created today which is not pop music and is not following current pop trends.
I'm working on a new programming language and every point resonates with me on a spiritual level. One thing that helped me a lot was writing more integration tests at the outer edges of the application, opposed to unit tests of individual modules. Usually the logic doesn't change between rewrites, so keeping a somewhat stable interface keeps me from breaking stuff in between grand rewrites.
A lot more backstories to many design, technical and political aspects of early Macintosh development can be found at https://www.folklore.org/ - it's a real treasure trove for people interested in how the Mac came to be.
