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.
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).
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
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.
"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."
This is exactly what I had in mind reading this article. My experience with IDEs and languages has been that they are, for the developer, orthogonal to one another. Throughout school I never even touched an IDE - ended up writing a 100KLOC+ program (C compiler) with a text editor and debugging using print statements, no debugger or anything. It was a ball of mud but it worked great.
Where IDEs have really helped me is for larger scale projects, especially where I integrate lots of new-to-me 3rd party libraries. Being able to contextually explore the namespace of the libraries without sorting through all the documentation is a huge time-saver. Refactoring is also a plus; I don't end up using the refactoring tools that often but Eclipse's refactoring beats find-replace any day.
I guess what I'm trying to say is, languages help developers implement algorithms and data structures. These tend to be the 2-by-4s and screws of software development; a high-quality language is a straight, square, well-finished set of building materials that are sized & shaped for the structure you're building. IDEs help explore namespace and refactor, they're your drills and saws. Understandably the building materials can influence how easy it is to work on them with high-powered tools, but from a development perspective, they're complements, not substitutes.
My feeling is similar as your, that is, I consider my IDE to be something that helps me understand and inspect my code. Language features, on the other hand, helps me write code.
No, we had gcc :-P but for a compilers class the goal is to write your own. Lots of people used gdb for debugging their assembly programs and probably at least half the people I know used Eclipse for development.
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.
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.
+1 for edit and continue not working. It rarely does what it says on the tin. Usually in our case as we have 64-bit COM binary dependencies, we can't use it anyway as it doesn't work in 64-bit CLR processes. In 32-bit processes it throws the HRESULT of death MsgBox and dies.
Regarding ASP.Net debugging, I have to resort to the same thing. We actually have a set of custom framework assemblies as a last resort debugging tool that we load into the GAC in a VMware instance which have gone through a tool I wrote using Mono.Cecil that makes all members and classes public and not sealed. They all have exported PDBs as well from MS symbol server so we can step through :)
However, Visual Studio would get a fuck ton more love from me if it didn't crash 8 times a day as well. It's so damn unreliable.
My "other world" of gcc + C + vim + Linux is far more pleasant.
Light Table looks like a REPL on steroids, E-n-C is like REPL on tranquilizers. It has limited use, allowing only limited changes. There's little interactive environment (immediate window), and even that's pretty limited.
So no, I don't think edit and continue is that big of a deal. A REPL would have been easier and more useful, see F# Interactive.
As far as stepping into code, I find the MS symbol server and .NET source code stepping to "just work". But I sympathize with the pain of debugging a deep stack in ASP.NET, trying to figure out how their abstraction worked. For 3rd party libraries, would it not be up to that publisher to publish their own symbols/source?
For me the biggest problem with edit-and-continue in Visual Studio is that you can only edit code when program is paused at breakpoint. You can't change drawing routine formula and observe effects on animation on the second screen. I've seen Notch doing that in Java and it was cool. In VS you get "Changes are not allowed while code is running" error when you start typing.
Even php/javascript feels more interactive than C#, just press F5 and watch the page change. In VS ASP.NET you have to restart whole site (10x longer).
Also edit-and-continue works only for very local changes.
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.)
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).
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.
I looked up that claim about the origin of Python’s block-starting colon. It turns out that making Python easy for editors to parse was indeed one reason, but not the primary reason. The primary reason was that Guido thought that the code looked more readable with the colon than with just an indent.
You caught me ;). I know the FAQ says it's only a minor reason, and that it's just more readable, but I like to leave that part out since it's wrong =p.
I 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.
The 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.
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.
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.
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.
That's an interesting contention. Any chance you could share some examples?
I don't doubt you, but I do wonder at your benchmarks for success and influence.
FWIW, I use Emacs, which is an editor with a programming language embedded. So does that make me a language maven (as I like emacs lisp and playing with it) or a tool maven, because I am learning about the tool I use to edit code (and almost everything else textual)?
I don't agree that it stops the language from advancing. What is your definition of advancement here, exactly? Lots of successful, productive languages pay attention to tooling as well. I see it as just weighing the costs and benefits of various trade-offs.
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...)
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.
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).
I do the same in vim. I do any actual editing of code in vim with eclim loaded. I run eclipse in full GUI mode though, and I switch to that when I want to use the debugger or some of the other Android related tools.
I've been pretty happy with the experience with this setup.
I used to use Netbeans when I was doing java development. It's one of those languages that have so much cruft/overhead you have to deal with that working outside some kind of ide can be very painful.
I've been using vim for class projects recently, but then I haven't needed to deal with particularly long package or symbol names. Eclipse users seemed to struggle a lot with getting the Nachos instructional operating system to work in their environment, which used Makefiles and which is not structured like typical Eclipse projects. I also notice that many of them know very little about the command line, and get instructions from the lecturer for how to set command-line arguments in Eclipse.
Using IntelliJ IDEA for Java has been a real productivity boost compared to C++ in Emacs, mostly for the navigation support (a lot of programming is navigating the existing code base), but also for auto-complete and refactoring.
I 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.
I'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.).
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 ;)
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?
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
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.
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.
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 :(
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.
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.
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).
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.