Programming won’t be automated, or it already has been
mortoray.com
mortoray.com
We're looking at a similar situation in the programming, ops, and IT support areas.
A friend of mine Tweeted this the other night: "I'm sleepless so I just created a voice-based health tracker using Google Assistant in about 20 minutes that took me wks to write 3 yrs ago." [2]
I've heard numerous anecdotes of "A Zapier account and 20 minutes of fiddling with things just replaced a SAAS app/consultant, etc. we were paying for."
This is what automation looks like: the top 10% in a profession doing 100x the work previously done. To date the appetite for more and more software development (eating the world) has sufficed, but there is no guarantee that will always be the case.
Sounds like someone scripted an Ajax-Json-API-Call to Google Servers.. today's equivalent of writing a small shell script.. "wow, I piped grep, had I done this by hand in C this would have taken me days" would have been the tweet in the 80s.. what did they call it back then, Gopher?
And actually it was even simpler than that. No coding involved - I did this with nothing more than a handful of IFTTT recipes. Hook it up to Google, listen for "Home" commands, and send them to a Google Spreadsheet. I have one for each type of entry I wanted to log - meals, symptoms, medications. Planning to add activities and some general exercise capturing when I have another 20 minutes (ha).
And I'll add some biometric logging, although my ultimate goal would be to actually script that to get data directly in from my BP monitor and a scale automatically. Same with sleep data from the app I use to track that. Both would be easier if I were using one of the devices or apps for tracking those that IFTTT supports.
The idea is to set up and collect as much as I can with as little manual entry (i.e., typing) as possible, with as little coding as possible.
Exacly. Pipes and grep functionality are great abstractions that have saved people countless hours.
The fact that there are a lot more easy to use tools today means things are easier to do today, and are going to keep getting easier.
There's no such thing as "real" tools; there are only different models of risk. If you're building a system that needs speech recognition, what you should care about is the risk that the next recognition won't be correctly interpreted, and the odds of that are probably greater for a local installation of PocketSphinx than for a Google service, even including the possibility of it "going away".
I don't think that programming is a good opportunity for automation, because I think programming is something that humans are actually very good at. In order to write a program, you have to figure out what functionality would be useful to a person, both to elicit latent specifications and to intuit what would be acceptable for things that are not precisely specified. Anticipating what a person would want requires having a theory of mind and understanding the experience of being human. That's about the hardest task in all of computer science. It's also the thing that people are probably best at. On top of just making it work, it has to work well enough be cost-competitive with employing a person.
If we ever get to that point, there will be so few jobs left for humans that almost everyone on earth will be a programmer. So it won't cost very much to employ one.
Right now, is there any natural language system that can appropriately correct the punctuation on these sentences (not meant rhetorically)?
SPLINTERS WEAR SHOES
PANDA EATS, SHOOTS AND LEAVES
Are you setting up for a joke about a gun-toting panda at diner, who left the scene of a crime? Are you paraphrasing an informational sign at a zoo about a black and white animal?
Assuming you're not trying to go for a bit of clever wordplay, however, plug the panda sentence in Google Translate and it'll correctly translate "leaves" to be the plant, and not the verb tense of "to leave", in the chosen destination language.
TechCrunch discussed Google's internal representation of language[1] which implies that while the computer doesn't have a concept of the animal and its food sources, it recognizes that "panda" has something to do with "leaves" as being related to plants rather than "to leave".
Google Translate's far from perfect, but as poor as it is, it was once considered impossible to advance to where it is now.
[1]https://techcrunch.com/2016/11/22/googles-ai-translation-too...
You can't parse conversations effectively without a social context, because a lot of the meaning is implied by the context. The words themselves are more like pointers into the context, and are never a full description of the meaning. (See also: "Make me a sandwich".)
So when someone on HN says "Time flies like an arrow, fruit flies like a banana" the context tells a human reader that the real meaning is "This is a meta-sentence illustrating a point about grammar, context, ambiguity, and NLP. It does not mean I am saying anything specific about flies, time, arrows, fruit, or bananas."
The contextually correct response would be to continue with a different comment about AI. Or maybe to make a context-bending joke. (But not on HN, where the context doesn't allow that.)
Every so often someone in AI rediscovers this idea and tries to model it, but for some reason it keeps being forgotten. It's been around since at least the 1970s, but so far as I can tell modern statistical ML largely fails to be interested in it.
With respect to creativity becoming more important relative to technical ability-- I think that both will be important.
In fact the price for most art is very low, below the cost of materials, or free. This implies that demand for art is very, very finite.
Andy Warhol's whole point was that the art that sells for real money has nothing to do with art. It's a sale of association with social status, and the physical art itself is superfluous.
Demand has multiple dimensions. There is only demand for so much quantity of art, but competition can drive the quality up indefinitely.
This has been happening for a long time. Back in the 80's and 90's, most of the major tech companies had their own derivative of UNIX because it made sense (sort of) to have their own in-house OS. Now almost everything is Windows, Linux, or MacOS. It would seem very strange for any company to go off and do their own thing rather than use one of those three.
As it is now, we - as humans with programming skills, not professional programmers employed by few select corporations and their subsidiaries - might never hit that point because we'll be prevented from doing so. Trusted computing, DRM, SaaS model and various other things together conspire to take away the ability to run Turing-complete programs on our own machines. It's something we need to keep in mind too.
Now we're in a situation where we produce most goods that society needs (and a lot that we don't need) yet there are fewer jobs. This is absolutely going to get worse, but we shouldn't be thinking of robots as any different to the market forces that have been going on for years. Something has to give.
Before, automation only impacted the jobs of blue collar workers so nobody cared. Now it impacts the jobs of white collar workers so everybody is starting to whine.
Karl Marx, etc already wrote about a kind of devastating "singularity" that is here and now at the roots of many social, physical and spiritual ills.
As per Josef Pieper – it's all about leisure.
School especially so:
"The Greek word for leisure (σχολή) is the origin of Latin scola, German Schule, English school. The names for the institutions of education and learning mean leisure."
In this potential world of abundant leisure we just need to get back to good old sharing – because sharing means caring!
For everyone else, Leisure the basis of culture is worth reading and relevant here.
But finding a realistic economic system where the benefits of automation don't just benefit the top x% and lead to a morlocks and Eloi society is HARD!
There are all kind of possible ideas. Just the other day I read about, instead of taxing corporations, make that a minority percentage is owned by the society. Not without its problems, but sounds like it would line up some bad incentives that we see now in action.
At the end of the day, we always go back to who owns the means of production.
As is always the case with humans, change it's not going to happen until we are in real trouble. Maybe not even then.
I thought sharing meant copyright infringement! ;-)
I think not.
It is not very different than the political handling of man-made global warming. The solution is for affluent nations like the US to reduce its standard of living and cede more control to international bodies. We can debate the merits of the science all we want, but the solution put forward promotes a pre-determined political agenda.
We're seeing the same type of thing starting now with the talk of the automation crunch. Ideas like UBI are declared the solution and a shift to greater reliance on government because we will all soon be unable to have good enough jobs to look after ourselves.
Where is this solution put forward? By what politicians is this "political handling" being done? What legislation has been proposed, let alone passed?
It's not that they're so different as such; it's the scale and speed of change that's different.
Every new level of abstraction leads to new capabilities and new demands. You may have to learn new technology or move in a different direction, but I'm pretty sure software development as an industry is pretty safe unless we develop strong AI.
Higher levels of abstraction allow people to build virtual goods that are more complex and there is no foreseeable limit to the desire for more complex goods virtual goods, and no real physical limit.
Programmers ended up getting more work. Whatever the computers displaced is where the jobs diminished.
In this case, I actually did create it that quick while lying in bed, and used nothing more than IFTTT and a Google Spreadsheet. I probably should have mentioned "without coding" in the original tweet to be clear about that, cause I think it's a pretty big factor.
Literally anyone with the least bit of tech savvy and a recent Android phone could do this, and it's actually more effective than the original web app I used.
Edit: clarified the time it took
How many programmers were knocked out by C?
Are you assuming it's a small number? It seems reasonable to assume that without WordPress we might have another 10,000 web designers. Or 100,000. Or 0. Or -10,000 if WP theme design increased the size of the web industry. We don't know.
These sorts of notionally statistical questions breakdown when you try to use "common sense" or logic-but-without-data to answer them. We have no way of knowing what might have happened without WordPress.
Remember those "website for $100” ads? All gone.
How many code-monkeys (who are real humans with real needs) can't find a job now because modern high level languages take out so much of the monotony of programming in the 50s?
How big would MS have to be if all code was written in Assembly?
I think the increase in prevalence of software since C was created provides some empirical evidence that this dynamic was occurring (and perhaps still is).
WordPress is a bit trickier as it allows non-technical people to implement working software. However, isn't there a booming market of WordPress devs who do more complex customizations? Such work is different than being a full stack engineer at Google, but it is still a technical role that produces software.
In fact, you can be a business owner, set aside a Sunday, and you're done. You don't need to hire anyone
That was essentially my point.
Just wait until things go wrong (for whatever reason).
Throughout my career in computing I have heard people claim that the solution to the software problem is automatic programming. All that one has to do is write the specifications for the software, and the computer will find a program [...]
The oldest paper known to me that discusses automatic programming was written in the 1940s by Saul Gorn when he was working at the Aberdeen Proving Ground. This paper, entitled “Is Automatic Programming Feasible?” was classified for a while. It answered the question positively.
At that time, programs were fed into computers on paper tapes. The programmer worked the punch directly and actually looked at the holes in the tape. I have seen programmers “patch” programs by literally patching the paper tape.
The automatic programming system considered by Gorn in that paper was an assembler in today’s terminology. All that one would have to do with his automatic programming system would be to write a code such as CLA, and the computer would automatically punch the proper holes in the tape. In this way, the programmer’s task would be performed automatically by the computer.
In later years the phrase was used to refer to program generation from languages such as IT, FORTRAN, and ALGOL. In each case, the programmer entered a specification of what he wanted, and the computer produced the program in the language of the machine. In short, automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level programming languages.
1. Imagine you have a reasonable library of primitives (say, library functions). And you build a program that does exactly what you want, but it's ugly, a hodge-podge mess of something written quickly together. No SW engineering rules followed. Then an automated process can refactor it, keeping the behavior the same, but making the program look much cleaner, or maybe even inventing new primitives (functions) along the way (if it sees the opportunity in your program or even across programs), in general, making the resulting program easier to understand, modify and work with. Then you can iterate on this process. (I have discussed this at https://news.ycombinator.com/item?id=13820070)
2. We could limit computers to a total language, which would describe some basic operations on non-recursive tree-like data structures. Then given some examples of transformations between those data structures, a computer could automatically infer a good description (from some building blocks) of the transformation that satisfies most of the examples. Since lot of today's programming is transformation of such data structures, it could greatly save time. This is similar to machine learning, but the goal is to have a succinct, understandable explanation of the transformation.
That's most of what such research has been to date, but that doesn't mean that's necessarily all that automatic programming will ever be.
What is clear is that reasoning about programs is a remarkably difficult AI problem. Still, in a world where AlphaGo has beaten Lee Se-dol, I would not want to bet that it will never be solved.
User: 'Make me a sandwich'
*mighty robot slices up user and places in between two pieces of bread*
Computer: 'You are now a sandwich'>Make me a sandwich.
Do you want to (1) be turned into a sandwich or (2) have a sandwich prepared?
>2
What ingredients do you want in the sandwich?
(etc.)
Although in principle it should be possible to have a machine that performs each iteration near-instantaneously, rather than wait three hours between each change.
^ everything is a file...
Nevertheless, entire industries revolve around correctly writing contracts, making sure they are executed in the intended way, and resolving ambiguities and disputes about the original specification.
If it's ever possible to go directly from English to running code, programmers will still be around; they'll just sound more like lawyers.
You're always going to have people that manage the details and edge cases of complex software systems. Those people will be programmers.
And if there is ever an AI invented that can replace those people then many white collar workers are at risk of losing their jobs, not just programmers.
Lawyers are only paid to create clear specifications some of the time, and that mostly in criminal law and political legislation.
In non-trivial corporate contract law they're paid to find favourable ambiguities in existing specifications, and to build possible ambiguities and hidden implications into negotiated agreements.
They're also paid for their ability to use rhetorical, verbal, and theatrical tricks to persuade counterparties, judges, and juries of their point of view.
Outside of STEM, the relative predictability of code is a very poor and superficial model for the relationships, transactions, and goals that define most domains.
Natural language is rife with ambiguities, contextual information, and implicit assumptions. It is a terrible method for precisely conveying instructions or expectations, even to equally intelligent peers. Making this work at all requires a whole specialised profession with its own elaborate procedures and complicated argot.
If you wandered into an IBM office and said, "I need a document storage system. Here's a blank check; make it happen!", do you think you would be happy with the outcome? Probably not. What changes when you tell this to a chatbot instead of a guy in a suit? Instead, you'd work with someone lawyer/programmer who knows how to spec out the solution in enough detail that the vendor/optimizer can't go "well, you said STORE the documents, but you never said anything about RETRIEVING them later!"
The conversation at hand is not about "programs" in the traditional sense, but more a conversation between a human and an AI which is providing what is asked for.
This is very similar to asking a Genie to satisfy your wishes. You need to be clear and precise or it is likely you'll get exactly what you asked for, but not what you intended.
We're NOT talking about traditional programming here.
> Lawyers are only paid to create clear specifications some of the time, and that mostly in criminal law and political legislation.
Sure, but it appears that a Lawyer's domain involves the interaction between intent, specifications and reality. In all the points you raise, this is what the lawyer is doing.
> In non-trivial corporate contract law they're paid to find favorable ambiguities in existing specifications, and to build possible ambiguities and hidden implications into negotiated agreements.
This is exactly what a programmer is doing almost all the time (when not talking to clients). Finding the edge cases, creating rules. Avoiding or documenting them. Closing the loopholes, turning them into features or guiding the user away from them.
> They're also paid for their ability to use rhetorical, verbal, and theatrical tricks to persuade counterparties, judges, and juries of their point of view.
Okay, so lawyers are sales-people too. Do you really think that programmers are not already salespeople, or have people on their team that are?
> Outside of STEM, the relative predictability of code is a very poor and superficial model for the relationships, transactions, and goals that define most domains.
Bear in mind that a programmer RIGHT NOW is managing the issues that you are discussing, as the computer is only half their domain. The other half is interactions with teammates, clients, etc. They already have to manage "human relationships, transactions and goals."
Instead, I'm arguing that writing an air-tight specification of your goals can be tricky, time-consuming and requires a certain mind-set, even if we assume perfect natural language understanding and ignore all the implementation details by saying that wizards...err...deep neural networks solve those issues. As support for this argument, writing contracts is still tricky, despite everyone involved having perfect language understanding and the sort of generalized intelligence that computers lack.
Therefore, if there ever is an English-to-bytecode compiler, I expect that the "programs" written for it will look much more like a contract with lots of awkward but precise language and much less like "Yo Siri, build me a chatbot." You can call the person who spends all day drafting these things and interacting with the code-generating software something other than a programmer if you want, but if the shoe fits....
I'm also not convinced that optimal defaults exist for many things. You could certainly recommend a data structure based on the way it is accessed (if it's always being queried for the min, throw it in a heap, but use an array or hash table for random access), but how do you gradient-descent your way to a fun original video game without also assuming a decent model of human psychology? At some point, you have to specify that "when the player does X, Y happens", which is programming.
Ruby is a good example of this direction; it's intended to (mostly / sometimes) read like actual english (RSpec is an even better example), but in the context of the language, Ruby's abstractions are precise, rather than the vague abstractions of human language.
Additionally, there's a difference between "able to speak the language the computer can understand" and "able to program something"; that difference is "detail of thought".
I tried to demonstrate this to a friend with a pretty good "Uber but for X" idea. I said - Okay, you want to rate people. Who rates whom? When? On what scale? What do you want each rating to mean? What do you use the ratings for?
Following this train of thought - it's not JUST that we (as in the entire software engineering community) are adding levels of automation, it's that each higher level language adds "default" answers to those questions, so that at some point, you could just say: "Give me a rating system", and you'll get the usually-best one that you can refine; like the core CSS classes. We're rebuilding language from scratch, layer by layer, in order to have non-leaky abstractions.
Or maybe we'll see something like the neural nets that can draw based off a phrase - you say "give me a rating system between users and drivers", and the NN generates something that satisfies, and then you refine from there - "give me a rating system... from 1-10, where normal service is a 7".
So uhm... More seriously, what do you mean?
That name lookup is ambiguous.
What they are, indeed, is dynamic. The lookups you are talking about are done in runtime, so the result of these lookups can vary depending on the state in memory at a given time.
That doesn't mean they're ambiguous. Everything is perfectly unambiguous and deterministic. They're just dynamic. And that's fine.
FYI: People also write tests in static languages.
What I meant were things like automatic type conversions or used of undefined object properties, which aren't ambiguous, but certainly seem ambiguous and lead to many errors.
However, as a specialized language can quite plausibly make you 10% or 100% more productive, no one serious would use general english even if it was a possibility. You might imagine a somewhat efficient programming in a very "jargony" english (similar to "legalese") with very specific (and likely unintuitive) meanings of a large number of particular phrases, but then there's no meaningful advantage of it, it's just as far from everyday english as any other programming language, and requires just as much training.
We might see, say, "Unambiguas English version A", as an experimental or academic version.
Then a trial "English B".
And maybe on the third try, they'd get it right, say, "English C". We could call it "C" for short.
(I know, I skipped BCPL.)
You can't fully understand human language with anything short of Strong AI. And yes, we made some progress in our ability to extract specialized meaning from natural language with high level of accuracy for things like translation or indexing - but we didn't get any closer to having computers understand and reason about the meaning of the text.
In short, to say that we're rapidly getting to the point where computers can replace programmers in understanding natural language requirements and designing programs that achieve these requirements, you need to show consistent progress in general-purpose AI.
However, you might still need a huge bunch of english text to describe the problem domain. If such a text isn't already available, you need to write it yourself (coding).
However, you might not write it in one shot, so you need to store it in text files that you can read and modify later. Maybe you would team with other people to write it, and you would share and track your modifications (versioning). Maybe, to make it easier to manage, you would split your description in multiple text files (modularizing).
And then, you'd need a way to ensure that your text actually unambiguously means what you want. So you'd need ways to identify (testing) and correct (fixing) theses ambiguities.
And maybe, at some point you would change your mind on some behaviours ; and then you'd come back to your description and modify it so future behaviours changes might be easier to deal with (refactoring).
And also, maybe your intelligent system has inferred a correct way of doing things that is actually too slow. Maybe you could order "do it faster!", or maybe you would need to identify the source of slowness (profiling), and edit your description so a faster behaviour is inferred (optimizing).
At this point, you in an attempt to improve your efficiency, you might consider using a simplified notation, which would be less-ambiguous and less verbose (like did scientists, musicians, engineers, mathematicians ...).
See, nothing to do with programming!
Natural language typically doesn't supply many sound abstractions. Everything you say is open to interpretation, as the many misunderstandings in this very thread clearly demonstrate...
The quoted person doesn't seem to realise this, but that is literally where the term "patch" comes from.
Even with all DeepMind can do we still are very far from anything remotely human intelligence. On the extreme low end, the tiny worm C. Elegans has only 302 neurons in its nervous system. The full circuit has been completely mapped out for over a decade, and still no one knows how it works. Bits and pieces are understood, but that is all.
The fruit fly has a meager 100,000 neurons in its nervous system
No - we don't know how the C.Elegans 302 neuron connectome works - but if you slap it into a robot or simulation, it tends to act in a similar manner as the actual biological creature (at least, that's what I understand).
We've seen similar results with biological neural networks (cell cultures and such) hooked up to machines as well.
If the connectome of a fruit fly were somehow mapped, and then simulated on a machine - it is very likely that it would act like a fruit fly.
Taken to the utmost extreme, the same could possibly be said for the connectome of a human being, could it not?
Does it matter in that case, then, whether we understand how it works - versus the fact that it is working?
Why do you?
It seems akin to suggesting that if I can teach my dog to respond to "sit" despite it lacking human emotion or innate grammar, it seems only reasonable to believe my dog can also learn to respond appropriately to the complete works of Shakespeare. Come to think of it, I'd place more faith in our ability to train our pets to write software than our ability to create a human brain emulation so accurate it's like adding another developer to the team.
What's the saying? Something like: "To err is human; to err a million times in one second, you need a computer." Computers are going to need caretakers and, if we're at all serious about usage, we have to recognize that computers will need a special hyper-specific dialect to define what we need done with adequate precision. Human language is not designed to handle such specificity. That dialect will need its own experts. Today, we call those who wield such dialects "programmers".
Computers using AI, deep learning and natural language processing will eventually be able to program themselves. This is the next, big revolution that is inevitable.
How am I assuming that human programmers are special apart from all others disciplines and tasks? I'm saying that ensuring computers do the will of a human will require some amount of human labor. There are many other disciplines and tasks that also require human labor. How is this attempting to elevate anything?
> Computers using AI, deep learning and natural language processing will eventually be able to program themselves. This is the next, big revolution that is inevitable.
"Program themselves" is so loose as to be meaningless. Do you mean that when I say "Echo, play me some music", it programs itself to go out and stream some music? If so, then sure, I agree, thanks.
As another poster stated, "self-programming computers" basically just means that new languages which handle more of the manual work for us emerge and enter general usage. Until a computer can learn to read thoughts (which may happen, but afaik is still quite distant), humans will still need to communicate their intent to the computer; that is, the computer will need "programming", which is the term we now use to refer to instructing a computer.
That being said, modelling neurons is a tough problem we haven't figured out. All the problems we _do_ figure out kind of accumulate, so programs can be written faster if you're trying to make something where you can get more and more parts off the shelf. I'm not sure this is a topic that demands an analogy. We all understand how to write programs and what makes it easier to do so -- having a cool API or library, ya know, that helps. No metaphor needed.
In other words: constraint-based design, in an interactive context-sensitive dialogue, with the machine-agent able to resolve change requests by—among other strategies—discovering and consuming new third-party components it was previously unaware of. Such a tool essentially presents the same interface that a contract programmer presents to their client: tell me what you want, I'll build it; tell me how it's wrong, I'll fix it.
The article brushes the concept of such a level of automation aside as requiring near-human intelligence. But, unlike a human programmer, said tool wouldn't need do the hard part—requirements-gathering—for you, or have any sense of what "sensible" requirements would be. Where human software architects guide their clients into specifying requirements, this sort of tool would be much like the compilers of today: it would take you literally and give you what you asked for, rather than what you wanted, until you ask for exactly the right thing. It would just do it very fast, such that this could be the basis of an effective feedback loop.
Just imagine trying to describe how to draw that table to a human artist. It would take forever, with a ridiculous amount of iteration.
If you want to program like this, you would have to get VERY good at describing the thing in an unambiguous way, and the skill to do that is going to become the new 'programming' skill.
Right, that's more what I was picturing: in reality, interacting with this kind of software would be like interacting with a sketch artist. It would be a very exhaustive (and exhausting) process.
(Though, it'd essentially be the same effect you get by outsourcing piece-work to a service like Mechanical Turk—just with instantaneous response-time.)
> If you want to program like this, you would have to get VERY good at describing the thing in an unambiguous way
Today, the intelligence/intuition/common sense of the programmer "allows" the client to avoid ever having to develop the skill of requirements analysis for themselves. Thus, even though it doesn't take any special aptitude to learn this skill, it's currently rare.
On the other hand, the naivety and short iteration time of an interactive constraint programming system would, I think, make it likely that anyone who used it would quickly/easily develop the ability to do requirements analysis. Perhaps not without being "lead by the hand" in a person-machine conversation, but certainly with it. (Much like how people who have only ever used CAD software can't necessarily do mechanical drawing by hand.)
I do like how just telling the holodeck computer to make an opponent challenging for Data in the Sherlock setting was enough to grant sentience to the Moriarty character. That's pretty impressive.
If we move to a more automated env where we have high quality softwares like the author mentions, it'll just enable us to deliver projects faster, bring better software in the world.
Plus, who is going to build these automation tools? surely every company is going to have a different requirement, considering that for the last 30yrs we haven't yet discovered how to build OTC softwares, where the main software is a generic one which can be customized across domains, it remains to see the "automation scare" and who'll sell robots who do everything that humans do.
Plus, I don't know why this doesn't get discussed, the day we have a general AI which can think for itself, why would it work for us?
Then it won't be a straw man of "it will never replace what I do" or "well, people will find other jobs." Some will, some won't. It's not all or nothing, but the AVERAGE DEMAND FOR HUMAN LABOR will go down, which means wages will progressively become worse as a means of delivering money to the masses. You already see it now, but few people state it in such clear terms.
We need to stop thinking in terms of "well, why doesn't everyone just buy a ticket out of the ghetto" and realize that some will, and many won't. For those many, we will need single payer healthcare, single payer food, rent, movies, etc. You can call it basic income. Whatever you like. But it's inevitable.
Given that history - especially recent history - has shown the opposite trend, I wouldn't worry too much about it.
Ummm https://www.dougsguides.com/content/whats
Have you even read Piketty
Example: "mankind will never set foot on the moon...how absurd!"
Programmers don't have to be fully automated away for automation to happen. Suppose I have a "Really Good Compiler" for a "Pretty Nice Language" (let's not start a language war by discussing which language is closest to this, or which exact features are in it). This "Really Good Compiler" has a great optimizer, the "Pretty Nice Language" has a garbage collector that's really good for the task, etc. The PNL standard library has a huge collection of well-tuned data structures and a generics system that actually works etc. The PNL toolchain also has a ton of really effective static and dynamic analysis tools to find lots of bugs that its type system didn't.
Meanwhile the folks down the hall in a hypothetical competing startup are programming in C using pcc, like they just teleported from the 80s.
How many staff do they need to do the same job, even assuming that they are people just as smart as we are (despite their strange choice of tools?)
We have managed to be largely blind to this because the amount of work that's available to programmers has expanded hugely to compensate for increased productivity - plus our tools aren't quite as nice as the hypothetical I described.
On a related note, I found a great code sequence for something I'd been thinking about for a while, by specifying what the sequence was meant to do, and specifying the semantics of a few SIMD instructions, and turning Z3 loose. Not quite ready to fire myself though.
If other companies didn't want to use Lisp, so much the better. It might give us a technological edge, and we needed all the help we could get. When we started Viaweb, we had no experience in business. We didn't know anything about marketing, or hiring people, or raising money, or getting customers. Neither of us had ever even had what you would call a real job. The only thing we were good at was writing software. We hoped that would save us. Any advantage we could get in the software department, we would take.
The increased complexity allowed by increasing levels of abstraction is a huge part of that increase in demand.
When we move up the abstraction chain we can generally build more complex systems. People then come up with new ways to use the increased capabilities to solve new problems. I don't think this is going to stop unless we develop strong AI.
I don't know if 'blind' is the right word since this topic gets discussed on the regular both here on HN as well as on more general programming forums like reddit.
Anyhow, I certainly agree that programming as a career the way we know it today is predicated on the notion that the potential scope of work available continues to increase. Why wouldn't it, though? IMO we've barely begun scratching the surface of what's possible with computation technology. Will productivity really outpace the amount of available work by that much, that fast? Seems weird, but I'm no futurist so maybe I'm just being naive.
This whole "everything will be automated and we'll all be out of work" argument I think is similar to the mistake made by Malthus, who famously predicted the world would become overpopulated and be unable to feed itself by the 20th century. There are several mistakes in his work, but one of the most prominent is not accounting for the fact that agricultural technology, and thus yields, also increase exponentially.
I think we can all agree that the more we automate deployments and the like, the better, but when people talk about automating "programming", they are absolute not talking about automating pushing new versions to the cloud, etc.
Most of good devops who I worked with came to this field from development, not from sysadmin.
It doesn't really matter where they came from, or what's involved in the job, they're sys admins.
No one calls a physicist a programer because the simulation software they wrote could've been written better by a professional developer, they just call them physicists.
And I'm a software developer.
The decision making I see come out of some companies (and some people) absolutely blows me away. VS 2017 doesn't install support for MVC 4 by default, saving themselves a godly 6MB in the process... who the fuck thought that was a good idea? I found out because I installed VS 2017 and spent several hours trying to figure out why all my projects stopped working.
Or I found out today that if you try to use CPanel's automated licensing api, it won't license if the IP has previously been licensed with someone else, but has been cancelled. WHY?!?
Or SmarterMail's API's, only about half the options their documentation claims is settable is actually settable via their API. The rest just doesn't change unless you manually dive into their XML files and then reload the service. WHY?!?
People bitch about C and C++, but I personally find working in those languages less stressful because most of the time you're working at a low enough level that people aren't throwing shit over the wall at you constantly. I really really wish C++ had a better build tools story, but when it's all said and done I honestly believe the quality of the software written by C and C++ tends to be better than that written in higher level languages.
I know I'll be hung out to dry for that sentiment, and this turned a bit ranty, but after a while I just stop trusting any code that isn't my own because I know someone somewhere made a stupid fucking decision and I'm going to experience productivity loss as a result.
alright, I'm done ranting :)
I was surprised because in Delphi 2 that was a File / New Form followed by a Show or something like that... I never even thought of the API calls required to do all that.
[1] https://i.imgur.com/HVeO7ek.png (CH 8, Algorithms - Sanjoy Dasgupta, Christos H. Papadimitriou, and Umesh V. Vazirani)
And if humans can write code, a sufficiently advanced AI will be able to write code too.
I don't believe this proves that programming can't be automated, though. Humans too aren't able to prove completely that what they write is correct, it doesn't stop them from making programs.
The tasks that cannot be automated usually require human level performance.
As AI advances, when it achieves human level performance in a task, that task can then be automated. This means that fewer people is required to meet the same productivity goals.
Some people argue that automation allows humans to focus in higher level tasks, using bank tellers as an example. Bank tellers remain relevant even after the deployment of automatic teller machines. I think this is just temporary.
When every activity expected of a job is automated, the job can be fully automated and the human becomes redundant. In this category you have: elevator operators, telephone switchboard operators, human calculators, etc. Soon: truck drivers, dog walkers, etc.
Automating programming is going to be a thing. Just enumerate the activities a programmer performs and see how many of them can be automated.
My hypothesis is that our jobs will first become negotiating requirements with a computer, and then the computers will fully take over.
Once it's done once, then it's about serializing their trained state and deploying that same system many times. Then, it's over for humans:
A professional programmer requires 20+ years to train. Then, can only work 8 hours, gets distracted and has lots of benefits/compensation and rights, including the right to leave you at any time. In contrast, AI will do whatever you say with no objections, and if your project is late then you can spin up 30 more AI programmers that know exactly the same to work.
I decide the instructions and the robot pushes the buttons for me?
Those can also be broken into activities, and some of them can be automated.
"Give me the latest sales figurs for the new XLine line."
We coudn't parse that into
"exec sales_report '2017-03-23', 'xline-123'
thus rendering the data analyst job you used to have obsolete?
EDIT: Google will easily solve the problem of speach-to-code, or someone else will if Google's not interested once they "crack" NLP, and they will. But what does it mean to crack NLP? Well, they already have the means to build the perfect model. I love the word2vec idea and I think there can be innovation still, standing on the shoulders of that discovery. What would a perfect model mean? With a perfect model you would be able to spot concepts with unflawed precision and be able to translate those concepts, with unflawed precision, into whatever language you have. It's perfectly doable.
To get rid of data science jobs, you would need the computer to be able to translate from business speak to generating code for all the things data scientists actually do, which probably involves something more than Excel. For starters, that would be cleaning and wrangling data into a format that a tool like Excel could be meaningfully used on.
What does "the latest" mean? The latest 24 hours? The last 7 days? The last financial quarter? Next thing you know you'll be asking the user (the business person from your example) to spell out pseudo-code to the machine.
Concerning programming automation, consider modern IDEs, they automate so much, that for me it's very hard to program without them. All this automation is quite intelligent but not human level.
If we consider latest experimental programming languages, for example, Agda, its environment has limited ability to complete code based on its type. If we can make this functionality more efficient, it's theoretically possible to find small programs which satisfy specification, though writing correct specification isn't easy.
But this is not fun, and being the next level requirements elicitator is not a prestigious career goal. Authoring a new javascript framework is.
The rise of the agile methodology has IMO worsened the problem by basically making throwing in the towel the default approach. (Throw in some "but, but, you're doing agile wrong!" here.)
To actually provide value the requirement world should offer a higher abstraction level - say, map requirements on "business objects" that are already implemented and configurable, and build software out of those. Workflow descriptions, relations between entities should result in actual code.
Otherwise, you know why doing agile sounds attractive to many developers.
Otherwise
The only difference from Visual Basic days is that now we have ML and AI to further simplify and do the thinking for us.
Designers will be hit the hardest. Followed by developers.
They have already been hit hard, by Wordpress and Facebook.
Excel would sort of fall in that category.
One might say that abstractly, from the business perspective, the programmer is an expensive AI licensed for use by government. The executor or authority declares what they want, and the machine attempts to build a program with what specifications it was given.
Most people don't really think of it in these terms, but aren't functions and macros just automation for programming? You define it once and then it handles it from there. You "taught" it how to handle something.
But if the computer could do that, who would need a plugin?
edit: 25yrs
http://www.ted.com/talks/jeremy_howard_the_wonderful_and_ter...
Eventually (30-150 years), there will be AI pottery artists selling kitsch, easily-offended toasters and corporations without wetware upper management.
The viable career option will, IMO, unquestionably vanish for the majority.
Manufacturing and working at McDonalds were once seen as a viable career path. They've been streamlined and automated such that it requires only a fraction of the human labor it did a generation ago. Google and the like will make this happen for computing as well.
We'll only need so many Evernote like apps. I'd wager we'll have reduced GUI interaction in general, such that a lot of JS/HTML/CSS, and similar coding work will be gone.
We're abstracting things into higher level languages. TODAY I can, with my voice alone, tell my phone to perform a truly fascinating amount of work compared to a decade ago.
When programming as a career is reduced to filling out text files in something like YAML and having ML go to work, only the bleeding edge, the mathiest of the mathheads, will have skills to command a living wage.
Why? People have been saying this since the 1960s, so much so it's become a running joke. And some of them were very smart people too, like Marvin Minsky.
What is it about AI that creates this illusion of progress (or at least, wild overestimation of progress)?
Minsky was very optimistic, and then he got burned by the AI winter, and became very pessimistic about AI.
There is quite a lot of very serious investment aimed at this type of 'real' AI now. For example Deep Mind, DARPA L2M, recent $100 billion Vision Fund that Softbank's founder said was intended to bring about the singularity.
I believe it because I can basically see how to handle most of the challenges using embodiment or virtual embodiment and interactive learning/L2M etc., by combining or taking inspiration from various techniques that have been published. Stuff like this:
Overcoming catastrophic forgetting in neural networks (adding plasticity to NN models) http://www.pnas.org/content/early/2017/03/13/1611835114.full
"Decoupled Neural Interfaces using Synthetic Gradients" https://arxiv.org/pdf/1608.05343.pdf, somewhat similar to autoencoder/decoder pair use in
"Feynman Machine: The Universal Dynamical Systems Computer" https://arxiv.org/pdf/1609.03971.pdf
"Safe Baby AGI" http://agi-conf.org/2015/wp-content/uploads/2015/07/agi15_bi...
(cognitive architecture) "OpenPsi: Realizing D¨orner’s ”Psi” Cognitive Model in the OpenCog Integrative AGI Architecture" http://goertzel.org/OpenPsi_agi_11.pdf