The developer world is divided into two camps. Language mavens wax rhapsodic about the power of higher-level programming —- first-class functions, staged programming, AOP, MOPs, and reflection. Tool mavens are skilled at the use of integrated build and debug tools, integrated documentation, code completion, refactoring, and code comprehension. Language mavens tend to use a text editor such as emacs or vim —- these editors are more likely to work for new languages. Tool mavens tend to use IDEs such as Visual Studio, Eclipse, or IntelliJ, that integrate a variety of development tools1.
New languages, such as Laszlo and Groovy, and new language extensions, such as AOP, are typically available for text-editor-only development before they have support within an IDE2. After a while, if the language or extension is successful, the tools catch up. This isn’t just because it’s harder to implement a tool than just a language. It’s because language expertise and tool expertise are to a certain extent alternatives, that each reinforce themselves to the exclusion of the other. Here’s why.
Language-Maven Perspective
If you’ve spent most of your time learning about languages and how to use them, your picture of the world may look like this:
In this diagram, the choice of language can make a great deal of difference to your productivity, because you know how to apply each language feature to a variety of situations. The choice of IDE, on the other hand, doesn’t matter much, because you’re mostly using the IDE for its text editor —- maybe with a little bit of compilation support thrown in, but not for the whole set of modern IDE features that a modern tool maven uses.
Tool-Maven Perspective
Conversely, if you’ve spent most of your time mastering the development tools of your trade, you understand what it’s like to get into a flow state with an integrated editor and debugger, and to go at a program with refactoring and code comprehension tools at your disposal. Your picture of the world may look like this:
An IDE presents huge advantages relative to a simple text editor, for you. The choice of programming language, on the other hand, doesn’t matter that much —- you’re mostly working with the same old classes and methods, statements and expressions, in any of them, and the real development power comes from the IDE.
Two Camps
Why can’t one be a language maven and a tool maven? It’s hard. One reason is that developers have limited time, especially for learning new skills. You can use any given block of time to master language features, or to master development tools. Each of these choices contributes to a positive feedback cycle, but they’re competing cycles, so they create divided camps.
Taking the time to learn language features puts you in a position to appreciate the features of new languages. You can then adopt a language before tools support it, because you don’t rely on the tools for your productivity anyway. And it’s worth adopting these tools early, because their features are valuable to you —- making use of them is where your expertise lies.
Invest the time in mastering development tools, on the other hand, and you won’t want to give these tools up to try a new language —- the development tools are a major part of your productivity. For you, a new language doesn’t have many advantages over other languages anyway, because you haven’t studied how to use language features to make you productive.
This means that the more you invest in language features, the more they benefit you, to the exclusion of tool features —- and vice versa. And this is what creates the two camps, with two perspectives on the relative merits of language features and tool support:
Language Buffet
At any given time, the editor-only developer is in a position to choose from a wider selection of languages —- because, at any given time, more languages have a compiler and a runtime, than a compiler and a runtime and a language-aware editor and and debugger and etc.. The diagram below shows what this looks like for a number of languages at different points in their evolution. Within each language, the line at the end of the red transition marks the point at which it has acquired enough features to be useful for some class of programming. The line at the end of the purple transition marks the point at which tool support (beyond a compiler and runtime) exists for it too. At any time, more languages are programmable (the red squares) than have tool support (the blue squares).
One consequence of the greater language selection available to the editor-only developer is it typically includes languages that are more powerful. So while one reason that the “Language” block is bigger in the “langauge maven” illustration above (reproduced below) is that the language maven dedicates more time to learning how to leverage language features, the other reason is that the language maven may have a more powerful language to work with, because there are more languages available to her.
The Language Developers Dilemma
In fact, the most powerful languages may initially have the least powerful tool support. The reason for this is that the language developer, like the language adopter, has to make a choice: whether to dedicate limited development resources towards language features, or towards tool support3.
Consider the diagram below. This diagram represents three languages, whose respective developers have chosen to concentrate initially on language features (the top arrow), on tool support (the left arrow), or (the middle arrow) a middle-of-the-road strategy that emphasizes them both equally. The arrows are roughly the same length, representing roughly equal amounts of effort.
Although the arrows are equal length, they achieve different levels of language features and tool support. The “language-first” strategy of language development achieves a greater degree of language features, as indicated by the red tics across the bottom, but a lesser degree of tool support, as indicated by the blue tics across the right. And conversely for the tool-first strategy.
Of course, if a language succeeds, it will eventually get tool support. So in the long run both the language and the tool mavens will use the popular languages, such as Java. That’s where I’m hoping we’re going with Laszlo.
The Perils of the Pioneer
All this makes the language approach sound comparable to the tool approach; it’s just a matter of which skills to learn. But this isn’t always true. We could argue about whether understanding closures or a source debugger makes one more productive. But what isn’t arguable is that there are penalties, beyond the lack of tools, to adopting a language early.
One is that the language may not have staying power. Another is that, just as tools lag initial development, so do other ecosystem artifacts such as books, articles, newsgroups, and, in the enterprise world, the ability to hire developers who know a language, or to be hired on the basis of knowing one.
There are contexts where none of these disadvantages matters. If you learn languages easily, finish projects quickly, and move on to new projects frequently, it doesn’t matter whether a language is going to succeed, so long as it helps you with your current project. If you learn languages from reading source code or reference manuals, you don’t need the books and articles that will follow later. And if you’re working with a small team (perhaps as small as one) of elite developers, you aren’t hiring them for what they already know anyway.
Which isn’t to say that you can’t be an elite tool maven too, it’s just that the conditions for success are different. You can be the only one on a team to use Eclipse. If you’re the only one on your team using Haskell, something is probably wrong.
Comments
Bob Congdon points out Lisp and Smalltalk as counterexamples to the “language developer’s dilemma”: both are powerful languages with powerful development environments.
Lisp was a powerful language first, and had a powerful environment second: it only appears to be an exception because it has been around so much longer than any other extant language and has had time to acquire both. Smalltalk, however, is a genuine exception. Smalltalk might be viewed as a step backwards in language features from Simula 67, and a simultaneous step forwards in tool support —- but this is holding the language to a higher standard than any other.
Congdon also points out that it is possible to both a language maven and a tool maven. True in theory, just as it’s possible in principle to become both a concert pianist and mathematician, but in practice there may not be enough hours in the day to do both.
And Harry Fuecks explains some of what I was trying to say better than I did, as well as adding points of his own.
Notes
1 A sophisticated emacs user, who uses something like psgml-mode or jde for every single language they edit, is arguably in both camps. I haven’t met many of those, though. The emacs users I know use it configure it as an HTML-editor or a TEX-editor, say, but use it as a text editor for everything else.
2 C#, with Visual Studio.NET, was an exception —- at least, if you’re outside Microsoft. Microsoft is an exception to almost everything.
3 And this is why Microsoft is an exception: because its development resources are effectively unlmited.
Comments
Very, very good post.
I'm teaching several classes at university and I have used some part of this post in order to teach several concepts.
What type of ajax projects do you normally do ?
Regards
[...] Oliver Steele writes: [...]
[...] What do Sophisticated Languages Have To Offer? September 15, 2007 – 8:58 pm | by ProCOM | 1 Views If you're new here, you may want to subscribe to my RSS feed. So that you can read the latest updates about Web2.0 tools, Making Money Online, Tips in SEO, Ajax and many more. Thanks for visiting ProgramimiCOM!Oliver Steele has written an interesting article, The IDE Divide, describing two camps in the developer world: language mavens and tool mavens. If you frequent this blog you should be well aware that I am pretty excited about Code Browser, a simple text editor with some cool folding capabilities. And as I find programming languages to be one of the most interesting subjects in the field of computer science, I think that I would intuitively put myself in the language camp. I would like to claim that language design will provide programmers with the required tools to improve their efficiency in the years to come. I am starting to doubt that this is the case, though. I wonder if this divide is related to static versus dynamic typing. It seems to me that for an IDE to be any good, your language has to be somewhat towards the static end of the scale. The more binding that takes place at run-time, the less can be inferred by the IDE when editing. Bruce Eckel argues that a Python IDE is not quite as necessary as Java IDEs are. In Python, he claims, productivity is inherent in the language whereas in Java, you get the boost from the IDE. Now I know that dynamic typing people hate the insulting “scripting language†argument but I am going to take it up anyway: what about large systems? I am not claiming that you cannot make or maintain large systems with dynamically typed languages. In fact, I think they might work very well for such systems. But with large systems, I find that the IDE really comes to the rescue. Intellisense provides me with the documentation that I need 90% of the time, right at my fingertips. The live parsing and syntax error highlighting is something that I could easily do without. But knowing which methods a class has, which parameters a function takes and what their types and names are is invaluable. I am reminded of the GMail slogan: Search, don’t sort. I think this resembles the main difference between the language camp and the IDE camp. Language people like to sort, IDE people like to search. When a system grows, the complexity will grow with it. Introducing layers and abstractions help - they’re indispensable, but they can’t remove complexity completely. Even if you have perfectly refactored code forming a tree of abstractions, you will have to trace through it vertically as well as horizontally. There will be many functions, files and lines of code. And in this case, I think that the IDE and the search “paradigm†work better. As I said, I would really hate to claim that language research is unimportant, and I would love to be convinced that I am wrong here. Maybe I should do some work on Chandler or some other large, dynamically typed project, just to see what it is like.. [?] Share This Print This Post Email This Post [...]
[...] If you are unsure what good these commands are to you, because you have “better tools”, I invite you to read Oliver Steele’s The IDE Divide. [...]
[...] Das erinnert mich an den sehr interessanten Eintrag The IDE Divide bei Oliver Steele. Grob gesagt geht es um eine Eigenschaft, die Softwareentwickler in zwei Lager trennt: Es gibt Hacker, die die Sprache beherrschen und dadurch produktiv sind. Auf der anderen Seite gibt es Hacker, die produktiv sind, weil sie ein Tool (eine IDE) beherrschen. Gleichzeitig geht es darum, ob man ‘on the edge’ in Sachen Sprachentwicklung ist, oder wartet, bis Tools vorhanden sind, die das Entwickeln in der Sprache unterstützen und vereinfachen. Wie gesagt, ein interessanter Eintrag. [...]
[...] In programming naked I already mentioned The IDE Divide by OliverSteele. In that article Mr. Steele talks about two kinds of hackers: (1) the ones that hack in a text-editor and (2) the other fraction that hacks in an IDE. I am rather clearly in that latter camp knowing keyboard-shortcuts most people don’t know existed and soon customizing things so that they better fit me and my way of doing things. Eclipse is a very fine IDE for such kind of people. I know. I had to switch to VisualStudio for my new job. I especially miss Eclipse’s ReFactoring-features. Moving code around, increasing (hopefully) the quality of SoftwareArchitecture and beautifying code is one of my favorite pastimes. [...]
[...] Something that often puzzles me is that I often find myself at odds with my peers with regards to selection of tools, languages and, to a lesser degree, operating systems. I really haven’t had a real clear understanding of why this is the case. For me, IDE’s are sort of a clunky inconvenience that constrains the way that you think about things. To be clear, I’m not criticising IDE’s per sae, I’m saying that they present certain difficulties for me. Anyway, this blog post makes a distinction that clarifies the differences between me and many of my peers. The author categorizes programmers into two groups, language mavens, and tool mavens. I think that I definitely fall within the language maven camp. I love learning about computer languages. To me, it’s very satisfying to pick a language unknown to me that is particularly suited to solve a novel problem. On the other hand, most of the folks I work with would use C# .NET and Visual Studio to solve nearly all problems. Again, I’m not saying one approach has merit over the other, each just represents different ways of looking at things. I would go so far to say that in most cases, the tool mavens are more productive than us language mavens. However, I’ve seen many cases where the tool mavens get themselves backed into a corner through inappropriate application of their limited tool-set to solve a problem. In these cases, they burn up a tremendous amount of time and either don’t solve the problem at all, or solve it poorly. I suppose, like many things in life, the best approach is to stay flexible and be open to both approaches. [...]
What do Sophisticated Languages Have To Offer?...
Oliver Steele has written an interesting article, The IDE Divide, describing two camps in the developer world: language mavens and tool mavens.
If you frequent this blog you should be well aware that I am pretty excited about Code Browser, a simple tex...
[...] Braithwaite’in bu sözleri bana Oliver Steele’nin The IDE Divide yazısını hatırlattı. [...]
[...] Oliver Steele » Blog Archive » The IDE Divide A great overview about the difference between language mavens and the tools mavens. (tags: programming productivity tools) [...]
[...] Interesting angle on programming: Tool-based vs. language-based approaches to improving programming. [...]
[...] April 7th, 2006 in Links The IDE Divide, a discussion about the difference between text-editor lovers and IDEites. [...]
[...] Pyre blogjárol jutottam ide. Sok meglepetésre nem kell számÃtani, inkább csak összefoglalja amit zokszigen már jó ideje sulykol belém. [...]
[...] Interesting essay about the trade-off between familiarity with language features and IDE features: http://osteele.com/archives/2004/11/ides Oliver Steele wrote: Taking the time to learn language features puts you in a position to appreciate the fea [...]
[...] code should no longer be used. Second one discusses developers that are attached to using IDEs vs. the no IDE developers. And lastly, this one is an interesting idea but it’s doable only in . [...]
Les outils de RAD et le monde PHP
Le 14 avril prochain aura lieu le prochain Rendez-Vous AFUP : DreamWeaver, un outil de RAD pour PHP. Les inscriptions sont ouvertes depuis 2 jours seulement et au rythme où vont les choses, ça sera très vite plein (on peut accueillir 50 personnes et je...
Experts and categories.
Oliver Steele has written post that categories programmers into two camps--language mavens and tool mavens.
IDE lockdown - give my Java back
With the recent proliferation of IDEs, a Java developer should be aware not to fall prey to the "shortcut lockdown" honeycomb trap.
[...] engo bases - estoy en mejor posición - para hacer una comparación imparcial. Más aún, yo soy un language maven. Pero definitivamente la libertad es mucho más importante para mi que para ti [...]
[...] eiben.
Das Blog von Oliver Steele - Languages of the real and artificial - habe ich wegen The IDE Divide zum ersten Mal besucht. Via Eclipse download hell.
Paolo Massa Blog - Ramblings on Trust [...]
[...] vide
Filed under: General AgitProp — edwards @ 11:44 am
Oliver Steele observes a significant division among programmers: the Language Mavens vs. the Tool Mavens. I want to ex [...]
Crossing the IDE Divide
Oliver Steele observes a significant division among programmers: the Language Mavens vs. the Tool Mavens. I want to explore this distinction further, and use it to make a point about the nature of programming. You see, for a long time I was a Language ...
Hey Maestro, Can You Spare Me An IDE?
Oliver Steele has an entry/article on the IDE Divide which serves as a budding focal point for a flame war between the emacs/vim people and the Eclipse/Visual-Studio users. Steele elaborates his point with lots of pretty pictures that developers with...
[...] e one that I needed.
I'm a huge fan of Eclipse: it makes Java development bearable (see the IDE Divide) but installing it is such a pain I nearly gave up! A note to the Eclipse guys: please, p [...]
links for 2004-11-27
Oliver Steele: » The IDE Divide Interesting article on advanced languages and advanced programming tools and the limited intersections...
Oliver Steele on "The IDE Game"
I'm not sure if I like Oliver Steele so much 'cause he's so dam smart, is a nice guy, or becuase he's the principle architect and programmer behind Laszlo. His theme of "The IDE Game" is appropos - since IBM just announced that Eclipse will be an...
IDE vs Text Editor
Very well thought out piece on The IDE Divide: The developer world is divided into two camps. Language mavens wax rhapsodic about the power of higher-level programming — first-class functions, staged programming, AOP, MOPs, and reflection. Tool maven...