
The IDE Divide (2004) - milesf
http://osteele.com/posts/2004/11/ides
======
bitwize
_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._

Tell that to Tom Lehrer.

Virtually all of the best hackers I can think of eschew IDEs and would be
narratized as "language mavens", but they are very particular about their
tools, have a set of favored tools, and engage in toolsmithing to extend their
reach. Accordingly they select languages in which it is easy to build new
tools. (In the past these were usually C, shell, awk, and later Perl; nowadays
Python and Ruby are the strongest candidates.)

This dichotomy exists only when you consider programmers whose main goal is to
solve problems that fit into a finite number of well-known categories. When a
programmer is regularly confronted with problems of unknown scope and
complexity and needs a way to dynamically extend his reach, he gravitates to
an approach like I described above.

~~~
stephencanon
Tom Lehrer is a brilliant satirist and song writer, but he was never a
"concert pianist" in the sense that that phrase is typically used, and I
understand he essentially stopped being active as a research mathematician ~50
years ago.

That said, there are a number of active research mathematicians who are
outstanding musicians, though they tend to not have the time to play enough
concerts to be known for it (being busy with math).

~~~
dshefchik
What about Caribou ie Dan Snaith? The dude has PhD in Mathematics and an
unbelievably talented musician...yeah I don't really know where I was going
disproving your example

------
MichaelGG
Tooling isn't such a linear improvement as this article makes it out to be.

In VS 2005, Microsoft spent a huge amount of effort adding edit-and-continue
support. This is a feature that requires collaboration from all parts of the
environment. The additional boost to productivity is minimal, compared to
having colouring, auto-complete, and a REPL, and those 3 features combined are
probably less work than EnC.

I'd argue that auto-complete, one of the major IDE/editor features, is alone
responsible for most of the boost I get from coding in an environment.
Instantly, thousands of symbols can move out of my brain and into a list that
appears as I type.

~~~
mattmanser
Woah, woah, you're saying edit and continue, which everyone's flipping out
about in Light Table, isn't that much of an improvement?

I think the problem is more that most people don't know it exists and it's
almost impossible to get Edit and Continue working properly in Visual Studio.
I think I've only ever managed once for console programs, but then it
completely breaks debugging for ASP.net.

There's a load of things I wish worked properly in Visual Studio that don't
that I know would make a massive difference in my productivity. It's almost
impossible to drop into .Net library code, load external symbols, etc. When
you get a gnarly problem where it's due to some 'helpful' utterly insane
choice that the ASP.Net framework guys made the time I would save just
dropping into the code from the IDE is massive, rather than popping open
ILSpy, figuring out the flow and trying to figure out the path the program is
taking.

My workflow is code, read through the code, test the code, fix the code, test
the code, fix the code. Annoyingly during testing I can't edit the damn code
to fix the simple mistakes I've missed. Edit and continue would be great if it
actually worked.

~~~
seanmcdirmid
Light Table goes way beyond "edit and continue," which is small potatoes left
over from Smalltalk (and early systems that support hot code swapping). Light
Table supports much more feedback (we call it live programming), the code is
actually re-evaluated when changed; edit and continue only holds for future,
not previous execution, which is why it breaks so easily.

------
javajosh
Love Oliver Steele. His visualizations and work are really under appreciated
in the world.

