Manifesto of the Programmer Liberation Front

This Manifesto is deprecated. My views have evolved, and a new version will be released “real soon now”.

Compared to every other field of design and engineering, programming is an embarrassment and a failure. The “software crisis” has dogged us from almost the beginning. We who have made programming our life will no longer tolerate this.

Language matters

Programming languages are the fundamental technology of programming. To make fundamental improvements in programming you need a fundamentally better programming language.

History is not over

There is a widespread belief in both industry and academia that working on new programming languages is pointless. This is short-sighted. Historically, all sciences and technologies undergo revolutionary change. The lack of meaningful progress in the last 20 years means that there is an enormous pent-up potential for change, and the lack of interest in it means there is an enormous opportunity for the intrepid. It is a good time for a revolution.

It’s usability, stupid

Programming is so hard that only highly talented, trained, and dedicated individuals can do it passably well. The inescapable conclusion is that programming as we know it is just unnatural for humans. The solution is to reinvent programming to suit human cognitive skills – to program the way we think. This is a matter of usability. The sad fact is that modern programming languages are usability disasters, full of design mistakes inherited from earlier eras.

Power to the people

The first principle of usability is to know the user. The vast majority of programmers are those building end-user applications, and the even greater population of potential programmers are the end-users themselves. This kind of programming is hard not because of sophisticated algorithms and data structures, but rather because of the overwhelming multiplicity of simple constructions. Application programming is where the most people stand to benefit the most. Kernel coders and compiler writers can stick with C.

Development is adaptation

To make programming languages more usable, we must ask how they are used. In practice, programming is rarely development from scratch, but the adaptation of existing code to new needs. Development from scratch is generally a last recourse due to the inability to adapt existing code. The fragility of code to changes in design and intention is one of the most appalling failures of programming, and one of the most visible to outsiders.

Extreme Programming is a movement to adjust our methodologies and practices to the reality of adaptation. Refactoring is a technique to build support for adaptation into IDEâ€™s. The logical next step is to build adaptability into programming languages themselves. Programming languages have often been designed, and are still largely taught, under the naïve illusion that programming consists of first specifying behavior and then implementing it. OO inheritance provides a little improvement, but is increasingly acknowledged to be fragile and inadequate. We need an Extreme Programming Language.

To fully embrace adaptation as the essence of programming will require a change of attitude that is quite difficult: discarding elegant yet fragile constructions in favor of messy but flexible ones. One case in point is copy-and-paste programming. This violates all the accepted rules of modularity and hygiene, yet everyone still does it routinely. Either most programmers are stupid and evil, or the accepted rules are idealistic and impractical. The latter is the case. It is necessary to embrace copy-and-paste as a first-class “semi-modularity” mechanism in the language to track it, manage it, and eventually refactor it into proper modularity. This may be heretical, yet an honest appraisal of how programmers really work requires something like it. Usability is a subversive idea.

Text is a dead-end

Programming is stuck in an evolutionary dead-end: the use of character strings to encode programs. Every other computer-mediated form of expression has evolved beyond text into sophisticated WYSIWYG interfaces to complex data structures. For example, no one still uses textual markup for word processing (except, notably, Computer Scientists with TeX). We need WYSIWYG programming.

It’s called “code” for a reason

Programming languages are built upon two basic tricks: the use of grammars to encode tree structures (AST’s) into text, and the use of names to encode linkages across these trees. Much of what makes a language unique is its particular style of name resolution, as in the polymorphism and inheritance techniques of OO languages. Text is a dead-end because all these sophisticated techniques in one way or another are just encoding structure in text strings. This is disastrous for usability.

Structure needs to be made explicit and directly manipulable, not implicit and encoded. Mentally parsing and interpreting this implicit structure is an enormous cognitive burden for the programmer. Modern IDE’s such as Eclipse go to great lengths to extract the encoded structure back out of the text and help us to visualize and manipulate it somewhat more directly. Refactorings are provided by the IDE to automate the complex and widespread changes in syntax necessary to effect simple semantic changes. This is absurd. We should manipulate semantic structures directly through a WYSIWYG interface. The language is the IDE.

Much of what we know about programming language design is about clever ways to encode structure in text, and fancy ontologies to rationalize naming. Discarding the textual representation suddenly makes all this irrelevant, and opens a whole new space of design choices. Some who are invested in the status quo will see this as a threat and become counter-revolutionaries.

Visual languages are not the solution

Prior and ongoing attempts to evolve beyond textual programming have focused on Visual Programming. The common idea is to replace AST structures with some form of graphical diagram. While well-intentioned, nothing compelling has yet resulted from this approach, and it is widely seen as a failure. The reason may be that it does not go far enough, merely substituting a different surface representation for the same old semantics (and generally retaining even the surface syntax of names). These semantics are highly evolved to suit textual representations, so it is not a surprise that merely altering the surface representation does not help. We need to simultaneously rethink both the syntax and the semantics of programming languages to break out of the current deadlock.

Programming is not Mathematics

Many usability failures of programming languages are due to the pernicious idea that programming should be like mathematics. The need to discard unrealistic expectations of mathematical elegance has already been discussed.

Expressions do not scale

In Science and Math, formulas are typically one-liners. Even small programs are far larger than any mathematical statement. Expression-based languages attempt to scale up formulas to hundreds or thousands of lines. One reason this does not work is that people can not easily handle more than about 2 levels of nesting. We are not stack machines! Natural languages rely on linear narrative flow and avoid deep nesting. This may be the real problem with LISP: people complain about parentheses, but they are really complaining about deep nesting.

Featureless structures do not scale

