

Programming will never be "easy". - MDMStudios
http://mdmstudios.wordpress.com/2010/08/28/programming-will-never-be-easy/

======
shadowsun7
There's actually a simpler argument, and probably a better one:

Programming can (and is!) described as an art, and it's difficult to imagine
people thinking like this about _other_ kinds of art. There are few people,
after all, who would say things like "Oh, one day music will be easy and
everybody will be able to play like Joshua Bell." or "Oh, but one day novel
writing will become easier, and everybody will be able to write like Stephen
King." And so it's ridiculous as to why programming is given this treatment.

Sure, mastery of the tools in programming may be harder than in writing, say,
or in photography. But tools are just one bit of it - ideas are the other bit,
and much more important.

~~~
makmanalp
I think a larger issue lies in this:

Nowadays, any moron can take a mid-quality camera with good auto settings and
do "photography", and the average customer is likely to not distinguish this
person from a professional photographer with years of experience, or an
established photographic artist.

Is this also true, to some degree, with programming? Can any moron who
"learned java" in a first year college course compete with a good, experienced
programmer because the customer doesn't know any better? (and thus will go for
lower price) The answer, in my experience, is "yes".

~~~
maukdaddy
There was a time that only experts could "make" websites (mid 90s). Today you
can get a wordpress blog with a nice template and look as good as a lot of
major websites. So we're partially there as far as the web goes.

I'd argue that frameworks like Rails have significantly lowered the barrier to
entry for web programming. It isn't "easy" per se, but significantly easier
than just 10 years ago.

------
jeromec
_A couple of people I have seen with have gone so far as to insinuate that the
reason programming is to hard for most people, is because we design our
languages to be too hard, just to keep people away from programming, and to
secure our jobs._

That's like saying building engineers erecting a skyscraper in New York design
their blueprints to be complex and confusing to keep other people away and
secure their jobs. That's totally ridiculous. Anyone with this line of
thinking is truly ignorant of the complexities and considerations required to
carry out certain real world jobs.

To be a "programmer" means you can effectively communicate with, and
manipulate a machine. The more direct your communication, the more you are
considered to be a programmer. Microsoft became one of the most successful
software companies in the world because their Windows operating system allowed
anyone to become an effective _operator_ of their own computer. If you can
only manipulate, but not communicate with a machine you are an operator, not a
programmer. Programming the machine has not become any less complex because of
the Windows GUI; it's just the complexity of managing the computer is handled
by the operating system. The reason nerds will always be better at
programming/technology is that we actually have an interest in the complex
details of underlying technology, and putting in the time to learn. Some will
even _write their own operating system_ as Linus Torvalds did, just for the
heck of it. If you are someone who can't program, but wants to, roll up your
sleeves and learn. Don't start making excuses diminishing the talent and skill
actual programmers/engineers have attained because of your own shortcomings.
That's insulting.

------
kenjackson
I think he underestimates the power of domain specific languages. It may be
hard to program with a general pupose language, but I think we'll soon see
trees that look more like: Application -> Game -> Sports Game -> Resembles
Basketball ...

And then you get a whole bunch of stuff dropped on you that starts as a
basketball game, with constructs for players, scoring, fouls, etc....

Then people can come and say, "I made this new game. Like basketball, but no
free throws, winners outs, dunks are 4 points, and you can tackle the player
with the ball".

Sure you can't write any arbitrary thing you want, but I think most people
would be happy with how far that gets you.

~~~
varjag
I remember Game Construction Kit and alike back in the day of 8-bit machines.
You could build your own version of Space Invaders, only with aliens smiling
and you shooting them down with flowers. Never really took off.

EDIT: this is not to say I don't see a point in your post, just that perhaps
games industry is a poor example.

~~~
kenjackson
I agree. The game industry is not a great example. Largely because people are
a lot more likley to simply by major party games. Mathematica or Matlab are
probably better real world examples, although certainly not an app that Joe
Plumber would use.

------
gaius
As programming gets easier, the problems we will tackle will get harder. Net
"difficulty" will remain constant.

