Things don't have to be fully automated to mean big changes. The factory that makes Ikea bookcases employs twice the number of people it did in the 1980s but they make 37x as many bookcases [1]
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.
> 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."
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.
External servers and API offered by some other company cannot be considered the same as actual tools. They are not guaranteed to exist tomorrow. A hammer that you own, or a compiler in your computer are real tools.
I suppose you also only drink "real" water, sourced from your own well, and use "real" electricity, produced by you?
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 agree that owning your own hammer, if it is a good one, is preferable to borrowing your neighbor's; but when everything looks like a nail wherever you get your hammer does not keep it from working as such.
It's not that the tools are easier to use (I'd argue they aren't). It's that the function call you make are much richer, and you can deploy at global web scale just as easily as running that function in a local script.
The demand for new programs will not abate unless people stop thinking of new things to do with computers. The number of useful things that a computer could do might be infinite -- or it might not. We're unlikely to ever hit that point, because will probably be a long tail that never quite reaches zero.
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.
Agree 100%. The fact is (well, in my experience anyway) that the people who want programs written don't really know what they want (they only think they do). The art of requirements analysis is very difficult to do well, partly because of this, and like you say, when (if) any machine becomes intelligent enough to equal a human in eliciting good requirements, we will all be in a lot of trouble.
Right now, is there any natural language system that can appropriately correct the punctuation on these sentences (not meant rhetorically)?
It's impossible, as a human, to know what you actually wanted to say with those sentences in isolation.
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.
One reason computers don't have common sense because [insert large but hard to calculate percentage] of human interaction is context, learned and scripted social setting/interaction, and tradition, not semantics. And certainly not statistics.
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.
There are many tasks related to programming that would be maximally hard for computers. It would be kind of like a gordian knot of all the intractable problems in AI all woven together.
Very much agree. And I think the corollary, which you describe more than state outright, is that as the tooling and technology gets better, the human value-add would likely demand the talents of the more imaginative, "right-brained", and creatively extroverted - not the stereotypical techie profile. Knuth thought he could do it with literate programming, which didn't take off, to say the least. Maybe it won't ever be that way. Interesting times ahead!
Actually, if you consider programs that can be considered art, like video games, that may create an infinite demand for programmers, because the demand for art is infinite. In art, the fact that something has never been done before can be the sole justification for doing it.
With respect to creativity becoming more important relative to technical ability-- I think that both will be important.
If the demand for art were infinite, it's a mathematical fact that the price would also be infinite, regardless of the quantity supplied.
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.
It would be more correct to say that demand for art is non-zero at every point in time when a person exists. This only becomes infinite if humanity exists for an infinite amount of time.
I agree, and will add that I believe this is the secret sauce in the truly exceptional data scientists, engineers, and developers: people who take the tech skill set and remix with heavy doses of creativity and interpersonal skills.
The demand for new software may never go away entirely, but the scope of what can be accomplished while writing little or no code is ever-increasing. I expect it's going to get harder and harder for businesses to justify spending money on software development when there's already a good-enough program that already exists.
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.
In the 90s, I thought that there wasn't much software left to write. It turned out that there was. I don't want to be glib, but I think it's always hard to imagine the things that haven't been created yet.
I think Moore, after his famous prediction , had some crazy predictions about the stuff computer will do. I would guess Steve jobs had some idea too. So maybe in general , some rare visionaires do know, but most people don't.
In the case of Steve Jobs, his predictions were things that he did himself. I think what youre saying is that he predicted what a good cell phone would look like. I'm not sure that's really salient to my point.
> The number of useful things that a computer could do might be infinite -- or it might not. We're unlikely to ever hit that point, because will probably be a long tail that never quite reaches zero.
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.
I don't understand the constant focus on the upcoming automation crunch. Efficiency improvements (through automation and otherwise) have been happening over the past several decades - more output with less jobs - where the majority of the benefits go to the owners of the clockwork.
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.
> I don't understand the constant focus on the upcoming automation crunch. Efficiency improvements (through automation and otherwise) have been happening over the past several decades - more output with less jobs - where the majority of the benefits go to the owners of the clockwork.
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.
To be fair, I think a modern day professional carpenter would much rather work with modern power tools than what carpenters had to use at the dawn of the Industrial Revolution. Modern-day miners much prefer using their heavy machinery than swinging a pickaxe and pushing a trolley. I can't see many modern-day blue-collar workers volunteering to go back to the old ways in order to increase employment counts.
Pretty sure the carpenter will complain when anything made w/ wood can just be put through a 3d 'wood' printer and come out flawless, or a device that basically can take a block of wood, or 4x4s and construct just about anything without any human intervention. Won't be long before mining operations are all manned by drones and not a single human. This isn't sci-fi, it's near-future tech.
But when AIs start to program we as programmers have a simple solution : we simply bring them into a meeting with marketing and product management and let the result natural suicidal impulse take care of those suckers.
People like Ray Kurzweil prophecy about a time when human "intelligence" is replaced in value. But what about human work? It is something deeper and at least as precious, our freedom to be physically integrated with one another and and with the physical environment we are embedded in.
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.
Aristotle would have been OK with that. Work simply is "non-leisure" and therefore shouldn't be aspired to per-se.
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!
Never thought I'd see Pieper referenced on HN. Great point and reference.
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!
It's not so hard to find it, it just it sounds too much as socialism.
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'd say both, and that's why I think we need to loosen up on the copyrights a bit :). Too much "intellectual property" protection is harmful to society.
I'm not sure if we should be taking lessons from people who's leisure time was created from slavery. Arisotle was the ancient equialent of billionaires who's family can live forever off of interest/investments
Aristotle's contemporaries who claimed "nature has made nobody a slave" also held similar, if not the same, views on leisure. Of course, you could argue all Athenians really took others into slavery by virtue of war, or their unquestioned military superiority of the time. The question is, is hypocrisy actually contradictory to Aristotle's views?
The new focus on the 'automation push' is for political reasons and not for any other real concerns. Ask yourself what changes in society are being agitated for the most? What is being put forward for the solution to the automation push?
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.
> 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
Where is this solution put forward? By what politicians is this "political handling" being done? What legislation has been proposed, let alone passed?
Maybe people don't react rationally? Maybe we wind up in a world where you don't want to be in anything remotely seeming part of the government. Think French Revolution.
How many programmers did commercial Operating Systems put out of work?
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.
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.
If you think about it, how many web designers were knocked out by WordPress?
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.
No I don't. I think it's a huge number. Think about all those diners, souvenir shops, whatever, who need websites no longer go to mom-and-pop website designers but click, click, click and they have a decent WordPress installation.
But my point is that this was going on for a while.
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 because its so easy & cheap to create websites using wordpress, we have so many websites. Without that I think a lot of demand will disappear. So while there is some impact on web designers, it will be at the low end and unlikely to be huge.
The C programming language undoubtedly reduced the cost of making software. However, an increase in efficiency (in this by reducing labor costs) can often actually increase overall demand, as new use cases become economically viable. There's a term for this phenomenon, but I can't remember it at the moment.
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.
It probably affected the DMV and grocery hiring pools more. Not that WP is for dummies, but it absorbed many people who back in the day were underemployed, intellectually and creatively.
I wonder if we could create a limited AI that could prompt users to define requirements better? Something where the output to would be a bunch of user stories.
My two cents about this and back to work: I do code deployments to production with the click of a button and some years ago it required a lot of careful planning and time.
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.
Yet, you could approach the problem from two other angles:
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.
I'm working on a tool to automate a fair amount of the web development process (or in other words, bring it to a higher level) and having an available library of components is basically part #2 of that process. If we can share units of functionality then we can speed up development massively in the same way that the advent of the book increased the rate at which people could learn.
> Research in automatic programming is simply research in the implementation of higher-level programming languages.
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.
Sure, and AlphaGo is an impressive feat, but it's still just a board game, which is a far cry from the unbounded nature of programming and trying to figure out what a customer wants. Go has well defined rules and a limited space. This is not true of software development in general. It's an entirely different kind of problem.
That is an error, which will be backpropagated and forever corrected. We have to assess whether 1 human life per ambiguity is an appropriate price to pay
Exactly, so what we need to do is use a formalized language with strict rules to keep out any ambiguity. And then we fully specify what software we want and... this process is called 'programming'.
But what if the programmer program could identify possible ambiguities and interactively ask you to clarify them? That would obviate the need for a formal language specification.
>Make me a sandwich.
Do you want to (1) be turned into a sandwich or (2) have a sandwich prepared?
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.
I'm working in this space (check my profile) and I'm betting pretty heavily on the idea that the problem there is not the user's conception of their idea, but the flawed nature of language. If users can interact with their concept as they build it, and shape it like you would a physical product, they can get much closer to the ideal stored in their head than if they have to describe the idea in minute detail using ambiguous concepts.
We already have this--contracts are "programs" that specify how other people should perform some action.
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.
Contracts are not "programs", any more than programs are binding legal agreements between users.
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!"
> Contracts are not "programs", any more than programs are binding legal agreements between users.
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."
But everyone can use language to clarify things, not just lawyers. A proper AI system would fill in the missing info with the optimal defaults, and ask for clarification for the rest. Every new edge case added makes the system smarter
Of course! I'm not saying that only people with 180s on the LSAT will be able to program.
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.
This is exactly what a skilled developer does. In principle you could probably design a system that does it automatically. Sounds like strong AI territory though.
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".
Todays dynamically typed languages are already too ambiguous for most people to write correct software without tests, how should this get any better with using English? :D
Yeah, I think this is the key. English is simply not specific enough to work as code. To the extent that "English" some day becomes a programming language, it will be a special dialect that looks an awful lot like something along the lines of SQL.
Yeah, because current paradigm in programming is about specification. When dominant paradigm becomes focused on probability, then English could become programming language.
Your money was transferred to your account with 60% probability and donated to the Trump Foundation with 40% probability. Press escape or e to abort with 10% probability.
No, dynamic languages are not "ambiguous" in any possible way. Programming languages are unambiguous by definition, as any formal languages.
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.
I'm not going to play that game, if you can't think of an example of a dynamic language that's syntactically correct but fails at runtime due to name lookup issues, that's on you, but it doesn't change the validity of the point.
You're in an empty room with a light switch. GLaDOS says 'please turn on the light'. You flip the switch and the floor disappears, dropping you into a pool full of hungry gators. That doesn't make 'turn on the light' ambiguous.
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.
I'd guess it would be more of a question-and-answer session between the computer and the designer rather than attempting to describe the algorithm up front.
Probably not. Currently, the part of training/learning time spent in educating developers that refers to the language syntax is at most 5% of the whole; perhaps 10% for the most junior developers; so 'programming in English' saves you just a tiny part of the training.
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.
Yeah, you can see this in comparing how long it takes a person to learn a new programming language versus someone learning their first programming language. Learning a new language is trivial, learning to program not so much.
English is such an ambiguous language, I would think that training would be a lot harder (especially for native speakers to unlearn the imprecise parts of English).
Very little programming needs any algorithms though. Most of it is literally deciding what data to record, what validation rules to apply, and how to aggregate the collected data in to something useful. It's why MS Office is so prevalent - most business software is written in Excel with all the "code" abstracted in to forms and macros.
Programming languages have gradually evolved into higher levels of abstraction, but they haven't consistently become more humanlike.
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.
This always makes me think of scene from Star Trek next generation when Geordie is on the holodeck trying to create a table. It takes 4 attempts for star fleets top engineer to get what he wants. I've often pondered this deeply illustrative example.
You no longer have to deal with solution domain issues (memory leaks, crashes, deadlocks, type errors ...).
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 ...).
The elephant in the room is that programming in English would be a huge step backwards. Modern programming languages are all about scalable, modular abstractions.
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...
>To completely remove programmers from the equation would require essentially a human level artificial intelligence. And if I start seeing near sentient robots walking around, my first thought is certainly not going to be, “oh no, it’s going to take my job!”
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
While everything you say is true (ie - I agree), does it really matter?
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?
I don't think it's remotely reasonable to extrapolate making a simulation of 302 neurons wiggle a simulation of a simple muscular structure without full understanding of the wiggle process to making a simulation of 90 billion neurons produce outputs which resemble expressions of human cognition without an incredible depth of knowledge of a connectome structure that shows more variation in an individual over the course of a day than C.Elegans does within the entire species, and how that relates to long term memory storage and a mind-bogglingly complex array of sensory inputs and outputs.
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.
Even human intelligence is not always correct. Serious misunderstandings and miscommunications occur all the time. If we get to the level where instructing a computer is just as simple as instructing a human, we're still going to need people who have the job of ensuring that the instructions were correctly received and are being correctly executed and who fix things when they go wrong.
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".
There is no reason to assume human programmers are somehow special apart from all other disciplines and tasks, except maybe to delude oneself with a false sense of (job) security.
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.
>There is no reason to assume human programmers are somehow special apart from all other disciplines and tasks, except maybe to delude oneself with a false sense of (job) security.
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.
This is one of those times where I think the discussion might be confusing one hard problem with a slightly hard problem that's hard to scale. It seems like the hard problem is understanding how to model how neurons interact with enough precision to get a meaningful picture of how they do what they do. Once we have that, I'm not sure the difference between 302 and 100,000 and 100,000,000,000 will be _fundamentally more difficult_ and not just much more expensive to get going.
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.
I think that scene shows the ridiculousness of the concept; there is NO WAY the computer could have gotten that close to the actual table they were talking about based on those descriptions. It made all sorts of assumptions about the table that just happened to be right in order to move the plot along.
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.
> Just imagine trying to describe how to draw that table to a human artist. It would take forever, with a ridiculous amount of iteration.
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.)
Sure, once we have a holodeck that can understand arbitrary requests and make them physical reality, I might be worried about finding work as a programmer.
But even on Star Trek the crew is often portrayed as writing some form of code. I don't know how accurate that would be once you can have computers that do such a fantastic job of extrapolating simple requests into extremely realistic world settings, but then again, stuff seems to go wrong often enough on the holodeck, or with the transporter, or some spatial anomaly requiring tweaking of the deflector dish, so maybe you still need programmers in the 24th century.
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.
I have been hearing this for a long time now, "automation will take away lot of jobs", I don't understand the people who make such statements. Do they realize how much manual work is done in projects in even the biggest companies? Do they realize that the internal tool which caused AWS downtime last month was not built in one go, it was built eventually, that's why it is hardly perfect.
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?
I would like for more people to talk about automation as REDUCING the need for as many workers, than an all-or nothing REPLACING workers.
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.
Can't imagine the fierce debates that are coming over that, particularly in countries like the US, which have strong ideological aversions to such things.
Finally some damn sense on this topic. The whole "programmers will be automated away" is just a scare tactic to slow down the automation of what can be automated. People scared and afraid and attacking what they perceive as the enemy. Lots of things will be automated, automating will not be one of them.
ok, yes, but cut me some slack. when i said that, i was stuck on the side of the road next to my model T with three flats and i was reflecting on the poor quality of leather they'd used in the tires.
technically, that's business analysis and it's part and parcel of most day-to-day programming jobs. Automating processes does not inherently require typing logical statements into a text file - only our current conception of "how to tell a machine what to do" requires this.
And not everything is worth automating. There are still people working in retail, maintaining industrial machines, negotiating loans, and agricultural workers.
The idea that "automating away programmers" == "building some ridiculous tool that allows the pointy-haired boss to program with 'plain English'" is a strawman.
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.
Quoting PG used to be all the rage around here, but it seems to have gone somewhat out of fashion. Anyway, he basically credits the power of Lisp with the success of Viaweb, in exactly the way you suggest:
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.
>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
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.
> 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.
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.
Programming doesn't need automation to reduce a companies needs for programmers. Cloud computing, better open source projects, and basically anything we are excited about reduces how many programmers you need in order to build a set of product features in comparison with say even 5 years ago, go 10 years back and it gets worse.
Yes and no. Yes, with those things the productivity per programmer is much higher. But the trend seems to be that increased productivity per programmer simply increases the work demanded to create products. The easier it is to add features to a project, the more features customers (and thus managers) will demand.
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.
Luckily, there seems to be a near endless amount of things that can be improved with software, so that more automation doesn't mean that programmers lose their job, instead we just solve more problems with software.
At the same time, what is expected from those solutions in terms of features, usability, security and reliability also grows.
So I'm not sure it will get worse, it will however change the skill set required. As it has been changing since programming exists.
It's not programming that needs to be "automated" but the project process. If you could shave 30% off of meeting times you can probably boost productivity by 50% or more.
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.
Devops is a highly automated sysadmin job. When we automate something, we write code. When we write code, we want to make it maintainable, which developers are usually good at, but sysadmins are not.
Most of good devops who I worked with came to this field from development, not from sysadmin.
And yet, we don't continue calling a sysadmin turned programmer a sysadmin, so why would you insist that we call a programmer who turns sysadmin a programmer?
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.
I think, the difference between devops and programmer is similar to the difference between a programmer in OOP and a programmer in a functional language. Or a programmer in a commonly used programming language and programmer in DSL.
I think the difference between devops and a programmer is that they're 2 different titles that describe two different responsibilities in the long term maintenance of software inside a company.
I just felt a million sysadmin voices cry out and be suddenly silenced at the thought of developers caring more about maintainability than them. Sysadmins are the ones that have to maintain all the crap that is thrown over the fence at them, whilst the developers go chase the new shiny.
I can't necessarily disagree with you, as I get older I start disliking software more and more specifically because most of it is half-done bullshit.
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.
I'm with the "or it already has been". Automation is always happening with programming. Fully automatic programming has no meaning, since you have to define parameters for some set of algorithms to act upon. Once you define parameters, you are already using automation because today we can already with a single line effectively "open file x for appending, and create it if it doesn't exist" and thousands or tens of thousands of lines of code will execute behind the scenes to make this happen.
This reminds me of the time when I saw the C code required to display a window in Windows, with all the things we've come to expect from one (close "x", system menu and so on). At the time (Windows 95 I think) it was around 80 lines of code.
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.
The halting problem doesn't prove that at all. It just shows that there exist programs who's output can't be predicted except by running them (potentially forever). It obviously doesn't prove that all programs have that property. I mean, we write programs which provide useful output then halt every day.
And if humans can write code, a sufficiently advanced AI will be able to write code too.
You can use Rice's theorem[1], which is a generalized version of the Halting problem.
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.
From my perspective, programming is the work of automating the mechanical parts of human work and experience, whether it be something as simple as FizzBuzz, or a web scraper, to DeepFace. Novice, and even experienced programmers seem to forget that the appeal of a system like DeepFace or ReCAPTCHA is the ability to apply it at a massive automateD scale, not the bespoke ability itself to detect or classify human faces/behavior. I think by definition, programming would seem to be among the final group of human activities to be automated.
A job is role responsible for conducting productive activities. Today, some of those activities can be automated, some others can't.
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.
Do you all mean to say that nowhere in the near future will it be possible for a business person to speak out loud to their computer, asking it to show him on screen the latest sales figures regarding the new line of products he released yesterday?
"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.
How is that much of an advance over what we currently do? If Excel isn't rendering data science jobs obsolete, then being able to tell the computer you need some sales figures isn't going to either.
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.
> "Give me the latest sales figurs for the new XLine line."
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.
Having been programming for a long time, automation has been talked about for a long time and never really happened. We have had CASE tools, RAD tools and so on, but users demand for new features and capabilities increases at the same rate as developer tool productivity increases meaning the developers are still required.
I think, deep learning is only one part of universal AI. What these system are good at are visual processing, we don't have really good (comparable to what a human can do) models for language, logical reasoning etc.
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.
The focus of software engineering research should be on requirements elicitation, analysis and transformation. There has basically been no progress at all.
It's completely incomprehensible to me why research pussyfoots around the large elephant in the room. Commercial requirements tools (that are amenable to partial transformation into inputs for data driven code generation) do exist (DOORS, ReqIF), but there's a distinct lack of FOSS communities, which is something I cannot understand.
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.)
People don't want to do requirement engineering for their FOSS project, of course - that's the boring part.
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.
I feel like at the rate we are going we will eventually reach the Visual Basic days where a monolithic IDE will lower the barrier for front-end development so much that anyone could tinker with it and produce stellar applications with little to no programming knowledge.
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.
The ultimate programming interface is a declarative one, where an authority tells an AI to build a program for them.
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.
I assume they mean in the general artificial intelligence sense?
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.
>> Moreso, if the goal is to produce reusable applications, we need this to be even more abstract: “Create a plugin that downloads bank statements, compares to the expense statements, and produces a standard report”.
But if the computer could do that, who would need a plugin?
How many 'DO NOT' believe that programming will be brain interfaced in distant (25 yrs) future ? where 'program-thinking' brains 'can' result in new 'products' ?
Eventually (30-150 years), there will be AI pottery artists selling kitsch, easily-offended toasters and corporations without wetware upper management.
Marvin Minsky has pointed out that modern AI methods lack common sense, which is one of the requirements for general purpose AI. Rodney Brooks agreed with him.
These discussions usually conflate "programming, a viable career option" with "programming, an intellectual human endeavor".
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.
It not what ambiguity means in a programming language. Sure, you can make up your own terminology and call whatever you're talking about 'mauve'. You'll probably have a hard time convincing people dynamic programming languages are mauve as well.
I agree with most of that, but I think based on current trends we should anticipate that human-like ("human level") artificial general intelligence will be created within less than 10 years. And not too long after that happens, we must assume that there will be AIs that are tuned or turbo-charged so that they can perform better than humans in specific areas like programming. And not too long after that, there will be competition between multiple such AIs being sold to replace humans. And then prices will be reduced and you will be able to buy 10 of these 50X AI programmers for the cost of one human programmer. Then no one will have human programmer employees except for the novelty of it.
> I think based on current trends we should anticipate that human-like ("human level") artificial general intelligence will be created within less than 10 years
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)?
"Wild overestimation of progress" has been part of the story for many technologies.
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:
(cognitive architecture)
"OpenPsi: Realizing D¨orner’s ”Psi” Cognitive Model in the OpenCog Integrative AGI Architecture"
http://goertzel.org/OpenPsi_agi_11.pdf
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.
1 - http://www.bbc.com/news/business-38747485
2 - https://twitter.com/Raelshark/status/843776684407111680