|
Flawlessly if the spec is unambiguous. Otherwise you get...something, though you could argue that the AI should refuse to write the code in that case.
|
|
|
|
|
Greg Utas wrote: though you could argue that the AI should refuse to write the code in that case
If real-life developers can't get away with that attitude today, why should an AI in the future?
|
|
|
|
|
Artificial Intelligence is no match for natural stupidity.
(Attributed to Einstein)
|
|
|
|
|
"I'm now telling the computer EXACTLY what it can do with a lifetime supply of chocolate."
|
|
|
|
|
You don't see the contradiction in that assumption?
If we already knew exactly what to do in every case, we would not need an AI. If we don't know, we better leave the AI some room to learn, and don't hard code our incomplete ideas into it. The problem is that no AI up to now is aware enough to recognize insufficient results of this complexity, and much less is then able to decide on a reasonable course of action.
Natural stupidity is one thing, but artificial stupidity can be even more entertaining.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I didn't see a contradiction. I was assuming that the AI was for generating code from a natural language spec, not for helping with the spec itself. But because the AI has to understand the spec, it should complain if the spec is incomplete.
|
|
|
|
|
And how do your train your AI to do that without already knowing how to do that?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I don't know how to train it. I was just assuming that it existed. Maybe it would be trained similar to Google Translate, which is constantly improving. But it would be even far more complex than that, so maybe it will never exist.
|
|
|
|
|
Never say never, but it is not going to be so easy as some people would like it to be. And in the end it will be questionable if the whole effort is worth the results. It might be easier to use the original for a while longer than to create a machine in our own image.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I've been hearing similar since the late 80's. Does anyone here remember CASE tools, how they would allow a person to design software specs and them the code would be generated for you? That didn't seem to last too long....
|
|
|
|
|
I'm not holding my breath either. If AI could write code from unambiguous specs, the specs would have to be debugged and fixed if the code didn't do what was actually intended. So in the end, software engineers would simply become "natural language" engineers. Plus ça change...
|
|
|
|
|
Exactly, just another language for those of who design software. One to add to all the other languages learned along the way.
Software development isn't about language specs and such. It is more about having the right mindset, where a person can take a problem and break it down into logical units. Unless you can do that, it doesn't matter what language or tools are used.
I still remember way back to first year of university, sitting in a programing class. A lot of the other students just couldn't get their head around how to design their apps, and ended up switch majors or dropping out....
|
|
|
|
|
 Quote: Does anyone here remember CASE tools, how they would allow a person to design software specs and them the code would be generated for you?
I do: 30 years ago, when I moved to Canada, a friend was raving about Rational Rose and suggested I should look for a different profession because pretty soon all software will be written by tools like that. I was rather sad as I liked coding and I wanted to keep doing that.
In the end I’m glad I didn’t listen to his advice
Mircea
|
|
|
|
|
Thanks for dredging up unpleasant memories. That wasn't even coding with natural language, but coding with drawings. I had to argue against a very similar thing, developed in-house, that was promising the world. Snake oil, but senior management were lapping it up.
|
|
|
|
|
And where's that friend today? Do you ever bring that conversation back up with him?
|
|
|
|
|
We didn't keep in touch. He opened his own consultancy business and did quite well for himself.
Besides, he doesn't have a monopoly on bad ideas or shortsightedness: back in '94-'95 I thought Compuserve was the best network around and the future of Internet lies with them.
Mircea
|
|
|
|
|
It isn't just the business people that see us that way. If you have ever worked with a recruiter, they all seem to see us a commodities, with very little to differentiate any of us. Not to mention that very few of them have any basic understanding of technology, thus are unable to see how best to place us.
I still get job offers to Java development because of a job I had over 10 years ago. Similar for embedded development, even though I haven't done anything like that since the 80's.
Nowadays when I am approached by a recruiter, I tell them I am looking for a management position, or at least as a team lead role. I have yet to be presented any such roles.
|
|
|
|
|
Ugh, recruiters are the worst.
They're also very bad at geography as "a job near you" could just as well be a two hour commute away.
Also, I have my own company, but I still get messages like "you're probably enjoying your current job, but maybe you're looking for a new challenge?"
|
|
|
|
|
If you can create a bot that codes, It can improve infinitely. It can be revolutionary, but fictional.
|
|
|
|
|
And it will demand payment.
|
|
|
|
|
They'll function as middle men: talking with the cloud people about an issue a user is having but can't articulate themselves. The in-house Customer Rep.
As some point, users will simply be told "that is not a service" / option (instead of expecting a software fix).
At one point, no one built LOB apps; they all bought canned systems. Then the PC came out, and everyone started "programming".
We're now back to "packages" (cloud services and "the rep").
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Allow me to take a different approach to an answer. (With the same outcome of course.)
As has been said before, there's a difference between a "handy man" and a "licensed contractor", and they have different duties.
Home owners who hire handy men to do licensed contractors' jobs to save money often wind up with a huge mess which costs even more to remedy.
I am not a Software Engineer, I have never met a Software Engineer.
Very little software is engineered. Airplane flight systems, missile guidance systems, Mars Rover systems, these are engineered.
Point-of-sale systems and Automatic Teller Machine systems, these are engineered.
Operating Systems used to be engineered, I suppose the kernels still are, but the UI less and less.
Web apps, mobile apps, business apps, these are not engineered.
I suppose that this is part of the reason why some people have such a low opinion of "Software Engineers" -- they just don't understand the situation.
There are many hacks who style themselves "Software Engineers" -- these developers should be eliminated from the work force, I wouldn't even buy a cup of coffee from them.
The tools still need to be developed and maintained by Software Engineers.
But the users of the tools are usually not software engineers, they can be software developers like me, people who know what the tool does and how best to use it, how best to apply it to a particular problem set.
So of course the particular details of what the developer does will continue to evolve.
From writing machine code, to assembly code, to C code, to fourth-generation code, etc.
If a business analyst has the ability to specify the details of a program to an nth-generation tool, then that analyst will be a developer.
And it will likely continue to be that the most experienced analyst (with the fewest bugs) will become the go-to developer for the organization (the guru).
Software Engineers will always be required.
"Computer Science" will always evolve.
Bob will continue to bless us with his benevolence.
|
|
|
|
|
|
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
Interesting, I've always used software engineer and developer interchangeably (and I've seen it used that way).
I prefer developer for myself too.
I get what you're saying though, and indeed, I'm not engineering anything.
PIEBALDconsult wrote: And it will likely continue to be that the most experienced analyst (with the fewest bugs)
Not necessarily the most experienced, but the one who just fixes the bug instead of pointing people to some ticketing system, needing approval from a manager, and then gets it into the sprint after the next (because that one's full already), so you'll have your fix in six weeks.
I've been in such an environment and I was the go-to guy.
It's often easier and faster to fix something now (mostly typo's or adding an if-statement or something like that) than to do things the "official" way.
Most of my coworkers weren't that flexible 
Sure, sometimes it's a bigger fix and I'll tell them to do it using the official channels, but then they'll say something like "Sander already knows about it" because they always came to me first.
I can tell you, when the software architect (and management) didn't extend my contract (because they thought I was too much of a cowboy), a lot of people were not happy because at least I actually got some work done 
And yeah, when things get done normally, the number of bugs is absolutely a key metric for becoming the go-to guy 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