Argument lists become difficult to use beyond about 2 or 3 arguments. Even in math, operators and functions of arity more than 2 are rare. English verbs take at most 4 arguments. It is absurd to expect humans to remember large function/method signatures purely by argument order. The simple expedient of keyword arguments is lacking in most languages. This fact reveals a shocking disregard by programming language designers of even the most basic considerations of usability. What can they be thinking?

Terseness bad

Terseness is prized in Math and Science. While being able to write Quicksort in 3 lines may seem like a powerful feature, it is in fact bad for the actual practice of programming. Theorems and Laws of Nature may last a century before becoming obsolete, and are generally about widely relevant concepts. Programs are lucky to make it to the next release, and are mostly about highly localized and detailed concerns. The primary use-case of programming is the modification of code written by someone else. Readability, as opposed to terseness, is far more important in programming.

Many programming languages are designed as if saving keystrokes was important. This might have been appropriate when we used teletypes to program, but it is not relevant in real life programming, where far more time is spent reading and thinking than typing, and especially when there is a smart IDE to fill in some of the typing.

Change is natural

There has been much effort expended to remove the concept of mutable state from programming, to be replaced by immutable values as in mathematics. This is entirely misguided. The idea of a changing world, if not in the nature of reality, is certainly in the nature of humans. To replace this utterly common sense idea with elaborate abstractions is precisely the wrong thing to do to make programming more usable. Monads are a reductio ad absurdum.

Control flow considered harmful

Most programming languages adopt a control flow model of execution, mirroring the hardware, in which there is an execution pointer flowing through the program. The primary reason for this is to permit side-effects to be ordered by the programmer. The problem is that interdependencies between side-effects are naturally a partial order, while control flow establishes a total (linear) order. This means that the actual design exists only in the programmer’s mind. It is up to the programmer to mentally compile (by a topological sort) these implicit dependencies into a total order expressed in a control flow. Whenever the program’s control flow is to be changed, the implicit interdependencies encoded into it must be remembered or guessed at in order to maintain them. Obviously the language should allow the partial order to be explicitly specified, and a compiler should take care of working out an execution schedule for it.

Performance is a cop-out

Performance is a favorite excuse for rejecting technological change. Performance improves with engineering investment, and thus tends to be superior for entrenched technologies. The fact is that performance is not critical in most software, especially in the end-user applications that are the target. Performance also steadily improves in hardware. Based on history, it takes 20 years for a new programming language idea to become mainstream, and in 20 years we can expect a 1000-fold improvement in hardware performance. Thus the appropriate performance target is to handle unintensive end-user code given hardware 1000 times faster than today. This provides so much leeway that performance becomes effectively a non-issue.

Concrete is better than abstract

Programming is fundamentally about building abstractions, and humans are fundamentally weak at understanding abstractions. This conflict is an essential reason for the difficulty of programming. Whenever possible, language features should favor the concrete over the abstract.

The proven method for understanding abstractions of all kinds is to make them concrete with examples. Abstractions should appear, whenever possible, in the context of examples. The fullest realization of this idea is to integrate examples into the abstraction mechanisms of the programming language itself. There should be no such thing as naked code which is isolated from a working example. Another perspective on this approach is that it builds testing into the semantics of the language. For more details, see Example Centric Programming

Vive la revolution!

Programming will continue to suck until we treat this as the overriding issue, and are willing to sacrifice absolutely everything else to fix it. Commercial considerations often dictate that compatibility and performance have the highest priority, with disastrous consequences (witness C++). As the Open Source movement has demonstrated, progress requires overthrowing the economics of software. We will need to go even further, freeing our minds of traditions established with the very first programming languages. Usability is the guiding light to rationally reinvent programming from scratch.

Programming is at a dead-end. The only way things will get better is with a complete revolution. More conservative attempts over the years have repeatedly failed to make a difference, leading to the widespread abandonment of hope. We have nothing to lose.

Share this:

45 Replies to “Manifesto of the Programmer Liberation Front”

People are not “fundamentally bad at abstraction.” It’s a bit more complicated than that. Sometimes people work really well with example-less abstractions.

Even if it takes 20 years for a language idea to become mainstream on average, that time is dependent upon how efficient the idea is to implement. If a language is only efficient enough to be practical in 20 years, it will probably take longer than that to become mainstream, because nobody will be able to try it out until 21.

WYSIWYG is the wrong word to try to apply to programming. Programming is the act of modifying a notation to produce a different, more complicated result or space of results. WYSIWYG is an interface where you modify the result directly. If you could create the result directly (ie. creating a list of factorial values you computed in your head) you wouldn’t be programming.

On the one hand you say that it takes 20 years for new language ideas to reach application; on the other you say there hasn’t been language progress for the last 20 years. There has been, and will continue to be, progress in languages.

If you think text is a dead-end, you’ll need a better argument than “programmers are the only people still using text.” That heuristic argument is a dead-end and has never proven anything.

Aneesha – good question about GUI’s. Form-oriented, VB-like GUI’s ought to be natural. A form containing controls would be just another visualization style of a structure with fields. The typically messy business of attaching code actions to controls, and binding controls to data, gets handled seamlessly.

I haven’t worked on demoing that yet, because there are already many existing visual form development environments, so it would not be all that shocking.

As to getting involved, you are welcome. Perhaps at this stage we most need to just discover others of like mind to get a discussion going. Nowadays that means blogs or wikis. Start a blog, and we can cross-link each other! Let me know if you find anyone else.

I first encountered your work at Onward! 2004. The tool you demoed there didn’t look like something I’d want to use, at least yet, but that wasn’t the point. It’s a valuable experiment in putting your thesis into practice. I’m quite sympathetic to the ideas that you espouse here. I spent a few months delving into Haskell, an elegant and beuatiful language that I quickly realized I’d never want to write real programs in. So this line from your article stood out to me as if (blink)ing:

