13 ms·
The IDE Divide (2004)
- milesf 14y agoThis 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 14y agoI 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
- seanmcdirmid 14y agoWe 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 14y agoI 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 14y agoOut of curiosity, why don't you like the idea of language developers spending time on tools?
- JulianWasTaken 14y agoI guess because I fall into the first category. I use the same text editor for a wide spectrum of languages that I fiddle with, and feel like the time spent by core language devs on an IDE is better spent on the language itself. People who work on IDEs / text editors can work on tooling and integrating with languages as they become popular (or before), but developing an IDE from scratch with a language and continuing to support it seems like a waste of time when I personally would never really consider using it and its chances of being a decent text editor are slim. Which is all not to say that I definitely do like coordination between the two camps. So I guess I made two arguments, one that I like what I use and prefer to keep using it over having some new perhaps questionable tool, and two that it's a non-trivial amount of work that has already been done, which I feel is better spent by other external parties rather than core devs.
- seanmcdirmid 14y agoThe PL designer can always customize an editor off the shelf (e.g., Eclipse), and this is what happens mostly. However, I find myself implementing an editor now simply because the idea I want to show off requires many features current editors don't support, like projecting code onto program execution rather than have separate windows for code and inspecting run-time state.
- markokocic 14y agoHe 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.
- msluyter 14y agoI'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...)
- malkia 14y agoI'm not sure what Rich Hickey uses to write the java portion of clojure, but it could be emacs (just wildly guessing).
- abhimishra 14y agoI always used Java with Eclipse or IntelliJ personally. But in the Microsoft world it is not uncommon for coders to use tools that are very 'plain text' and 'ungraphical' like WinDbg even with languages like C#, alongside other tools like Visual Studio.
- martinced 14y agoI've been using IntelliJ since version 4 or so. But there are just so many times where it simply doesn't cut it compare to Emacs that I've always been running both simultaneously, both configured to "re-synch upon file modification" :-/ Rich Hickey said: "Patterns means 'I've run out of language". Someone blogged recently about IDEs being a language smell. I understand if you're stuck in the Java+Hibernate+XML+Spring+SQL development hell that you need IntelliJ. But you're not necessarily being "productive" for doing so: it's pretty much the Java ecosystem forcing that down your throat : ( So if you say: "I can't really imagine using a plain text editor for $BLUB development work" (where $BLUB would be, say, Java or C#) then I kinda see your point (been there, done that). But don't imply that no "development work" is done by people using Emacs / vim. As to me, when I do really need to work in Java, I'm now using Emacs + eclim (Emacs connecting to an Eclipse server to get Eclipse code nagivation, refactoring, etc.).
- 14y ago
- MichaelGG 14y agoTooling 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 14y agoWoah, 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 14y agoLight 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 14y agoLove 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.)
- bitwize 14y agoCongdon 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 14y agoTom 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 14y agoWhat 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
- yason 14y agoI 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 14y agoWhat 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).
- aidenn0 14y agoThis 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.
- mariusmg 14y agoA 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 14y agoI 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.
- dmritard96 14y agoIt 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.
- npsimons 14y agoI 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 ;)