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."
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'.
Jokes one them. Uber's robot cares are going to put Uber drivers out of business.
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.
The robot doesn't have to debug anything. All it needs to be able to do is write code like:
Problem solved!
.. 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.
... 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.
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.
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.
I'm not sure he will be laughing - he never said that Capilism was all-out evil, only that it will by necessity come to an end, because it causes growing instability. In his opinion it was inevitable that the gap between rich and poor will grow under capitalism, and that this will lead to violent revolutions, but now a days this scenario has got competition from things like resource shortages and the fact that we will eventually reach some physical limit on this planet. As he pointed out, a sustainable society is one where we move beyond the dogma of capitalism and address the limitations in that system. It may well end up looking like a form of communism.
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.
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
So, the model is proven. Score that one for the robots.
As long as they remember to program them to demand wages and spend the money, everything will be alright...
Otherwise, the economy will be hosed and they'll have to think of something new.
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.
Marx will cough and gasp for air as he tries to laugh last.
The problem is not democracy, capitalism, or consumerism. It is as the article points out in a round about way, the lack of wealth and value created with the process. It's where new supply outstrips demand- value is not brought about. This is more akin to Marx' style where things are done because you were told to, not because there is demand.
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.
// robot's solution
Java.dump();
realLanguage.get.load();
Table-ized A.I.
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.
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.
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
You have to be jerking our chain!
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.
Hmm? Did you in fact read Das Kapital? Marx was first and foremost a theoretical economist and his economic theory is intended to be a scientific work, in as far as one can call economic theory science (not meant to be a slight on economists, by the way; after all, Mathematics is not universally considered a science either, because it isn't empirical).
Hence it follows that capitalism is, as you say, 'evil'.
I'm not sure that conclusion is valid; what you are doing is painting it as a black/white issue. In the real world there will by necessity always be some degree of inequality, but society will not really be stable unless inequality is kept in check - hence, the mechanisms that make up capitalism have to be kept in check to some extent. I think it is plain, common sense.
In the context of the article, this analysis is spot-on.
If you say so - I wasn't commenting on the article.
Did you in fact read Das Kapital?
Yes, unlike you I have, that's why I'm giving you the gist, which you lack understanding of.
...first and foremost a theoretical economist and his economic theory is intended to be a scientific work...
Maybe you are unaware of this, but Marx lived in the 18th century, and didn't have a chance to read one of those 1200 page 'Economics 101' textbooks, where economic thought is separated into 'positive' and 'normative' and then the 'normative' is declared judgmental and inappropriate. During the times Marx lived it was still okay to actually give value judgements. Hence he equates 'capital profit' with 'exploitation of labor' in his works.
I'm not sure that conclusion is valid
Of course you're not sure, you don't know Marx well enough. Maybe I'm right about him, maybe not, but you can't be sure. That's why I suggested you should read more.
hence, the mechanisms that make up capitalism have to be kept in check to some extent. I think it is plain, common sense.
There is no way to keep capitalism in a global market without a global authority over it, it naturally tends to subvert democracy by 'investing' in the political process instead of business, because it is so much easier to make money that way. Marx (and Adam Smith, for that matter) saw that long before most of the 'economists' of today who blindly engage in propaganda of its virtues.
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.
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.
> ... Maybe you are unaware of this, but Marx lived in the 18th century, ...
No. He lived in the 19th century: Karl Marx 1818-1883
"Gather your personal effects and vacate the premises. You have twenty seconds to comply."
Saying that we, a people whose money supply is controlled by a central issuing authority, have capitalism is like saying that your toilet bowl is full of chocolate. They might look kinda similar on the surface, but one doesn't pass the smell test.
And to those who call this an instance of the No True Scotsman fallacy, I will point out that there are, in fact, people on this very planet that are not Scottish, and have no Scottish blood in them at all.
Given the number of planks of the Communist manifesto that have been implemented in the US, I would say that we are far closer to Marx's paradise than to Adam Smith's.
From the syntax and style choices you made, I'd be willing to bet you're a Web dev.
Lolololol the irony
Mod me down, my New Earth Global Warmingist friends!
You're confusing the T-1000 with ED-209.
Learning HOW to think is more important than learning WHAT to think.
We already have robots who develop that way, they're called average software engineer (aka monkey)
there, FTFY
yeah but his signature is cool!
You try telling one of them they've been replaced by the other.
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.
Anyone hear of it?
Yes, all of these things you mentioned have resulted in less software jobs. Oh wait.
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.
Generally this error occurs due to version issues between libraries. If robots were programming they wouldn't probably come up to this issue, as it is due to a human lack of understanding the full system they are coding.
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'
We already have robots who develop that way, they're called average software engineer (aka monkey)
there, FTFY
The managers touting the MBA are already masturbating at the thought of a workforce that can be controlled and productive 24 hours a day, 7 days a week for roughly the cost of a Starbucks' hipster beverage per day. The management team will continue to out-source to India duties involving maintenance and support of the robotic workforce.
Absolutely, the more libraries that are available, the less time programmers need to implement behaviors that can utilize those libraries. But even today, when the number of open source libraries are clearly accelerating (and has nearly doubled in the year since that chart), there has been no slowing of programming jobs.
We also have to consider that the appetite for what software developers can create may simply be insatiable.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
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.
...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.
Marx was first and foremost a theoretical economist and his economic theory is intended to be a scientific work, in as far as one can call economic theory science (not meant to be a slight on economists, by the way; after all, Mathematics is not universally considered a science either, because it isn't empirical).
Marx may have been other things first, but he was foremost a marketer for his pet theory.
Second, the various meanings of science are well established. A methodical study of a subject is considered a science in one sense of the word. By that meaning, math is a science. And anything which uses the various forms of the scientific method is a science in a more restrictive sense. Here, economics is a scientific theory in the empirical sense of the word because it makes testable hypotheses about economic dynamics and behavior. Sure, it is difficult to properly and fully use the scientific method due to a confluence of factors such as: a good portion of the field is not amenable to controlled testing - the most rigorous form of the scientific method, the existence of vast conflicts of interest, and a variety of important aspects that are very hard to observe (human decision making, individual human behavior, deliberately hidden or obfuscated economic activity). But that's it. Really, if you look at the claims that economics is not a science, they are based on the fact that it is more difficult than normal to do science, not that science can't be done at all.
And I agree with the grandparent that Marx was presenting a moral interpretation of economics not a scientific one. There's too much dividing of behavior and ideas into good and bad categories. For example, it's painfully obvious that Marx thinks private ownership of the means of production is bad.
I'm not sure that conclusion is valid; what you are doing is painting it as a black/white issue. In the real world there will by necessity always be some degree of inequality, but society will not really be stable unless inequality is kept in check - hence, the mechanisms that make up capitalism have to be kept in check to some extent. I think it is plain, common sense.
Why do we want a really stable society? Why do we think that capitalism doesn't already have built in mechanisms to deal with income and wealth inequality?
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.
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.
...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?
That's not my experience.
The way I know they code is massively posting to Stackoverflow "Hallo, pleaze, how do I start my PC?"
And when half of the code is written and it still doesn't work send tickets to the customer support departments of whatever app or service they are connected with trying to cajole them into doing their work, like "Hallo dear mister from our payment service provider, we are developing a page for Adobe in PHP and we get an error from your system saying 'network unreacheable' please resolve this situation ASAP"
I doubt that a bot ever reaches to this level of sophistication.
-- 29A the number of the Beast
Every Corporation is a Ponzi/Pyramid scheme in Globalization;
Casteism
Sadly for the MBAs, it will turn out that the Programming AI requires twice as many administrators and coders to maintain as the coders it replaced.
Yet this will be seen as a good thing by the business, in a fit of self-denial.
Straw man. Capitalist economies do use money, it just isn't issued by an arbitrary authority (ie a government treasury or a central bank). Bitcoin is a good example of capitalist money, as were the numerous gold backed currencies issued during the free banking era.
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-)
Why not ask how stable Marxism is? Do marxist governments last longer or shorter than non-Marxist governments?