Monads are a reductio ad absurdum.

Your remarks on Lisp expressions not scaling has me thinking, too. I’ve always encouraged a style of development in which parentheses don’t nest too deeply, by having folks write code in layers of abstraction. This is the right way to program, certainly in a functional language, so that the developer can make concrete his understanding of each layer of abstraction. Buit, as you point out, the abstractions themselves tend to grow heavy on the programmer’s mind. The How to Design Programs guys have done a nice job creating a development style that let’s programs grow naturally in this way, but they may eventually reach a point of diminishing returns based on the ordinary programmer’s inability to manage all those abstractions.

But what is the alternative? Software problems are complex. The complexity can’t go away merely by giving examples. I applaud your raising these questions and, even moreso, putting your energy where your mouth is by building tools and trying out the ideas.

Very nice work.
Me and some friends had the same vision and I was planning to try to bring it to life some day.
One thing slightly disturbing about in your demo is that the statements in your program are ordered.
Although you do tell in your manifesto that programmers shouldn’t do the topological sort.
One way to solve that is to make the system graphical, which was what I was planning to do.

Keep up the good work

[Yair – Thanks for the comments. One clarification: order is irrelevant to semantics in subtext – it is purely a matter of programmer preference as to the presentation order. In other words, “narrative flow” is independent of data flow. It is the topology of the links that controls data flow. I strongly believe that control flow is an evil manifestation of the hardware model of computation. We will never escape from the moral equivalent of Assembly Language programming until we eliminate control flow. Figuring out how to manage mutable state (not yet allowed in subtext) without control flow is a major hurdle I have yet to surmount. — Jonathan]

I am the author of Leo. I think anyone who wants to understand complex programs, data or systems would benefit from looking into Leo. You will probably want to revise all of your opinions after using Leo for awhile 🙂 See:http://webpages.charter.net/edreamleo/front.html

Jonathan:
In one of your comments above, you use the phrase “topology of links”. I’m trying to understand what that phrase means.

Is a link a path between an observer structure and an observed structure, such that a change in the observed structure results in a reaction by the observer? And, that a topology of links is the set of all these paths/links at some moment in time?
If my understanding is somewhat correct then is a rule-based/production system the type of control model that you’re looking for? In this type of system control is limited to sequences and, of course, rule firing.

[ Peter – rule-based systems are essentially logic. Adding logic might be a worthwhile experiment, but it is not my main focus. Logic has this spooky global semantics, where everything can affect everything else. I am trying to stick to very simple and mechanistic models of execution, with explicit causal relationships. — Jonathan]

i’ve been trying to say pretty much the same thing for some time now w/r/t end-user programming and spreadsheets. apparently the outline model is more of a half-way point between traditional text-indenting of “dead” source code and presenting live code, which several other programmers / language designers have taken to heart as of late.

my other, and recently more prominent assertion, of which i’m in complete agreement with you is “control flow considered harmful”; dataflow, i feel, represents the much more natural way people then think about the manipulation of “concrete examples” within their mental models of abstraction.

Well, I looked up monad in the dictionary, and I looked up “reductio ad absurdum”, but the statement is still meaningless to me!

Anyway, this is a great Manifesto and I almost totally agree. Previously I commented in [The future of programming] about your beef with Control Flow; now I can at least see that you’re not asking everyone to ditch Java for Prolog. Still, I can’t quite imagine how you think program behavior should be controlled if not by Control Flow.

I wonder if the “Anonymous Coward” of comment #1 could give us some examples (no pun intended) of people that “work really well with example-less abstractions”? Maybe he’s talking about himself, but for me (and most others, I’m sure) I usually can’t understand an abstraction (or the embodiment in language thereof) without some supporting examples, preferably several. I think “example-oriented programming”, whatever it turns out to be, could be very useful for programmers everywhere.

Incidently, the importance of examples in human learning, as well as programming, doesn’t get the attention it deserves. Thanks for bringing it up.

Totally agree with statement of problem.
A very interesting sets of hints towards a possible solution
Will be thinking about with interest
Trying to out-simplify Self would in itself be an interesting enough problem
Following related long standing interests, I’m now trying to run aspecty/ role-based /metaprogramming thoughts past this lovely set of ideas
(theres a challenge when it comes to trying for radical simplicity)

I also don’t agree that Humans are weak in abstractions. Abstractions and Metaphors are used everyday by humans to encapsulate complex behaviour into simple blocks that he can manage more easily (hope this phrase doesn’t sound to OO :). I usually see this in people who deal with creative work (not only programmers but architects, designers, painters, musicians, writers, etc.). Apart from our “different” perspective of the human mind’s capabilities and inner working, I tend to agree with the rest of your manifesto. The movie that you have in your website also seems very interesting and with great potential. It’s a subject I’ve been experimenting with for some while ago, and it inspired me to start coding a tool with similar ideas (though I hope to use even more iconography and less text). Is there a forum/wiki to go further with this kind of discussion?

I too agree with most of what you are saying (especially on mutable state and functional programming languages), but I am not sure it is the model of programming (i.e. text-based) that is at fault. I personally have found out what is wrong with programming: the computer knows nothing about the assumptions made by the programmer. It’s up to the programmer to remember all those assumptions, from the lowest level (for example, the index in a loop) to the highest (for example, the host O/S filesystem limitations). And since humans can’t work like machines (due to emotions, instincts and all other things that kick in), assumptions tend to be forgotten, misunderstood, ignored, etc. A good programming language would allow to code those assumptions along with the program, so as that the programmer does not need to remember them, and have the computer mechanically check them. I would go as far as making the ‘absurd’ statement that that’s all we need to make bullet-proof programs.