~~~
pvg
_As programming gets easier_

I'm not sure this is something that's actually happening.

~~~
forinti
In the 8-bit age, you turned on your micro and had instant access to BASIC
which you could easily edit line by line. Today, you have to install your SDK,
maybe an IDE and learn a language a lot more complicated and deal with
enormous APIs.

~~~
Proleps
Today you can download python, run the installer and you get IDLE, and you can
start doing some tutorials right away.

You can also download .NET and get started right away. I'm sure there are a
lot more examples. It has never been easier to start learning how to program.

------
drblast
Programming is hard because it involves a trade-off. Programming isn't really
about solving a problem, it's about limiting options until the only ones left
are what people want.

I spent a few months about a year ago re-writing a massive cobbled-together
database to track training, testing, and readiness for a large number of
people. It had to conform to a number of requirements, like one sub-group of
people's grades were averaged, but people could belong to multiple sub-groups
and sometimes overlapped.

A monthly report had to be generated from all of this data. The format of the
report was set in stone, and was not designed with automation in mind.

I avoided hard-coding many things as much as possible, but eventually I found
that the more flexible I made the program, the more difficult it was to use.
At one point you almost had to be a programmer to tell my program what kind of
output you wanted.

Ah ha! So there are problems, it seems, that are fundamentally complex; there
is no right answer, you can either have a flexible, complex program that
accounts for every possible scenario, or a hard-coded program that is simple
to use but will break the minute something changes.

The same principle applies to computer languages, spreadsheets, databases,
anything. They are "easier" because they remove options from you and make
assumptions that you won't miss those options. The moment those assumptions
are wrong, you need a programmer.

~~~
tene
The name I've always seen given to this is the waterbed theory of complexity.
There's a certain amount of necessary complexity in a problem, and pushing it
down in one place just increases the complexity necessary somewhere else. The
only way to reduce the necessary complexity involved is to solve a simpler
problem instead. Note that this does not exclude the possibility of
unnecessary complexity, which is also possible.

<http://en.wikipedia.org/wiki/Waterbed_theory>

------
rdtsc
Programming will be easy when problem solving is easy.

Programming is solving problems. Some programmers would consider it fun and do
it for enjoyment. But for most people programmers just solve a problem. It is
just a form of engineering. A civil engineer builds a bridge, a software
engineer sets up a web store.

At the bottom it is just about knowing how to organize the concepts and them
build a system according the specifications.

There are tools of course: the language, the platform, programming paradigms,
patterns and algorithms. A good programmer will have to be familiar with a
large set of those and then pick the best for the job.

~~~
5teev
> Programming will be easy when problem solving is easy.

An especially hard part is identifying where the problems actually lie. The
average person "solves" a problem by addressing only the best case scenario
and lacks the pessimism and pervading sense of doom that enables programmers
to figure out in advance, and account for, all the ways in which every little
thing will go wrong.

------
scotty79
Imagine how would you order a human to build you window with a table view,
etc.

If human would not know what style of window do you want then he would ask or
assume something and allowed for your comments. "Programming" humans is much
more conversational. Your workers know what to assume and when to ask.

Also naming is not something that people usually do when they tell what they
want to have. "Put new button in the window." I have only one window, why
should I name it window1. When I will have second window I'll probably refer
to this window as the first one, and to the other as second one, or other one,
or the blue one. Or if everything fails I'll point it with my finger.

Programming will always be hard because deciding on what you want is hard.
People can't do it at first and they need conversation to understand what they
can and cannot have and decide what they want.

~~~
derefr
> If human would not know what style of window do you want then he would ask
> or assume something and allowed for your comments. "Programming" humans is
> much more conversational. Your workers know what to assume and when to ask.

Whenever I think about how programming _should_ work, I think about the
interactions Star Trek characters have with the Holodeck in its design mode.
For example: <http://www.youtube.com/watch?v=SI0wqTsIq3Q#t=3m40s> (Star Trek
TNG, "Schism") — a conversation of iterated constraint-satisfaction through
property alteration and library retrieval.

