Slashdot Mirror
The Robots That Will Put Coders Out of Work
snydeq writes Researchers warn that a glut of code is coming that will depress wages and turn coders into Uber drivers, InfoWorld reports. "The researchers — Boston University's Seth Benzell, Laurence Kotlikoff, and Guillermo LaGarda, and Columbia University's Jeffrey Sachs — aren't predicting some silly, Terminator-like robot apocalypse. What they are saying is that our economy is entering a new type of boom-and-bust cycle that accelerates the production of new products and new code so rapidly that supply outstrips demand. The solution to that shortage will be to figure out how not to need those hard-to-find human experts. In fact, it's already happening in some areas."
wake me up when the robot knows how to debug an AbstractMethodError...
This time was different :(
Well, someone will have to write the detailed specification, and list of instructions for the system to use to know what the humans want it to code. We could call that person a 'Programmerator' and the system a 'Compileatron'.
The combination of capitalism and democracy that has been good for us since the 19th century is now too old to cope. We need something new beyond plain consumerism and 'get rich quick' to drive us. Maybe Marx will indeed have a last laugh.
Jokes one them. Uber's robot cares are going to put Uber drivers out of business.
At first, it will begin in the Open Source community.
By the time they are ready to embrace the future they were promised it will be gone. Ah well at least it might be an amusing hobby for them.
.. They wont
This is nothing new. For instance, word processing consultants were put out of business by Word Perfect. If those former word processing consultants wanted to stay relevant, they had to retrain themselves. In software development, we're constantly trying to automate our own work and replace ourselves, until one day we're actually successful at it, and then we have to find a new problem to solve if we want to stay relevant on the open market.
I'm not sure why those guys are taking a jab at Uber thought. Uber isn't replacing Taxis. It's meeting the demands of the open market during peak hours, which Taxis are incapable of filling by themselves (at least, not in places like San Francisco or New York where it's absolutely impossible to get a taxi during the time when you most need one).
Will there also be robots to write reviews of the coding robots?
TFA is crap and has nothing to do with TFP which is also crap.
A quote from the Introduction of the paper (The alive reader will notice that they failed to spellcheck it):
Ironically, smart machines are invaluable for considering what they might do
to us and when they might do it. This paper uses the most versatile of smart
machines – a run-of-the-mill computer – to simulate one particular vision of hu-
man replacement. Our simulated economy – an overlapping generations model
– is bare bones. It features two types of workers consuming two goods for two
periods. Yet it admits a large range of dynamic outcomes, some of which are
quite unpleasant.
The model’s two types of agents are called high-tech workers and low-tech work-
ers. The first group has a comparative advantage at analytical tasks, the sec-
ond in empathetic and interpersonal tasks. Both work full time, but only when
young. High-tech workers produce new software code, which adds to the ex-
isting stock of code. They are compensated by licensing their newly produced
code for immediate use and by selling rights to its future use. Thestock of code
– new plus old – is combined with the stock of capital to produce automatable
goods and services (hereafter referred to as ‘goods’). Goods can beconsumed
or used as capital. Unlike high-tech workers, low-tech workers are right brainers
– artists, musicians, priests, astrologers, psychologists, etc. They produce the
model’s other good, human services (hereafter referred to as ‘services’). The ser-
vice sector does not use capital as an input, just the labor of high and low-tech
workers.
Code references not just software but, more generally, rules and instructions
for generating output from capital. Because of this, code is both created
byand is a substitute for the analytical labor provided by high-tech workers
in the good (autmomatable) sector. Code is not to be thought of as accumulating
in a quantitative way (anyone who has worked on a large software project can
testify that fewer lines of code often mean a better program) but rather in
efficiency units.
Our new
I'm sorry Dave, I'm afraid I cannot finish that.
... he just endorsed the (fallacious) idea that all children need to learn to code.
It little behooves the best of us to comment on the rest of us.
I read the article, and I'm not buying it.
I can see programmers in some small, well-understood niche markets replaced by complex applications (which require more programmers to write!) and causing some programmers to go looking elsewhere for jobs. But new technologies for computer-aided software design are not going to cause structural unemployment any time soon in the IT profession.
Some reasons include the cost of miracle software-building robots will be at a premium, which means only the biggest players would be able to afford them. And after they purchase them, they will only be able to work well within a limited number of tasks.
Imagine how many more programmers would be needed if we didn't have compilers. Or automatic code generators. And the whole point of machine learning is that you write software that teaches itself how to do something, rather than program it directly.
Software developers have been quite good at moving up into higher levels of abstraction each time we multiply our productivity. There's so much work to do that I doubt our tools will ever "displace" us.
Doing a job that requires thinking without thinking may be the MBAs dream, but that always ends up involving more people, to clean the mess up and to do it right.
Any good software architect or engineer should have the goal of minimizing the needed code / work for a project. If it takes metaprogramming, then fine. If it requires creating general purpose run-times (such as auto optimizers, such as simple hill climbers or as advanced as large neural nets) thats fine too. If the general purpose runtimes can code and thus are meta programs, great.
The idea of declarative programming for specialized run-times is nothing new. If you apply it to a general runtime that can do programming, you then have a system that makes functions that meet specs: programming moves to producing what ever declarative specs such a system consumes. Once again its just a move to a higher level language and abstraction. If (and thats a big if) its trivial to write in such a language, and all us coders no longer need skill or experience to develop new applications and we all become unemployed, well, thats the goal right: make developing your applications trivial?
Every advancement we make, assemblers, higher level languages (like C), and all those language paradigms (OOP, functional, generics/templates etc) are supposed to help with this. So are libraries. We make software hundreds of thousands of times more complex than we used to because of these advances. Much of the software of today may become trivialized by the coming advancements just as much old software has been since we started programming. Maybe we will just keep making software more complex, or maybe well will create more different applications, or maybe we will just have time to catch up, optimize and fix all the broken shit? Or most of us could become unemployed because we have enough complexity, and new tools will make the work needed go down not up.
You know, I would be *delighted* if some robot could write my project for me. However, the author of the Fine Article doesn't seem to understand the difference between a "just good enough" sports story and even the difficulty in the first step of writing clear requirements, let alone coding them.
This is a "we'll all have flying cars" sort of paper by people who could not make flying cars but were convinced that they'd be here any moment.
Strong AI is the first "computer program" that has the potential to automate the act of creativity. Everything less can be a compiler, a pattern recognizer, an Uber driver, and in general a tool that does what it is told .
And we are not particularly closer to Strong AI than when it was first theorized.
I would be more impressed with a paper by people who could actually make the software these guys theorize about, rather than sophomoricaly discussing it.
Bruce Perens.
It was called The Last One
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Anything that can be automated will be. An awful lot of programmers are already doing nothing more than running macros and "smart commands" with IDEs like Eclipse to produce the bulk of their code. Given a sufficiently detailed application model and an appropriate rule engine, the need for that "skillset" becomes obsolete.
Eventually only the highest level functions will need to be coded "by hand", themselves driven by the application models instead of class and structure definitions.
Throughout my career as a programmer and even after I retired, programming has consistently and constantly evolved to higher and higher levels of abstraction. It's only a matter of time, effort, and the question of who will be first to market.
But it will happen.
I do not fail; I succeed at finding out what does not work.
the first, due to happen right now, is a bunch of smug posts claiming that programmers are too smart and talented for anything like that to happen to them. obsolescence is for the merit-less poor, people doing crappy non-programming, non-geek jobs - people who actually deserve to be treated like shit. it could never happen to them, they're far too important.
in a few years, when it is actually happening to them, there'll be a bunch of whining posts about how unfair it is that programmers have to compete with machines for their jobs, that was never supposed to happen to the super-smart, super-talented entitled rich white dudes...they'll all be crying something like "Google, why hast thou forsaken me?"
even then, these stupid entitled fucks will cling to their idiotic libertarian beliefs and refuse to believe that the owner class, the 1%, the bosses, the venture capitalists don't give a fuck about them and never have - if they think of programmers at all it's with resentment that they currently need some people who are difficult to replace....all worker units are meant to be slot-in replacements for each other, and they'll invest large sums of money to make sure that's the case for everyone.
Code is not crystal, and shouldn't be managed that way: see The Honeymoon Effect in software development.
Given the need for smarter software in the cloud, and the need to refactor old code due to security issues - most good programmers will be employed doing that for some time.
The sky is not f------ (connection lost)
A lot of coding is busy work. And I'm sure the AIs can do a lot of it. But who hasn't been sitting there doing it and thought "I'm too smart to be doing this stupid job."... because that happens all the time for a lot of people in a lot of jobs. And yeah... a computer or a monkey could do those jobs so long as they were taught how to do the trick.
But the nifty problem solving that only humans are still capable of doing? That's a different matter.
Rather then getting all upset about people losing jobs they hate to machines rejoice that the jobs of the future will be more interesting because the only things you'll need humans for will be more interesting work.
Here someone will say "but there are a lot of stupid humans that can't do interesting work!"... yes and no. A stupid human isn't going to do anything that requires high level human intelligence. But even low level human intelligence is actually very useful if properly applied.
At some point, low human intelligence is going to be a barrier to entry to the job market. But really, it is already a huge problem for someone if they're stupid. Lots of jobs simply are closed to them and that is likely going to get worse going forward.
Anyway, I'm not worried about it. I'm just looking forward to the expert systems that I can use to help me cut out the busy work in my coding. Sounds like fun.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
...laser printers are never out of work. :(
Sent from my ENIAC
Greedy corporate overlords don't want to pay their workers, and economists keep on trying to blame technology.
If your operation is more productive, you can afford to pay your workers more. They just don't want to.
"Your job has been terminated."
Please stop posting sensationalistic InfoWorld articles submitted by snydeq.
Back in my FoxPro days I cranked out smallish biz apps like lightning with 1/4 the code I use now. The multi-layered client-server and then the HTML/CSS/JS/foo++/SQL stack gummed up that and turned CRUD into a mini bureaucracy.
Blow up the HTML stack and create GUI and CRUD-friendly browsers and markup, and database-integrated table-driven languages, and many internal biz coders will go gone. (No, MS-Access didn't integrate the database and code side well. I don't count it.)
Table-ized A.I.
It tries to paint this picture of machines no longer needing upgrades, only maintenance. What corporation is going to put out machines that do not need replacing? Corporations that want to go out of business cause they have no products being sold, only maintenance contracts to coast along on, dwindling revenues mean no money for R&D to make new products and they are in a death spiral until they are gobbled up, the good parts stripped out, and the rest sold off.
Seriously, corporations stopped doing that years ago in the tech sector.
Let's see them work with PHB's and clueless users to nail down "requirements". Automating logic is easy, automating prediction of random idiots is not so easy because randomness is by definition not predictable.
You have go to lunch with and sit in boring meetings with them to figure them out, and the robot will be booted out of the room because it will ask good but embarrassing, ego-shattering questions; and not get the design analogies that use Kardashian asses as reference points, asking silly questions in an attempt to figure it out. The business world is bunches of social institutions much more than it is think tanks.
You are trying to replace humans, not Vulcans. Kirk ran the missions better than Spock because he could identify better with illogical and petty aliens.
Table-ized A.I.
They already have code robots. It's called outsourcing to India and the quality is about what you'd expect, lousy.
The article does not have anything even worthy of consideration. It is just bloat with a snappy headline. The story goes like this: we know there is technical progress, software developers are in as high demand as never before, with wages 70% above other 'induatrial workers'. In the past, such high skilled workforce lead to investment into automation, and that's already happening. Case in point: standardized sports events are written by computers, not journalist. See? If you can replace journalists, sure developers are in immediate danger. After all, not much difference, developers and journalists alike type on keyboards and sit in offices and are good at exressing their thoughts in words. Developers beware!!
Again, just plain and utter BS. Makes me wonder if that article was written by a bot, too.
No code. Business analysts write program logic with a ui.
It is a nightmare. Especially to debug. You think isolating a single line in a program is hard? Try it with a ui. Debugging with visio. Sigh.
research the name columbia and it's real history and meaning
Coders have to write that robots code. Unionize coders, stipulate that union coders refuse to write code that can lower their wages or put them out of work. Problem solved.
The media worries about coders, programmers..... who cares.... I have done those tasks for decades ... that is not the important part.
The key need is elegant, effective design of any given system, and it better actually solve the business or functional requirement.
Nobody is automating that solutions design ability .... I can assure you. Why? Because good design encompasses both technical constraints and real world issues: like support staff capabilities, financial resources, and the personality issues of the team involved.
Back in 1996 I was working on building websites. I met lots of people that told me when Microsoft get in to this you will have to find another job.
I laughed and carried on smugly. Then one day they launched frontpage. A client told me they thought it looked interesting and might help them do it themselves. I was gutted, it was starting, what I now look back at and realise was the event that led to me not working again.
No more charging thousands for animated gifs of workman digging roads or web pages with tables that were really hard to do by hand.
I should have looked for a job for life, like in retail at Woolworths selling chart music. Something that never changes.
But I didn't. 19 years without a job. You have been warned
The Immortals will rise, and they will put the coders out of work.
But not before the rest of you.
Mwha hahaha.
The solution to that imaginary shortage will be to figure out how not to pay those easy-to-find human experts. We call part A of this solution "offshoring", and part B the "H1B Scam." And it's working just fine.
FTFTFS.
I've fallen off your lawn, and I can't get up.
TFA seems to think that just because there is demand for something, there will automatically be a supply. It's not so. Some problems are just hard. There was no automatic solution to the flying car shortage of the 1950s or the gold shortage of all of time.
This is why I make video games. The coding is the mechanics of the game, and they are part of the entertainment content along with the story.
Even if everyone has a car, there will be car collectors and gear-heads. Given sufficient supply, products that entertain are always in demand. This is thanks to the magic of boredom which cyberneticians like me understand as normalized activity cycles, while utilitarian economists struggle to understand the cyclic nature of life.
I put it to you that even if programming is made as simple and accessible as having a device read solutions from one's mind, programmers will still exist because higher ups won't want to waste their time doing so.
programmers will still exist because higher ups won't want to waste their time doing so.
Bullshit. Wait, do secretaries really exist?
I heard about automated programming nearly 40 years and it still doesn't exist. The real world has lots of boundary conditions that must be described to a computer using maths and logic: A lot of people can't talk or think in those terms.
When CS researchers invented AI they predicted walking, talking robots and perfect weather forecasts in a decade. Then they discovered how complex motion and speech is. Then the discovery of chaos theory ruined their hope of forecasting perfection.
There's no need for experts: Throw enough monkeys at typewriters and one-day you'll have a Shakespearean sonnet. The trick is regulating that process so the failures are quickly identified and eliminated. Which is also an AI-based problem, so one needs AI to get AI. Maybe one day AI science will reach that critical mass. But the past teaches us that making AI isn't easy, and is a long, slow journey. Today, state-of-the-art AI seems to generate intelligence equal to an ant.
i think we all know it's inevitable.
:) but we are building these smart systems because they earn us money.. Cant stop that train.
..
:)
How we'll get there is interesting, and what we'll do after the fact is something I sometimes ask myself.
Imagining the faster computer get at connecting neural networks of public domain or the opensource world | collective thoughts to other connections.
Shit i'm slow to figure whats 'cool' these days.
> How do I feel about computers surpassing us?
humm not so wall. It seems to be something genetic built in that says survive
> the turning point... when computers view us 'atoms' as not important anymore....
I wounder if the 'computer' will have the same strategy to survive as us. or view the would as something that is not important because of a predetermined nature
Another view more hopeful, exploring 'cosmos' more in detail and continue the strategy to learn/survive.
too much fun after a night of drinking... hope my words were worth typing
I'm an embedded developer. Let's see what a robot has to do to replace me:
First of all the robot would have to sit in meetings with the customer understanding what the customer wants, telling him what can't be done and outlining alternative solutions in dumbed down language the customer understands. It should tell the customer if some of his choices will raise the cost (Yes, in theory the hardware can do X but the current drivers can't).
It would have to write an offer listing everything that the customer wants to have implemented but worded so he can't expect more for his money. It has to be worded so that sales people and management understand enough to agree to the price written at the bottom.
It needs to understand all documentation provided by the customer and it needs to be able to find more. It also needs to know who it can ask for an undocumented detail. Currently documentation includes data sheets, Doxygen like API descriptions, articles, standards, schematics, forum discussions, RCS commit messages, source code, and books but there will probably be a new form designed to be understood by machines. It is also useful to remember everything the customer said even if it might turn out to be wrong.
It has to know sources of errors. Documentation can have errors. There can be errors in the design of the hardware. The hardware might be faulty (f.ex. bad solder joints) and you need to know what will destroy the hardware (no you can't configure that GPIO to output a low value). It has to fix simple errors itself (yes, I did have to solder some jumper wires and pull up resistors in the past few years). If it can't fix the error, it has to discuss the problem with someone who can. If the problem won't be fixed (no we won't spin a new SoC revision for you) software workarounds have to be devised and the pros and cons have to be discussed with the customer. To be able to find errors, it has to know about software and hardware debugging techniques (printf debugging, Gdb, Valgrind, JTAG, oscilloscope probing, ...).
It has to write code in a form that can be maintained. It has to merge code (complete components and updates thereof) from suppliers and know what has to be changed to make it work again. Our suppliers often don't know they are supplying to us, so is has to have an eye on their release and security announcements. It has to decide if an update is advised and then has to inform the customers (if they signed a support contract).
It has to come up with software tests. Some customers explicitly want unit tests or detailed test reports. It has to do the tests that have been paid for. Of course the minimum testing is determined by what makes you feel confident that it works.
It has to write documentation. Test reports, end user documentation, API descriptions.
It has to communicate with the customer to ask for things that have to be provided (We need a cable for your special connector on port X. When can we expect the display PCB to be done?), to learn about bugs and to announce releases. Doing so it has to be polite. It must be pleasant for the customer to communicate with the robot.
It has to meet with the customer for an integration workshop (Our first board revision will be assembled on Thursday. Can you come on Friday to make the software work? Yes, we know it did work on the evaluation board.) or to analyze bugs on size (Our factory stops working about a handful of times a day. No we can't send it to you and we won't connect it to the internet for debugging.).
There is probably still something I forgot. In my opinion it would be inefficient to split all this between humans an robots. How would a human know what is possible if it doesn't do the coding? Given all that, I think my job is safe until machines are intelligent enough to rule the world.
Tfa days that when code is produced that works so well that improvements are unnecessary then demand for code will fall ... Just like demand for mobile phones went when someone made a phone that was good enough.
First of all, the argumentation of the article is wrong. And second, the automation of coding is no new thing happening in this world. At the beginning of programming people draw solutions on paper, then encoded them in machine operations and pushed holes in punchcards. All these tasks were first done by humans and then subsequently transferred to machines and computers, by assemblers, compilers and later build systems. As time passed only the jobs where algorithms had to be written remained making compilers and assemblers workless. Since then complexity of software increased and better programming languages allowed to structure programming even more. Nowadays, we have four distinct areas of software systems: Embedded systems, desktop software (which includes to some degree app programming), enterprise systmes, and high performance computing.
Embedded systems are mostly reactive systems and they have to fulfill high savety standards. Therefore, they use specific languages to achieve this combined with verification. However, standard C for example, allows for too many errors therefore they limit the use of certain constructs in the language. Furthermore, they use domain specific languages (DSL) to abstract from plain C. In addition they use libraries for specific reoccuring functions. For desktop systems, OS wirting has similarities to embedded systems, however the main effort is put into programming applications and apps. Therefore, people use any number of frameworks which provide a specific API which is also seen as internal DSLs and use external DSLs often encoded in XML to describe the UI and other typical tasks of their applications. In enterprise computing the use of DSLs is even more widespread. For example, most people use there templating languages such as JSF or GWT with various extensions. They also use DSLs to define the data model and queries on that data model. Also workflows can be formulated in BPMN or BPEL. All these technologies have been used to rise the level of abstractions. Therefore, present day coders do not need to know that much about implementing an specific algorithm, they more need to be able to find the right function in their DSL and frameworks. This even lowered the barrier for people to enter programming compared to systems around the 1980/90s when it was necessary to be able to implement quicksort. True, today it is harder to get started with programming, but that is beside the point.
In future, we will even more use people to model software. They will use any number of modeling languages to do so. And they will still be required to think logically. We might have less webdesigners, but hey when the few remaining designers would be able to not only draw "nice" interfaces, but would also understand that what they design is there to be used to communicated between human and machine, then we are in a better world than now. The only problem I see, is the unwillingness of you computer scientists to go into modelling. And that compared with the fact that most of them are not really able to code. And yes, those poeple will have a real big problem in future. People who are able to write generators, however, will have a superb future and a lot of work.
I would love if somebody come and make my job easier, but the hard part is not programming, is to deal with people ambiguous needs, changing specifications. Its a StrongAI problem. Another problem is that good programming must generate programs that are easy to mantain, to do so you need somebody to understand the program. Understanding is another strong-ai thing.
Fresh Plankin.
TFA says that programmers have created programs that are so good at chess that they can beat any human. It goes on to say that programmers have created news-writing programs that adequately report on sports. From this, TFA concludes that programs will magically be able to replace programmers.
This story comes up every few years. They are all written off the same template, like how this new generation of tools will allow everyone to write their own apps, and you don't need professional programmers, and here's an example of an 8-year old who made an app in two minutes etc. These stories are written by people who don't have a clue what the working day of a programmer looks like, and imagines something sitting isolated at his desk typing in code all day
The programmer's job is to translate the requirements from other humans into requirements that a machine can understand. For very well-defined domains of applications, it is indeed possible for non-programmers to use tools that can achieve the same thing. That was the same with VB 1.0 or equivalents prior to that. I don't think the scope of possible applications that can be written in this way has broadened much in the decades after. Applications that is just a dialog with very simple logic can be written by drawing the dialog and copy-pasting and adapting small statements etc.
Beyond that there's not been much progress in "auto-writing" applications. The reason is, that the current programming languages are actually fairly efficient and precise ways of explaining to a computer what it should do. The job of the programmer is to translate the "business" requirements into that specification.
Even for a fairly trivial stand-alone program computers can't do this today. Even if that were to happen, consider that much of the programmer's time is not spent writing code within some confined, well-defined environment, just writing line after line. Rather, it is spent understanding the customer-specific requirements, realizing if they are impossible/inconsistent and working out a solution together with the customer, integrating multiple systems and many different levels in those systems using completely different interfaces and paradigms, and figuring out how it is all going to work together.
My experience is that most automatic code-writing and analysis tool stop working when you add this layer of complexity. They may work well for a completely stand-alone Java application with a main() method, but how does it work when you have client code, native code, server code, 10 diff. frameworks, 3rd party libraries some written in other languages, external web services, legacy systems, end-users who think about things in different ways than the internal data models etc, implicit contracts/conventions, leaky abstractions, unspecified time-out conditions, workarounds required due to bug in other systems and difference in end-user setups? The complexity and bugs here is always resolved by human programmers and I suspect it will be that way for a long, long time even if computers manage to be able to write stand-alone programs themselves (which IMHO will be the point where we have something approaching general AI). While you can take individual aspects of these problems and formalize them, the amount of combinations and the diversity in scenarios is so big, that it becomes impractical.
If you have competent programmers, most of the bugs are going to be in these areas, since it is also easy for a competent human programmer to write a stand-alone program that works well on one machine.
It is funny when these fear-mongers appear. People have tried to automate the shit out of software development for as long as it was a thing. Assemblers, compilers and frameworks. The only thing that has happened was that we got developers that specialized for the usage of the tools. e.g. People automated the shit out of web development with Ruby on Rails, the only thing that happened was that we got demand for Ruby On Rails "programmers"(users).
Before the programmer who is automating job X is laid off, the person currently performing job X will be laid off due to the new program.
Yes, but it'll be persons who get laid off - as in thousands of persons.
And we need to realize that automation is affecting all levels of workers - including knowledge workers like programmers. What I can do by dragging and dropping in XCode or Visual Studio in a few minutes took me days of coding. Go and write a Windows program using C/win32 sometime - with all those message loops - and you will get an idea. Back in the old days, we also had to hand code the UI features too - none of WYSIWYG dragging and dropping. Of course, it is wonderful not having to write the same or similar code over and over again; so automation has taken a lot of tedium out of programming.
But in the 21st century and with modern computers, nobody is immune from the effects of automation.
Will code production become so pigeonholed to so few actual programs variants that you will be able to simply pick a few blocks from a list, fill in a few blanks and make the program that processes what you need?
I doubt it very much.
Too many endcases in real programming and too many specific tasks that even when 'big chunks' might still be 'picked' (like data bases etc..) but all the rest of the specification will be customized and if anything programs are being written for more and more things still.
Most of the "coders" I know cannot code. A robot would do better most of the time. Great idea... I'll start writing a robot coder now.
Code generators, syntax highlighting, then on to integrated refactoring tools, things like Intellisense.... I give software engineers 15 years.
I am very small, utmostly microscopic.
If there are less technical people and if I'm strapped for cash perhaps I can do back hat pen-testing. Of course there will be certain organizations that I would never help, but there are organizations such as green peace that I would help.
This is nothing but a fear piece designed to sell ads and maybe keep wages from going thru the roof.
The example about the chess programmers is pure bullshit. They weren't displaced by robot coders, they were simply not needed any more because the existing solution was good enough. None of the examples have anything to do with developers.
There's lots of people working on implementing machines to write code. Be it meta-languages that are needed to simplify all the boiler-plate code, or graphical language representations.
If we just had a chance to write the code needed (right down there in assembly, or very close), without too much abstraction etc. on top, most things would be much cheaper to get done. Considering the the typical half-life of modern applications, limited maintainability isn't even a real problem.
Short: There is machines writing code, but overall this approach takes more effort than just doing what would otherwise be needed.
I am still waiting for the translation toolkit which would translate 50% of moderately complex sentences right from one human language to another. Only after this I'd start worrying about computers generating good programs.
We need to move full time to 32 hours or less.
Start at 32 hours with say X2 OT at 60 and at 70-80 X3 OT with no more salary BS or say for salary with no OT pay min pay level 100K+COL.
We may end with lot's of people not working and others pulling 60-80 hour weeks doing the work of 2-5 people + overseeing the bot system.
The robots still need commands, like, I like a blue rectangle here, a red rectangle here, I want this button to send this text, etc. So at the very most, I see only higher level programming languages developing. It's similar to what's happening with electronic music. Once upon a time, it was preferable to create your own tools. It required engineering. Now, so many people are creating tools, most of the process (and credit) has been shifted to the composers. Still, there's a lot of room for improvement in music software, and I simply see larger teams assembling in the future who can create the sounds they're looking for, the systems that help in the composition of good music, and then composers to compose with them.
Anyone hear of it?
Researchers warn that a glut of code is coming that will depress wages and turn coders into Uber drivers,
So what we have discussed hundreds of times here, and what I have seen labelled racism, is finally admitted flat out. I am personally rather impressed by the honesty.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I work in an area of law where there is a great glut of "talent" (doc review) and pay varies greatly. Read Chinese? Japanese? Ukrainian? You earn much more than English.
I predict pay will increase for obscure talents (Cobol), and collapse for the rest. (except that's already true??)
I've been trying to automate myself out of a job for TWO DECADES and have yet to notice any decrease in my workload.
They're called 'executive assistants' now.
A smart development team lead gets one for the whole team to share. It's a hell job. Assburger programmers.
Once employed one who reminded me of Nurse Ratchet. I was not allowed to pay her what she was worth. I think she made the whole team at least 20% more effective by acting as a preschool teacher; putting biters in timeout. Of course she got sick of it and moved on.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
I'm not sure I buy the whole argument, but there is one thing that might come true. Most development frameworks are so far abstracted from the actual hardware and software dependencies that it might as well be like gluing together functionality chunks. This has and will continue to make simple application/web development more accessible. Look at iOS and Android -- lots of the hard work is done for the developer. Instead of calling into the database directly, a complex API feature optimizes the query somewhat and returns the results in a nice format. Accessing the phone's hardware is similar -- just more glue code. Web frameworks are similar, and the design goal is to make applications easier to write/maintain.
Automating development has been tried for years, as has separating dev from business logic and giving analysts the ability to write applications. (Access and Excel macros are the best I've seen so far in this category.) I think the market for the typical junior developer writing a CRUD application or web forms might be less lucrative, but someone still has to know how to interact with the hardware at a low level. The toolkits, libraries and frameworks can't write themselves.
What AI does today is adjusting variable value to increase prediction.
So at a point, yes software could and do self-improve after a certain level of complexity.
What AI don't do, is finding and describing deeply enough a new concept to put it into code.
And as code is merely a procedure description, that's just what we are talking about.
So yes, we will have a levelX programming language, where the details will be AI covered.
And yes, in a case of shortage for new ideas, you will find programmers out of job.
But as new applications does brings news opportunities, that day has never comes.
So, as statistical prediction are made of the average of what's already been...
It's what we do. Remember what a "coder" (or a "programmer", before that) used to be: a data entrist. Who needs them anymore? Smarter programs kill manual coding. Nothing new.
...as soon as robots can write code, the singularity hits! It is impossible to predict what that world will be like, but I am willing to wager that unemployment for programmers will be pretty low on the list of anyone's concerns.
Relevant words of a prophet.
We knew it was coming. The lavish positions for programmers, the absolute demand with the high salaries, it has to end. And there's no backup because everyone who works in the industry is coming in with five figures at least, often six. And the job doesn't demand harsh working conditions. Little risk compared to more manual labors, and the only thing needed is a little knowledge, and a laptop.
There are labor unions that exist, and I encourage you to check them out.
Communications, Computer, and Software Workers:
Industrial Workers of the World: Industrial Union 560 - http://www.iww.org/unions/dept500/iu560
If we fear this, then we need to take action.
developers, not less. Author is under the mistaken impression that more is better. It's not. Code is liability. The more you have, the bigger your problems. Nothing will change that without strong AI, which would be a much, much larger matter.
I see InfoWorld is also the same site that gave us the useless "Java vs. Node.js: An epic battle for developer mind share" article.
It's a constant irritation, reading articles written by so-called science and tech journalists that don't know what they're talking about.
They make a lot of assumptions about what is possible, based on economic cycles. It's really the industrial revolution all over again. The amount of work one person can do has been increasing for a couple hundred years now, but somehow we keep finding things to do. In the 60s, there were widespread predictions that by 2000, people would typically work 24 hours a week, because of automation and computerization of work. Ha! Don't we all wish!
Software development is more like product design than product production. After decades of getting better at product design, computerizing all kinds of aspects of the design process, we still need lots of product designers. For the same reason, we will always continue to need people with programming skills...the job called "programming" will just use different, more powerful tools. As efficiency increases, the pace escalates. Now we can go to market with new products (or new software) in a matter of weeks or months, instead of years.
Software helps to make programmers more productive; computers can translate (compile) code, but not create software.
The real challenge: if robots put lots of people out of work, the economy will go into a depression and put a certain number of programmers out of work.
But who will program the program? Once the new amazing program is created, will users somehow be able to communicate requirements or will they just get a wizard?
The problem is not the lack of coders, the problem is that our species can not keep pace with our rate of technological innovation and expansion. Technology is ubiquitous as evidenced by people walking around like zombies starting at screens. Until we get a handle on technology, what it "is", where it is taking us, and how to adapt it to our species in a sane way, I doubt that programming will go away. It might morph, but it will still require advanced knowledge of business rules, databases, and processing.
As long as we are chasing the shiny ball of hardware, technology, and new functionality we will need programmers. When the ultimate platform is finally decided or all the players agree to use a platform neutral architecture, then we can run code generators. Oh wait, I think we tried that with JAVA and .NET.
This guy is making the laughable assumption that code is really write-once run-forever. Most code is specialized to the needs of the moment due to the cost barriers to making it sufficiently robust to solve problems is a run-forever way. Even in cases where the broad problems are in scope, it's usually with a fixed set of performance, availability, and security needs in mind. Clearly we're all still driving a Model-T, Mr. Ford.
In reality most programmers aren't building new code, they are custom fitting known techniques to a particular client's needs at that time. That is driven by the changing desires, needs, and wants of people - as long as people want a new iPhone 12 there will be a large army of programmers rehashing code to fit the new API, new swipe, thumprint, camera combination it provides.
I agree software now is a mess. I program in JavaScript for deployability, but it too is a mess, and much harder to work with than Smalltalk or even Java or Clipper. HyperCard was another great system for its time. Greed harmed several of these languages, Smalltalk and HyperCard especially, but even Java by keeping it proprietary for so long.
Ironically, compared to the article's suggestion, it seems the more code we have, the more programmers we need to keep up with it. :-) On economics, one might otherwise expect that the more infrastructure code there is, the less workers you need to build more of it. Otherwise, in general, I agree with C. H. Douglas that we benefit by building on the work of previous generations.
http://en.wikipedia.org/wiki/S...
"Douglas disagreed with classical economists who recognised only three factors of production: land, labour and capital. While Douglas did not deny the role of these factors in production, he saw the âoecultural inheritance of societyâ as the primary factor. He defined cultural inheritance as the knowledge, techniques and processes that have been handed down to us incrementally from the origins of civilization (i.e. progress). Consequently, mankind does not have to keep "reinventing the wheel". "We are merely the administrators of that cultural inheritance, and to that extent the cultural inheritance is the property of all of us, without exception."
As I see it though, we probably have about 99X+ more programmers than we need already, as far as core infrastructure. :-) For example, why did we need JavaScript when Smalltalk was a perfectly fine language that was better in many ways? How many accounting software packages do we really need? How many word processors? How many CAD tools? How many plugins do we need to just work around problems produced by endless similar formats? Do we really need so many image formats or audio formats (driven in part by patents)? Most programs out there are essentially needless variations on basic themes. Just like most new pharmaceuticals (90%) are "me too" drugs for rich people's problems.
Much of what programmers do in practice is (perhaps unintentionally) make work for each other. It may well be worse than the legal profession in that sense (where lawyers make work for each other or create or encourage conflicts). A lot of that comes from the nature of capitalism and competition vs. alternative economic forms based more on cooperation. Programmers typically can't freely share code or specs with others in different businesses, so everyone is always re-inventing the wheel and reverse engineering data structures and data formats and communications protocols, which create a proliferation of slightly different code bases with different edge cases.
For another example, why do we really need so many web browser engines? Also, why could not some web standards body accept Sqlite as the defacto web browser data storage engine because there were not "multiple implementations"? A shared public codebase is often the best standard. Like Alan Kay says, any textual standard of more than five lines is ambiguous. On that Sqlite issue, see:
http://diveintohtml5.info/stor...
"All of which brings us to the following disclaimer, currently residing at the top of the Web SQL Database specification: "This specification has reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. Until another implementor is interested in implementing this spec, the description of the SQL dialect has been left as simply a reference to Sqlite, which isn't acceptable for a standard. ""
Instead of that well engineered Sqlite library, we now get a half-baked "IndexedDB" standard as Firefox refuses to support Web SQL as Sqlite even though Sqlite is already baked into the F
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
As an example, and with its own problems, the Raspberry Pi has proved "good enough" for a lot of embedded companies, who just accept various tradeoffs to code in Python (or whatever) under Linux. In ten years, such hardware will be even cheaper and even better, and may have even better RTOS support:
http://pebblebay.com/raspberry...
Likewise and even more so for the truly free and open source Beagleboard family:
http://beagleboard.org/
What a far cry from the Kim-1 with 1K of memory I bought as a kid (with my father's help) for probably 50X in current dollars what a Rapsberry Pi or Beagleboard costs and supplies about 1GB memory. We even had to build the power supply ourselves. :-)
This is not to disagree with what you are saying right now. I know how hard and important all that work can be. But if better tools eventually let fewer engineers produce more projects in the same time, and cheaper hardware means less constraints, and other standards change expectations so customers know to work within them, than the need for managing such complexity (including the human side) may go down. Granted with a rising increase in an internet of things and robotics, embedded work may well still increase in demand for a decade or two until better standards come to dominate the field and change the nature of so many embedded tasks. So, for anyone already well enmeshed int he embedded field, it may well be a good gig for the next decade or two.
Anyway, for fun, to go through your list (a bit tongue in cheek, so not completely serous answers):
"First of all the robot would have to sit in meetings with the customer understanding what the customer wants, telling him what can't be done and outlining alternative solutions in dumbed down language the customer understands. It should tell the customer if some of his choices will raise the cost (Yes, in theory the hardware can do X but the current drivers can't)."
This can be replaced in part by a web interface where the customer clicks on options and the software tells them if the combination is allowed.
"It would have to write an offer listing everything that the customer wants to have implemented but worded so he can't expect more for his money. It has to be worded so that sales people and management understand enough to agree to the price written at the bottom."
Again, web backend generates this based on web interface choices.
"It needs to understand all documentation provided by the customer and it needs to be able to find more. It also needs to know who it can ask for an undocumented detail. Currently documentation includes data sheets, Doxygen like API descriptions, articles, standards, schematics, forum discussions, RCS commit messages, source code, and books but there will probably be a new form designed to be understood by machines. It is also useful to remember everything the customer said even if it might turn out to be wrong."
This could be mostly replaced by machine-readable standards as you suggest.
"It has to know sources of errors. Documentation can have errors. There can be errors in the design of the hardware. The hardware might be faulty (f.ex. bad solder joints) and you need to know what will destroy the hardware (no you can't configure that GPIO to output a low value). It has to fix simple errors itself (yes, I did have to solder some jumper wires and pull up resistors in the past few years). If it can't fix the error, it has to discuss the problem with someone who can. If the problem won't be fixed (no we won't spin a new SoC revision for you) software workarounds have to be devised and the pros and cons have to be discussed with the customer. To be able to find errors, it has to know about software and hardware debugging techniques (printf debugging, Gdb, Valgrind, JTAG, oscilloscope probing, ...)."
Bad hardware becomes so cheap it is discarded. Twenty years ago O
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Programmers do more than code. On a large project coding is about 10% of the effort. And it is difficult to find quality people to do the work. The idea that this can be automate is an insult.
15 years ago they said that programmers would go away because pluggable modules would be easily usable by lower tech workers. But what happened instead, is that the number of programming jobs has continued to grow at an ever increasing rate, the complexity of knowledge required by a programmer has grown, as well. I call bullshit.
...the original article were written by a bot.
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
Or maybe that's scripting languages.... or maybe it's compilers.... or maybe it's HEX.
Every rule has more than one consequence.
Why is there no map theory? Because a map is a theory.
Code is a theory about solving a problem. There is no general theory about problem solving.
It's the major reason CASE failed. You could get the job done in less time than it takes to search a library of code.
Until Big Blue is sentient, if ever, it will be able to search code and suggest or possibly refactor and apply solutions. Another big drop in the need for coders follows. It will do what most coders can't do; look at all possible solutions and understand if there is a good fit.
Are there truly 1M-1.5M unique apps? Which are the truly best ones and how does one find them?
Harvard Undergrad writes app that predicts economic boom-bust cycles
Human beings cannot successfully turn vague specs into a working product. Why would machines that are orders of magnitude dumber, yet orders of magnitude faster, be able to do so? I've never seen evidence to indicate even the possibility.
All automation is either doing dumb things quickly, or accurately reproducing intelligent assumptions given to the machine by the more intelligent programmer. Nowhere is completely new intelligence being generated by the machine.
Every Corporation is a Ponzi/Pyramid scheme in Globalization;
Casteism
http://motherboard.vice.com/re...
We already have "robots" that write code! They are called Compilers and Linkers, and they have put all of the Assembler coders out of work.
Except me and a few others. But I have not actually done assembler for a long time.
The next step up is code generators, like what the Clarion development system has. They are run by scripts which can be written by coders, if necessary. So instead of writing assembler or writing source code, to run the app, we write "Template" code to run the code generators.
But Clarion has been around for more than two decades, so it is not that new... 8-)