As a platform, they are big on encouraging people who wouldn't otherwise write to do so, so you get a lot of articles that are by new writers or who lack a presence elsewhere. This is a good thing in general as we need more diversity in people writing and sharing their experiences. It does mean you need to take this context on board as a reader, though.
It's counterproductive. It comes to the point where I do not read anything from certain sites. Diversity is nice, but it does not mean that someone, who has little knowledge in certain area, should write an article from the area.
"Only well qualified writers should tackle technical topics in depth" seems like a much more reasonable proposition, and is (I believe) more what mikulas_florek meant.
Well, let me try to clarify what I mean: there is no obvious correlation between having your own platform (or being an experienced writer, for that matter) and being qualified to address technical topics.
Programming was in its infancy 50 years ago. Things tend to change drastically the first few decades but then the rate of (significant) change slows down as something matures. Take aviation for example. Think of how rapidly aviation technology advanced between the Wright brothers first flight and 50 years later. Now think of how aviation has changed over the last 50 years - sure there's been some advances, but nothing like the changes in the previous 50 or the first 50.
Programming will certainly continue to make advancements, but I wouldn't expect the advancements of the next 50 to rival the magnitude of those of the last 50.
Programming was in its infancy 50 years ago, but in reality we don't really know what its development arc is. We could be in the toddler stage right now, or we could still be in infancy when compared to future developments in the field. I believe we are much closer to the latter.
There were things being done in the 60s that we still haven't really integrated into our trade. [0] We joke about having to program with hardware switches and punch cards, yet here we are still typing carefully crafted cryptic commands that tell the computer exactly what it is supposed to do, and storing them in linear text files which we have to mentally map to program states. I think there will always be a place for this kind of programming, just as people still use Assembly today, but it's a bit premature to say, "Well, this is it, or nearly so!"
I recall reading that one of the giants of early computing, Von Neumann perhaps, never understood the benefit of Assembly and thought that it was a waste of the computer's time to compile to machine code rather than have a human write the machine code directly. We are working inside a problem domain that we barely understand. I find it hard to believe that we will have the glorious sci-fi future that many of us imagine will come out of advancements in technology without also developing corresponding advancements in how we describe and create and interact with it. One potential example that I am looking forward to learning more about is Luna, which features a visual development environment that is isomorphic to its code. [1]
The implicit goal of programming language and tool development is "How do I make it easier to accurately map 'the thing I want done' into a functioning system?" And our tools are getting better all the time, opening up new avenues of interest and possibility. This is a great time to be a programmer, and I think it's only going to get better, and become more accessible.
> in reality we don't really know what its development arc is
That's true, but we know we're past the rapid advancement portion of the arc. Look at the most widely used languages today, the top ten, regardless of methodology[1][2][3], are dominated by languages that are ~20 to 30+ years old.
> advancements in how we describe and create and interact with it
As a funny, but accurate, CommitStrip[4] pointed out, you'll need to create a specification, and we already have a term for a project specification that is comprehensive and precise enough to generate a program...it's called code.
> One potential example that I am looking forward to learning more about is Luna
That was discussed on HN recently[5] and some people were pointing out it appeared to have made little to no progress since the previous time it was submitted and others mentioned various short-comings of these types of visual programming languages in general. Time will tell, we'll see what happens /shrug
This is the analysis of this topic that I agree with. Programming has already evolved an incredible degree; from "programmers" rewiring the first computers as means to input new programs, to coding 1 and 0's with swithes on massive panels, to assemblers that magically did all that for you (Hammings "automatic programming") to compilers and high level languages. We are truly standing on the shoulders of giants.
I also agree with the idea that any ai that programs will have to be human level. So much of what we do is making sense of vague requierments and product owners who don't even know or can't express exactly what they want. Personally, I do very little actual programming, haven't for years.
Assuming neural nets could solve every problem, who writes the formal contracts and validates the proofs? I would call the person writing the contract the "software engineer" and the prover the "QA engineer", and we're back to the status quo.
You can represent any function with a neural net, it's just a matter of figuring out how to get it to learn the function.
But at the end of the day you need something human (or equivalent) to validate it, and as any programmer knows it's a lot easier to understand and validate something you've written than something someone (or something) else has written.
I do think machine learning will become more mainstream, like the saying "Google uses Bayesian filtering the way Microsoft uses the if statement".
Even so, if statements tend to be written by humans, compartmentalised into functions/modules/methods/etc. and plugged together to form whole systems. Microsoft software (presumably) isn't one huge `if/elif/elif/...` in a single `while` loop, even though that would suffice in theory.
Likewise, I imagine Google's software isn't one giant formula, conditioned on inputs and sampled for outputs. Although many of their user-facing applications do contain a black box of this form (e.g. for translation, text-to-speech, etc.), they're only used in very narrow, well-defined tasks, and are surrounded by a huge amount of "normal" code.
Your comment is being dismissed (and downvoted) pretty thoroughly; but I think there's a grain of truth to it. As has been said by others, we don't get complete specs as it is, and our industry has moved towards "release often and fix the bugs or mistaken assumptions." The only real difference between the output of a NN and a human is the inference of the context to drive those assumptions.
Seeding a NN would be a simple listing of invariants: Headers are at the top of the screen, footers at the bottom, there exists a name field in the page and the datastore; the name field on the page corresponds to the name field in the datastore. Once those invariants are defined, the intermediate product is released to the customers and they directly drive further development of the NN by simply saying "this is not the expected behavior" in some easy drop-down.
I think the biggest hurdle will be that a human's assumptions are going to be more palatable than a NN's assumptions. But once a number of those assumptions are codified (or a statistical preference is determined), this weakness may be effectively mitigated.
This "crowd-sourced" definition of correctness has already been proven - in chatbots. People have been able to coerce chat bots into providing their desired output without touching a line of code.
Cleanly connecting NNs to contracts / rules is indeed a hard problem, which many people would like to see solved. Please see my post about that [1], and the corresponding HN comment thread [2].
Yes, we already have excellent programming automation. They're called compilers.
No one has yet succeeded in making a language that can convert a spec to code, especially when it ought to deal with things that are "obvious" and as a consequence never mentioned, special cases that no-one's ever really thought about, fundamentally contradictory requirements &c &c &c
I think the kicker will be when natural language and AI becomes good enough such that a non-technical person can state their intent, and computer generate a working interpretation. Then that person iterates.
That will speed up developer time, as will expert systems that automatically account for known failure modes and ever more sophisticated operational environments.
But that person talking to the AI, will need to know best practices about stating intent, experience with when that goes poorly, and an ability to think about the problem and break it up into stateable intentionality. All of that is just a developer doing their job...
Your average non-technical person will be long bored before they finish their program. Heck, that boredom kills a lot of programs even today, before they are finished. Look at the graveyards of Open Source known as Sourceforge and Github :p
I'm not saying that these "graveyards" don't also produce a lot, but the vast majority of programs are never finished.
And that's for generally trained professionals who love or at least like what they're doing.
I've found that a lot of the time the businesspeople with the requirements know the answers, though they don't necessarily know what they know - a lot of the programmer's job is in figuring out the right questions to ask them.
Programming is already a complex machine learning system:
- The Reinforcement function is a human programmer (organic evaluation function) that transforms human needs (requirements) into an executable language (code).
- The organic evaluation function is made more efficient by shared knowledge where the evaluation functions can learn from each other (Stack Overflow, HN, etc.).
- The organic evaluation function is also made more efficient by improved organic processes (sleep, food, exercise, etc.).
- In addition, improved variety of executable languages can allow the organic evaluation functions to decrease input-speed and increase accuracy of translated requirements.
So, the level of automation is simply: To what extent are humans required to explain their own needs to machines.
Pure automation would seem to indicate that machines could interpret all human needs. But in reality, that would mean the machines are simply no longer listening or care about what a human thinks it should do.
This is short sighted on many levels. Past experiences don't predict the future accurately. Just because we couldn't fly before 1900s didn't predict we never will. We already seen birds doing it but it took a while to reach a breakthrough.
> This is not something AI is anywhere close to being able to do.
YET :) Just look at these research available today:
Artificial general intelligence (AGI) is not an impossible goal, but we are simply not there. Bug saying we never will needs a great evidence which we don't have afaik.
An AGI system should be able to write computer code based on vague specification. If it's intelligent it will write back clarifying questions. Just like I do on a regular basis. I imagine such a system will be running constantly for years.
> Past experiences don't predict the future accurately. Just because we couldn't fly before 1900s didn't predict we never will. We already seen birds doing it but it took a while to reach a breakthrough.
OK, but by this logic literally any outcome is as likely as any other. Not much basis for prognostication there.
> An AGI system should be able to write computer code based on vague specification. If it's intelligent it will write back clarifying questions.
What makes you think this approach is faster than just writing down the specification in your head? Is it because you assume the machine can guess important design decisions that you leave out?
To me, what you describe sounds like what every programmer does: enter code and look at what the compiler says. There's nothing qualitatively different from what you describe and a sufficiently powerful type system.
You have to somehow communicate a specification to a computer; this is programming. Languages might become more powerful, but you always want to be able to point to the place in the specification that implements your important feature, and not have some computer hopefully deduce it.
If you have some extremely important implementation note, would you rather specify it in exact terms via code, or give vague hints about it and depend on it being deduced by some AI compiler? What if you have hundreds of important implementation notes? It all ends up being code.
> What makes you think this approach is faster than just writing down the specification in your head?
For non programmers, manager type people it would be the holy grail. Not necessarily faster but probably cheaper :)
> Is it because you assume the machine can guess important design decisions that you leave out?
Yes, if sufficiently enough systems are wired up then it should be able to at least guess what level of abstraction is missing or what to ask next to proceed.
I know what programming is, I do it day to day. Here I'm talking about a generally intelligent system that could do the same. The trick obviously is to skip writing detailed enough specification that would be equivalent to code.
The article says that programming won't be automated. I say that we don't have the capable systems, but we are getting there slowly.
Correct - it's about managing complexity of a different kind. It's not about reducing the complexity, it's about changing the kind of complexity to that which humans are better-equipped to handle. As you say this is the holy grail for non-programmers, which is to say it'll completely redefine what we call "programming."
> Artificial general intelligence (AGI) is not an impossible goal, but we are simply not there. But saying we never will needs a great evidence which we don't have afaik.
"AGI is not an impossible goal" also has no evidence afaik.
I suspect they just mean that there's no particular part that seems impossible from where we sit now. There's no part that is prima facie impossible (eg a square circle). The problem of course is that we don't know enough to do it yet... so we also don't know enough to know that it's not doable. We may learn some reason that it's impossible along the way, but we haven't learned of any so far.
I worked for a software company where the CEO believed he could eliminate the programmers if he could get them to build enough "components" that could be "glued" together. He had a large team of architects and programmers working on this for multiple years. They literally had a GUI that was like a circuit board where you could drag and drop these components and connect them via a wires.
After multiple years they couldn't build a basic clock out of these components, let alone any kind of program. The CEO eventually fired all the programmers on the team because he felt they were undermining his brilliant idea and were refusing to get it done.
Idris language encourages type-driven development, and can make guesses about holes in your program based on the types. I expect (and hope) we'll be seeing more of that in programming in the future. It's not a silver bullet, but should definitely help.
I don't think automating programming is the next big source of productivity but what should be the next big source of productivity instead is to make programming available to end users.
What we really lack is a modern VBA, simpler and less clunky than VBA, that end users can use to automate their most mundane tasks.
Unfortunately we are going the opposite way, with IT departments locking down ever more end users' machines and Microsoft / Google / Apple dumbing down their OS.
I always feel like the most impressive part of these kinds of discussion is, the following question has already been answered: "Can you devise a mechanical process that can, given an axiomatic system in first-order logic and a predicate, decide whether the predicate can be deduced from the axioms?"
The answer is "no."
That people still believe in future self-programming computers in spite of that is just---strange.
65 comments
[ 2.8 ms ] story [ 127 ms ] threadProgramming will certainly continue to make advancements, but I wouldn't expect the advancements of the next 50 to rival the magnitude of those of the last 50.
There were things being done in the 60s that we still haven't really integrated into our trade. [0] We joke about having to program with hardware switches and punch cards, yet here we are still typing carefully crafted cryptic commands that tell the computer exactly what it is supposed to do, and storing them in linear text files which we have to mentally map to program states. I think there will always be a place for this kind of programming, just as people still use Assembly today, but it's a bit premature to say, "Well, this is it, or nearly so!"
I recall reading that one of the giants of early computing, Von Neumann perhaps, never understood the benefit of Assembly and thought that it was a waste of the computer's time to compile to machine code rather than have a human write the machine code directly. We are working inside a problem domain that we barely understand. I find it hard to believe that we will have the glorious sci-fi future that many of us imagine will come out of advancements in technology without also developing corresponding advancements in how we describe and create and interact with it. One potential example that I am looking forward to learning more about is Luna, which features a visual development environment that is isomorphic to its code. [1]
The implicit goal of programming language and tool development is "How do I make it easier to accurately map 'the thing I want done' into a functioning system?" And our tools are getting better all the time, opening up new avenues of interest and possibility. This is a great time to be a programmer, and I think it's only going to get better, and become more accessible.
[0]https://www.youtube.com/watch?v=8pTEmbeENF4 [1]http://www.luna-lang.org/
That's true, but we know we're past the rapid advancement portion of the arc. Look at the most widely used languages today, the top ten, regardless of methodology[1][2][3], are dominated by languages that are ~20 to 30+ years old.
> advancements in how we describe and create and interact with it
As a funny, but accurate, CommitStrip[4] pointed out, you'll need to create a specification, and we already have a term for a project specification that is comprehensive and precise enough to generate a program...it's called code.
> One potential example that I am looking forward to learning more about is Luna
That was discussed on HN recently[5] and some people were pointing out it appeared to have made little to no progress since the previous time it was submitted and others mentioned various short-comings of these types of visual programming languages in general. Time will tell, we'll see what happens /shrug
[1] https://www.tiobe.com/tiobe-index/
[2] https://octoverse.github.com/
[3] http://spectrum.ieee.org/computing/software/the-2016-top-pro...
[4] http://www.commitstrip.com/en/2016/08/25/a-very-comprehensiv...
[5] https://news.ycombinator.com/item?id=14612680
I also agree with the idea that any ai that programs will have to be human level. So much of what we do is making sense of vague requierments and product owners who don't even know or can't express exactly what they want. Personally, I do very little actual programming, haven't for years.
Until there exists a Neural Net proofen to be able to validate any contract specified for a NN to uphold.
After that its unemployment, like the rest of humanity.
But at the end of the day you need something human (or equivalent) to validate it, and as any programmer knows it's a lot easier to understand and validate something you've written than something someone (or something) else has written.
Even so, if statements tend to be written by humans, compartmentalised into functions/modules/methods/etc. and plugged together to form whole systems. Microsoft software (presumably) isn't one huge `if/elif/elif/...` in a single `while` loop, even though that would suffice in theory.
Likewise, I imagine Google's software isn't one giant formula, conditioned on inputs and sampled for outputs. Although many of their user-facing applications do contain a black box of this form (e.g. for translation, text-to-speech, etc.), they're only used in very narrow, well-defined tasks, and are surrounded by a huge amount of "normal" code.
Seeding a NN would be a simple listing of invariants: Headers are at the top of the screen, footers at the bottom, there exists a name field in the page and the datastore; the name field on the page corresponds to the name field in the datastore. Once those invariants are defined, the intermediate product is released to the customers and they directly drive further development of the NN by simply saying "this is not the expected behavior" in some easy drop-down.
I think the biggest hurdle will be that a human's assumptions are going to be more palatable than a NN's assumptions. But once a number of those assumptions are codified (or a statistical preference is determined), this weakness may be effectively mitigated.
This "crowd-sourced" definition of correctness has already been proven - in chatbots. People have been able to coerce chat bots into providing their desired output without touching a line of code.
[1] http://blog.foretellix.com/2017/07/06/where-machine-learning...
[2] https://news.ycombinator.com/item?id=14717692
This person severly lacks vision.
No one has yet succeeded in making a language that can convert a spec to code, especially when it ought to deal with things that are "obvious" and as a consequence never mentioned, special cases that no-one's ever really thought about, fundamentally contradictory requirements &c &c &c
Human "specs" are more analogous to statements of intent.
Ever higher levels of abstraction will come about but generating the "spec" will continue to be the programmers job.
But that person talking to the AI, will need to know best practices about stating intent, experience with when that goes poorly, and an ability to think about the problem and break it up into stateable intentionality. All of that is just a developer doing their job...
I'm not saying that these "graveyards" don't also produce a lot, but the vast majority of programs are never finished.
And that's for generally trained professionals who love or at least like what they're doing.
- The Reinforcement function is a human programmer (organic evaluation function) that transforms human needs (requirements) into an executable language (code).
- The organic evaluation function is made more efficient by shared knowledge where the evaluation functions can learn from each other (Stack Overflow, HN, etc.).
- The organic evaluation function is also made more efficient by improved organic processes (sleep, food, exercise, etc.).
- In addition, improved variety of executable languages can allow the organic evaluation functions to decrease input-speed and increase accuracy of translated requirements.
So, the level of automation is simply: To what extent are humans required to explain their own needs to machines.
Pure automation would seem to indicate that machines could interpret all human needs. But in reality, that would mean the machines are simply no longer listening or care about what a human thinks it should do.
> This is not something AI is anywhere close to being able to do.
YET :) Just look at these research available today:
https://www.youtube.com/watch?v=XgB3Xg5st2U
https://www.youtube.com/watch?v=vzg5Qe0pTKk
Artificial general intelligence (AGI) is not an impossible goal, but we are simply not there. Bug saying we never will needs a great evidence which we don't have afaik.
An AGI system should be able to write computer code based on vague specification. If it's intelligent it will write back clarifying questions. Just like I do on a regular basis. I imagine such a system will be running constantly for years.
OK, but by this logic literally any outcome is as likely as any other. Not much basis for prognostication there.
What makes you think this approach is faster than just writing down the specification in your head? Is it because you assume the machine can guess important design decisions that you leave out?
To me, what you describe sounds like what every programmer does: enter code and look at what the compiler says. There's nothing qualitatively different from what you describe and a sufficiently powerful type system.
You have to somehow communicate a specification to a computer; this is programming. Languages might become more powerful, but you always want to be able to point to the place in the specification that implements your important feature, and not have some computer hopefully deduce it.
If you have some extremely important implementation note, would you rather specify it in exact terms via code, or give vague hints about it and depend on it being deduced by some AI compiler? What if you have hundreds of important implementation notes? It all ends up being code.
For non programmers, manager type people it would be the holy grail. Not necessarily faster but probably cheaper :)
> Is it because you assume the machine can guess important design decisions that you leave out?
Yes, if sufficiently enough systems are wired up then it should be able to at least guess what level of abstraction is missing or what to ask next to proceed.
I know what programming is, I do it day to day. Here I'm talking about a generally intelligent system that could do the same. The trick obviously is to skip writing detailed enough specification that would be equivalent to code.
The article says that programming won't be automated. I say that we don't have the capable systems, but we are getting there slowly.
"AGI is not an impossible goal" also has no evidence afaik.
After multiple years they couldn't build a basic clock out of these components, let alone any kind of program. The CEO eventually fired all the programmers on the team because he felt they were undermining his brilliant idea and were refusing to get it done.
It's been around for 3 decades. It hasn't revolutionized the world yet...
So the CEO didn't realize this very step is no other thing than... programming?
What we really lack is a modern VBA, simpler and less clunky than VBA, that end users can use to automate their most mundane tasks.
Unfortunately we are going the opposite way, with IT departments locking down ever more end users' machines and Microsoft / Google / Apple dumbing down their OS.
(I went to find the Parnas reference and realized it was on an earlier copy of the same article: https://news.ycombinator.com/item?id=13929633, i.e. this submission is a dupe.)
The answer is "no."
That people still believe in future self-programming computers in spite of that is just---strange.