Is WYSIWYG the right way? Do you really think we’re going to stay in front of a screen using a mouse (or something else) to control visual elements? Dont’ya think we’re going to give some peace to our eyes and start talking to the computer in the near future?

Jonathan,
Interestingly, I ran across Subtext on Wikipedia. A wiki, by coincidence, is a web enabled, text notation based information co-authoring tool! Given the popularity of Wiki’s, I feel it would be difficult to dismiss the effectiveness of text as a tool to represent ideas. But, that would make a poor argument against your assertion that ‘Text is a dead-end’.
What I really want to say is that, history is proof positive the power of the written word cannot be undermined, ever! Although the art of writing started out with the intent of preserving information, it has grown to its current level only to help *represent* thoughts in a more communicative manner. We write simply because we can’t contain ideas in our head! Not so much that we can’t keep them there but that they would be wasted if not brought to the world. So, I guess the stronger argument would be that a programming language is just that, a language! It is a mode of structured communication between me and the interpreter (with a compiler in between).
Nevertheless, I realize that a means of representing ideas in the pure mental form of multi-dimensional relation/decision graphs would be ideal, but I don’t see how Subtext fits in here.
I realize itâ€™s more than just a 2D graph of strings, but when it boils down to the fundamentals you end up needing the text notation to express actions. For example, the Difference function in you demo builds off the Product & Sum functions; but in the definition of Product, how do you tell the machine that, “I need you to multiply ‘first’ with ‘second'” or “I need you to accumulate ‘first’ into the (intermediary) result ‘second’ times”. I can’t picture how you’d do this without the ‘*’ operator. Similarly, Sum needs to be told what to do with ‘first’ and ‘second’ to arrive at the result, where the ‘+’ operator seems inevitable.
As for the usability aspect, I see how you could represent complex inter-related concepts with a certain ease in Subtext, but given the false pragmatism that several programmers follow (which, I assume, would be aggravated if copy-paste becomes the de facto standard mode of programming) I cannot even begin to imagine the fishnet of compass vectors someone could come up with!
On a slight side note, I really like the idea of ‘naming’ your structures for reference (functions, classes, local variables, et al). I donâ€™t buy the fact that a local variable can be wasteful. The whole idea behind naming a local appropriately is to make the programmer think twice before creating one! Also, I canâ€™t see substantial benefits arising from a semantic link to a function as opposed to well constructed string references.
Don’t get me wrong, you’ve really sold the WYSIWYG idea to me. I was refreshingly amazed at the idea of ‘seeing’ my program ‘work’ as I wrote it! I just think we need to explore **better representations** of mental concepts. But that’s where I see the other problem, ideas in the human mind are usually very abstract or ‘cloud-like’; now you see it, now you don’t; or worse yet, now it’s an elephant, now it’s a hairpin!!!
The mind is a fascinating playground where everything works, even the impractical. I guess thatâ€™s why programming languages are still in the Stone Age, they stick to simple logic! 😉

Very nice work. This is definitly a view from outside the box. Self is a great example of this too, and it provided us with many unique ways of integrating code and concreteness. I had a phone conversation with Randall back in 2001 and we talked about Self, text, and visual programming. We agreed that text was to a large degree also visual, albeit, small visual symbols, and that graphical symbols representing concrete entities leaves much to be desired since programming is to a large degree about the definition of abstraction, something that non-programmers have no training in and find difficult or impossible. Your use of other small symbols embedded in text reminds me of this conversation and how treating them as such has benifits in dealing with the creation of abstraction. Nice touch.

I also agree that control flow is a problem but I don’t believe, or that we should, take it out completely. Programmers need a sense of control, and that they are controlling their programs. Programs need to make decisions based on state and/or to loop or iterate something so control of these constructs, however they are done, just need to be comprehensible. Most imperative languages force the programmer to explicitly define control flow where data flow, concurrency, or non-determanistic execution sequences can better serve as a solution. This is why our research group has found that data flow as a visual programming language has actually been very successful.

It is true that most of the visual programming languages coming out of the 80’s and 90’s have been a failure, but I submit that this is not a case of the idea being a failure, but rather a case of the implementation of those ideas. Point of fact: LabView is the single most successfull visual dataflow programming language to date, and is used by over 100K programmers to write “real” programs. It has been shown in studies, comparing it to C, to be faster at producing programs with more accurate customer requirements and has enabled customer integration into the programming process, due to its visual and comprehensible nature to customers, from inception to delivery (what we now call eXtream programming). Prograph/CPX, another dataflow visual programming language of the 90’s, was also very successful – until its producers financial demise not related to the language but poor financial management. Companies, including Apple Computer, used CPX to produce over 100 successful products in the 90’s. It’s main problem of adoption, apart from the company folding, was its closed software policy and the reliance of companies to depend solely on one vendor for its programming system.

The Prograph language also had severl technical problems, one of which was the lack of modern programming language feature such as familure control flow model, exception handling, concurrency, and GUI programming integration. All of these have been addressed in a successor to Prograph called ReactoGraph, a visual dataflow/message-passing programming language that is the topic of my research. The ability to understand large programs is provided by abstraction through object orientation, prototyping (I too use the copy model), message passing, and simplified control constructs – all of which have been shown to work for textual languages. The problem of rearranging the nodes of the dataflow graph has been addressed with semantic-based automatic layout. ReactoGraph is a research project that, like Subtext, is not ready for prime-time, but will eventuall be released as open source. I would be most appreciative of any comments you may have. Again, great work and keep the faith =).

A lot of valid points. I also admire that you are unafraid to state the problem, without stating a solution. This could lead to some very important steps. Keen to see if this leads anywhere.

