None of the "code generation" stuff is new by the way.
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs this is true and it bothers me so much that people keep talking as if we haven't been trying to "generate" code since the invention of c
-
@thomasfuchs @dymaxion The other 90% is configuration where to be fair LLMs are useful quite regularly.
-
@thomasfuchs "all you have to do is meticulously and accurately describe 100% of your requirements and restrictions"
Sure, seems great Jan.
@petrillic @thomasfuchs in a language like English which is open to misinterpretation. Writing a complete and unambiguous spec in English is just as time consuming as writing working code. I see philosophy logic courses becoming required learning for future ‘ai developers’
-
@grepe Yeah, though those specific people are probably already prone to believe in magical thinking (more prone to everything spanning from being religious to pseudo-science to racism; not saying they believe in any of this, just that they're more susceptible to it).
@thomasfuchs actually - no. i understand where that assumption comes from but it is very wrong. in my case one of them is a professor on renowned university doing academic research. and, surprisingly, being prone to believing pseudoscience, being religious or racist is not connected in my experience... this is anecdotal but i've known medical doctors who were into homeopathy (former flat mate), religious astrophysicists (colleague), racist atheists (class mates) and very rational and inclusive priests (jesuit)...
-
@thomasfuchs actually - no. i understand where that assumption comes from but it is very wrong. in my case one of them is a professor on renowned university doing academic research. and, surprisingly, being prone to believing pseudoscience, being religious or racist is not connected in my experience... this is anecdotal but i've known medical doctors who were into homeopathy (former flat mate), religious astrophysicists (colleague), racist atheists (class mates) and very rational and inclusive priests (jesuit)...
@grepe intelligence and wisdom in a specific field does not automatically extend to other fields ¯\_(ツ)_/¯
People with thorough systems and rational thinking are relatively rare.
This might be an evolutionary thing as much as cultural/educational.
-
@thomasfuchs "all you have to do is meticulously and accurately describe 100% of your requirements and restrictions"
Sure, seems great Jan.
@petrillic @thomasfuchs This. As someone who took at least two courses that delved deep into requirements and iteration of said requirements in undergrad, and then having to work with requirements constantly at work, it blows my mind how there's people that feign that what they do is engineering, that claim that requirements are an easy task for LLMs.
No they're not, and they probably have cognitive dissonance so huge that they can never be good at engineering.
-
The gist of this is that _even if code-generating LLMs work perfectly_, it doesn't have that much of an impact on how good the software works for people; which in turn means it won't matter for profits.
@thomasfuchs
Oh, it's even worse than that: modifying, correcting issues, maintaining in general is perhaps 95% of the time.So overall, the LLM can save you 5% on 10% . If it works. Which it doesn't.
-
@landelare Software isn’t a scarce resource (it’s very cheap to hire programmers for a long time)
@thomasfuchs @landelare very cheap? How do you figure?
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs
throwback to UML-to-code-generators... -
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
It strikes me that capitalists don’t want to make good software. Like all products: if it’s good, why would you need to buy it again?
They want software that is just good enough.
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs@hachyderm.io I generally ascribe to the perspective that code is a liability, so writing code faster is irrelevant at best. The actual effort is spent on domain understanding with clients and adapting to changing environments. There is no silver bullet.
However, business is much happier just saying more LOC equals productivity even if it's digging them into a hole. -
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
Exactly. What bothers me isn't code generation. That's a good idea if done correctly (with precise tools).
What bothers me is the technofascist makeover of our world.
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs I don't think this is the entire story. Tools and techniques like RAD/OOP/Expert Systems/4GL can definitely save time when used correctly. Abstracting or automating boring parts leaves more time and headspace for the complicated parts -- which are typically the business rules and the non-functionals.
The way LLMs generate code is the exact opposite: they make it harder to focus on the hard parts by trying to generate "everything".
-
@thomasfuchs I don't think this is the entire story. Tools and techniques like RAD/OOP/Expert Systems/4GL can definitely save time when used correctly. Abstracting or automating boring parts leaves more time and headspace for the complicated parts -- which are typically the business rules and the non-functionals.
The way LLMs generate code is the exact opposite: they make it harder to focus on the hard parts by trying to generate "everything".
@elricofmelnibone maybe these tools save time or improve quality, maybe they don't, it probably depends on circumstances.
but my point is: it doesn't matter if you can speed up 10% of the total effort to make software by 5%; that's a rounding error.
-
@elricofmelnibone maybe these tools save time or improve quality, maybe they don't, it probably depends on circumstances.
but my point is: it doesn't matter if you can speed up 10% of the total effort to make software by 5%; that's a rounding error.
@elricofmelnibone what actually happens is that the important parts of software development are starved of attention because "we can write software so easily now"
-
@alper
@thomasfuchs it's also where they're as likely as not to take what should be a footgun and turn it into a self-inflicted head shot. -
@dymaxion @thomasfuchs It’s been debugging DNS and other issues for me just fine. Ideological and outdated views here aren’t going to be very productive.
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs yup, we used custom Fortran pre-compilers to build complex numerical simulations of nuclear power plants way back in the 1980s. They were error-prone and had to be manually debugged, but it was still considered a major advance over attempting to do all that programming by hand.
-
M monkee@other.li shared this topic
