1. 3
    1. 4

      This might have once been true, but I don’t think it is currently true. I think JetBrains and Eclipse have evolved in ways that the original author never imagined in ‘04. If you learn the tooling for a single language in JetBrains or Eclipse, there will often be a plugin for other languages that has very similar keybindings. My hunch is that emacs is similar, although I have only ever used emacs as a text editor with syntax highlighting, or occasionally as a REPL (usually for python—I never used SLIME, and haven’t had good experiences with ENSIME, mostly because scala compiles so slowly).

      Because tools work across many languages, learning tools is a force multiplier. Being an avid vim-scripter, or emacs lisper, or an eclipse junkie, will not only make you more effective in the language you learn it for, but also across all other languages. Yes, knowing the shortcut to compile a program will not be useful for an interpreted language, but it might be useful if you can remap that keybinding to use a linter. F3 goes to method definition will always be useful. Command+shift+t, search for the initials of a class to find where it’s defined in code is far better than using a regex egrep/ack.

      Of course, there will always be some tricks which end up only working where the tooling is the greatest. One of my old mentors showed me a trick where he got around the problem where Java didn’t have smart type inference, and so you would always have to type your parameter twice, something that could get messy with a lot of nested generics, by using eclipse’s smart type inference. Instead of typing:

      TYPE<TYPETY, TYPE, TYPE> x = new TYPE<TYPETY, TYPE, TYPE>()

      he would instead type

      x = new TYPE<TYPETY, TYPE, TYPE>

      And then ask eclipse to fix his errors. The error was that he had omitted the type, so when it fixed it, it added the proper type for him. Three keystrokes (ctrl+1, enter) instead of many.

      I think that this article is good in that it doesn’t necessarily pass judgment on tool-mavens vs. language-maven, but I think that it doesn’t promote being a tool-maven and language-maven sufficiently. I don’t think becoming a low-grade tool-maven is that expensive, especially if you’re not writing your own tools, and because of its force multiplying effects, I think it is very useful. Learning new languages is also important, not only because not every language is good for every job, but also because they make you think in new ways, which is in its own way its own force multiplier.

      The one shitty thing for me about using powerful tools is that they are slow on my puny macbook air. My old dev box had 8 gigs of ram and 4 cores, so it chewed up eclipse like it was nothing, but my macbook air sometimes chokes on “organize imports,” which is frankly an embarrassment. When I just want to read-only a file, or know exactly the change I want to make, I usually use vim instead of tools I know better, just because of its short start-up time (unless I already have an emacs instance running, in which case I just fg it).

      1. 4

        depends on what you consider as a new language. Scala is pretty popular and has a lot of traction compared to, say io. io is an amazing language, and learning it can really change how you think about OOP, but if you have trouble using a language not supported by JetBrains, you are SOL.

        The other thing is that editors have their own form of productivity — they FAR outstripe IDEs in the act of actually manipulating text. An IDE will make that back with stuff like automated refactoring and smart auto-complete, but using vim with minimal language support vs heavy language support isn’t as wide a gap as jetbrains with minimal support vs heavy support.