|
Quantum Robin wrote: Programming languages will end up being increasingly high-level until they become identical to natural language.
That's where I stopped reading; they won't.
AI may learn your language and translate it to instructions, but natural language is too ambigious to be used as a programming language.
Quantum Robin wrote: An intelligent compiler will ask for clarification whenever there's an ambiguity and may suggest improved wordings to resolve the issue.
I heard these predictions before, and they're unrealistic for the foreseeable future. It's an academic way to get funding, but not something to expect for the next version of .NET. It's vastly underestimating the complexity of possible wordings.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: but not something to expect for the next version of .NET. in our lifetime
FTFY
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: but not something to expect for the next version of .NET. in our lifetime in a million years
The only process that we know to have produced something that resembles 'universal intelligence' is evolution and that process takes its time because of its aimless nature.
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.
|
|
|
|
|
Then taking that premise as true... then it will take a some billion years... evolution is definitively not even done with its first prototype (us)... just look around you  
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I have been thinking that the whole time since I landed here. I could use a vacation, even on a hot world like in the nearby 40-Eridani-System.
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.
|
|
|
|
|
Quantum Robin wrote: Humans are the only things we you currently know of which have general intelligence
FTFY 
|
|
|
|
|
I first met programming as a teenager in the mid-1970s. What fascinated me - and eventually lead me to a master degree in programming - was not program language syntax or indentation rules.
I was fascinated by systematic approach, the problem analysis, the deep understanding of the problem solution required before you sit down and code it in some programming language.
So I hate this "agile" approach: "Let's start with 'int main(int argc, char** argv){}'. There... We are on our way! Could you now try to describe your problem, and we will write it down between the braces?"
You must thoroughly understand both the problem and the solution, in "problem space", not in "coding space", to create a robust, working solution. You cannot just throw some vague, fuzzy stuff into a processsor (compiler, interpreter), and Voila! Problem solved! Anything that appears as automagic is, by definition, a poor, incomplete solution.
Of course we use high level tools that takes care of individual tasks. But when using a tool, whether you see it as a library, an algorith, an API or whatever: Always make sure that you understand how it works, and why it is doing what it is doing, on at least one level below the one you are working on. And then it really isn't that important what the programming language looks like.
---
Deep down in my large piles of old xerox copies is an old presentation of the COBOL 60 standard, proclaiming that thanks to this language, programming can now be done by anybody. No special education or training is required; you just state in plain English what you want the computer to do.
They were right, sort of ... if you know what to ask the computer to do. Over the years, I have been shocked (so many times that I am no more shocked) by how poorly most people, in all sorts of professions, understand what they are doing, and why. We drink white wine with fish, red wine with meat, just because that's what we do. We drive on the right side of the road, but why - the British do not? We think the Beatles were the most clever rock group ever, but why do we think so? You can even as a composer why he composes his music that way, he rarely knows. It is great that the IP protocol suite won over the OSI suite in the 1990s, but what makes it a better choice?
I have been in a few projects aiming at making people understand what they are doing. One primary example: We made a map of the total information flow in the city administration (about 200,000 inhabitants), and the "Wow! Now I see!"-type exclamations were numerous. After everybody had gained this understanding, the following discussions about what to automate and how to do it went far more smoothly than anyone expected. (This was about 30 years ago, so lots of procedures were still manual.)
To help you understand the problem, and the solution, you need tools quite different from programming languages. In those analysis projects around 1990, we used the Entity-Relationship model, as ER was at that time. ER "evolved", essentially with mechanisms to automatically generate code, and became tremendously complex, with mechanisms for identifying constraints and foreign keys and datatypes and whathaveyou. There was no way to use ER "properly" without fairly deep knowledge of SQL. So ER as a problem solving tool was ruined.
This is what we really need: A problem solving tool, detached from any programming (including SQL foreign keys and constraints and...). A modern replacement for what ER was around 1985-90, before it grew cancer.
That is what we need. Are we going to get it? I certainly wouldn't hold my breath...
|
|
|
|
|
With regards to having an AI system you can describe your requirements to and it writes the code for you. I agree, that is a very obvious future that we will eventually see. We arguably already have the basics of it with "project templates". We "say" what we want, and the template makes the code appear.
Over time this will hopefully get better and better to eventually what you describe.
With regards to having natural language programming, well I am not sure that will happen. Not only because of the insane complexity of it, but more importantly... WHY? Why do we need a language that we type like we would talk to another person?
If we are being hopeful, the future will be that programmers get 'paired up' with an AI system that makes their job easier.
If we are being realistic, the future will be that programmers get REPLACED by AI systems... just like what is already happening in other industries.
|
|
|
|
|
musefan wrote: If we are being realistic, the future will be that programmers get REPLACED by AI systems... just like what is already happening in other industries.
That will happen during a while at the first moments because some idiots in management positions will think we are not needed anymore.
Until the AI starts to make errors or better said it starts to make obvious the errors of the management or the one writing the specs, because an AI is not able of interpretation in the way we have to do just because the other is a moron and doesn't even know what the real needs are.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Even if that is true, you will only need say 1 "code fixer" programmer, instead of 4. So net loss is still there.
Also, you assume those "managers" will be the same as they are now. They won't. The new "managers" will be better equipped to use the AI. They will know what they are doing, and how exactly to use the system. If they fail, they will be the ones replaced.
|
|
|
|
|
musefan wrote: The new "managers" will be better equipped to use the AI. They will know what they are doing, and how exactly to use the system. If they fail, they will be the ones replaced.
Just exactly as it is now, with the human resources  
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
musefan wrote: If we are being realistic, the future will be that programmers get REPLACED by AI systems... just like what is already happening in other industries.
A very distant future, if ever. Mother nature needed a billion years to get to us, and we have no better or quicker alternative. We have tried to influence evolution for our purposes since we started breeding animals. Just look at some of the results.
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.
|
|
|
|
|
Why don't you just use the Force, wave your hand at the computer and say something like 'These are not the data rows you are looking for'?
Even if you really have such an AI, which I seriously doubt will be any time soon, you expect it to be an expert for everything. When I just look at the customer for which I'm doing work right now, where every word has 20 meanings and every meaning is tacked onto at least 20 different words. You really must understand what they are doing, how they are doing it and what he is trying to tell you before you can write a single line of code. Bonus points for anticipating occasional changes of mind.
Look how many silver bullets you want to combine into a single silver nuke:
- "Universal" intelligence. I'm not so sure that such a thing really exists.
- all knowing, perhaps even psychic, intimately familiar with everything that someone might ask and a professor for everything, including things we have not discovered yet.
Don't add 'allmighty' to the list, or you might slowly get negative attention from the Old Man Himself.
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.
|
|
|
|
|
No, this won't happen this way.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I've been using Visio in my last company...
What do you use? and why?
PS: I've also used pencil and paper too... :P
|
|
|
|
|
Visio has always worked for what I need. But I only do simple diagrams.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
I use open-source Graphviz[^]. This is one of the applications I could hardly get rid of.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
Graphviz is great for a whole lot of graphing tasks.
But I'd say it is better suited for automatically generated input files. You wouldn't want to maintain a flowchart by editing the DOT input file, which is oriented towards the graphic display elements, not the abstact structure and flow that you want to present.
Well, there may still be old Unix (pre Linux) guys around who frown at GUIs and want to write DOT files in vi to create output on their pen plotters. For most of us, we would rather drag boxes around than editing 7 bit ASCII files. (OK, UTF-8, but the editing is done in the same way for ASCII and UTF-8 files.)
I use graphwiz myself, but for maintaining flowcharts, I would use other tools. On the other hand: I haven't ben drawing a flowchart for ages.
|
|
|
|
|
I like to use Graphviz as well. Though more for displaying my charts for others. I tend to create my actual flows as text, then put them into Dot files.
Yea. I know. I'm a little odd. I am so far the only person I know that does it that way. I always structured things as text long before I was ever introduced to flow charts. Going all the way back to my grade school days, my teachers hated seeing what my rough drafts of reports looked like.
Money makes the world go round ... but documentation moves the money.
|
|
|
|
|
I don't use a formal tool - or even software - but I do use this: ROOTS[^]
I was introduced to it when I worked for Rob at the Atlas Computer Division of Rutherford Labs as my first industrial placement (one of three in a thick sandwich degree course at Uni) and worked on the FORTRAN program that drew them from preprocessor code.
It fits surprisingly well with modern OOPs apps I think - certainly better than traditional flowcharts which are far too procedural for my taste.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I haven't done a flowchart since high school if memory serves. Since then, I've done a few UML diagrams (in PowerPoint) to document frameworks--but only afterwards. I just sit down, start coding, and ruthlessly iterate and refactor by letting the code speak to me, as the cliche goes. Sometimes I write high-level design notes before starting, but the details often end up being different than what I had envisaged.
|
|
|
|
|
|
I am using yEd, a freeware, from yworks yEd - Graph Editor[^]
As I mainly do trees, I am very found of the automatic layout feature.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
I second yED, it's a good all around drawing tool!
They call me different but the truth is they're all the same!
JaxCoder.com
|
|
|
|
|
When I was programming PLCs and I had to develope something, I wanted to see the whole structure / sequence so I used paper (usually DIN A3, couple of times up to DIN A1), pen and rubber gum to make the graphcets and then I used coins to simulate the evolution of the truth states
If I had to write some documentation I have mostly used excel or ppt for diagrams, because they always were installed by the company I have worked to and they were enough for what I needed in 99% of the times.
If the diagram was way more complicated AND if Visio was installed, then Visio because I find it easier to manage the multi page format, although there are times I must rant very loud, because its automation annoys me, when I tried to do something not that standard. If it wasn't installed... back to excel, powerpoint or even paper + scan the result
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
