
Programming won't be automated, or it already has been - BerislavLopac
https://dev.to/mortoray/programming-wont-be-automated-or-it-already-has-been
======
le-mark
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.

------
moomin
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

~~~
kasey_junk
That's because the spec _is_ the code. The product is the binary.

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.

~~~
chii
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.

~~~
moomin
I think the natural endgame of that will be Skynet deciding to murder all the
humans.

~~~
KSteffensen
[http://www.ted.com/talks/sam_harris_can_we_build_ai_without_...](http://www.ted.com/talks/sam_harris_can_we_build_ai_without_losing_control_over_it#t-227265)

------
kowdermeister
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:

[https://www.youtube.com/watch?v=XgB3Xg5st2U](https://www.youtube.com/watch?v=XgB3Xg5st2U)

[https://www.youtube.com/watch?v=vzg5Qe0pTKk](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.

~~~
runeks
> 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.

~~~
kowdermeister
> 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.

~~~
taylodl
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."

------
ricksharp
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.

~~~
emodendroket
Theoretically there isn't any reason true human-like intelligence has to imply
human-like consciousness.

------
dsun179
I dont really understand why. But it feels like every afticle on dev.to has a
low quality.

~~~
petercooper
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.

~~~
mikulas_florek
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.

~~~
emodendroket
Only well-known writers have anything to say to the rest of us? Seems like a
questionable proposition.

~~~
AnimalMuppet
"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.

~~~
emodendroket
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.

------
Killeroid
We already do have robust efforts at automating programming. See the field of
Genetic Improvement (
[https://en.wikipedia.org/wiki/Genetic_improvement_(computer_...](https://en.wikipedia.org/wiki/Genetic_improvement_\(computer_science\))
)

~~~
emodendroket
That's still a far cry from being able to voice vague requirements and have a
computer develop a program from them.

~~~
collyw
Interpreting requirements is usually the hardest part of programing. Not the
coding part.

------
sigsergv
I think programming as concept will morph in the future. It was really
different profession back 50 years ago, and it will be different in 50 years.

~~~
frostmatthew
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.

~~~
gasbag
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.

[0][https://www.youtube.com/watch?v=8pTEmbeENF4](https://www.youtube.com/watch?v=8pTEmbeENF4)
[1][http://www.luna-lang.org/](http://www.luna-lang.org/)

~~~
frostmatthew
> 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

[1] [https://www.tiobe.com/tiobe-index/](https://www.tiobe.com/tiobe-index/)

[2] [https://octoverse.github.com/](https://octoverse.github.com/)

[3] [http://spectrum.ieee.org/computing/software/the-2016-top-
pro...](http://spectrum.ieee.org/computing/software/the-2016-top-programming-
languages)

[4] [http://www.commitstrip.com/en/2016/08/25/a-very-
comprehensiv...](http://www.commitstrip.com/en/2016/08/25/a-very-
comprehensive-and-precise-spec/)

[5]
[https://news.ycombinator.com/item?id=14612680](https://news.ycombinator.com/item?id=14612680)

------
cm2187
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.

~~~
tomtompl
How about python? It is as easy as it gets.

------
colorint
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.

------
tycho01
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.

------
dang
Everyone interested in this should know the David Parnas piece on it from the
mid-80s. Excerpt and link at
[https://news.ycombinator.com/item?id=13935004](https://news.ycombinator.com/item?id=13935004).

(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](https://news.ycombinator.com/item?id=13929633),
i.e. this submission is a dupe.)

------
digsmahler
Here is an interesting development contradicting edA-qa mort-ora-y's premise,
AI Software Learns To Make AI Software:
[https://www.technologyreview.com/s/603381/ai-software-
learns...](https://www.technologyreview.com/s/603381/ai-software-learns-to-
make-ai-software/)

------
flavio81
I wish i had $5 each time a person has asked me "why don't you write a program
that creates programs?"

~~~
logicalmind
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.

~~~
flavio81
> 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.

So the CEO didn't realize this very step is no other thing than...
programming?

------
crimsonalucard
Nevermind programming, I'm sure your intelligence as a human being will one
day be automated. Though we are not close.... we are getting closer...

~~~
emodendroket
We may be getting closer, but it is not exactly guaranteed that our progress
will not reach any wall preventing it from going further.

~~~
crimsonalucard
True, but we are aware that this isn't like the speed of light. Our own brains
are testament to what is possible.

------
emodendroket
I agree with this piece; I think enthusiasm is really outstripping reality in
this case.

------
vbuwivbiu
are you having a laugh ? of course programming will largely be subsumed by
machine learning!

~~~
emodendroket
I mean, you aren't really engaging any of the arguments.

------
miguelrochefort
It's obvious that the gap between using software and creating software will
disappear.

This person severly lacks vision.

~~~
emodendroket
Why is that "obvious"? What really made computers revolutionary was the
opposite development.

------
honestoHeminway
Programming will turn towards proofing correctness of trained Neural Nets.
[http://oregonstate.edu/ua/ncs/archives/2017/jun/research-
aim...](http://oregonstate.edu/ua/ncs/archives/2017/jun/research-aims-make-
artificial-intelligence-explain-itself)

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.

~~~
skywhopper
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.

~~~
swiley
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.

