The IDE Divide

(via Keith)

Oliver Steele:

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....

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.

It has been awhile sine we had a good IDE war er.. discussion...

The distinction between language mavens and tool mavens rings true. It shouldn't be too hard to guess to which camp I belong... I rarely spend time thinking about IDE issues if I can only help it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Smalltalk

Smalltalk is obviously different.

not so different

Smalltalk is just the same.

The huge personal investment in learning and marketing a particular language makes it difficult to step-back and think about it as just another programming language.

(And the huge personal investment in learning and marketing a particular brand of Smalltalk can make one imagine that particular brand defines Smalltalk.)

Another language maven here

I'll try to be provocative in case it might actually tempt someone to try to defend the "tool maven" perspective on LtU...

The article, apparently trying to avoid being provocative, fails to draw one obvious conclusion from the observations presented - if language mavens are able to use more languages, they have more freedom of choice, and are more likely to be able to choose the language that's "the right tool for the job".

The benefits of the kinds of tools referred to in the article (IDEs and RAD tools) are mostly quantitative; the tool can offload some of the work from the programmer.

The benefits of a broader selection of languages are more qualitative; being able to choose an appropriate language can allow a programmer to come up with a better design and better implementation.

In some respects, tools can also improve implementation quality, by performing tasks for the programmer that would be more error prone if done manually - e.g. consider parser generators. However, I'm not sure if it's true of the kind of tools the author of the article was thinking of.

It may also be worth questioning whether it's actually true that IDEs have any significant effect on the productivity of an experienced programmer. They obviously provide some hand-holding for less experienced programmers that may help them significantly, but in my experience, I barely spend any time doing things that an IDE could have any kind of effect on. In that sense, I'm also a "tool maven" - I'm very good at using the tools that I do use efficiently.

I'd be very interested in knowing if anyone does not accept the following claim as obviously true: the knowledge and understanding of different programming languages and programming techniques is far deeper knowledge than the knowledge of the use of an IDE, and is far more likely to make someone a better programmer.

Another means of comparing - which direction do more people move toward with experience? How many former language mavens have become disillusioned with programming language features and come to value IDEs more with experience? Does anyone know of a single case?

Note that I'm not claiming that IDEs, as a concept, are worthless. On the contrary, I can imagine ones that I'd find very useful and more desirable than the tools I currently use, but current mainstream IDEs are pretty far from that ideal.

And what about standards?

I guess I might qualify because I used to try out lots of different languages back when I used emacs. Since I started using IntelliJ, I've pretty much stopped. I haven't found any other language sufficiently tempting to go back to emacs.

One thing that put me over the edge is working on large amounts of legacy code. A good IDE is tremendously valuable for navigating legacy codebases, and IDE features tend to become more valuable as codebases get bigger.

I suspect many "language mavens" work on green-field projects. You normally only get to pick a language if there's no existing code.

That brings me to my next point: the consequence of using "the best tool for the job" without regard for the *other* jobs your organization is doing is that you end up with a legacy codebase written in many different languages. This greatly limits integration and code reuse. Also, you can't go on vacation because nobody else understands your code.

It's far more important to me that other people on the team understand what I write, that we are able to pair-program, and that a wide variety of open-source libraries are available, than to use the latest language features.

The right tool for the job

How about this: instead of using the wrong tool for the job just because nobody in the team understand right tool X, educating those same people about X and why it is the right tool for the job and hence it's a good idea to understand and use it?

Nothing like people's unwillingness to learn new skills... still, why not try?

We don't actually disagree on many things...

Most projects I work on do in fact use mainstream languages. However, as the article notes, a "language maven" may have a deeper understanding of the languages used (even if mainstream) than a "tool maven". Although in this context I'd probably broaden "tool maven" to describe, in general, the kind of developer who prioritizes "just getting something to work" over "doing things right", regardless of whether they like to use an IDE.

I'm also not sure to what extent what you refer to as "trying out lots of different languages" includes gaining a good understanding of the features of and programming techniques allowed by those languages.

Random Thought

Consider Haskell's syntax for monads and arrows, for instance a >> b, c <- d, e >- f -> g. It seems to me that one major motivation behind that syntax is to make the "flow" more pictorial, more visual.

