I just caught myself sending 4 tweets in a row on the same subject. That's probably a sign I have a blog entry topic at my finger tips.
I was reading an article entitled "Microsoft's top developers prefer old-school coding methods". Whoever picked that title clearly missed the point of the panel discussion he was covering, but it's an awesome read.
The panel involved a handful of distinguished engineers from Microsoft and they were discussing the future of programming technologies. And hilarity ensued! It reminded me so much of the discussion we had about JavaScript at the end of the Ottawa Eclipse DemoCamp last week. There was much hilarity ensuing there as well.
At any rate, I totally agree with what these guys are saying. Everything we're doing to innovate in programming around graphical programming languages and concurrent programming is crap. Here's some of my favorite quotes from the article:
re graphical programming: "when you have 500 things, graphical programming is completely unusable. You zoom in and zoom out and you lose all context. I think it's just smoking dope." (a similar comment was made about using JavaScript to build complete apps at the Camp).
re managed code: "lets developers perform above their level of competence. It's like antilock brakes". (They were talking about CLR, but I'd include Java in that).
re abstractness: "programming is getting so abstract, developers will soon have to use Microsoft's Natal to write programs through interpretive dance." (That I don't want to see).
But the one quote that really confirmed what I had been thinking about multi-core programming: "It will be a long time before parallel programming becomes mainstream. Because of the bias towards sequention programming, we'll still be reinventing ourselves as parallel programmers 12 years from now."
This was a classic Ward Cunningham "A-ha" moment for me. I had hoped graphical programming could be an answer to break the sequential rut we're stuck in. But the usability of building complex programs graphically kills that. I think at the end of the day, we still need to look at hardware description languages such as Verilog and SystemC as holding the key. They are all about concurrency since the hardware they model is too.
Very interesting.
ReplyDeleteI've always doubted that graphical languages would ever catch on for general purpose programming. For small domain specific languages it can be useful, but to replace C, C++, Java etc... I don't see that ever happening.
I think that IDE's provide a good compromise between text and graphical. The base representation of the language is text files like Java and XML, and you do your coding by editing those files. But the tool provides you with alternative graphical representations of the structure of that text like the outline view, type hierarchy, semantic highlighting, etc. This always felt very natural and very productive to me, and its a big reason why I decided to work on Eclispe.
Very true. I guess a parallel (sorry for the pun) could be made between books and movies. If you're in a hurry and don't care much about the details, you watch the movie. If you really want to get involved in the story, you need to read the book. Capturing complex ideas in text is just way more efficient.
ReplyDeleteWhat bothers is that text is linear and implies a sequence. It'll be hard to break our habit of thinking that way when writing code. Mind you, the Verilog guys have been fighting that forever and seem to be successful at it.
I don't think that text necessarily implies sequence, especially when you read sentences that are based in predicate logic. For example, if you read the sentence "Apples and poppies are red", there is no ordering implied in the relationship between apples and poppies. Sure, you have to read it in sequence by nature, but the logic of the sentence has no sequence attached to it.
ReplyDeleteSo, I think that it is possible to have a language in which each statement is independent without any temporal relationship implied in its spacial relationship to other statements. Maybe a data-flow language of some sort? Temporal relationships would be implied by the availability of data. You could do it in a way that is actually quite similar to languages that we are used to:
PROCESS_A(PROCESS_B(), PROCESS_C(), DATA_A);
PROCESS_D();
In such a case, PROCESS_A and PROCESS_D would attempt to run in parallel, but A would have to wait for the data from B and C to be finished. Both B and C would run in parallel as well. The paradigm shift comes in when you consider the data to be the center of your program rather than the process. Statements can run at any time, but only when the data that they require is available. For practical purposes, this parallelism might be too fine-grained because it could become a scheduling nightmare, but there isn't a problem with it theoretically.
Doug, you appear to justify your bias toward textual programming based on these MS distinguished engineers. It is also feasible that this next-generation programming languages may not resemble its predecessors in any way other than performing advanced functionality - similar to the way the transistor was not a ‘state-of-the-art’ vacuum tube? What is so special about systems representation from all other domains of practice that can be expressed in the visual realm? Perhaps the right graphical programming language just has not been invented as of yet?
ReplyDelete@corecubist: As new graphical programming languages come along I'll be more than happy to evaluate them. What this panel did for me was change my perspective to a more realistic pragmatic one. With that, I agree with their conclusion.
ReplyDeleteIt's hard not to consider the evolution of hardware description languages from schematics to textual languages and wonder why they abandoned graphical representations. I just worry that graphical representations don't scale as well as text.
@Del: I think you're on the right track. We use declarative languages every day for setting up configurations (e.g. xml files). I think the data flow paradigm is where we need to head and I draw a lot of inspiration from UML Actions for that. The trick will be coming up with a clean syntax.
There are few situations where true parallel programming techniques are really required - and it's mostly when dealing with large data sets that are only processed pretty much on super computers (e.g. animation generation farms, scientific data analysis).
ReplyDeleteMost programmers could simply learn to do better with event-driven programming, and learning when and how to spin threads off to handle the various events. Thus far, I've found that Qt really has the best paradigm to do this, and makes it easy to do in the process, all in C++.
I believe that functional, stateless programming (take Haskell for example) is a possible way to go.
ReplyDelete>I just worry that graphical representations don't scale as well as text.
ReplyDeleteThis concern will melt away when the right graphical paradigm comes along. Won't be UML or data-flow either. There has been dozens of data-flow languages over the years and all get cornered into a specific domain and have not generalized. Haskell and other functional languages? Maybe for a finite problem set, but the semantic model is not aligned with the way most people break problems down.