I do a lot of coding in PHP, and recently learned Flash, and am expert in Java and have recently returned to C++, and I had forgotten all the ways in which C++ requires so much extra work (repetition, mostly) compared to Java. When I mention them, I hear the mantas of “power!” and “lazy!” and similar stupidities. When working in PHP, Flash and Java in one week, I notice the difference in requiring typing in the languages. “Why DIDN’T Flash stop me doing this?” one day, and “Why WON’T Java let me do this?” the next.

It makes me think: We’ve seen how groups of simple tools come together as a solution in AJAX, which is very interesting, and I see my own partners in game-design spending a little time inventing a content-tool and speeding themselves up enormously. This article makes me think of ways I could attack the slowdowns of C++ and perhaps gain productivity.

While I think the problem presented here is pretty interesting, the article is chock full of wishful thinking and has little regard to the technological implications of such drastic change. Every computer we use a von neuman machine, it just so happens the most efficient way to manipulate these types of machines at a level of performance demanded by users is by using languages like C and C++.

“Performance is a cop out”

Saying “performance is a cop out” is a fairly common comment I see made by proponents of high level languages and the wide-spread adoption of VM-powered systems. The reality is, no programs are fast enough, no program performs well enough. Until every single operation I do on my computer is perceived as instantaneous (the only time I’m waiting is when I’m deciding what to do), computers are NOT fast enough and performance is important. I don’t know about you, but hourglasses are still common in my world….

And why are we ditching text? I didn’t understand that part at all. Keyboards are here for a while… The idea that we need to adapt computers to humans instead of humans adapting to computers is somewhat flawed. Humans are excellent learners, we can learn many very complicated tasks. The trick is coming up with something humans have an easy time learning and can perform reasonably efficient. The keyboard is one of these things. Sure, it may take weeks to learn. Tons of things take time to learn, nothing is perfectly natural, and humans perform a cost/benefit of the learning curve of the task to the quality of the output. It just so happens that a keyboard has a relatively short learning curve and yeilds a very efficient mechanism of text entry. Once you learn, you know it and you don’t need to learn it again, you now have a task that you can intelligently perform at a level of speed adequate to do daily tasks with. I don’t see the problem, every attempt at alternate forms of human input I have seen is mostly a complete failure. Not that I block out the idea of replacing a keyboard, but asserting to replace a perfectly good device just for the sake of a revolution and not provide any sort of alternative is a little much.

Very good article with some radical thoughts, but we need to come back down to earth now.

>July 7th, 2006 at 1:47 pm
>Text is not a dead end. Brain-dead programmers who canâ€™t learn to type >are a dead end.

This is new to me. I didn’t think typing is a requirement for being a programmer. Typing is a tool programmers use (one of many..like their brain). Brain-dead managers who can’t learn to manage are a dead end.

>Text is optimal for coding, if you can type, at the speed your brain works >at.

Actually you are incorrect. Text is slow for coding. The idea that Mr. Edwards is presenting should hopefully start steering programming in the right direction. As far as typing at the speed your brain works at, good luck finding someone who can even come close.

>If you canâ€™t type 10 characters per second (120 wpm) or better, you >should find a new job.

Sounds like an off-the-cuff managerial remark. Quantity doesn’t equate to quality. I would like to know what your reasoning is behind this remark. I type at 15-25 words per minute, while some of my co-workers are faster than me, and others are slower. I put a great deal of time into writing the best code I can (given stringent deadlines) which optimizes the use of available resources within the system. If someone can type 10 times as fast as I do and writes out 10 times the amount of code I do in the same given time period, but my code is five times as efficient and runs in half the time their does and performs four times the amount of work that theirs does, which is better? Programming isn’t just about spitting out code. If you think it is you have no right hiring programmers, and should seek employment in a new field.

>I am sick of hiring programmers only to find they canâ€™t type. What about >seamstresses that canâ€™t sew, or cooks that canâ€™t cook? Your job is to >produce CODE. So write CODE.

Once again this sounds like a remark made by someone within management who has no right holding a managerial position. Just because someone gets promoted to a management position doesn’t mean they are suited for the position. If you rant like this on a website, I can only imagine the way you manage your employees.

Dallan
is not a dead end. Brain-dead programmers who canâ€™t learn to type >are a dead end.

This is new to me. I didn’t think typing is a requirement for being a programmer. Typing is a tool programmers use (one of many..like their brain). Brain-dead managers who can’t learn to manage are a dead end.

>Text is optimal for coding, if you can type, at the speed your brain works >at.

Actually you are incorrect. Text is slow for coding. The idea that Mr. Edwards is presenting should hopefully start steering programming in the right direction. As far as typing at the speed your brain works at, good luck finding someone who can even come close.

>If you canâ€™t type 10 characters per second (120 wpm) or better, you >should find a new job.

Sounds like an off-the-cuff managerial remark. Quantity doesn’t equate to quality. I would like to know what your reasoning is behind this remark. I type at 15-25 words per minute, while some of my co-workers are faster than me, others are slower. I put a great deal of time into writing the best code I can (given stringent deadlines) which optimizes the use of available resources within the system. If someone can type 10 times as fast as I do and writes out 10 times the amount of code I do in the same given time period, but my code is five times as efficient and runs in half the time their does and performs four times the amount of work, which is better? Programming isn’t just about spitting out code. If you think it is you have no right hiring programmers, and should seek employment in a new field.

>I am sick of hiring programmers only to find they canâ€™t type. What about >seamstresses that canâ€™t sew, or cooks that canâ€™t cook? Your job is to >produce CODE. So write CODE.

Once again this sounds like a remark made by someone within management who has no right holding a managerial position. Just because someone gets promoted to a management position doesn’t mean they are suited for the position. If you rant like this on a website, I can only imagine the way you manage your employees.