Consider C++ bit shift syntax: a << b. Again there's an arrow-esque symbol, in this case it designates the direction into which you shift. (Yeah I'm stating the obvious... ;)

Consider Python's indentated blocks (or indentation in general). It's a visualization of the concept of nesting.

Consider GUI editors for many languages.

I think there's an important point somewhere behind that. All those languages try to make stuff more "visual" - by overloading operators, by modifying language syntax, by providing external tools, etc. That's why I think it's important to explore possibilities beyond purely textual syntax: Even in a language which provides custom syntax via means of macros or whatever, only the "textual" syntax can be modified/extended if the language is purely "textual".

That's one of the reasons why I'm really interested in projects such as Intentional Programming, which allows arbitrary _views_ onto the program tree/graph - whether it's a purely textual view, or a "GUI editor"-kinda view, or a workflow graph, etc..

I've no idea whether my ideas are coherent in a way.. hope it makes a bit of sense :-)

I don't like it

Quite frankly, like most language-oriented guys here, i abhor the concept of "visual" development. Giving you several visions -- be it UML diagrams, flowcharts or syntax-highlighted code -- is ok, for a high-level overview of the many aspects of the underlying system. A tool forcing you to connect squares with the mouse, or fill in lots of forms accessed via context menus is not.

I don't think a GUI is any good to software development, it just comes in the way too much. It's just much easier to type in (given you're using a good text editor with autocomplete features) the attributes for a class, say, then to drop a class UML diagram in the viewport, then clicking in the properties menu, then typing in names for the attributes, then selecting the type for the attribute, then... and so on...

It's tiresome. Just use a language with some good high-level abstractions or flexible enough to allow you to create them close enough to the problem at hand, instead of trying to comply by the IDE rules and then fight its inadequate GUI.

A tool forcing you to connect

A tool forcing you to connect squares with the mouse, or fill in lots of forms accessed via context menus is not.

I don't want any tool to force that onto me, either. For instance, in a common view in IP you just enter the code using the keyboard, but instead of working in a simple text editor, your commands actually edit an AST in the background. But it feels about the same.

OTOH, there are cases when you would want to use the mouse, like creating GUIs by dropping controls onto a form and visually editing their properties, modelling work flow using a domain-specific editor, refactoring (on all levels of abstraction), etc.

PS: I'm a language-oriented guy :)

DSLs & visual development are a perfect match

Quite frankly, like most language-oriented guys here, i abhor the concept of "visual" development.

There's a distinction between visual development which maps to say, Visual BASIC or Java, and visual development which maps to a DSL.

If you use visual development to generate code in a general purpose language, there's a strong chance that you've skipped an abstraction level: the visual tool effectively implements a visual language which happens to "compile" to e.g. Java, and as with any compiler, you don't really want to mess around with the generated code.

This situation is at best a compromise: not just "worse is better", but perhaps "horrible is better than nothing". But that doesn't mean that all visual development is bad.

For a counterexample, look at e.g. visual tools for relational database schema design. Anyone who's ever worked on a multi-hundred-table schema should know how useful these can be. A big reason for their usefulness is that, as Michael Walter pointed out, they just provide a particular view of the underlying language -- and further, that view is at a semantic level similar to the underlying language.

That means that (ideally) it should be possible to easily edit either the visual view or the underlying language view, and both views should contribute to an understanding of the system.

To bring this back to Oliver Steele's article, the only point he makes that I really accept is that tools catch up with successul languages over time. The rest of what he's saying is an an artifact of our current point history: that current mainstream languages are all pre-theoretic relics of the dark ages of programming, and the tools for more advanced systems haven't yet caught up. What language mavens are doing today are what the tools will support in years to come.

Agree, visuals can be your friends

There's a distinction between visual development which maps to say, Visual BASIC or Java, and visual development which maps to a DSL.
Or, in other words, there are "visual" tools that just duplicate concrete syntax and tools that enable you to access abstract syntax.

My experience is:

  • textual concrete syntax is more concise than graphical
  • typing is more efficient than point-and-click
  • abstract syntax is more natural to work with than concrete one

Therefore, my ideal visual tool will allow several views, accept typing for everything, and operate at AST (or rather ASG) level.

The worst tool would allow only one graphical view, in which you must drag-and-drop parentheses and digits :-)

Not 'visual tools', but user friendly languages