As someone who has crossed this divide (and I'd like to think, successfully)
from Tool Maven (Eclipse) to Language Maven, I'd like to say that I much
prefer being a Language Maven. As pleasant as navigating static types can be
in a well-crafted system, I don't think this automatic navigability is worth
the overhead. Taxonomy needs room to evolve, and at any point in time a
statically typed system is making an (unjustified) assertion that yes, this
time we have it right.

That said, I think there is quite a lot of room for inferring taxonomies from
dynamically-typed languages (I'm thinking specifically of JavaScript, but also
of Clojure and Python). After all, human programmers infer taxonomy all the
time. And indeed, this inference has the great benefit of not even pretending
to be set in stone, and is explicitly meta-data about your code, rather than
insinuate itself into your code.

The future is bright and I look forward to seeing the new tooling that can
give us the best of both worlds across a wide variety of languages. (I heard
that Steve Yegge is working on something related to this that at Google.)

------
seanmcdirmid
We language designers must increasingly consider the entire programming
experience: the libraries, the editor, the debugger, even the more social
aspects of the community. The language itself is a tool, and throwing all your
effort into syntax and semantics without regards for how the editor or
debugger will work is ridiculous. And in fact, I'm a strong believer in the
holistic approach where the IDE is actually a part of the language (very
smalltalky).

~~~
JulianWasTaken
I really _don't_ like the core language developers spending time on an IDE or
editor (which is why I would have loved for IDLE to never have been part of
the Python standard library), but just as a tangentially related anecdote on
the value of interaction between language designers and text editors: I found
it eye opening (and insightful) when I learned that in Python the reason why
statements that introduce blocks (if, with, for, while) have colons at the
outset, even though newlines would be enough (as it is in Ruby and elsewhere)
is so that text editors have an easier time indenting: To put it simply, if
you see a colon at the end of a line, you know it's time to indent. No need
for _too_ much parsing.

~~~
abhimishra
Out of curiosity, why don't you like the idea of language developers spending
time on tools?

~~~
markokocic
He just explained it with the semicolon in Python example. The moment when
language designer starts making compromise with the language just because it
would be easier to implement an _official_ editor or IDE is the moment that
language is effectively stopping to advance.

The history has shown that languages developed without concerns of IDE were
the most successful or the most influential languages.

~~~
seanmcdirmid
Whoa. That is a crazy assertion. First, not many languages have been designed
with the IDE as a concern, and second, all the industrial PL design teams that
I know of definitely work closely with their IDE team to ensure harmony
between tooling and language. I'm a bit more radical, all of my recent
languages have been heavily tied to the IDE, to the point that there is know
real boundary between the implementation of the compiler and IDE.

~~~
markokocic
Working closely with the IDE team is a good thing, but core language
developers focusing on the IDE and the language in the same time can indeed
lead to some compromises that hurt the language.

~~~
seanmcdirmid
Working on both might require trade offs in the language that lead to a better
holistic programmer experience. That sounds reasonable to me.

------
msluyter
I'm just curious: are there any java programmers out there who _don't_ use
eclipse or intellij? Having gotten used to intellij recently (and it didn't
take that much effort), I can't really imagine using a plain text editor for
(java) development work.

Edited to add: I'm currently working in Spring, and being able to click from
an xml bean definition directly to a class, and/or from an interface to
implementing classes is pretty nice. I hadn't used Intellij until recently and
it makes working in java much less painful than I had found it in the past.
(It's still somewhat painful...)

~~~
tadfisher
I use Emacs, but in a roundabout way. I've installed the eclim plugin, which
turns Eclipse into a headless server; the corresponding emacs-eclim client
library then speaks to the server to get the niceties such as project
management, autocompletion, import organizing, etc.

The emacs-eclim project could sure use some developers if anyone is
interested. My elisp-fu is pretty weak.

~~~
disgruntledphd2
I need to use Java soon, so I will probably try to support this effort
somewhat. My elisp isn't great though, but learning when you _really_ need a
feature to work properly is typically the most effective way to learn (for me
at least).

------
npsimons
I have a (possibly) more interesting way to approach this divide: ask yourself
how many IDEs (and I mean true out-of-the-box IDEs, not a tweaked Emacs or VIM
setup) from over ten years ago are still in heavy, widespread use. Now ask
yourself how many languages from over ten years ago are still in heavy,
widespread use.

Language designers: please don't design for today's flash-in-the-pan IDEs that
no one will care about in ten years; design a language to last a lifetime (or
more!), and the IDEs will follow. Bonus in that your language won't be locked
to some IDE no one will care about in ten years. Also, wasting your time and
focus on making an IDE for your language will take away from your time and
focus to make your language better, or you may make compromises in the
language for the sake of the IDE.

(and yes, in case you couldn't tell, I'm an Emacs user ;)

------
milesf
This older blog post has become a classic for me, and has greatly influenced
my view of software developers. Was surprised to see that it was not on HN.

If we are going to move forward into parallel programming, the solution is
going to come from the Language Mavens IMHO.

Has anyone ever seen this idea articulated elsewhere?

~~~
abhimishra
I don't think things have to be mutually-exclusive. The article suggests that
you have to be in either the language camp or tools camp because of the time-
investment developers have to make in either - but in reality the investment
is smaller than portrayed IMO.

As for parallel programming - that itself is a wide-spectrum of different
types of programming, and again I don't think we have to paint it as choosing
one or the other.

For example, when I worked on parallel algorithms for very large clusters, I
was really missing some of the things IDEs provide like graphical debuggers.
While a better-designed language may have made some parts of my task easier,
it would also have made low-level optimization much harder.

tl;dr - different things needed for different situations

------
aidenn0
This first two-thirds article is so contrary to my actual experience that I
almost didn't finish reading it. Most people I know that uses a cutting-edge
language bemoans the lack of tooling, and they often hack something up
(usually as an editor plugin) to make due.

Thinking about it more, I do know some people that would fall under the
authors definition of "Language Maven" and I think there it is not the lack of
tooling that makes them eschew tooling, it that so much tooling is garbage. An
example: when you use a cross-reference browser and it either misses some of
the references, or lists so many false-references that you have too low a SNR
to find what you were looking for, it makes you stop using cross-reference
browsers.

------
dmritard96
It depends on what I am working on. If I am writing some stupid GUI in VB, or
something in matlab, etc. - well yeah, may as well use the IDE. For my
projects at home (and when I was in school) I tend to use gedit with a couple
of plugins (nothing lang. specific though) - typically working in c, c++,
python, bash. Sometimes I use vim and for a while I was using emacs for the
gdb integration. I think if I did more remote work I would probably just live
in vim.

------
mariusmg
A good text editor with intellisense and refactoring is all most developers
need. Unfortunately this beast don't exists so we're stuck with VS/Eclipse/etc
for static typed languages.

At least they should try to make IDEs more modular so they can be "stripped"
to editor + intellisense + refactoring. But no....the innards are too twisted
together for this so you're stuck with the entire beast :(

~~~
spullara
I think you could probably do this as long as the IDE understood an external
project file format like maven — getting rid of IDE specific configuration
files is a big win. Otherwise it is hard to know what the dependencies are in
order to allow for intellisense and refactoring.

As soon as you do that though people will ask for plugins and then people will
make plugins and then you'll be back where you started. IntelliJ isn't much
more than a project file format, an editor and a plugin API.

------
yason
I probably don't understand the tool maven. My personal intention is to get
the _tools out of the way_ as much as possible so that I can focus on
programming. Crafting and learning new IDE features and that sort of stuff
seems counter-productive to me.

~~~
abhimishra
What about for IDE features that are 'non-intrusive'. A lot of the editor
features Visual Studio (+ Resharper) or IntelliJ provide don't get 'in my
way'. To be honest I can't think of many ways in which tools get in my way to
be honest, except perhaps initially having to define a 'project' that the IDE
understands (versus just files on disk).

