Programming will never be "easy".

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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

Writing will never be "easy" either, apparently.

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.

Not building this:

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

with those tools will stay just as hard.

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.

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.

You can almost express something like that, in SQL.

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?

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

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

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

A true AI could probably do stuff like that.

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.

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"? Easier perhaps, but there will never be a replacement for expertise.