Programming will never be "easy".(mdmstudios.wordpress.com)
mdmstudios.wordpress.com
Programming will never be "easy".
http://mdmstudios.wordpress.com/2010/08/28/programming-will-never-be-easy/
66 comments
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".
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".
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.
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.
agreed but imho programming is not only art , it is also science.
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.
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.
I don’t consider the definition of programming to necessarily include coming up with ideas. That would be software design. It’s not unreasonable to consider programming as including thinking of ideas, in which case you are right, but another reasonable definition is just “the implementation of ideas as a program”, in which case programming can actually be easy – or much easier than it is now, at least.
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.
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 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.
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 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.
EDIT: this is not to say I don't see a point in your post, just that perhaps games industry is a poor example.
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.
DSLs in general can do more than dumb skinning... bad example.
As programming gets easier, the problems we will tackle will get harder. Net "difficulty" will remain constant.
Put another way, the timeless definition of a programmer is "person who has the most control over computers".
As programming gets easier
I'm not sure this is something that's actually happening.
I'm not sure this is something that's actually happening.
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.
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.
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.
Or you can go to http://tryruby.org/ and start right away. Not to mention every computer has at least one web browser with a javascript interpreter.
And yes, today's languages may be a lot more complicated than BASIC, but that doesn't imply they're more difficult to learn.
And yes, today's languages may be a lot more complicated than BASIC, but that doesn't imply they're more difficult to learn.
And what used to be onerous tasks are now easy as pie thanks to those APIs.
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.
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.
[deleted]
Nonsense. One can build a mulit-user database system in a few days. That would have taken months just 20 years ago.
That's not because programming has gotten fundamentally easier, though, but rather because the tolerances have been widened by the progress of the underlying technology, removing some of the constraints. It's like saying tightrope-walking is easier now that all the ropes are a foot off the ground and falling off, touching the ground, and getting back on--that is, screwing up--is now a regular part of the show (like consuming 800MB of memory is now a regular part of peoples' applications.)
I think the argument can be made that the invention of the £Tightrope Support Scaffolding (whatever) made Learning How To Walk A Tightrope significantly easier. Programmer in, Application out.
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.
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.
20 years ago? Really? Months? In 1990?
Not that this has anything to do with 'ease of programming'.
Not that this has anything to do with 'ease of programming'.
Actually, probably, yeah. Say you want a database application for 20 concurrent users. In the early 90s that was client-server, thick client on the desktop (installed how? even the tools for remote deployment sucked back then), a "big iron" database server, proprietary languages on both ends, networking with IPX or Token Ring or something, etc etc.
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...
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...
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.
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.
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
http://en.wikipedia.org/wiki/Waterbed_theory
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.
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.
> 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.
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.
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.
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.
> 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.)
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.)
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?
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?
> 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.
No, but stringing them all together without making an unmaintainable mess in a reasonable amount of time, for most, is.
I agree with your idea , but:
In many programs today , you're pretty far removed from the problem domain by all kinds of technical stuff. just look at web development , when you have to learn python/JS/HTML/css/framework/scaling+deployment and write a lot of code, just to build a social networking site(which isn't a very complex domain).
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.
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.
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.
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.
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.
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.
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.
A couple of people I have seen with have gone so far as to...
Writing will never be "easy" either, apparently.
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.
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.
Seriously. Only someone who doesn't know how to write, needs to add a comma between every noun phrase and verb phrase.
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.
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.
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".
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".
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.
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.
The author doesn't touch on it much, but part of the added complexity is each person thinks differently too.
“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.
“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.
If we figured out the best practice for common GUI cases (ex. in tables, shade every other row light gray), you could hide the complexity from the average program writer and make better decisions for them.
A GUI toolkit is already a set of best practices. Designing one is a difficult matter of balancing convenience with flexibility. Make it too basic and you complicate special cases and impede innovation. Make it too detailed and you force noisy code and wheel reinvention.
Right. I think that's why good toolkits have good default behaviors that you can also easily overwrite through well documented APIs. I think a good abstraction should let you also access the underlying layer for special cases.
An API designed for overriding still suffers from the same compromise. Any particular use case will want to override a specific set of functionality and nothing more. More fine grained overridability means more overhead complexity. Simplicity means you have to override functionality in large units, likely reimplementing most of it.
I know there's application simulation tools , that let business users build a running simulation of an application, and let them improve and test it. from it they can generate more accurate specs for the development teams.
The claimed benefits are quite high: 50% reduction in app specification time , and 75% reduction in development changes.
The claimed benefits are quite high: 50% reduction in app specification time , and 75% reduction in development changes.
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.
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.
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.
Not building this:
http://simpsons.wikia.com/wiki/%22The_Homer%22
with those tools will stay just as hard.
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.
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.
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.
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.
“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.
You can almost express something like that, in SQL.
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?
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?
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.
Design is harder then coding because one has to define the constraints and requirements in which the program has to work.
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...)
Be wary of blanket statements of the form "X will never Y" (unless they break physics, and even then...)
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.
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.
"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.
Yet - but then don't say "never" in your title.
A true AI could probably do stuff like that.
“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.
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.
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"? Easier perhaps, but there will never be a replacement for 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"? Easier perhaps, but there will never be a replacement for expertise.
[deleted]
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.
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.
When we have computers that intelligent, we won't need to write any more programs.
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.