|
MSBassSinger wrote: The net, “middle of the bell curve”, result of programming by AI will be the further influx of “programmers” who write even more awful code, but work cheap.
Because of course in the good ol' days (fill in a date here) everyone knows that (fill in something here) was much better.
Of course defining better and how it is known that it was in fact better is very murky.
MSBassSinger wrote: If you, as a developer (full disclosure-I have 40+ years experience as a hands-on software developer/engineer/architect,
My decades of experience only allows me to state with certainty that long ago I absolutely did not have enough knowledge or experience to judge whether anything was good or bad.
Now with that experience/knowledge now I can state that, certainly not surprising to me, that programming, like everything else, drives towards the average. Because if not it would probably require some supernatural explanation.
|
|
|
|
|
So, given the un-finite range of human abilities, there's a fair chance that the outcome from one of us will exceed the average. While I'm pretty sure that over my 25+ years, I'm probably average or below, but I can also say that we've produced some way above average results as well.
How does an AI exceed the average if it is built on the average? And how does it judge the feedback that it gets? All we have to do is visit stack exchange to see the complexity of that issue.
|
|
|
|
|
In other news, Bing is constrained to five answers to avoid going wild. How many useful lines eat up the include statements at the top of the file? 
|
|
|
|
|
Not cynical. Entirely realistic.
|
|
|
|
|
Until incentives change to ones that prevent short-sighted decisions and rewards are given based on long-term success of the product, this will not change. And for that to happen, well, some serious shocks to the system will be required.
|
|
|
|
|
I'm not sure AI is the issue here.
Initially, the university where I work had a mainframe that handled student billing for many thousands of students and that system worked very well for 25+. It made sense to really invest in making the code right because the time you put in was rewarded with 2 decades of service.
The system was replaced with some difficulty in 2018 and yet five years later they're shopping for a replacement.
Coding as an engineering exercise makes sense when you're building something with hardware and software that will be around for two decades but it doesn't make sense to put the thought and effort into something that gets used for 6 months before being replaced by the latest framework/fotm language/cloud next best thing.
Look at the .NET framework - how does a 3 year support window for a version compare to two decades? If you start writing for .NET 6 right now and do a real quality job - on a complex system you may not even been completed before the framework is out of support. Why take all the extra time to produce good code when it will be obsolete security hazard before you can even get it out the door?
I'll worry about being an engineer when I get an environment that isn't completely upended every 24 months.
|
|
|
|
|
I’ve been developing systems in .NET for 22 years. It has never been upended. It has grown, expanded, and improved. Code I wrote 20 years ago still runs.
I remember the days of writing in FORTRAN and COBOL. Those languages grew, expanded, and improved over time, also.
There is a difference between replacing a program and upgrading it by extending it features.
|
|
|
|
|
If you've been maintaining it for 22 years you've either replaced the underlying framework a couple of times or you're running insecure code.
Regardless, I think technology churn is a huge driver for code quality problems.
|
|
|
|
|
I am not sure you know how this works.
The point is that there is no wholesale replacing of anything for the last 22 years of .NET. Expanded API, expanded OSS, added features, etc. But it is still .NET. Nothing like the false premise you offer.
All good, long lasting programs of any consequence are regularly updated and extended. It was true in the mainframe/minicomputer days, and is still true today.
To say that technology change - kin and of itself - is the cause for churn shows a lack of understanding or experience in software engineering.
As with any discipline, there are those who change something for change’s sake (always chasing the new and shiny), and there are those who change/amend/refactor/revise based on 1) need and 2) application of value engineering.
If you think it is “upending” to go from .NET 5 to 6 to 7, then you don’t understand .NET.
|
|
|
|
|
MSBassSinger wrote: If you think it is “upending” to go from .NET 5 to 6 to 7, then you don’t understand .NET.
I'm talking about decades of stability and somehow you believe migrating an application from .NET 5 (2020) to .NET 6 (2021) is a reasonable comparison?
Okay.
|
|
|
|
|
No, I think you don’t know what you think you know.
No production program remains unchanged for 20 years. The required business logic changes. If industrial automation, the hardware changes as it is replaced, thus making API or buffer location changes. The backend databases or third party APIs change.
Production software always changes to meet production requirement changes. The core purpose of the program can be stable for decades, but there are always changes. I’ve seen that in banking and HR with programs that had the same core responsibilities for 20+ years, written in COBOL.
The same is true where production programs were written to use .NET.
In both cases, stable production programs were updated to meet changing business requirements, not because .NET grew and improved like any language does.
Yes, churn does happen because unqualified and ignorant management chooses to ignore ROI and just chase after something new and shiny, or falls for the latest “best practices” silliness. That is not the fault of .NET. That is the fault of an organization hiring the incompetent and putting them in charge of something.
|
|
|
|
|
For some reason you keep moving the conversation to weird extremes.
For example:
MSBassSinger wrote: No production program remains unchanged for 20 years.
I never made that claim.
I've been more than clear - when you want to have a discussion with me and not weird caricatures of what I'm posting I'll re-engage.
Until then, good-day.
|
|
|
|
|
You wrote:
“I'm talking about decades of stability…”
So yes, what I wrote is entirely in context to what you wrote.
Maybe American English is not your first language and you are having trouble comprehending.
It is clear you do not understand the difference between a stable program that is decades old, being “upended” and one simply being updated over time while retaining its stability and scope of functionality.
Your assertion that merely updating .NET by improved versions over those decades you referenced is “upending” a stable program is sheer nonsense.
|
|
|
|
|
Which sections of this essay were written by ChatGPT ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
I've been programming all of my adult life - really from a teen around 1980, but with serious intent since beginning college in 83. I love being a part of such a fast-moving industry, but I do agree that we may well have stumbled over our feet with AI.
Here's the thing: I program with all of that old school as a foundation - man pages/reference books at hand as needed, wishing I could type faster wit accuracy to keep up with my plan for the code. I remember the beginnings of widgets, objects, and relational database design. Because I have all of that in my experience, I can make good use of code recommendation/auto-complete. It's like spelling for me - I'm pretty sure I know how to spell a word, but it's nice to have the confirmation of the auto-completer. What concerns me about newer programmers is that they have likely never had to man a function call. Do they use reference resources, or do they just use code snippets? Do they understand the 'grammar' of their coding language, or is the boilerplate a black box for them? And does it matter? I think it does; I don't know how it could fail to matter, but maybe things have just changed that much so that it doesn't matter in the end.
I love efficient code. I think it's important to optimize performance and write code that is maintainable because it's not junked up. I believe that the basics are important and we skip them to our doom, but I could be wrong; maybe this is how great leaps are made, by leaving the ground.
|
|
|
|
|
Yep. I'm betting using AI to help you program is going to make a new software engineer a less able architect/programmer. It's going to be like how the calculator (app these days) has destroyed younger peoples ability to do basic math.
I've got a college professor friend I game with who teaches immunology. He made the decision that his students couldn't use their cell phones during labs. There was an uproar from the students and one of the issues was they couldn't use their calculator app on the phone. He then posed a simple problem to the students: What's 13 divided by 26. Not one of the students was able to answer the question without using their calculator app!
|
|
|
|
|
|
Really, he was horrified.
|
|
|
|
|
I have been using ChatGPT the last couple of weeks and find it quite amazing, as a tool for me. And I am sure that as time progresses I will find it ever more useful. It is an accelerator, not a replacement. One of the core issues with technological advancement is the speed with which software is developed. Moore's Law defines technological, hardware advancement in geometric or exponential terms, but software advancement has been largely arithmetic, linear. It is an expensive and time consuming process to create software. It also takes a good deal of time for a developer to get comfortable with different programming languages, and it takes time to comprehend all of the complexity. AI is going to help accelerate significantly the speed at which developers can produce useful code, and that is a good thing. AI code will get better, a lot better, and we will learn how to become better programmers as a result of that. AI is not some singular independent consciousness, it is a cross section of our collective recorded history on the internet. It is us, empowered. Grab on tight.
|
|
|
|
|
I think it's an accurate view. Yet it does not HAVE to be that way.
First, there was "vi"
We got Notepad on Windows.
Then Visual C++.
Then we got Visual Studio with Intellisense (Visual C++ did not have that).
Now we have code-writing AI.
You can still program in Notepad today. Would you do it?
Probably not. But programming using Intellisense is a dependency, too.
You can do without, but it's slower. The quality will suffer only because it takes too much time, not really because of a different procedure.
It might be the same way with AI.
The only thing I hope is that no-one ever will think that AI can actually replace creativity in humans. And that's a key in programming.
But how could AI as a rule-built and rule-depending thing (may the rules be ever so obscure), compared to actual creativity of live beings? Of course it cannot, but the danger is that people might think it's "the same". People who think so must think that humans are just machines like a computer. I possibly digress but it might also be very pertinent.
|
|
|
|
|
until I read this [^], I just didn't get it.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
|
Neal Stephenson's latest book "Termination Shock" has eagles taking down drones!
|
|
|
|
|
I love Neal Stephenson's writing. I have Snow Crash and The Diamond Age on my shelf here next to me. Been meaning to read more of his books.
Neal appears to be prophetic almost, in his visionary writings; a little freaky if you ask me.
|
|
|
|
|
I am so sharing this.
“AI Comes Home to Roost” 😆
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
