> You would know this if you had any idea what actually goes into it
Goes into what? Into typing code or into creating LLMs?
Overall I'm not sure what point you're trying to make, nor why you feel bad about it. Mind explaining to a simpleton like me with simpler words and concepts?
Software can be about the beauty in an algorithm, the elegance of an implementation. This is very similar to the type of beauty and elegance one finds in Mathematics.
For many, writing software is more about crafting a beautiful design than typing lines of code.
Getting things done is not about crafting, though (although crafting IS about getting something done).
Thus the big clash when suddenly you can get things done well enough, without the craft part, with LLMs. Even if beauty and elegance are in there, most would not see it, because most do not want to review "LLM slop". They get things done.
> For many, writing software is more about crafting a beautiful design than typing lines of code.
Yes, I count myself as one of these people, hence not caring much about the actual typing part.
> Getting things done is not about crafting, though (although crafting IS about getting something done).
I'd say it is, I like getting things done, hence I care about high quality code and proper design/architecture of the software itself and its concepts. Without caring about those things, you can "get things done" initially but as the thing grows, it gets slower and more complex. I like when "get things done" is applicable over years and as the software grows, then you need to carefully deliberate about almost every change and be vigilant about the design and architecture.
> Thus the big clash when suddenly you can get things done well enough, without the craft part, with LLMs. Even if beauty and elegance are in there, most would not see it, because most do not want to review "LLM slop".
Right, but no one is forcing you to go down that path. You can tell the LLM "Build a calculator" or you can come up with the design then tell the LLM to implement the design exactly, the choice is up to you. Since I care about the abstractions, design and cohesive architecture, I do the latter, and if you too do not care about the typing but the crafting, I'd advise people to also make that latter choice instead of the first.
I agree, but would add that maintability is , and always has been , a hallmark of quality software.
LLM spaghetti code is unacceptable.
LLM code with a complex pile of overlayed abstractions only someone with a PhD in Software Engineering can debug or even get to compile years later when public APIs change is also unacceptable.
Same thing with human engineered software abstractions.
But I get you. Human directed AI is the only way to go ... for now ...
> You would know this if you had any idea what actually goes into it
Goes into what? Into typing code or into creating LLMs?
Overall I'm not sure what point you're trying to make, nor why you feel bad about it. Mind explaining to a simpleton like me with simpler words and concepts?
I understand what he means.
Software can be about the beauty in an algorithm, the elegance of an implementation. This is very similar to the type of beauty and elegance one finds in Mathematics.
For many, writing software is more about crafting a beautiful design than typing lines of code.
Getting things done is not about crafting, though (although crafting IS about getting something done).
Thus the big clash when suddenly you can get things done well enough, without the craft part, with LLMs. Even if beauty and elegance are in there, most would not see it, because most do not want to review "LLM slop". They get things done.
> For many, writing software is more about crafting a beautiful design than typing lines of code.
Yes, I count myself as one of these people, hence not caring much about the actual typing part.
> Getting things done is not about crafting, though (although crafting IS about getting something done).
I'd say it is, I like getting things done, hence I care about high quality code and proper design/architecture of the software itself and its concepts. Without caring about those things, you can "get things done" initially but as the thing grows, it gets slower and more complex. I like when "get things done" is applicable over years and as the software grows, then you need to carefully deliberate about almost every change and be vigilant about the design and architecture.
> Thus the big clash when suddenly you can get things done well enough, without the craft part, with LLMs. Even if beauty and elegance are in there, most would not see it, because most do not want to review "LLM slop".
Right, but no one is forcing you to go down that path. You can tell the LLM "Build a calculator" or you can come up with the design then tell the LLM to implement the design exactly, the choice is up to you. Since I care about the abstractions, design and cohesive architecture, I do the latter, and if you too do not care about the typing but the crafting, I'd advise people to also make that latter choice instead of the first.
I agree, but would add that maintability is , and always has been , a hallmark of quality software.
LLM spaghetti code is unacceptable.
LLM code with a complex pile of overlayed abstractions only someone with a PhD in Software Engineering can debug or even get to compile years later when public APIs change is also unacceptable.
Same thing with human engineered software abstractions.
But I get you. Human directed AI is the only way to go ... for now ...
[dead]