Very good article. Okay I won’t buy everything there but some good points. So, first, thank you for investigating new options, that’s fruictfull work.
I would tend to more compromise. Text is a good representation for a lot of things, be there also better ones in some cases. However I don’t think you will find a general representation that fits all cases, I think the best is a combination of techniques. The key is to allow different representation to coexist and allow programmer to build specialized representation easily. For example I tend to like UML live diagrams of code but there is much more to be invented there.
Programing by example : I think Test Driven Developpement is quite about that (first sepcify the comportement on examples, then code), and, as you say, really help catch abstractions + make a good doc. Interactive/visual debugging is a great tool coupled with it.
About performance : it matters (as Zac McCormick) but is not the priority. I think profiling / rewriting key part is the way (so higher level language should provide good bridges with lower level ones) and better, high level concept permits higher level optimisations which tend to be bring more gain.
About control flow : I mostly agree. That’s a point I have against current implementations of OO programming languages. You have to write the controller of everything. I’ll tend to think the good way would be to define objects with inner rules which then interact without your control (like in a simulation), all that validated by tests. There is to borrow from Prolog or others there.
That said for small parts, sequentiality is a kind of shortcut to express ideas so it can be kept (maybe re-interpreted by the language in a less sequential manner).
I really feel programming becomes intelligent when it’s easy to write heuristics and not only rules. I think accepting heuristic vs rules and only rules would provide more human like computers (not 100% true, but more robust), we don’t want it for certain task (say accounting) but for others (nets, predictions, system…) that could be invastigated more
Okay I stop there, just say that for myself, I would better express those ideas providing tools/improving an existing languages (and you know what, python would be my choice).

No matter what kind of platform you are developing, you have to become involved with some kind of compiled language. There’s no way around it.

However, there is still an important distinction to be made between platforms and end-user applications. This is, in my opinion, the current problem with the programming world. There is this duality between low-level and high-level, with nothing really to bridge the gap between the two.

What is needed is a virtual machine system that is generic enough to be usable by other languages of all sorts. In this manner, scripting languages can be designed to fit specific niches, with syntax that closely mirrors the applications’ needs.

Your environment provides all the important lower-level libraries, written in compiled language, and the application developer uses those libraries from within the context of their scripting language of choice.

All you need is a protocol for communcation and synchronization and tasks. Generic virtual machines are where it’s at.

The main reason that software is so unreliable and so hard to develop has to do with a custom that is as old as the computer: the practice of using the algorithm as the basis of software construction We must adopt a synchronous, signal-based software model.

Just a quick comment/thought… you’re planning to improve software development by making a better programming language. I’m probably being sloppy by this characterisation. Regardless, have you ever considered that the main problem isn’t with the languages used for designing and coding a project, but with the software development life cycle? I’m thinking in particular of the use of Barry Boehm’s Spiral Model of development and its newer relation Agile Programming.

The use of the Spiral Model means that you have to be up-front about project risks. It also encourages building prototypes as something that will be thrown away. In this way, ongoing developement can be seen as somehow “evolutionary”, with various projects and prototypes being subjected to Darwinian pressures, with only the strongest surviving.

The other nice thing about the Spiral Model is that if it’s used in an open source project, others can come along later and explore other avenues that you might have decided were too risky, left for some unspecified future, or not even realised within the project to begin with. The project might only have one output initially, but people revisiting it might have the time and the inclination to produce many, many outputs from the basis that the first project provided…

i agree that programming should be much simpler and the whole process of engineering software should be as quick and the software could be built while talking about the requirements of it with the customerâ€¦

if there is a programming language that is written in the language of thought, then while talking with the customer, (and if the UI of the software is sufficiently user-friendly and intuitive) u can also at the same time prepare the software by displaying the requirements of the user in the language of thought and then those ideas represented in that software would also be programmatically runnableâ€¦

thats the idea of the Nelements programming language that is in developmentâ€¦its to help software engineers to develop software in a much more efficient mannerâ€¦.

u’re saying in ur post that the hard thing about programming is precisely describing the algorithm right?

so if we have an algorithm in our minds (which is in the language of thought) then if we have a programming language which is also in the language of thought, it would be much easier to describe that algorithm in that language right? if the two languages were very similar, then there wouldnt be a need to convert from what we want in our minds to a programming language syntax.

zahid seems to miss the point. If there was “a programming language which is also in the language of thought” then it would be much easier to describe an algorithm in it, but that would in no way help us ensure that the resultant code actually implements the algorithm. Unless you construct a library of “quicksort”, “maximal flow”, “dominating set”, etc., etc. and then restrict yourself to calling algorithms from this library, then you’re still going to run into exactly the same problems we do with current languages, namely that programmers, being people, fairly suck at managing details and that we have little control over our mental models.

Most of us, for example, read “/” in an arithmetic expression as normal, everyday division forgetting that what we’re dealing with aren’t members of Z, N, R, etc. but usually inexact, bounded encodings with some quite different properties. It is this lack of attention to detail and inability to easily internalise the rules of formal systems (like, for instance, programming languages) rather relying on learning them by osmosis that makes programming difficult and no language will be able to solve that problem. Where new languages come in useful is helping us to offload the burden of keeping track of details.

With advanced languages like Haskell, we can use the language (specifically the type system) to ensure that we aren’t forgetting some important property or breaking some contract or interface rather than trying, and failing, to do so ourselves. On a similar topic, that you see monads as only relating to permutable state seems to indicate a lack of knowledge — they are a much more powerful abstraction than you seem to realise, encoding various patterns of storage, evaluation, error handling, data flow, and communication as well as making it easy to build exceptionally simple, elegant, and extensible interfaces between modules. I’d suggest taking a look at the STM from Peyton-Jones, et al. at MS Research, the Render monad from gtk2hs, and various applications of monad transformers.

