Why 10 years? Given that we've known what a mess the software development world is for 50 years and nothing has improved, what makes you think anything will be better 10 years from now?
Visual-based programming is definitely something that can help more people solve problems, but it gets complex to manage too (or so we've been told by blogs and others).
Perhaps something like visual-based programming would suit a different mindset altogether.
Truth be told though, programmers have managed to solve the website problem with all the new site-builders out there. They all seem to be "drag and drop", which should have been addressed long ago as a standard for at least the frontend.
The last (natively compiled) program I wrote to run on the Windows OS was done using an almost completely visual programming tool called ProGraph [1]. It worked well, and the small cards containing the code made sure you didn't put too much logic in one picture (much like the character limit Forth imposes on its page size). The system lives on as Marten [2], but only supports Mac OSX now.
While there are some things I like about visual programming, there are also many issues - perhaps the biggest is that it lulls the developer into believing they don't need to understand the underlying computer. I think a similar analogy is how a newbie RoR developer can create a CRUD application without ever looking at or understanding the scaffold-generated code.
I've thought about this a lot (in fact, years before I found ProGraph I tried to develop a system I called FloPro which was standard Fortran flow-charts on the front end and generated C (to compile on your local platform) on the backend), but I haven't seen a solution to these problems in any visual programming system.
At the risk of some criticism, I would like to make some visual language comments. I am the author of a visual language programming environment called Marten which supports the Prograph visual language. I use this IDE everyday to write commercial-grade software for clients. Marten is in fact written in Prograph using Marten. I have created software in many other languages such as FORTRAN, RATFOR, C, C++, C#, Objective-C, Java, Perl, Python, along with i386 and PPC assembly, so I am very familiar with the difference between programming in a text-based language and visual programming. I found that visual programming is so superior to using text-based languages that I wrote my own IDE to ensure that I could continue to do so. Consequently, Marten stands as an example that not only is visual-programming not "vaporware", it can be an valuable and powerful addition to a developer's toolkit.
"A relief from the unintuitive, unscalable, unfounded snake oils like OOP, markup, APIs, or the triumvirate of HTML/CSS/JS. As if these technologies are the best we can do."
At first I was mad. Then I read the above quote and everything clicked into place. This article is hilarious and I love every shrill, indignant, purposefully absurd word of it.
I don't think programming should be mainstream, I think software should simple and intuitive enough to let anyone get work done without having to know how to write code.
Hold on a second. OOP, markup, APIs, and HTML/CSS/JS are snake oil, while visual programming isn't? Say what you will about the former technologies, but they're being used for productive purposes. Visual programming is vaporware that someone tries to build every 5 years or so to no effect. Functional programming has much the same challenge, but it's getting integrated into mainstream languages. Otherwise, it would likely still be a research toy as well.
There's a bit of a stereotype about labview that it is graphically beautiful but its not visual programming because it inevitably results in more typing of text than anything else, otherwise you get a bowl of spaghetti. With textual languages you can interpret it to figure it out, perhaps a billion times slower than the computer, but exactly the same. Visual is a little harder to figure out.
Or in summary I've seen large complicated Labview that's totally write once read never.
You might be interested in screenshots from GNURadio. Same effect. Spaghetti bowl of a schematic where a plain text version would be a lot clearer. Google for a simple WBFM radio with squelch and AFC aka your $5 walkman broadcast radio, and you get something that looks like its launching the space shuttle.
I never personally used LabView (well, maybe in a Physics 101 lab in college, but that was a while back). The people using it in the offices I've worked in have generally been electrical engineers, perhaps the schematic view meshes better with their mental model of computation. It seemed to work well on most of the projects.
EDIT: I should add, when I did look at the LabView stuffs, it seemed to make sense to me (as a reader), but I'm not sure how easy or difficult it would have been for me to jump into and start working on after someone else has constructed a lot of parts.
I suspect that of equal importance to the schematic view, for electrical engineers, is the dataflow programming model. Another dataflow based programming tool, albeit non Turing complete, is Excel.
I have thought of excel as the closest real thing we have to visual programming.
Its a shame that it seems to be based on a "grid" rather than a better data structure. I guess that is why it makes sense to most non programers though.
Did I say it was the pinnacle? GGP post suggested that visual programming was vaporware. Perhaps for general purpose programming it is, but visual programming itself is not vaporware.
Visual programming has small niches where it fits well. GUI building for example. Actually the query builder in MS Access wasn't so bad, but it was a choice of learning that or remembering "proper" SQL when I used it. Proper SQL seemed more useful.
Likewise with functional programming. I uses small bits here and there when it is appropriate to write cleaner code. I would struggle to build anything of any size using FP.
I used LabView in college and a couple of other visual programming schemes in my work that have since disappeared, and they all had the same drawbacks: If your needs fit tidily within the assumptions made by the designer, they can be very productive indeed. Once you step a little bit outside of that, they turn into a tortuous mess. Can't even count the number of times I wished I could just write a few lines of code instead of trying to figure out a byzantine way to hook up enough icons that I got my desired end result.
I've always been told by labview advocates that "you can of course pull up a text editor and write code." The language and API is certainly a different matter, being a second class citizen and presumably an afterthought.
LabVIEW and the rest of visual/graphical programming needs to perfect the feature for cleaning the code layout. LabVIEW does a good job about half the time, but the other half results in time wasted to make the code legible. Mathematical formulas look nasty, which results in having to use a "Formula Node"[1]. The other major problem with LabVIEW is the speed at which you program is not much faster after you understand the fastest ways to do things, because you are still limited to how fast you can click and connect nodes.
I don't think we have to worry about "everyone" or even a small percentage thereof learning how to code. They won't. It's not that they can't, but it takes more than a couple of hours writing "Hello World" to do anything substantial and most people are not willing to put in the time, day after day, to learn anything substantial.
That being said, I can't imagine anything more human and more powerful than text. If I want to give instructions to a _human_, the best way I know of is to write them down as clearly as possible. If this works with a complex person, why would it not work with an incredibly simple (from an abstract point of view, not implementation) microprocessor. After all, all processors have an extremely limited set of instructions (even CISC ones).
This desire for something that is not text seems misplaced. After all, text is (IMO) certainly better than pairs of numbers indicating operation and data. Writing is one of the greatest human achievements. To dismiss it in favor of touch or something graphically visual is to disregard its power and superiority to both touch and visual systems of communication.
When designing a system, if I am able to give it commands in English (or any other language), this would be vastly superior to anything visual or touch based that I can think of or that the article specifies (or rather doesn't). To take the whole system of a language like English with its complex idea-expression engine and its vast array of words (1 million++) and discard it is ridiculous. Now, we are not currently programming in English, or anything even remotely close (though many languages' grammar follows from natural language somewhat), but I do believe this is, and has been for decades, a goal that may one day be achievable. This is desirable as humans are naturally inclined towards language and those who practice it can be incredibly good communicators (programmers of reality).
No, they really can't. Garbage in garbage out. Can't implement an algorithm or follow a protocol unless you understand it, and the world is full of people who literally don't understand how a thermostat works, how to drive safely, or how to implement the NRAs three basic rules of gun safety.
Note that our shared enjoyment of text as per your 3rd paragraph is only politically correct WRT to programming... if you dare to suggest text might also be the superior user interface, the dogpile will begin. Which is sad. Closed minds are always weaker than open minds...
Lets play a game, I'm thinking of a well designed, expressive, long lived programming language developed by a linguist... Its dumped on here at HN for no logical reason, just the usual womens fashion fad explanations. I suspect this would happen to any "English like" future programming language.
Men can be fashionable too, it's just typically not as fun for us. I would say most of the time the only reason men are interested in fashion is to become more attractive to women.
Edit: I realize this kind of generalization probably offends people. I'm sorry, I just believe that men and women are fundamentally different from each other. Here's my google search findings on the topic:
I should have been more clear in my writing as I did not mean to suggest most people could program, but that even smart people with the potential to learn it (a very small percentage) generally are not interested in investing the time.
I agree, text (reading and writing) is definitely a dying art, especially in America, although to me it seems to be part of the whole anti-intellectual culture brewing here and in other parts of the world.
I don't the author understands programming if he sees object-oriented programming as being in the same bucket as HTML/CSS/JS. OOP is a way to deconstruct problems, just like functional programming, and their beginnings are based on very similar principles.
Any language that fully accepts the object-oriented paradigm lends itself very naturally to functional programming, and vice-versa.
Uh. What? Fully accepting the object-oriented paradigm does not make a language any more likely to properly isolate state and side effects[1], any more likely to have immutability as a default assumption, or any more likely in any other way to encourage referential transparency. As referential transparency is the essence of functional programming, this makes your claim very confusing.
[1] Following OOP design patterns makes a given program more likely to properly isolate state, but this is by no means a virtue of OOP languages.
This blog post would have been way better without the ranting style of writing.
It doesn't even get to the point (that programming does not have to be text-based) until halfway into the article.
The title and the objection to other people learning to code are at most tangentially related to that point. Just because there could be better ways to give instructions to machine doesn't mean other people should wait to learn how to instruct machines until those methods are developed.
> "Programming is a notion to extend human capability, by offloading humanly-infeasible work onto a machine. It is the promise of an amplified knowledge worker. This would be worthy to learn."
With this (correct) notion the author continues until he decides that
> "Meanwhile there are few souls looking to evolve text code into something more humanly intuitive. For example something you can touch, you don’t have to read, or that tells you what the computer is thinking, so you don’t have to think like a computer yourself."
I can't help but feel that what the author really wants is some futuristic kind of AI assistant. Decades of programming progress has resulted in numerous abstractions piled on top of one another in order to minimize the amount of "thinking like a computer" that you have to do. But all abstractions are leaky and when you encounter those leaks you will inevitably have to be able to think like the machine you are trying to communicate with.
Why is it acceptable to say that effective communication with people depends on being able to think like the person you're talking to, but demand that communication with a far more different and limited machine should never require you to compromise on your preferred thought patterns? This is the fundamental fallacy of the natural language programming advocates. They want to use another entity to do things for them but demand all communication with that entity be in their preferred language, on their own terms.
> Why is it acceptable to say that effective communication with people depends on being able to think like the person you're talking to, but demand that communication with a far more different and limited machine should never require you to compromise on your preferred thought patterns?
Other people are sentient beings with their own personalities, dreams, desires, and attitudes. Recognition of our shared humanity necessitates some level of compromise, respect, and accommodation when dealing with other individuals.
In contrast, computers are unfeeling machines. We made them, and within the limits of physics, math, and our own creative powers, we can make them do whatever we wish. Why shouldn't we strive to make them as accommodating as possible? Why shouldn't I try to create a machine that intuitively corrects my mechanical errors to represent the shape of my ideas?
There's nothing wrong with trying. There is, however something wrong (or at least irritating) with demanding that it magically become like that, without trying, or contributing any insight into how to achieve it.
Is the entire premise of Neuro-Linguistic Programming (NLP) not that you can influence people's thought patterns by using language as code, as instructions?
That's basically my impression, but my understanding is that NLP is not very strongly supported so I'd be leery about using theories from there as if they provided much evidence about the world.
I don't think you need to get so vague though - if you want to communicate a task to a human, you very explicitly use language most of the time (particularly for anything complex). They may not follow your instructions for whatever reason, but the act of communication is done with text.
When I saw the title, I thought it was, "Come back after you practiced for 10 years" which doesn't help much.
I used to think the solution was better interfaces, or making programming more accessible to the lay person. I get less sure of this over time. It seems like what we've gained in language ease of use (Python versus C) we've given back in environmental complexity. The net is better productivity for programmers, and more people crossing the divide (CS programs growing by leaps and bounds) but we're far from being there for the Everyperson. I don't see this changing in 10 years without increasing the rigor and logic requirements of our entire educational system.
"All of the blood sweat and tears poured into making programming more productive over the years just isn't good enough. No, I haven't done anything, personally, to improve the situation. My plan is to continue bitching about how things aren't good enough until...well, indefinitely, because bitching about other people's efforts is much easier than doing the hard work of solving a challenging problem myself."
Is that too harsh? I don't see a single concrete, actionable proposal in there, let alone anything the author has personally done to fix the sorry state of programming.
I also think it's a huge disservice for him to dissuade his friends from programming until some state of nirvana is reached in programming tools. There are some hurdles to overcome, but a little bit of programming skill can greatly amplify the reach, scope and influence of non-programming talents.
You got my upvote. I can't understand the point of view expressed in this article at all. I particularly can't understand the claim that the accessibility hasn't improved.
Yesterday I implemented a couple of different machine learning algorithms on some test data using python and sklearn. Now, I'm just noob - but there is no way I could have that quickly implemented a machine learning algo on some data 10 years ago. It would have literally taken me months to do the equivalent thing rolling everything myself. And even then my code would have probably taken several days to run for any dataset of any reasonable size because I wouldn't have a clue how to build numpy's optimised data arrays etc...
Plus all this code is just given away... for free... no questions asked. It's so unbelievably awesome it boggles my mind.
So yeah - I don't get why this author is giving all that it's due. It really deserves a crap tonne of due. y'know?
I like your reading better. I would have liked the blog better if it had had more of the feeling of humbleness that your words have.
The blog felt like it was saying "shut up till you do something better" where it should have said "Imagine how cool it would be to do something better".
A humble approach is always nice, its always challenging to give an earnest opinion ( after all that's why I read your content, for your opinions) and be openly modest. your (authors) terminology in differentiating programmers form coders is different from my own 'naming'. My wording are often around application development vs systems programming. a sys programmer writes software for humans to control machines ( databases, OS's,tools) where as an app developer is focused on software (computers) that controls humans ( apps that constructively shape human actions) . I liked the article , good post.
I totally understand the viewpoint though that there were 0 solutions in the article. A rant like that is off-putting. Still, I felt it worthwhile to bring awareness to the, ah, malarkey in programming.
The issue with every Visual programming language I have used is that while it is easier to learn for beginners, it is almost always faster to type once you start to understand programming.
I think the author should read Fred Brooks's "No Silver Bullet". Many of his arguments are still valid after 28 years. "There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity."
"No Silver Bullet" reminds me of the physicists at turn of century claiming that Newtonian physics held all of the answers. He blames the issues in software engineering on bad programmers, instead of questioning his field. His narrow minded, defeatist arguments fail to recognize the full potential of computer science. I don't buy his argument that Java or JavaScript have eliminated most of the accidental complexity in programming. It's like Von Neumann claiming, “I don’t see why anybody would need anything other than machine code.
Computer Science is still in its infancy. We haven't reached the full potential of Von Neumann architecture, let alone the dozens of non-Von Neumann systems that have been largely ignored by academia. Recent advances in neuroscience may open up a whole new model for information processing, such as IBM's SyNAPSE project.[1] Have you watched Bret Victor's, "The Future of Programming"?[2] He does a wonderful job of countering many of Fred Brooks's points.
Yes I have watched Bret Victor's talk. Narrow minded or not, Brooks's predictions held true for more than a decade after the time of writing. I'd like to read your counter-arguments.
I'd say architecture and advances in neuroscience are tangential here. I think the core of the problem is still somewhere else.
* sidenote: Lisp machines weren't at least completely _ignored_ by academia.
There is a reason we speak and write words to communicate complex ideas rather than hold up pictures. Words are powerful and flexible. They are not going away.
That type of question is where a lot of things go wrong. Newbies ask that because they don't have the experience to break it into smaller parts, experienced people get tripped up because they can't see past the "well, what type of website doing what?"--all the while the question is "what would you use it for?".
It's a bad question, because the asker doesn't know enough to ask a useful one. Our job, then, is to help them learn how to ask the right question.
For anyone interested in the prospect of visual programming for web development, please join our newsletter at crudzilla.com ... we are coming out with an update that will attempt to fit a wordpress-like plugin system into an IDE. We think that'll be a good start for a more visually oriented development environment.
I agree with the author in regards to coding web sites. It's not enough to know a just a few languages, there's a whole frickin' vocabulary of crap piled on layers of services and frameworks frosted by the JS flavor of the week.
Or just configuration. Everybody wants to reinvent Make and they all do it wrong...
Just because something is hard doesn't mean it's broken. Nobody would say that say, advanced mathematics is broken because the layman doesn't get it.
My bullshit detector notes that he talks very generally about "knowledge workers leveraging machines". The problem with the phrase "knowledge worker" is it often means "person who sends lots of emails". You don't need to be a programmer to send lots of emails.
Real "knowledge workers", like, the kind of people that actually are working to extend human knowledge and need computers to do it, largely do know how to program to some degree (IE, scientists and mathematicians and so on). A lot of it isn't "professional" grade, but it works well enough for them and it keeps getting better.
Also a tangent: but I'm sick of the whole "coding is literacy" nonsense. Not everyone needs to code. Literacy unlocks centuries worth of knowledge in any domain you want, from contemporary thinkers to people who are long dead. Coding lets you tell a computer how to do specialized things. It's not even remotely comparable.
Exactly. Life is hard. Business is hard. Coding doesn't eliminate work, it just enables new kinds of work. And, it's like coding an app that makes money isn't completely effortless but it is obviously possible.
Coding != literacy. In fact, not everyone needs to go to college either and can still make a living. Mike Rowe's trades-awareness work is fantastic: http://profoundlydisconnected.com/ There are many trades where the average age is 50 because no one wants to be seen as blue collar. Some of these are high income opportunities that are being missed because they're not mainstream fashionable.
> Nobody would say that say, advanced mathematics is broken because the layman doesn't get it.
We do make math more tractable and accessible over time with various reformulations and new abstractions and conceptual tools, though. You're probably using arabic numerals when you do arithmetic, and there are good reasons for that.
(Though heaven knows, if I'm likely to run across an abacist anywhere in this sort of discussion, it's probably here. :)
but in the end, most people can't understand vector calculus, just like most people cant understand programming no matter how easy you make the syntax, the concepts themselves can be hard to grasp.
I wouldn't say it is easier (or harder), I would say it is different. Before you were having to remember lots of tricks to fit as much information into as little memory as possible. Today we have lots more stuff to remember. Operating systems are way more complex.
At the end of the day, most people are programming at a far higher level, so things are more productive. I have produced a reasonably sophisticated databases / web front end for my work, in Django as a one man team. Ten years ago I believe that it would have taken far more man hours to achieve the same thing. I don't have to remember tricks to compress data, as disk space is cheap now. I do have to know reasonably advanced SQL, and remember a lot about how Django works.
Woodworking is hard. The more you know and the better your toolchain, the better your projects and experience.
At one time, woodworking was incredibly relevant, so there was a good payoff for dabbling in it and you'd have a few tools and get "okay" or "pretty good" without becoming a professional wood worker.
Today wood working is irrelevant, so very few learn it.
The author is frustrated by a real and frustrating problem, but he's missing why things are this way.
The "triumvirate of HTML/CSS/Javascript" isn't just a technology. It's a social consensus. It's not actually "designed" in a meaningful sense -- it's evolved.
And things pretty much need to be this way, unless you want to be an island. Even if you have the ambition and the resources to throw it all away and "do it right" from scratch, by the time you finish the world will have moved on and your perfect gem will be obsolete. Real technology is always iterative.
The same constraints apply to programming languages in general, because they truly are languages that human beings use for thinking. Languages and their associated cultures can only evolve so fast. It's not really a technical issue, it's a social issue.
The author's assertion that our "arcane" interfaces persist out of a kind of perverse pride just doesn't ring true to my experience. Programmers cry tears of joy when they get to throw away something old and arcane because they don't need it anymore. And his assumption that visual programming will necessarily be better than textual programming is completely unproven.
Anyone who could actually make programming easy would reap vast wealth. The incentive is there. If it's really a no-brainer to build visual programming tools, well, where are they? There must be something harder about it than you think if we're still waiting.
An interesting thought about evolution is that text-based programming languages are exquisitely evolve-able, because the technology and effort to evolve a language or create a new one aren't too far out of our reach. If you don't care too much about efficiency, you can create a new language from an old one, and pass it around for others to try out.
This may be why there are 100's of text based languages, but I can think of only one graphical language -- LabVIEW -- in widespread use. LabVIEW requires a monumental organization to maintain. Adding a structural feature to the language, requires changing the entire GUI, menus, and so forth.
I suspect that if LabVIEW came out with a text based option for dataflow programming with support for their massive libraries, folks would abandon the graphical interface.
Maybe graphical isn't always better. Maybe text is really the best way to express programs after all. We could wait for programming to become "intuitive," or learn to develop our intuitions.
An anecdote about graphical systems. When I read tutorials for Windows, it's usually a lot of text interspersed with pictures of windows and dialogs. Even videos. Walking someone through a process over the phone is excruciating.
The same process using Linux: Open the terminal and enter this text.
In fact, Windows tutorials are starting to use: Press the start button and enter some text. I find the device manager by entering "device manager" into the start button menu, not by following an "intuitive" GUI.
Perhaps coding will look like minecraft, where you dig physical paths for the water, for the chickens, and hunt down bugs with bows and arrows. Modern tablets with no keyboards do minecraft just fine (my 8 year old and all his friends are completely addicted to minecraft). Also, they can join lan games, and work in the same virtual world. This may allow multiuser programming, no? Weird thoughts. They won't call it programming either, they'll call it something like flowcraft or some such.
I think this type of a concept is what the author is driving at. We shouldn't be manipulating blocks of words, we should be manipulating what those blocks of words create into making even bigger things.
96 comments
[ 3.3 ms ] story [ 147 ms ] threadPerhaps something like visual-based programming would suit a different mindset altogether.
Truth be told though, programmers have managed to solve the website problem with all the new site-builders out there. They all seem to be "drag and drop", which should have been addressed long ago as a standard for at least the frontend.
While there are some things I like about visual programming, there are also many issues - perhaps the biggest is that it lulls the developer into believing they don't need to understand the underlying computer. I think a similar analogy is how a newbie RoR developer can create a CRUD application without ever looking at or understanding the scaffold-generated code.
I've thought about this a lot (in fact, years before I found ProGraph I tried to develop a system I called FloPro which was standard Fortran flow-charts on the front end and generated C (to compile on your local platform) on the backend), but I haven't seen a solution to these problems in any visual programming system.
[1] http://en.wikipedia.org/wiki/Prograph [2] http://www.andescotia.com/products/marten/
Were you only able to build it by writing code itself?
At first I was mad. Then I read the above quote and everything clicked into place. This article is hilarious and I love every shrill, indignant, purposefully absurd word of it.
I believe that's an example of visual/graphical programming, it's fairly mainstream in some areas and not vaporware.
Re: Rest of comment - Filtered site, I'll read it at home.
Or in summary I've seen large complicated Labview that's totally write once read never.
You might be interested in screenshots from GNURadio. Same effect. Spaghetti bowl of a schematic where a plain text version would be a lot clearer. Google for a simple WBFM radio with squelch and AFC aka your $5 walkman broadcast radio, and you get something that looks like its launching the space shuttle.
EDIT: I should add, when I did look at the LabView stuffs, it seemed to make sense to me (as a reader), but I'm not sure how easy or difficult it would have been for me to jump into and start working on after someone else has constructed a lot of parts.
To guide intuition without making things tediously formal, most things that can go into an infinite loop are Turing equivalent.
Its a shame that it seems to be based on a "grid" rather than a better data structure. I guess that is why it makes sense to most non programers though.
Likewise with functional programming. I uses small bits here and there when it is appropriate to write cleaner code. I would struggle to build anything of any size using FP.
[1]:http://zone.ni.com/reference/en-XX/help/371361K-01/lvconcept...
That being said, I can't imagine anything more human and more powerful than text. If I want to give instructions to a _human_, the best way I know of is to write them down as clearly as possible. If this works with a complex person, why would it not work with an incredibly simple (from an abstract point of view, not implementation) microprocessor. After all, all processors have an extremely limited set of instructions (even CISC ones).
This desire for something that is not text seems misplaced. After all, text is (IMO) certainly better than pairs of numbers indicating operation and data. Writing is one of the greatest human achievements. To dismiss it in favor of touch or something graphically visual is to disregard its power and superiority to both touch and visual systems of communication.
When designing a system, if I am able to give it commands in English (or any other language), this would be vastly superior to anything visual or touch based that I can think of or that the article specifies (or rather doesn't). To take the whole system of a language like English with its complex idea-expression engine and its vast array of words (1 million++) and discard it is ridiculous. Now, we are not currently programming in English, or anything even remotely close (though many languages' grammar follows from natural language somewhat), but I do believe this is, and has been for decades, a goal that may one day be achievable. This is desirable as humans are naturally inclined towards language and those who practice it can be incredibly good communicators (programmers of reality).
No, they really can't. Garbage in garbage out. Can't implement an algorithm or follow a protocol unless you understand it, and the world is full of people who literally don't understand how a thermostat works, how to drive safely, or how to implement the NRAs three basic rules of gun safety.
Note that our shared enjoyment of text as per your 3rd paragraph is only politically correct WRT to programming... if you dare to suggest text might also be the superior user interface, the dogpile will begin. Which is sad. Closed minds are always weaker than open minds...
Lets play a game, I'm thinking of a well designed, expressive, long lived programming language developed by a linguist... Its dumped on here at HN for no logical reason, just the usual womens fashion fad explanations. I suspect this would happen to any "English like" future programming language.
Very classy, dude.
Edit: I realize this kind of generalization probably offends people. I'm sorry, I just believe that men and women are fundamentally different from each other. Here's my google search findings on the topic:
http://www.lloydianaspects.co.uk/evolve/fashion.html
I agree, text (reading and writing) is definitely a dying art, especially in America, although to me it seems to be part of the whole anti-intellectual culture brewing here and in other parts of the world.
Perl?
Any language that fully accepts the object-oriented paradigm lends itself very naturally to functional programming, and vice-versa.
[1] Following OOP design patterns makes a given program more likely to properly isolate state, but this is by no means a virtue of OOP languages.
It doesn't even get to the point (that programming does not have to be text-based) until halfway into the article.
The title and the objection to other people learning to code are at most tangentially related to that point. Just because there could be better ways to give instructions to machine doesn't mean other people should wait to learn how to instruct machines until those methods are developed.
With this (correct) notion the author continues until he decides that
> "Meanwhile there are few souls looking to evolve text code into something more humanly intuitive. For example something you can touch, you don’t have to read, or that tells you what the computer is thinking, so you don’t have to think like a computer yourself."
I can't help but feel that what the author really wants is some futuristic kind of AI assistant. Decades of programming progress has resulted in numerous abstractions piled on top of one another in order to minimize the amount of "thinking like a computer" that you have to do. But all abstractions are leaky and when you encounter those leaks you will inevitably have to be able to think like the machine you are trying to communicate with.
Why is it acceptable to say that effective communication with people depends on being able to think like the person you're talking to, but demand that communication with a far more different and limited machine should never require you to compromise on your preferred thought patterns? This is the fundamental fallacy of the natural language programming advocates. They want to use another entity to do things for them but demand all communication with that entity be in their preferred language, on their own terms.
Other people are sentient beings with their own personalities, dreams, desires, and attitudes. Recognition of our shared humanity necessitates some level of compromise, respect, and accommodation when dealing with other individuals.
In contrast, computers are unfeeling machines. We made them, and within the limits of physics, math, and our own creative powers, we can make them do whatever we wish. Why shouldn't we strive to make them as accommodating as possible? Why shouldn't I try to create a machine that intuitively corrects my mechanical errors to represent the shape of my ideas?
I don't think you need to get so vague though - if you want to communicate a task to a human, you very explicitly use language most of the time (particularly for anything complex). They may not follow your instructions for whatever reason, but the act of communication is done with text.
I used to think the solution was better interfaces, or making programming more accessible to the lay person. I get less sure of this over time. It seems like what we've gained in language ease of use (Python versus C) we've given back in environmental complexity. The net is better productivity for programmers, and more people crossing the divide (CS programs growing by leaps and bounds) but we're far from being there for the Everyperson. I don't see this changing in 10 years without increasing the rigor and logic requirements of our entire educational system.
"All of the blood sweat and tears poured into making programming more productive over the years just isn't good enough. No, I haven't done anything, personally, to improve the situation. My plan is to continue bitching about how things aren't good enough until...well, indefinitely, because bitching about other people's efforts is much easier than doing the hard work of solving a challenging problem myself."
Is that too harsh? I don't see a single concrete, actionable proposal in there, let alone anything the author has personally done to fix the sorry state of programming.
I also think it's a huge disservice for him to dissuade his friends from programming until some state of nirvana is reached in programming tools. There are some hurdles to overcome, but a little bit of programming skill can greatly amplify the reach, scope and influence of non-programming talents.
Yesterday I implemented a couple of different machine learning algorithms on some test data using python and sklearn. Now, I'm just noob - but there is no way I could have that quickly implemented a machine learning algo on some data 10 years ago. It would have literally taken me months to do the equivalent thing rolling everything myself. And even then my code would have probably taken several days to run for any dataset of any reasonable size because I wouldn't have a clue how to build numpy's optimised data arrays etc...
Plus all this code is just given away... for free... no questions asked. It's so unbelievably awesome it boggles my mind.
So yeah - I don't get why this author is giving all that it's due. It really deserves a crap tonne of due. y'know?
The blog felt like it was saying "shut up till you do something better" where it should have said "Imagine how cool it would be to do something better".
Computer Science is still in its infancy. We haven't reached the full potential of Von Neumann architecture, let alone the dozens of non-Von Neumann systems that have been largely ignored by academia. Recent advances in neuroscience may open up a whole new model for information processing, such as IBM's SyNAPSE project.[1] Have you watched Bret Victor's, "The Future of Programming"?[2] He does a wonderful job of countering many of Fred Brooks's points.
[1] https://www.research.ibm.com/cognitive-computing/neurosynapt...
[2] http://worrydream.com/dbx/
I'd say architecture and advances in neuroscience are tangential here. I think the core of the problem is still somewhere else.
* sidenote: Lisp machines weren't at least completely _ignored_ by academia.
"Can’t I just make a website?"
That type of question is where a lot of things go wrong. Newbies ask that because they don't have the experience to break it into smaller parts, experienced people get tripped up because they can't see past the "well, what type of website doing what?"--all the while the question is "what would you use it for?".
It's a bad question, because the asker doesn't know enough to ask a useful one. Our job, then, is to help them learn how to ask the right question.
Or just configuration. Everybody wants to reinvent Make and they all do it wrong...
My bullshit detector notes that he talks very generally about "knowledge workers leveraging machines". The problem with the phrase "knowledge worker" is it often means "person who sends lots of emails". You don't need to be a programmer to send lots of emails.
Real "knowledge workers", like, the kind of people that actually are working to extend human knowledge and need computers to do it, largely do know how to program to some degree (IE, scientists and mathematicians and so on). A lot of it isn't "professional" grade, but it works well enough for them and it keeps getting better.
Also a tangent: but I'm sick of the whole "coding is literacy" nonsense. Not everyone needs to code. Literacy unlocks centuries worth of knowledge in any domain you want, from contemporary thinkers to people who are long dead. Coding lets you tell a computer how to do specialized things. It's not even remotely comparable.
Coding != literacy. In fact, not everyone needs to go to college either and can still make a living. Mike Rowe's trades-awareness work is fantastic: http://profoundlydisconnected.com/ There are many trades where the average age is 50 because no one wants to be seen as blue collar. Some of these are high income opportunities that are being missed because they're not mainstream fashionable.
We do make math more tractable and accessible over time with various reformulations and new abstractions and conceptual tools, though. You're probably using arabic numerals when you do arithmetic, and there are good reasons for that.
(Though heaven knows, if I'm likely to run across an abacist anywhere in this sort of discussion, it's probably here. :)
People who think that programming is not dramatically easier today than ten years ago just have a short memory. Or they're 25 years old...
At the end of the day, most people are programming at a far higher level, so things are more productive. I have produced a reasonably sophisticated databases / web front end for my work, in Django as a one man team. Ten years ago I believe that it would have taken far more man hours to achieve the same thing. I don't have to remember tricks to compress data, as disk space is cheap now. I do have to know reasonably advanced SQL, and remember a lot about how Django works.
Woodworking is hard. The more you know and the better your toolchain, the better your projects and experience.
At one time, woodworking was incredibly relevant, so there was a good payoff for dabbling in it and you'd have a few tools and get "okay" or "pretty good" without becoming a professional wood worker.
Today wood working is irrelevant, so very few learn it.
So it is with programming.
The "triumvirate of HTML/CSS/Javascript" isn't just a technology. It's a social consensus. It's not actually "designed" in a meaningful sense -- it's evolved.
And things pretty much need to be this way, unless you want to be an island. Even if you have the ambition and the resources to throw it all away and "do it right" from scratch, by the time you finish the world will have moved on and your perfect gem will be obsolete. Real technology is always iterative.
The same constraints apply to programming languages in general, because they truly are languages that human beings use for thinking. Languages and their associated cultures can only evolve so fast. It's not really a technical issue, it's a social issue.
The author's assertion that our "arcane" interfaces persist out of a kind of perverse pride just doesn't ring true to my experience. Programmers cry tears of joy when they get to throw away something old and arcane because they don't need it anymore. And his assumption that visual programming will necessarily be better than textual programming is completely unproven.
Anyone who could actually make programming easy would reap vast wealth. The incentive is there. If it's really a no-brainer to build visual programming tools, well, where are they? There must be something harder about it than you think if we're still waiting.
This may be why there are 100's of text based languages, but I can think of only one graphical language -- LabVIEW -- in widespread use. LabVIEW requires a monumental organization to maintain. Adding a structural feature to the language, requires changing the entire GUI, menus, and so forth.
I suspect that if LabVIEW came out with a text based option for dataflow programming with support for their massive libraries, folks would abandon the graphical interface.
Maybe graphical isn't always better. Maybe text is really the best way to express programs after all. We could wait for programming to become "intuitive," or learn to develop our intuitions.
An anecdote about graphical systems. When I read tutorials for Windows, it's usually a lot of text interspersed with pictures of windows and dialogs. Even videos. Walking someone through a process over the phone is excruciating.
The same process using Linux: Open the terminal and enter this text.
In fact, Windows tutorials are starting to use: Press the start button and enter some text. I find the device manager by entering "device manager" into the start button menu, not by following an "intuitive" GUI.
Perhaps coding will look like minecraft, where you dig physical paths for the water, for the chickens, and hunt down bugs with bows and arrows. Modern tablets with no keyboards do minecraft just fine (my 8 year old and all his friends are completely addicted to minecraft). Also, they can join lan games, and work in the same virtual world. This may allow multiuser programming, no? Weird thoughts. They won't call it programming either, they'll call it something like flowcraft or some such.