The biggest problem with programming is that we don’t agree on what the problem is. The comments on the previous posts reveal fundamentally incompatible views. I am equally shocked by the opinions held by some distinguished academics and leading practitioners. Our views of programming are so at odds that it’s almost as if we were from different planets. Wait – that’s it! It all makes sense now…
I suspect that many programmers and computer scientists are Vulcans. You see, on Vulcan, programming is a form of applied mathematics. All software is precisely specified using logic and mathematics. What’s more, these formal specifications rarely change. So programming is like proving a theorem, and Vulcan programming languages are like mathematics. Vulcans prize elegant programs, and because the specs don’t change they can refine and polish their programs to perfection. Adding a level of abstraction is always worthwhile if it shortens the program. Vulcans don’t use debuggers, because errors are a sign of a flaw in reasoning, and it is better to puzzle out the root mistake than to make ad hoc fixes. Dijkstra must have been a high priest or something back on Vulcan.
Vulcans are renowned throughout the galaxy for their compilers and algorithm libraries. You would be crazy to use a non-Vulcan regular expression engine. But they are equally as famous for their terrible user interfaces, where they lack objective metrics to optimize. And don’t ask them to build something without first having a precise and complete specification, unless you’re into that nerve pinch thing. Luckily for the galactic software industry, there is an even larger community of programmers who originated on the Planet of the Apes.
The Apes aren’t into mathematics and logic. Instead their passion is for socio-economic-grooming systems of unrivaled intricacy. Galactic anthropologists are baffled by the incredible complexity of Ape society. There are no written rules, and the rules are continually evolving, yet Apes can simultaneously fulfill a dozen different roles without breaking their rules. On top of this, the Apes have integrated software throughout their society. All sorts of automated systems play central roles: communication, entertainment, accounting, manufacturing, distribution, you name it. All these systems exist primarily to interact with Apes in their informal shifting social games. So there are no formal specifications, nor can there be any. As a result the Apes have developed a style of programming inconceivable to Vulcans. Their software is constantly being redesigned, so they make it as lightweight and clear-cut as possible. The Apes can’t prove their software is correct, and they seem puzzled by the very idea, as if they were being asked to prove correct a chair. However they design amazing user interfaces that harmoniously blend cognitive, artistic, and emotional significance. Much like the Apes themselves do. Their systems are imperfect and provisional, but they are forever fixing and improving and transforming them at a furious pace. For these qualities, Ape programmers are highly prized throughout the galaxy. If the purpose of your system is to interact with sentients in a social or economic context, you get an Ape to program it. Using Vulcan tools.
The Vulcans and the Apes despise each other. The Vulcans believe the Apes are too stupid to think abstractly, which is the essence of programming. The Apes believe the Vulcans are crippled at communication, which is is the essence of programming. My doom is to be torn between these irreconcilable opposites. For I am Vulcan, and was raised Vulcan, but I married an Ape, and made her planet my home. I will not know peace until I find a way to combine the best of both worlds.
Your wife must love that last paragraph.
Pre-cleared.
That would have been an interesting conversation…
Seriously, I think in your last few posts but especially in this one, you’re flirting with the “two kinds of people” fallacy. Sure, it’s annoying when people focus too much on highly technical abbreviated programming tricks. It’s also annoying when some joker copy-and-pasted 10k LOCs of UI pages instead of using templates. It’s annoying when the DBA decides on some brain-dead partitioning scheme that slows everything to a crawl. It’s annoying when management decrees the use of a non-D VCS. The average programmer is annoyed in dozens of bizarre ways every day. Why pick out this particular place to draw a line? Unlike in previous posts, here you’re at least looking on both sides of the line, but it’s still unnecessarily divisive.
What I think you want is a cold and rational argument, backed up with empirical evidence. Really, nobody ever pays attention to these studies except for really smart people, because people prefer to have opinions rather than facts. Discharging opinions is how programmers relieve stress. It makes no difference that there are empirical studies — over 30 years old — showing that if you take a dynamically typed language and make it statically typed, the programmer becomes more productive.
I didn’t know there are studies for this, but I suspected as much, can you post links to some of them?
I’d have to disagree that there’s no way to measure UI. “Click counting”, eye tracking, color schemes. All of these and many more are analytic approaches to measuring user interface.
It’s quite obvious that we cannot have creative work don by computers, but user interface guidelines are there for a reason, and lets face it, they were written down by Vulcan.
I think the authors of the major UI style guides would take exception with you. They see themselves as designers, not engineers, and are the first to say you can’t quantify good UI design.
Well, recently I’ve landed on the UI/Frontend side of software (life in startup), and I have to say, even if they think of them selves as a designers, they come from Vulcan, every good designer I’ve met was consistent, had good reasoning skills, and could explain rationale for each design decision in language that I could clearly understand.
Marcin and I have had the same experience with “designers”. Every good designer i’ve met was consistent, etc. I have met no good designers. In fact, when someone calls themselves a “designer” , my translation is “someone who enjoys making things difficult to use”.
Apple is bearing the torch of “good designer” these days. I tried for 20 minutes to find the “on” switch on their all-in-one big screen Mac at a friends house 2 months ago. I should have known it was in the same place that the original toaster macs had them, in back, low down, hard to find and inconvenient to use. Unfortunately the great designers at Apple improved on their earlier work and made it flush with the surrounding bezzel so that even feeling for it couldn’t detect it.
When we have a difference between the assessments from the “mathematical elegance view” and “good UI view” for a given artifact, we know neither is particularly good. Jonathan, thanks for this excellent thread. You have me to talk to! I live your lang to IDE gulf and the unnecessary inelegance of apes or vulcans or W3C members, well motivated, but unnecessarily inconsistent with one another.
They see themselves as designers, not engineers, and are the first to say you can’t quantify good UI design.
Perhaps, but it seems that those at Google might disagree with you.
Those are some interesting observations. I agree with Jess, though, that to say that there is a clear division between Vulcans and Apes and thta they “hate each other” is exagerated. People approach programming in different ways to solve different problems, and the lack of understanding those differences in approaches and the differences in the problems they’re solving sometimes causes friction between software developers. I, for one, have worked on both Vulcan-esque projects and Ape-ish ones, and I adapt my approaches accordingly.
Doesn’t that post just make the point that Google is run by Vulcans, who don’t grok design?
I am glad you and Jess don’t observe much hatred and division, but I do. For example, there is a widespread opinion in academic computer science that most programmers are incompetent. I often have to bite my tongue. Imagine a meeting between Dijkstra and Guido – do you think they would agree on anything? Other professions don’t have these chasms of understanding. It is more like politics, where people despise each other’s basic value systems.
Your Vulcans seek to unify where Apes seek to diversify.
ApE (Application Engineers) compile to VULCAN (Virtual, Universal, List-Creating, Abstract Nonsense).
The Apes you describe are actually the Vulcans who’ve strayed from the path laid down in the ancient Syrranite (science) scrolls written around them by Surak.
The Surak of computer science would be Babbage who passed his decaying katra on to Turing and eventually to Dijkstra; just as Surak did to Syrran. Syrran then passed that to Archer who upon the end of his short quest passed it to a Vulcan elder, aka Johnathan Edwards.
Johnathan Edwards passed this now decaying and diluted katra on to the Internet.
You can see that the problem is the lack of Vulcan adherence to the enlightened path of Surak written in the scrolls and diluted as passed from one generation to the next.
The physical nature of the difference engine is what has been forgotten by most Vulcans.
The real problem is that most Vulcans, like most of Computer Science, has strayed from the path of Surak (science).
Programming is language is interface is physical is contextual.
Not subtextural.
Love it! The purpose of software is to drive the hardware to do work. We sometimes forget that. Paul gets it: http://mailinator.blogspot.com/2008/08/benchmarking-talkinator.html
I could hardly agree more. I am a Vulcan and an Ape at the very same time.
This is a bit of a simplification, though lingering in the functional programming community I understand what you mean. Take Haskell as an example: beautiful language but where great ideas arise, but the elegance is taken to an extreme (perhaps it should be). Many PL researchers are mathematicians at heart, while those of us who feel more like designers don’t really fit in.
Software systems are already so complicated that I believe the right approach should be more biological than black and white mathematics; meaning more statistical properties (the system is robust) and less about absolute truths (the system is correct). Vulcans can still play that game (statisticians are still mathematicians), but apes have an advantage in that they accept chaos as the norm.
Also, even toolsmiths should be thinking about developer experiences more than theoretical elegance. This is by its nature more design-oriented.
Sean, I have a lot of respect for your work. Let me ask you frankly, do you think I am being too extreme? I am really frustrated and alienated. The academics just want to solve puzzles and win their cleverness contests. The young practitioners divide up into warring tribes. Many wise practitioners have concluded that the only way to improve programming is with methodology. I have no one to talk to.
I feel similar. We are always in danger of becoming cranks zealously pushing radical but maybe not very useful ideas, developing are own little circles, but mainly being ineffective at large. Think Stephen Wolfram’s New Kind of Science. Brilliant guy, interesting idea, great coffee table book, but utterly pointless in the research sense, and he’s earned a crank label from other physicists (not that he cares, he’s still rolling in Mathematica cash). We could also isolate ourselves from the clever guys and not benefit from their constructive criticism.
But to heck with this. The best way to communicate new/radical ideas is to get them out in prototypes that other people use. Papers will often be ignored, cool demos will not, cool demos that people can actually kick themselves even less so. Lead (or fail) by example I guess.
That has the ring of truth. Unfortunately for me, getting to a cool demo means a full stack from language semantics up to an IDE. Hard to get there with no feedback or encouragement along the way.
Think small? The interesting chunk of the big vision? Prototypes will provide you with more feedback than whiteboard discussions.
This post was a very good read and resonated very well. This is a great quote:
> The Apes can’t prove their software is correct, and they seem puzzled by the very idea, as if they were being asked to prove correct a chair.
Can you give some examples of puzzles and cleverness contests? There certainly are papers that seem useless to me, but most do seem useful or interesting or both. For example papers on solving a specific, well defined problem (like compiler optimization or SAT solving or automated theorem proving) I find often both interesting and useful.
No way I am going to name names.
And you already gave a big enough clue, intentional or not, with suggesting we redneck research it – by Googling “stupid programmers”. The first page has a review of a parallelism talk by Yale Patt; the reviewer characterizes Patt as somebody who views most programmers as incompetent.
Patt is simply extremely closed-minded and visionary, fixated only on what he cares about, and adopts a simplified view of the rest of the world simply so he can focus even harder on what it is that really matters to him. Can’t blame him. Does his attitude suck? Eh… I would call him a jerk only if you are an Ape and he makes fun of you to your face for being an Ape.
Of course you won’t name people, but maybe you can give us an idea of which problems, or fields you mean. For example would you consider improving SAT solvers a (mostly useless) puzzle?
> The Apes can’t prove their software is correct, and they seem puzzled by the very idea…
That sentence is about proving programs correct. It is not about puzzles or improving programs. Clearly Apes and Vulcans don’t even speak the same language.
OKay, What would you say to somebody if you did have something to say?
Just post nibblets of ideas here and there and see what discussion that attracts. You obviously have a huge readership, judging from your huge list of replies recently. Why not also talk to the best Ape Bloggers like Jeff Atwood? Find out what problems Jeff would like solved and see if he can help you somehow. I think Jeff is usually very technically inaccurate, but I would never make the mistake of thinking Jeff couldn’t teach me something; even if all Jeff can teach me is how he personally approaches an issue, that could be enough to encourage me, since he appears representative of many developers – or, at least, many developers identify with him.
By “talk to” I really mean peer review: evaluation and criticism from experienced language designers. Language design has been largely banished from computer science. Some academics do it in secret and publish formal or empirical analyses of the language. Practitioners mostly work in isolation, without the time or peer review needed to do it right. I have been thinking of trying to organize a conference devoted to language design.
Hi Jonathan,
That assertion I suspect says more about your vantage point than how the land lies. PL research is huge and a significant portion of PL research is essentially language design. For example, concurrency and STM; language-integrated queries; self-adjusting/incremental computation; dependently-typed programming; information flow; DSLs; and so on ad nauseam. Pick virtually any PL topic and you’ll find someone designing a language about it.
Some of these developments involve potentially large shifts in how programming languages work. Even some areas that to an outsider look like fancy theoretical work (such as dependent type theory) are primarily about fundamental changes in how languages work.
Maybe things look closed to you because most language design is not radical but incremental. Not all progress in science can be radical, right? I think the “punctuated equilibrium” model is more accurate. But PL design is alive and well and like any other community the PL design folk include open-minded enthusiasts as well as closed-minded skeptics. The community as a whole isn’t closed to anything.
Roly, I strongly disagree. Design is making judgments to balance qualitative goals. Published PL research is not design, but is (pretending to be) science or mathematics: either doing empirical experiments, or proving theorems. You can not publish a design involving new features or new combinations of features that improve clarity, simplicity, flexibility, or any other qualitative consideration. Few of the landmark papers in language design could be published today. For example Barbara Liskov’s seminal paper about data abstraction, which led to her Turing award. Liskov herself is outspoken about the irrelevance of much modern PL research.
I am not against incremental progress. I am against the current dogma that programming language research must lie in the Procrustean bed of math and science. We aren’t allowed to talk about what really matters.
But much PL research involves exactly this sort of balancing act: for example between safety, ease-of-use, performance, expressive power, and so on. Just considering the one example of dependently typed programming, much of current research is precisely about trading off factors such as decidability of the type system, proof burden on the programmer, type annotation overhead, suitability for embedding DSLs, and so on. These considerations are mostly qualitative.
Many people don’t do this sort of “designy” stuff, certainly. Some do just prove theorems, others just collect data and make colourful charts.
I think PL design (and UI design, for that matter) fundamentally *is* science, it’s just that like all science there’s an art to doing it well, and effective communication is an unavoidable part of it.
I’m not saying no one does design. I am saying you can’t PUBLISH design. You have to have the theorems or the experiments.
Clearly we have quite different understandings of what science is. Therefore I doubt we can have a constructive conversation about it. We will just have to agree to disagree.
You don’t get points for design in a PL conference, which was shocking to me when I finally realized this. In committee I saw a beautiful design paper fall by the wayside since it didn’t provide strong enough scientific evidence…
Design is not and never will be science. Its hard to prove or provide strong/rigorous evidence that a design is better or even adequate. The closest we can come are through user studies, blind taste tests, etc…but here the evidence is often too soft to (a) be very useful in guiding the design and (b) definitely be used in a serious publication (well, barring an HCI conference).
Perhaps there is a way to scientifically measure the cognitive impact of a design on a user, but its very much in the realm of science fiction now.
This is a simultaneous reply to Jonathan and Sean.
Fine. Between sensible people a constructive conversation should still be possible, but maybe it would be better conducted in a more interactive medium, such as (dare I say it) actual conversation. Another time.
I think we should distinguish between what Kuhn called the “context of discovery” and the “context of justification”. The context of discovery can be as creative, intuitive and qualitative as you like. You’re free, qua designer, to pursue any language feature, type system or UI concept that makes sense to you.
The context of justification is when your idea grows up and leaves home. If you want public money, rubber-stamping, and state-funded dissemination then it’s reasonable for society to require that you produce some kind of evidence that your idea has some benefit. If it’s a type system there may be some minimal formal expectation (soundness, completeness, etc). If it’s a UI feature then some kind of empirical results, or whatever. At the very least some kind of anecdotal evidence.
If you can’t justify an idea other than in some kind of personal, whimsical way that’s absolutely fine, but society at large shouldn’t be expected to pay for it. Are you saying you have an idea you want to publish whose benefits can’t be made tangible in any way at all?
[As an aside Sean: certainly there are ways to scientifically measure the cognitive impact of a design on a user. You mentioned HCI, after all :]
Anyway, I disagree about a simple factual matter: that it’s hard to publish “designy” stuff. On the contrary, a lot of fancy language features are designed and disseminated with no more justification than some casual handwaving at the beginning of the paper. Making sure that these features are actually of any use is considered someone else’s problem.
Roly, you do know the distinction between hard and soft science right? Physics is a vulcan-style hard science, psychology is an ape-style soft science. Universities have both kinds of sciences, though hard sciences tend to attract more money since the results they produce are more reliable. Universities also tend to have design, architecture, and art departments, and they get funding too (although maybe less than even soft sciences).
HCI is a soft science embedded in computer science, which we could argue is more often a hard science. Techniques used to evaluate work in HCI, the user study, is expensive to perform and doesn’t provide us with very good information. In language design, a user study would never work since professional programmers are highly suspicious of languages they don’t already know (try doing a user study to see if randomly selected developers are “more productive” in Haskell than Java…that would be funny).
Your view of the world is simply different from mine, perhaps you exist where everything is a hard science and people focus on only making their points by collecting lots of hard evidence. Its a nice place to be but I’m not there, the real world seems to be much messier than that.
Sure, I think it’s a good distinction and one that’s clearly relevant here. And there’s a continuum between hard and soft sciences, naturally. In day-to-day practice the methodologies differ substantially, but at some meta-level the methodologies converge: you need to demonstrate, relative to the norms of acceptance appropriate to your location on the hardness spectrum, that your research is worth publishing. Otherwise you need to publish it at your own expense, Stephen Wolfram-style. Or just accept that you have hobby which you like to call “research”.
CS is unusual perhaps in that it spans the whole spectrum from hard to soft. That’s at least one of the reasons it’s *easy* (I believe) to publish “designy” stuff in CS. You just need to find the right forum and communicate the benefits of your idea successfully.
It’s easy to blame the system when people aren’t buying your idea. It’s much harder to convince yourself that it’s your problem and that you need to communicate better. At least that’s been my personal experience.
I’m not as optimistic as you are that soft evidence is very useful, the results are very noisy and subject to many kinds of biases. I would have never had succeeded as a psychology or sociology major since it’s very difficult for me to buy into their results. Better to consider architecture: you would only have evidence that a design is good over time and based on experience. There is simply no way to apply the scientific method to good design yet. Why is building A better than building B? Can you prove it?
Feedback and recognition from peers IS important, neither Jonathan or I are suggesting that PL designers have to be cranks. But when design isn’t research, how do you sell it to your research-oriented peers? They still care of course, and can provide great feedback, but they are focused on results at the end of the day that design isn’t going to provide directly. To someone who isn’t directly interested in language design…why, C/C++/Java/C#/ Smalltalk/LISP is the language, we don’t need anything else, and frankly I don’t want to learn anything else (this barrier is real: people don’t want new languages until they do). I remember the amount of fighting I had with my PhD advisor over these issues, in retrospect I was trying to cram design work into a dissertation…ah…of course things would go badly ?. Most adopted language design occurs outside of academia where practitioners focus on good language designs rather than good research. It’s definitely not a “hobby,” it’s just not research, rather you could call it design or even informed engineering.
You cannot publish designy stuff at a top tier CS conference without including a shaggy dog in the form of theory or experimental results, especially the SIGPLAN conferences (POPL, PLDI, OOPSLA, ICFP). It’s just impossible from my experience of serving on the PC for a similar conference (ECOOP). One can always go to a second tier or lower conference, but these venues aren’t really worth it. Onward has been a great venue for presenting a design work, but only because it lacks the rigor required for a technical paper track.
Above, Sean says:
“In language design, a user study would never work since professional programmers are highly suspicious of languages they don’t already know (try doing a user study to see if randomly selected developers are “more productive” in Haskell than Java…that would be funny). ”
and in his next post, re-emphasizes the point:
“I’m not as optimistic as you are that soft evidence is very useful, the results are very noisy and subject to many kinds of biases. ”
Sean is correct that user studies of PLs are hard to do, and thus are rarely done. They also can lead to ambiguous results. It is one of the more complex comparison tasks I can think of and I’ve done a bunch of such tasks over the years.
None the less I do think such tests bear fruit and exhibit A is:
http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/14462/1/00-0900.pdf
which Erran Gat describes such a study done at JPL between C++, Java and Lisp. I would also highly recommend:
http://www.flownet.com/gat/jpl-lisp.html which is
by the same author, more recent, more anicdotal and yields some of the surrounding story which I think old MIT Lisp hackers like me will note the ring of truth, fuzzy though that may be. (Disclaimer, I started the Macintosh Common Lisp project that GAT refers to (at Coral Software a few blocks from MIT) though I have never met him.)
“Adding a level of abstraction is always worthwhile if it shortens the program”…that’s important for Apes too. If your specs are always changing, the last thing you want is to have to make those changes with unnecessarily repetitive code.
I spend my days doing Ape work, and I add layers of abstraction wherever I can. If I can’t abstract the runtime code sufficiently, I write a code generator. It always pays dividends when my clients come back with changes.
Example: a validator for excel uploads. Pretty mundane Ape work, but by using lexical closures and a fluent API, I made an internal DSL that let me specify complex rules involving logical combinations of columns, in just a line of code per rule. Now my clients can give me an new template and whatever rules they want, and I can implement them in very little time.
One of the best-established results in empirical software engineering is that productivity and bugcount are directly related to number of lines of code. It works across languages, no matter what the nature of the code.
High-Vulcans are all using Haskell and creating Epigram (which btw is not really textual afaik) etc and other stuff that we haven’t heard about. They care passionately about good ideas but sadly they mainly care about communicating those ideas among themselves. Many academics do ingenious problem solving and then when the problem is solved they find something else to work on and their work remains unknown and so the problem isn’t *really* solved. They use cryptic terms like Monad, Category, GADT, etc, and use many cryptic symbols and so their inner circles are hard to penetrate.
Then some Vulcanoes re-invent the “known” ideas of the High-Vulcans but using their own original and intuitive terms for them. Some Tigers see their demos and get excited with the revolutionary and wonderful ideas, but the majority of Apes ignore it because of their lack of interest and lack of imagination. The highly respected High-Vulcans also ignore this work because it’s hard for them to understand it if it is not using their own terms, and when they do give it a chance they don’t see many ideas that are new to them and to add to that the stuff is presented with fun video demonstations and not in their beloved latex or postscript. The Tigers eventually don’t get involved with the Vulcanoes’ work, as they tend to abandon it when they discover the works of the High-Vulcans.
Combination… Spock! :0)
I will not nitpick the text but say it was very fun to read 😀
But you need to remember that Apes also have some insanely eloquent things as well. For instance the design of my hammer hasn’t changed in quite some time.
Jonathan,
I’ve been reading your blog off and on for a while now, and have enjoyed your insights into the HCI of program construction and understanding. I downloaded and ran SubText’s source when you released it. I particularly appreciated your spanning-tree+names for cross links representation of data flow. I’ve been researching independently for awhile now, and find myself similarly stuck between the industrial (my current home) and academic worlds.
The problem is really that there is a lot of synthesis work that hasn’t been done, that NEEDS to be done in order to make something of benefit to the majority of the populace. The relationship between proof, implementation, documentation, and interface is poorly understood, and it is precisely that relationship that us ‘tweeners have to solidify. We can also be evangelists, vulcanizing our homin(o)id friends, and humanizing our vulcan friends. There’s actually a long way to go before we get the great benefit we hope for.
Roly is correct in highlighting important aspects of current PL research
I’d add a few more: precise formalization of bidirectionalization, constraint propagation reified into user interface constraints, etc.
Take heart in the fact that the academic medium is so much less interesting then the ape world. Would you rather make pdfs with TeX, or structured editors? In fact, the people who have gone the farthest in our direction, entirely by accident, are the programmers who create design tools for games.
Feel free to keep in touch…
-S
You consider yourself being an Ape, yet you view the world as a Vulcan. I’m sure true Vulcans and Apes exists, but I would argue that the majority of the coding grunts out there fit both; they need to ‘get stuff done’, for which the way of the Ape is clearly the way to go, yet are always in search of ‘getting their stuff done quicker and better’, for which they’ll happily apply any sound advice coming from the true Vulcans.
Your first paragraph strikes me as a common pattern when the “correct” answer is unknown. Replace “programming” with “politics” or “religion” and the same holds true. We’re still searching for the optimal answer, and until we find it, we’ll always be disagreeing with each other.
Coherence kinda feels like UNITY except your concept of coherence is absent in UNITY.
Concerning Vulcans and Apes, I would say to master Vulcan language and tools, but use and combine them with Ape mad creativity.
My 2 cents.
Hi Jonathan,
Thanks for the metaphor explaining the gap between computer science and software engineering. You may enjoy this reading:
http://transformation-machines.com/blog/software_engineering/
Forget about arguments on both sides. Wonderful essay !
Jonathan, you are a hell of a writer.
Just keep writing !