At some point I think I realized that no matter how feature-rich my editor was, the main thing stopping me from writing good and fast code was _thinking_, not configuring my text editor.
This would ring in the back of my head as I spent many hours configuring my editor / shell / terminal setup. It felt like a guilty pleasure.
It dawned on me however, that what had drawn me to programming in the first place was a sublime text editor (TextMate), and that my business is in fact tool-building. My love for computing tools and the experience of using them reflects in the kind of software I build for clients.
On top of this, evaluating and obsessing over hacker's tools isn't confined to picking between models at the hardware store. I have pored over (and patched, however minor) bash, vim, tmux, rxvt-unicode, and many other programs that I use every day.
These things may well be rationalizations, so here's a simpler justification: the time I invest into my tools have made my experience of sitting down in front of a computer incredibly enjoyable. I once lived computer free for three years because I detested the uninspiring (and frustrating) experience of Microsoft Word and Windows 98. If that was what computing was, I wanted nothing to do with it.
I've found that too, asnd it helps me be productive. I run MediaWiki on my PC as my internal documentation system. I used to use it with the default skin, which looks a bit meh, but I recently added my own skin, which looks a lot nicer. I found that every time I looked at the wiki after that, I got a little hit of joy from looking at a nicely-skinned page.
This is the root cause of the endless Vi vs. Emacs debates as well.
But nobody comes to VIm knowing how to use it intuitively. Its features make the investment worthwhile. Same with Sublime Text 2. There are features that instantly save time (the tiny thumbnail of your entire file makes traversal a breeze for me) and others than take a while to get used to (ctrl-P).
The question shouldn't be, "Should I waste time looking at ANY tools?" especially in the ironic context of, "I've used two decades of my life learning VIm and now it ROCKS." It's, "What does this tool have that makes it worth using?" That answer for me so far is speed, flexibility, and features, like the two above. I'd hoped to see more on those topics here.
When I want to use VIm, I do. When I want to use JEdit, I do. As the previous fellow replying says, you don't simply use hammers. Figure out where this tool -- which is a very good one -- fits. Its best feature might be its untimed trial period. Give it a shot.
Actually, someone from design background once told me "Good tools produce great work".
and he also said that your tools protect you.. the day you get a flat tire is exactly the day you put your tools out of the car...
Same goes for a very simple word completion - when the editor already encountered the word in the previous line.
These are just _very_ basic things.
I'm not that fast and to be honest I really don't miss code completion at all.
Another invaluable feature related to this is documentation as you type. I can never remember the order of the arguments to the fold function. Fortunately Visual Studio helps out: https://dl.dropbox.com/u/388822/intellisense.gif (somehow my mouse pointer shows up in white, which makes it hard to see, but if you hover over the variables you get type information & documentation).
I would argue that the autocompletion training wheels for learning a new API are really only useful if you're rarely going to use that API again. If you're going to be using it a lot, there's actual value in spending the extra effort to learn it's functions. It'll stick more. Unless you have a photographic memory your brain will tend to discard information it had to expend no effort on, and autocompletion basically becomes background noise. I theorize that a fast typist will gain the edge after using the API 10+ times, even if they have to look it up the first couple of times, because the additional effort and focus they had to give to the task will commit it to memory (and they will potentially learn more about what the API is doing).
The focus is often on typing the fewest characters, but I think that's the wrong thing to focus on most of the time when choosing an editor.
Only ever using 5 libs does sound incredibly boring. However the toolbox of libraries I've accumulated repeated experience with over the years is in the hundreds, and learning more about them has proven worthwhile. I assume most developers would say the same.
Couldn't agree more with the second sentence: I actually print out a listing of common APIs and take the time to memorize them. But you just described 90% of the APIs in your first sentence. For those APIs having quick access to autocompletion lists (to see which methods an object supports) and quick access to documentation is tremendously useful. As for your theory, common sense would say that how much you learn is proportional to the time spend on it. So if you use the API 10 times by looking it up manually, and you use the API 10 times by looking it up in contextual autocomplete, then yes you're going to learn more with the manual lookup. But this is an unfair comparison: you'd spend much more time on the latter than on the former. In the same time to look up the API 10 times manually, you could have looked it up in contextual autocomplete 30 times and then you'd have memorized it just as well.
I sense a lot of irrational aversion to autocomplete, that it's for slow typists, it's training wheels, and Real Men don't use it. Look at it as an incredibly quick way to look up documentation. In fact unless the method name is really long I do not use autocomplete as autocomplete at all: I fully type the method name instead of hitting a key to accept the completion. It's just a way to short circuit the process of switching to a web browser, searching for and reading the documentation of the relevant class/module, and switching back to the editor.
I don't think autocompleting a call 30 times is nearly as valuable as looking it up for me at least, because since I'm already invested I'll take the time to learn about it. If all I did was tab complete something and it seemed to work I'd be far too lazy to dig any deeper. I don't see why I'd spend any more time on it during consecutive autocompletes either.
Also, when I use a new library chances are very high that I'll be using it over and over and over again. It's more like 10% of APIs that I'll never use again (but still may learn something). I'm speaking purely from experience, and it baffles me that others stated finding so little library re-use. That sounds incredibly frustrating.
It's been my experience having used autocomplete tools in the past (4-5 years ago would be the last time) I don't miss them at all. I don't think they provide me with any real benefits. This is completely thought through and rational IMO. However I will grant you that it's potentially subjective and not everyone would see the same benefits.
These days 99% of all Java/C# coding is in IDE's. And rightly so, because there is no reason to subject yourself to the torture of programming using an text editor. That sort of verbosity and boiler plate should be handled by tools, not humans.
People who code using simple text editors, in highly verbose and boiler plate demanding languages like Java are exceptional few and going by the trend will never be the norm.
I think the trend will actually go the other way though and there'll be less gigantic IDE usage in the future, but I'm not going to put money on it.
1. Ctrl-1: Automatically tries to fix a compile error. I use this a lot to get my imports automatically, and for other random things.
2. Open Declaration: This was touched on by others and is incredibly useful. The IDE can find the right Class even if two have the same name, while search can make this difficult in some cases.
3. Show References: Similar to above, this is just incredibly useful when you are refactoring or need to see how something is used.
4. Generate getters and setters: I know this one is dumb, but it's so convenient. I just hover over the unused warning then click, and i've got the code.
This editor is snazzy and fast but I don't think I can make the switch.
I wouldn't disagree about learning the libraries you use frequently, but I personally work on a huge stack with more than 80 dependencies and memorizing their api's just isn't time well spent.
Or, I work with a REPL. So I write the code there and run it before putting it into my code base, so I know it's correct.
Dynamic languages grant huge power to small programs. Greater power through less code is surely the future.
It is detailed in the later part of this Alan Kay presentation:
https://www.tele-task.de/archive/video/flash/14029/
( around minute 45 or so up, perhaps earlier for more background )
Tool generated code, might be a big thing in the future. Eclipse + Java is already 80% tool generated code.
Configuring my text editor isn't the main thing stopping me from writing good and fast code, but a badly configured editor does inhibit it. Working with 0 plugins is not a bad deal, but I am missing the point why I would want to.
Sure I can manually comment/uncomment(nerdtree), manually write nested html(zenconding), manually balance parens when writing clojure/racket(paredit, autoclose), do a :ls and buffer switch(bufexplorer), diff swap file and on disk file and recover accordingly(recover)....etc etc.
These aren't the most important things when it comes to writing good code. That doesn't mean it doesn't help. My .vimrc is 300 lines, and there is nothing in there which I don't need or which doesn't help me write fast code.
These simple abbreviations save me a ton of irritation:
inoremap \1 <%<Space><Space>%><Esc>2hi
inoremap \2 <%=<Space><Space>%><Esc>2hi
inoremap \3 {%<Space><Space>%}<Esc>2hi
inoremap \4 {{<Space><Space>}}<Esc>2hi
Adding simple customization to vimrc is simple. Plugins are even simpler. Committing the shortcuts to muscle memory is not as simple. But if you really need the customization/plugin, that means you will be using it and it will become muscle memory very quickly.
Thinking is the major hurdle when it comes to writing good code, but it isn't the only one. The other factors are important.
If I want to use vim, I can use vim. Heck there are many things these days that will give you the same GUI candy what GUI based text editors give.
Glossy text editors come and go every 2-3 years, Editors like Emacs and vim stay.
The next question then must be: when do we start writing the next generation of tools? Now, or should we wait?
Firstly you are not going to live for the coming 100 years. So lets not worry about impossible scenarios.
Secondly next generation tools for the next hundred years need to be designed such.
36 years × 39 = 1482 more years of Vi.
I know Vim has NerdTree and the equivalent Cmd-T plugin - I have tried them and they don't work out quite the same.
There are still lots of things I like about Vim that aren't there in Sublime but it's all about compromises. I still use Vim for editing single files but use Sublime for any project that requires multiple files to be opened and edited.
Classical pianists don't. Every other kind of professional pianist does it all the time.
Except if you don't consider someone like Keith Jarrett, Herby Hancock or Chick Corea a "professinal pianist".
As for "not supporting all the vim keystrokes", ever heard of the 80/20 rule?
Editors are vastly more complex than necessary.
I want an editor like google.com. It's simple "sentence" model totally wins. Of course, creation instead of consumption requires additional abstractions.
Three dimensions build an entire universe. An editor built with three choice abstractions could outstrip every other editor conceived. Ever.
Somebody do it.
1. all text is "alive" for the purposes of executing/finding
2. select/execute/find for left/middle/right mouse clicks
3. ed-like command language (sam) plus structural regexes with conditions and loops
The lack of syntax highlighting is a usability problem, but also the fact that there's no good way to integrate it into something like acme is evidence that we're still missing one of these dimensions. The general problem seems to be recovering structure from the text on-the-fly and doing something with it, like highlighting or special structured editing. Emacs gets its "power" by letting the programmer directly manage what's on the screen and what happens for any key press. Editors like SublimeText and TextMate just have keybindings and language grammars, and syntax highlighting is sort of built-in.
If we had a good general solution to this problem and could plug it into acme, acme would really be compelling. But I can't really use an editor that lacks syntax highlighting.
And of sam and how some of the best programmers I know use sam[1] a language that provides even less configurability than acme.
[1]: http://sam.cat-v.org
http://ipn.caerwyn.com/search/label/acme
If I understand correctly, these hinge on 9p; instead of Acme worrying about keypresses, it's some 9p client worrying about characters read. A clever solution, and self-evidently powerful, but with the obvious drawback that most of us aren't running Plan 9 or Inferno. And we still have the problem of syntax highlighting.
As someone with a computer that is horribly unstable (in the process of replacing it over the course of next month), the swap file has saved my ass on a few occasions.
set directory=~/tmp
set expandtab
au FileType make setlocal noexpandtabYou simply
set filetype plugin on
Within those, you can do things like setting expandtab or the tab/shift width - they are full local subconfigurations which override your global configuration. They are usually not very large (5 lines on average for me), but it sure helps keep things organized and easy to find and change.
http://utcc.utoronto.ca/~cks/space/blog/programming/FancyPro...
Vim is capable, out of the box, of everything a more heavyweight editor can do. The only thing really missing is library aware code completion.
I spend most of my time at a black/white board. Once I've won the chalkboard battle, I've put it into motion with chalk, whiteboard markers, and just wrote the computer code. I recommend the latter, though that still leaves a few options open.
For now, I'll let conciseness win.
When it sunk in for me, I found myself combining operations in new ways without thinking about it. The situations where I really have to think about what I'm doing are usually when it's something weird like encodings or huge blocks of strangely formatted daily-wtf-worthy legacy code.
Sublime Text certainly has a lower upfront commitment cost to productivity, though. I still pop it open occasionally just because Ctrl-D is amazing.