I wouldn't go so far as to call for funky 'views' of source code, but I agree %100 with syntax that helps the user. I had the fortunate to meet Simon Peyton-Jones at a conference several years back, and one of his comments that really rang true for me is that a language's syntax is it's user interface - said with regards to Haskell vs Scheme...

I've been thinking about languages that 'scale down', and one criteria is that you don't need a fancy editor to get started. You ought to be able to use pico or notepad or something like that. Sure, it sounds painful to us, but some people get started that way because they don't know any better.

http://dedasys.com/davidw/

Design the UI after the backend?

a language's syntax is it's user interface

Agree wholeheartedly.

For some applications I believe it makes sense to design UI first (both use cases AND mockups), but for many it's the other way around - build the main logic first, then UI comes naturally on top of that.

Also, for some reason I put PLs into the second category.

Therefore, I believe it makes sense to design abstract syntax first, and only when you are happy with it, should you bother about concrete syntax(es). And I think that graphical concrete syntax is as good as textual for many languages, and even superior for some. Of course, I would prefer to view arithmetical expressions in textual form most of the time (it's more concise), but when it becomes complex enough, I prefer to switch to graphical view (for this expression) instead of counting parentheses. If this switch is performed by a simple chord, and no mouse is touched in the process - where is the harm?

Difference between Languages and Tools?

I think "tools" in the IDE sense are largely overrated. It's nice to be able to create a new class with Cmd-n or something like that, but that's probably not what the author was talking about.

Anything that amounts to source-code manipulation (like refactoring) can be done with a program, which might be written in sh+sed/awk, perl, python, java, lex+yacc+C, elisp, or whatever. In the case of IDEs like Emacs or XCode, scripts are more or less part of the program (I don't know about the extensibility of Eclipse), so I can use the menu entry or keyboard shortcut that allows me to refactor. --> tools have to and can be written.

I want to make two points:
one is that any IDE function has to be written in a language, and I assume there are at least huge verbosity differences between Yacc+SML, ELisp and Java, to name a few. So programmers who extend their own Emacs might be just as productive -- only on a tool basis -- as users of Windows-style IDEs.

The other point is that any language is a tool, or at least the basis for one. Refactoring-scripts and programs like Lint are built with languages, while lex+yacc or Perl, python and other languages are tools actively employed by programmers to do powerful things. Unlike some IDEs they are 100% extensible (i.e. I can always write a new script).

The conclusion is that writing tools is not that much work, if you have written the parser-frontend for the target language. But while a language can grow tools later and thus gain productivity, a language, say Java, can't grow its language, so it doesn't get any better at scripting etc. You can only ever improve your tools, so why not start with a usable language basis and build the tools you need, if you really need them.

I assume the author of the article, as usual, knows his share of C dialects and scripting languages, and doesn't really think outside the IDE-box here...

BTW, it would be interesting to measure the productivity differences (or similarities?) between advanced, say, Eclipse users, Emacs users and shell+vi users :)

The Eclipse experience

One of our second-year courses for CompSci at UWO is a group project (software engineering) course. This year, students have started to migrate toward using Eclipse. I can say, almost without hesitation, that they have a much easier time writing code with Eclipse than they do with Emacs. As for their understanding of Java, well, it remains to be seen.

A friend of mine recently jum

A friend of mine recently jumped ship from emacs to Eclipse, and I have to say the Java mode is impressive when he demos it. He can still do things that amaze the Windows crowd with a few judicious emacs macros, though.

On the positive side, that sort of functionality could be a spur for emacs (still my poison of choice).

I'm an emacser that has dabbled in eclipse

I like eclipse, I didn't expect to. I like the concept also, they just need someone to really beef up CDT, write some really good python and ocaml modules and I could see using it with the emacs bindings quite a bit more.

It still doesn't have that fluid emacs feel to manipulating text. The class browser and some of the different perspectives are cool though.

I think with languages like java, wite long verbose names to classes and methods and often lot's of them scattered about, JDE and eclipse make it a ton easier to code with the assistance features. When writing C++, C, python, perl, or in most functional languages it seems like the developer isn't pulling in so many different parts all of the time. This is just a feeling I've developed after a lot of years in the field.

me too

I have used emacs for some years now, and I still like it. However, when I was writing java for a living, I tried eclipse and couldn't use any other tool for it. It makes writing java code much less painful, and this is not only the code completion: the refactoring and code-generation tools are top notch.

One complaint about eclipse is that it's far harder to extend; with emacs, in a few minutes you write a script to do what you want. The eclipse team considered added scripting support but the initiative stalled more than a year ago. The current view seems to be "if you want to extend it, write a plugin". But sometimes you need a simple thing and don't want to dabble with the plugin architecture and whatnot...

Even so, since my JDT experience I wondered how such kind of tools could help with better languages like OCaml and Haskell. I started the effort to create OCaml plugins for Eclipse; it's pretty much alpha still, and needs much work. I am working on it, but my spare time is scarcier than ever. The Haskell plugins are in better condition.

Scripting

What about those who write tools? Are they tool- or language-mavens? ;-)