What you get, in these cases, is entirely dependent on the amount of context-
sensitive and "common sense" knowledge the Holodeck has access to. The
Enterprise on TNG was able to create a sentient being, Moriarty, from a single
command, because it had access to a huge database of information about human
behavior, game theory, psychology, etc. and also the complete texts of the
Sherlock Holmes novels to constraint-match against.

However, Dr. Zimmerman, the programmer responsible for Voyager's EMH program,
had to spend years making intricately-detailed assertions about each aspect of
EMH operation—because, I imagine, the default human behaviors were no good in
a medical context. Given the show's base of theory, this should have been able
to be short-circuited by constraint-satisfying against a large database of
holographic recordings of the performance of medical procedures, similar to
the Sherlock Holmes corpus. The rest (prescribing medicine, etc.) would simply
be a "friendly bedside manner" on top of the already-helpful expert system
built into the computer (and it is a chronic question of why the ship as a
whole doesn't just come with such a "personality subroutine" already
installed—probably simply because of the show's chronic bio-centricity.)

------
Another1
Well, the main problem I have with this idea is the assumption that all
Programming is equal! Which is not.

It is easy to write a simple program that concatenate 2 files for examples, it
is also easy to create a CRUD database application

Systems programming on the other hand is hard, because to be good at it, you
need to understand how the systems work, which is hard, and by hard I mean you
need to do a lot of reading and remember many details

I believe Programming is as hard & complex as the Programming Problem domain.

Programming itself is not hard, because concepts like Iteration, functions,
conditional branching, recursion, OOP (Inheritance, encapsulation,
polymorphism ), etc ... are not that complex, are they?

~~~
gnaritas
> because concepts like Iteration, functions, conditional branching,
> recursion, OOP (Inheritance, encapsulation, polymorphism ), etc ... are not
> that complex, are they?

No, but stringing them all together without making an unmaintainable mess in a
reasonable amount of time, for most, is.

------
chipsy
I think of the problem of "learning programming" in terms of basic conceptual
difficulty. Programming is difficult mainly because of "how to build
algorithm," "how to design data structure" type problems. The syntax and vocab
of a programming language are there mainly to illuminate concepts that keep
coming up over and over in your domain, and protect you from errors.

But to solve the conceptual problems, you have to "get the picture" about
various models of data organization and how they might relate to each other.
If, for example, you don't know how a list works or its practical utility,
you're going to get stuck at a very low level of understanding of how the
infrastructure of the program might be implemented. Similarly, when you are
writing software for some class of end-user(e.g. "power users" who write bash
scripts daily vs. retired grandmas that are scared of any error message or
complex feature) you have to design an interface around _their_ most likely
mental model, so that they can get the job done quickly.

And, of course, when one programmer reviews another's code, or a programmer
reviews their own code years later, the initial reaction is always that it
looks ugly because it inevitably uses a thought process different from their
current one.

------
roryokane
There is a problem with the example he gives, of parsing “Create a window with
a table view, and then when someone clicks a button, add an entry to the table
view”. I think a future programming language could actually make a program out
of that. I agree that there is not enough information in that sentence to be
sure that the program is what the user wants, but in this case, the language
can use a popular technique in programming: have defaults. For instance, most
languages have a file I/O library. If you open a file without saying whether
you want to read or write to it, the compiler doesn’t complain, it just
chooses the default. If you realize the default isn’t what you want, you can
change it.

Similarly, a future language could parse the given sentence as “put a single-
column table view on the left, and a button on the right that says ‘Add an
Entry to the Table View’, and when the button is clicked, just put the string
Entry at the bottom of the table view”. And then the programmer tries this out
and tells the programming language “no, I want the button at the bottom, and
it should say ‘Add Person’”, and the language makes the necessary changes and
follows defaults otherwise, choosing to left-align the button at the bottom
rather than center it, and resizing the button to fit the text. And the
programmer could just keep specifying more details about what a Person is, and
how you edit it, and you can make a program in this way.

Basically, this is just like modern libraries: instead of writing your own
HTML parser nowadays, you can use a library with a “default” (non-custom) way
of parsing HTML. In the future, rather than specifying your GUI and attached
code in exact detail, you can just use a library of defaults. It will probably
be the case that programmers in the future would simply move on to bigger and
harder problems than GUIs with code, as gaius mentioned at
<http://news.ycombinator.com/item?id=1641514>, but I think programming at the
level we know it actually will get easier.

------
Groxx
Another reason to add to the pool for why programming is hard:

People don't _actually_ know what the want, nor do they know how to
communicate it accurately to another person.

The day _that_ changes, it becomes _possible_ for programming to be easy
because there will be an actual translation between our language and machine
code. Until then, programmers are the translators, dreamers, and engineers all
rolled into one. Not easy.

------
wyclif
Second sentence of this post:

 _A couple of people I have seen with have gone so far as to..._

Writing will never be "easy" either, apparently.

~~~
phoenix24
Yeah, and I'm not saying that blogging or writing essays was any easier.

Posting random snippets but writing worthwhile posts is a different thing
altogether. I think it probably requires as much patience and effort aswell.,
unlike writing code which happens pretty natural.

------
gfodor
The author, like many people, is conflating two issues that result in
complexity in software engineering. (Among many others.)

First, is the fact that we need to tell the computer what to do. This is, I
think, what the author thinks of "programming" as. He's right, it's hard, and
it's gotten easier as we've improved our tools and languages that enable us to
tell the machine what we want it to do.

However, second, is the problem of taking a description of a problem, from
another human, and translating it into a piece of software. The source of this
information, in the worst case, is a verbal description. At the extreme, it's
a written specification (which, as we all know, ultimately ends up in the
trash.)

It's this knowledge capture problem that I think has a wide open opportunity.
There needs to be a better way for the 3rd party humans to describe their
problems in a way programmers can build on top of. It doesn't have to be
precise, it doesn't have to be perfect, it just has to be better than the
status quo of verbal descriptions and .doc files of specs.

~~~
hasenj
It's often a mistake to think that a human can describe his requirements.

People don't really know what they want.

No one could have gone to Steve Jobs and said, hey, I want a phone that can
read mail, play music, download apps, and has a touch screen.

No one thinks in these terms.

At best, people would say: I want a device that I can carry around with me
that can act as a small computer.

There's a wide and huge gap between "creating great products" and "gathering
user requirements".

~~~
gfodor
An improved means of communication would not presume to solve the problem of
humans being unable to precisely describe requirements. The point is right now
the status quo is that people are _unable_ to describe the requirements to a
satisfactory degree of precision, for those that they _do_ have the ability to
describe.

Note that this means of communication can apply not just to third parties but
to those within the organization (designers, product people) who need a means
to describe their own, more specific vision in terms that can be then used by
programmers to turn into working software.

------
cubicle67
From what I've seen, people find programming difficult because they lack both
the ability to break a problem into smaller and smaller pieces until the
pieces reach the same granularity as the language in use, and the ability to
anticipate a range of possible scenarios.

~~~
wake_up_sticky
This hits the nail on the head. It's not that people don't understand the
syntax or even the semantics of programming languages (well, some people can't
write a for loop, but they're just hopeless). It's that they can't see how to
use the language to get from point A ("I want a program that does x") to point
B (an actual program that does x). For instance, when I first began
programming, I struggled mightily with deciding how to represent real-world
data. Other people might be able to decide how to represent data, but become
hopelessly stuck when it comes to turning their verbal descriptions of tasks
into actual algorithms. I think that this is why so many people go on
programming interviews and then can't actually solve simple programming
problems: they do fine when they're taking exercises from books, but they
can't concretely conceptualize the solution to an even slightly ambiguous
problem.

------
noonespecial
Building complex things will get easier with more powerful tools.

 _Not_ building this:

<http://simpsons.wikia.com/wiki/%22The_Homer%22>

with those tools will stay just as hard.

------
Seth_Kriticos
I agree. Learning the programming language is just a very small part of
programming. More importantly you need to understand programmatic problem
solution concepts, work-flow and maintainability.

Creating GUI's with gui editors is already there for most frameworks, but it
does not make programming easier, it merrily reduces UI design effort for very
simple applications (and increases hassle for more elaborate widget
interactions).

As a computer programmer your biggest challenge is to understand the problem
and apply your experience about problem solution logic to it via a programming
language, than slap a UI on to it.

------
elbrodeur
Programming might never be easy, but interfacing with technology will become
increasingly easy. Additionally, building simple applications will, as well;
there's already a trend in that direction.

For instance, telling a server you want a blog with a theme is fairly easy.

Telling a website you want a gallery of images themed a certain way is fairly
easy.

Programming might never be easy, but building simple applications -- like the
one in his example -- is already easy.

------
didip
“Create a window with a table view, and then when someone clicks a button, add
an entry to the table view”

You can almost express something like that, in SQL.

------
znt
Well a google search for "drag and drop programming" led me to this project:

<http://www.codeproject.com/kb/miscctrl/scriptstudio.aspx>

It looks like an UML diagram creator but instead creates basic code for simple
scripts. I guess you can't write a full program with this, but it's a small
step towards a greater goal maybe?

------
gmlk
What about evolution? All known life is algorithmic? Hence, given enough time,
programming (coding) should be easy enough so that it could be automated.
Given a suitable environment it could even spontaneously just happen. No?

Design is harder then coding because one has to define the constraints and
requirements in which the program has to work.

------
sz
As much as I understand the points he's making, it reminds me too much of old
archives of skeptical posts along the lines of "What, 12 CPUs with 32nm
transistors on a single die? That will never happen, it's impossible."

Be wary of blanket statements of the form "X will never Y" (unless they break
physics, and even then...)

------
aufreak3
I think the task that the author is referring to is that of taking an
imprecise specification of "what I want" and generating an implementation that
_automatically_ resolves all ambiguities and inconsistencies in the
specification.

------
Hexstream
You know, I consider setting up filters in gmail to be a form a very high-
level programming (DSL), and it's so easy that nonprogrammers can use them.

------
Tichy
"we don’t have that type of technology quite yet"

Yet - but then don't say "never" in your title.

A true AI could probably do stuff like that.

------
pendragon
“Create a window with a table view, and then when someone clicks a button, add
an entry to the table view”

The thing is, even the above has logic "then when someone clicks". A lot more
logic than that is needed to write any reasonably sized program. Many
conditions need to be thought of and allowed for. This is even though the
above requires the computer to write a lot of code for us - which would have
been originally written by humans.

------
InclinedPlane
There's an element of symantic imprecision at play here. Software engineering
is not the same thing as programming. Much the same way that furniture making
is not identical to woodworking. I know my way around a wood shop well enough
but I wouldn't trust myself to make a high quality wooden table or chair, as I
lack the necessary expertise.

It takes a great deal of expertise to translate problems, requirements, or
"stories" from user space into a design that is not only implementable but
represents a good balance of optimizations and tradeoffs. This is a different
skill than that needed to create the end product, a running application.

P.S. Consider: the fundamental tools make it easier than ever to be a graphic
artist, or a film director. Does the fact that GIMP is free and photoshop is
widely available make producing art "easy"? Easi _er_ perhaps, but there will
never be a replacement for expertise.

------
Devilboy
Reminds me of the classic paper
<http://en.wikipedia.org/wiki/No_Silver_Bullet> from Fred Brooks where he
argues that programming will always be complex because the real-world problems
we're solving are complex. No programming technique or system will magically
make that go away.

------
hc
someday your computer will be intelligent enough to handle the ambiguities of
natural language as well as any human can, and then programming will be as
easy as telling a good human programmer what needs to get programmed.

~~~
extension
When we have computers that intelligent, we won't need to write any more
programs.