If we assume that natural human language is the evolution of point-n-grunt, and that point-n-click corresponds almost directly to point-n-grunt, then where is panacea in anything mouse drivin? I think text is more ‘agile’. I can use it in mathematics, programming, and to respond to weblogs.

I agree that language matters and there is value in researching new languages. I agree that usability is key and that end users should be able to extend the behavior of their applications to the greatest extent they are able and that the application should enable this and make it easy as possible. I have no problem with copy and paste.

Text is dead? On this I am not convinced.

On visual languages I agree with a previous post that LabView is successful. The new Lego NXT programming language is based on LabView (I donâ€™t have one yet). Last year I had a rare opportunity to visit the Tufts University CEEO department where they work on education outreach programs with Lego Mindstorms and Robolab. I asked one of the programmers there if real programs could be created with LabView and he assured me that they could and he said it was easier. Iâ€™m looking forward to trying out the NXT visual programming environment. The old RIS was crap. I switched to NQC which is text based.

I somewhat agree with programming is not mathematics. As for control flow, I find it natural to think procedurally. When faced with a declarative language where I shouldnâ€™t have to think procedurally I find that I really do end up having to understand how my declarations are executed procedurally.

I agree that performance should not be a roadblock to research in new languages but it is important even in end user programs. I just got a new HP printer and it came with image management/editing software. It is .NET based and extremely slow. I don’t use it (except to print). I use compupic, which is extremely fast.

Thanks for doing this fine work. A few more thoughts on subtext at my blog

Damn, am I happy to see someone else thinking along these lines. And even doing something about it to boot! I haven’t checked out subtext yet, but the criticism of the status quo is spot on! I’m mostly a practical programmer with limited mastery of the theory, but I’ve been nagging about these things to anyone who will listen for the last couple years, and only found one person (a researcher in computer languages, who tipped me off about his article after a disussion) who even understands what I’m on about. It is _so_ good to see there are more of us. Viva la revolucion!

Subtextual demo reminded me a textual spreadsheet at some point. Of course Excel calculations are far simpler and less flexible, however the immediate feedback on results of the calculations is the same. Probably you could study and exploit other useful features of spreadsheets when developing WYSIWYG programming tool. Nice work, looking forward to it’s development!

I agree that programming is not really mathematics. It’s harder. We can’t make mistakes and expect to get paid – at least not reliably.

I’ve been writing software for more than thirty years, and the underlying problem is the need to be painfully precise about everything. Beyond a certain point that really is not natural in any field. Diamond cutting is not natural either, even though it is “just” breaking rocks. So, why should careful thinking be any exception?

As you say, “… programming is hard not because of sophisticated algorithms and data structures, but rather because of the overwhelming multiplicity of simple constructions.”

Thus, it doesn’t matter to me much what languages, platforms, graphical tools, or IDEs I happen to have available. The biggest problem is to get a precise definition of the requirements from the end-user. I’m usually dogged enough to get them to tell me what I need to know, but often they are mad by the time we’re done. They may know their own business cold, but like all experts they forget how much detail that involves, and they are always shocked how long it takes to explain things to an outsider, never mind precisely enough to enable the design of a fully automatic process.

Does this mean I have no preferences among available tools? No. For instance, I will choose VB over C++ because I can avoid all the grunt work of handling windows. Nor do I have to mess around with crummy “wizards”. I just drag and drop, and the screens are done. Then I can plop in the actual business rules, or whatever, without worrying about a bunch of mechanical bookkeeping stuff that VB automates for me.

I also think in terms of dataflow, use referentially transparent functions, and formal state machines, because all of these items make it much easier to see when I’ve forgotten to take something important into account, and they also minimize pathological implicit connections.

Finally, a big fraction of my code, typically 25 – 35% is assertions checking for invariants that must always be true if execution and program state are correct. If every third or fourth statement is checking something in the system, not too many bugs go undetected for long. Furthermore, if you’ve grilled the user hard enough, you really do know what he wants, and you can get pretty close the very first time. My experience is that rampant change is a problem only for those who are too lazy to get the complete requirements in the first place.

Experience also helps in this regard. I now know what people in a lot of industries do and how they do it, so I don’t need to learn their whole business from scratch. Even if I did need to do that, I have long since learned to read an introductory textbook on the industry in question BEFORE I go waste the end user’s time.

They don’t expect me to be an expert, but they love it when I mention the book I’ve read. They’ve often read it themselves, and thus can feel confident of my exposure to their key working concepts. They also know right up front that I put real value on their time, because I RTFM. Thus, I get more of their attention when I do need it.

I think your manifesto has some interesting ideas, and I’m always interested in improved tools. However, at some level we have to actually understand both the problem and the solution in detail, and tools may help, but they will not easily free us from our fundamental responsibilities as designers, if ever.

After rereading my comments from yesterday I see I skipped over an important point.

You say: “Compared to every other field of design and engineering, programming is an embarrassment and a failure.”

I agree that the software industry has way too many embarrassing failures, and I certainly have spent a lot of time studying those cases. However, there are also a good many projects – historically about one third – that have come in on time, on budget, and doing what the end-users wanted. Moreover, when you look at those successful cases, they have certain characteristics in common, which can be emulated by others, provided only that those others are willing to work rather hard.

That is to say, before I worried about reinventing anything, I would go see what has already worked, and why.

I also realize full well that I sound like some cranky old fossil lecturing the young whippersnappers. However, please note that I am a SUCCESSFUL fossil.

I have often, as I said yesterday, irritated my customers with endless questions, but in the end they have gotten what they paid for, and I have gotten to keep the money secure in the knowledge that the clients will not be calling their lawyers to get it back for them.