I guess designing a scripting language for your IDE, or better yet using Scheme should qualify you as a language-maven, shouldn't it?

Consumerism

Re extensibility: This is my take as well, after briefly dabbling with JEdit and Eclipse on the mac. Despite having plugins and such, both treat all but the most skilled and dedicated users as IDE consumers rather than craftspeople. While both are a far sight better than monolithic apps like CodeWarrior, both expect the majority of users to simply put up with whatever customization is afforeded by the preferences panel. So perhaps Emacs is the proper environment for a hobbyist tool-maven, who is interested in extending his programming environment, but not enough to get to know Eclipse.

Emacs is not for the faint of heart

People used to Windows-style IDEs surely will have much less trouble with Eclipse then with Emacs. Productivity gains show soon, since previous skills with similar tools already count. Advanced uses of Emacs don't show before 1 year, i guess. And that means RTFM, something most people simply aren't willing to do so often...

I wonder though, if Gosling would code faster in Emacs or in Eclipse. That should be fair.

Well, perhaps today he's more of a Netbeans guy... :P

It's all an evil Joke..

People used to Windows-style IDEs surely will have much less trouble with Eclipse then with Emacs.

I have had the unfortunate task of introducing Old Windows Dogs to New Linux tricks.

I made the mistake of not ramming Emacs down their throats on day one. I went soft and let them use whatever they chose. Things like Visual Slick and kdevelop. Emacs CUA-mode etc. etc.

Waste of time.

The poor blighters are totally stuck as soon as they hit the command line.

Or typing in a text form like this one on Mozilla. ALL OTHER TOOLS USE EMACS BINDINGS ANYWAY! BAW-HA-HA-HA-HA! (Mad evil genius laugh)

Going back on topic...

Language Mavens use emacs 'cos you can trivially tie in any language you want and extend it with Elisp or via pipes to whatever language or tool you care to.

I have had the unfortunate ta

I have had the unfortunate task of introducing Old Windows Dogs to New Linux tricks.

Shouldn't that be "New Windows Dogs to old UNIX tricks," seeing as most UNIX/Linux shells predate Windows.

But...

...what if you're the only one on your team using Haskell in Eclipse?

Little to say...

...other than (1) you are either insane or insanely productive; and (2) your machine must have way too much RAM. I thought the appeal of Eclipse was that, like Smalltalk and Unix, the development and environment construction languages were the same. Out of curiosity, do you bother to customize Eclipse, and if so, in what language?

Scheme plugin

I do bother to customize Eclipse. I have begun the development of a Scheme plug-in a few months ago (SchemeScript), almost entirely written in Java, and I'm planning to write other plug-ins for some proprietary languages.

But to be honest, I do prefer hacking Emacs. Developing plug-ins for Eclipse is not always fun: (1) there are so many APIs to know, (2) you cannot modify the environment and test it immediately (you have to start another Eclipse to test your code...).

So why bother writing this plug-in? Well, I program in Scheme at work and all other developers use Eclipse for Java programming for other parts of the same project. So it made sense to have a unified environment. Having to switch between XEmacs and Eclipse all the time was a pain. And Eclipse is definitely a more modern environment. You don't have to design all your views using only a text-based interface.

I only I could hack Eclipse the way I hack XEmacs...

Emacs hacking

But to be honest, I do prefer hacking Emacs. Developing plug-ins for Eclipse is not always fun: (1) there are so many APIs to know...

Emacs has a never-ending supply of those as well!