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.

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

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.

It would be like to say to be good at programming you need to be good at art and math, which are both considered "hard to master", which make programming even harder.

And then you can add the 3rd element: time (or experience), or the classic "to be good at something you need to practice it for at least 10 years", which make the whole thing even harder.

I don't know any tools that can make those 3 things easier.

I must say that the article have one flaw, it presents programming as an activity you can or can not do, eg. "I'm not able to do something because of something else", me I would say that to be able to do programming you have to be good at it, and I'm not just talking about understanding the tools, the languages, the API, etc.

Really, it is all about being good at using a language to solve one or more problems.

My guess is when people says "programming is hard", is that they assume it is easy to solve problem if you know programming, and fail to see that it's not programming that is not easy but solving problems that is not easy.

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.

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

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.

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

Need to open a file, write to it and save it? A couple of lines.

Need to parse some badly written HTML to get data out? Include a library and then a few lines of code.

Want to enable table re-ordering client-side in javascript? Include one file and then one line of code.

We're spending less time mucking around with solved problems now.

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.

And yes, today's languages may be a lot more complicated than BASIC, but that doesn't imply they're more difficult to learn.

But you are right of course about the downside of this evolution, which is wasteful use of resources.

If oil would suddenly become 10x cheaper, it would make it easier to drive long distances but would also lead to waste of fuel.

Not that this has anything to do with 'ease of programming'.

Nowadays you can take for granted everyone has TCP/IP and a web browser and you can knock up a RoR app in a day...

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.

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

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.

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.

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.

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

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?

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

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.

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.

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.

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

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.

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

If you asked a room of 30 people to draw you a picture of exactly what that sentence means, you will get 30 different results. Building on your comment, I'm not sure the actual act of programming would be hard if you had to take only 1 person's viewpoint into account and work off that.

The claimed benefits are quite high: 50% reduction in app specification time , and 75% reduction in development changes.

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.

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

Writing will never be "easy" either, apparently.

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.

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.

Not building this:

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

with those tools will stay just as hard.

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.

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.