In at least three cases, my managers overrode my advice on this sort of issue, and their clients wound up suing them out of business. However, in no case was I one of the defendants. Why? Simply because I had dealt with everyone honestly. It’s no more complicated than that.

In many contracts I have given my clients very generous warranties, and I have yet to get a call making a claim, much less have to do a lot of free work to clean up my own mess. That is to say, NO bugs, NO complaints, and NO esoteric tools to make that possible. Just a lot of patient, careful thinking about what the customer is telling me, backed up with a great deal of cross-checking of my assumptions, mostly be means of careful questioning of the customers themselves.

If I sound a trifle hot about this, it is not simply the sententious tone of your manifesto. Rather I went to check out your demo, and it sucked. You say that performance doesn’t matter, and I understand the point you were making, but the software does have to perform reasonably well, and your demo does not.

I have a broadband connection, but the damned thing still took MINUTES to load, and then it ran like a sedated pig, a terminally pregnant, sedated pig. I sat there for over twenty minutes watching the equivalent of a few Power Point posters swapping on and off my screen, with no clear idea what you were getting at. At erratic intervals a cursor moved around, red lines flashed on and off, and then a symbol might change. What was I supposed to get from that?

Perhaps you should try an antique concept that we creaky old fossils call “documentation”. It is a text-based methodology, so perhaps beneath the consideration of modern minds, but it has surprising utility despite its crude simplicity.

Finally, if you think I’m being unnecessarily harsh, you should try the real world. After all, this is just a little academic discussion. How do you suppose that customers will behave if you piss away a few million of their hard-earned dollars. Well, I’ll tell you. They won’t be a little snippy. Rather, they will hired cold-blooded lawyers, who will take your entire life apart. Angry clients can, and usually will, try to put you in the gutter if you don’t deliver. And that is assuming you managed to get the contract in the first place.

Typical CTOs will wait thirty to sixty seconds for a demo like yours to load, and then they will simply cancel the meeting. And they will never take a call from you again. Period.

In industry we call this “failing to pass the laugh test”. If your prospective customer goes away laughing, and your product is the butt of the joke, then you are out of business.

The demo you watched has a voice track. It doesn’t sound like you heard it, or perhaps there was some other technical difficulty. But, of course, without that, you wouldn’t have gotten the point, and it would have appeared to be running ‘slow’ because you aren’t hearing the presenter’s voice explaining what is happening or what the illustrations on the slides are meant to point out.

Secondly, its silly for you to make the argument about the load times. Its a video after all, and the load time is not THAT long (unless the server was possibly having bandwidth issues), and this isn’t a presentation being targeted at corporate executives. Its a presentation for computer science academics and others who are interested improving the art of programming. Of course, if this were targeted at corporate executives, that would be another story all together.

Lastly, I might point out that the author of this presentation has been programming since 1969, and could hardly be classified as a ‘young whippersnapper’.

In any case, I agree with your point that no tool will ever absolve the programmer from the resposibility to understand what he/she wants the computer to do in a very precise way. Better programming tools probably wont directly improve communications between customers and software developers. But, that isn’t the only problem in programming. Even if the problem is perfectly understood, the act of solving the problem and encoding that information into a program and maintaining it as it changes over time is a very error-prone, time consuming, and difficult process, and fundamentally better tools CAN help fix that problem.

After I got past being irritated at the smugness and dismissiveness of the writing, I noticed that this project, like Self and many other failed language projects initiated by brilliant lone developers or isolated groups, fails to even mention three requirements that I believe are basic for real software:

* It must be possible for a programmer to *share* *parts* of his or her work with other programmers. To enable this, programs must be decomposable into parts in a way that immediately manifests as much information as possible about the relationships / dependencies between a part and other parts.

* It must be possible for a programmer to work readily on programs they didn’t write. I.e., real programs must be able to long outlive their original authors.

* It must be possible to reason about the program and what it does. Just being able to execute the program is not enough. This is a fundamental tenet of engineered systems — it’s not acceptable to find out whether a bridge design works by building the bridge and seeing if it falls down.

Subtext seems to take the point of view that it is perfectly OK to reinvent the wheel a thousand times if it’s cheap enough, and perfectly OK to have software be messily unreliable as long as it’s easy enough to fix. I find this appalling.

For the record: I have nearly 50 years’ experience in building software by traditional means, including some software that is considered to be of high quality (Ghostscript, VisualWorks Smalltalk JIT compiler). I hate building software that way, and agree that radical new thinking is required. Subtext is a wonderful initiative in fresh thinking, but its underlying philosophy seems to me to be incompatible with the requirement for software that has the reliability and longevity required for widespread use in society.

——————————————–
Peter,

I am sorry that you have formed such a negative impression of my work, as I respect your own. I am a working programmer, and I agree with the three requirements you state. I will admit that I haven’t made any progress yet on those requirements, due to the immature state of my work, but I don’t see how anything I am doing makes things worse than the status quo.

My latest work is about static reasoning on programs to reveal their logical structure, and prior work was on making side-effects hygienic, which could improve our ability to modularize code.

Perhaps you are assuming I am following in the footsteps of Smalltalk & Lisp. Those language’s cultures do tend towards the attitudes you complain of. The “system image” model of development encourages solipsism. OTOH I am fairly certain there is an entire level of Hell where programmers are forced to use textual Version Control systems. There has to be a better way, but I haven’t gotten to that yet. I am still working on basics like how to represent conditionals and iteration in ways that expose their semantics.

Do we agree that programming is still in the Stone Age? If we do, then a responsibility falls upon those who have labored long enough to gain some wisdom, and who care about their craft. Someone with your deep experience and talents could make a difference. How would you improve programming?