Lambda the Ultimate

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

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.

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?

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.

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 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 :)

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.

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

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 :-)

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/

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?

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

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.

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

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.

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

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

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

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!