Archive for the ‘Coding’ Category
A couple of months ago I bent the ear of a friend whose opinion I really respect. She’s a totally sharp engineer who actively writes code for a living as well as managing large teams. She’s held top-level technical roles at some large and extremely respectable companies. In short, her perspective and experience is very valuable.
One of my most important questions was what technologies she saw as established or emerging winners — good technologies to use as the foundation for a startup. I had a list of requirements I needed my technologies to meet, but I wanted to know what other requirements she thought would be important to consider. For example, the ability to hire engineers to work with the technologies.
My prime candidate for a main programming language was Go, and I was also considering Java, Scala, Clojure, and C/C++. Most languages were easy to eliminate based on my requirements. I tried to summarize my reasons for Go and against others, and asked what she thought.
In the weeks that followed, I did a lot of hard thinking, and also sought the advice of many other people. In the end, I chose Go as a main language, and so far I don’t see a reason to change that decision.
Why would I choose Go when so many factors seemingly weigh against it? Partly because it’s easier to meet many of my specific requirements in Go than it is in other languages. Meeting these requirements gives a lot of business benefits (significantly lowering the barrier to customer adoption, for example).
So regardless of the negatives, the positives for Go for my specific use case are very strong.
In addition, the usual benefits discussed about Go are turning out to be very true in my experience. You can read some articles or watch some talks on golang.org to see what those benefits are. It’s not hype; Go really is that good. Check out this great talk.
The real reason I chose Go, though, is that I took it for a test drive and found out for myself. Not just reading about it or doing code tours and walk-throughs — building systems with it. I decided to reimplement my most recent Perl program in Go and see how it went. The program does adaptive fault detection on time-series data at a fine resolution. It takes 1m16s to run on a sample dataset I use a lot. After rewriting it clumsily in Go, it runs in a few seconds. Keep in mind that I’m not a novice Perl programmer, and I don’t think my Perl program could be made much faster. This is an illustration of the execution speed difference between a scripting language and a compiled language.
That was a nice validation, but I wasn’t close to being ready to decide on Go. I spent a few weeks implementing throwaway prototypes for risky or uncertain parts of my planned system in Go, as well as writing portions of things that I knew would be humdrum turn-the-crank code. Along the way I learned a bit about designing to Go’s strengths, and started to become a little bit more productive (I am not as fast a learner as many of the people who say they’ve learned Go in a couple of weeks). I probed into things like how robust its support for MySQL client libraries is, and how easy it is to work with C or C++ libraries in case something doesn’t exist in Go but does in a C library.
I also dug a lot into the community: the mailing list, the blogs, the projects that companies build in Go. It turns out there’s a lot more adoption of Go than I thought at first. There are many major systems written with it, some of them at hot up-and-coming companies, some at older companies. It’s not just Google.
In the end, I still really appreciate the advice from my friend. It was good advice and pointed out a number of things I needed to think about more or investigate further. But you have to make your own decisions, not just follow advice. And that’s the difference between asking a friend for an opinion, and asking a friend to decide for you.
Terminal-based, keystroke-driven editors are enormously powerful, and I still haven’t seen anything more powerful than Vim. I’m a longtime Vim user, and although I’m not the world’s foremost jaw-dropping expert on Vim, I would call myself an advanced power user at the very least, and probably a true expert. Still, I have maintained a relationship with GUI text editors over the years, too. An editor that has an insertion point for a cursor, and “native” mouse interaction, has an appeal I’ve never quite shaken. I’ve used (and been highly productive with) Kate, GEdit, Notepad++, Visual Studio, and many others. I have purchased licenses for Textpad, Textmate, and most recently Sublime Text 2.
Sublime Text is a very nice editor. I’ve chosen it for my recent Go programming because of the GoSublime integration, which uses gocode (which also works for Vim, by the way) to provide IDE-like autocomplete and other helpful functionality, like incremental syntax checking and running gofmt on save. Sublime Text also has a limited Vim emulation mode, which lets me drop into Vim command mode for some mouseless productivity.
Keep in mind that I think Sublime is great, and well worth the license fee. That said, I find its advocates a bit wide-eyed and breathless in their enthusiasm. I keep thinking, Have they never used a decent editor before? Take the “multiple selection” feature. You can select something, such as a variable name, then press Control-D repeatedly and select other occurrences of the same text. Then you can type, and all of the occurrences change simultaneously. Revolutionary! Any praise about multiple selections is an understatement!
Really? You’ve been able to do that with just as few, or even fewer, keystrokes in Vi or Vim forever:
All you have to do is press a key for every occurrence. If you want to change them all without confirmation, leave off the trailing ‘c’ command to the regular expression. This is basic, not a power-user feature. It’s Unix regex 101 for any number of tools — nothing new to learn here.
Similarly, a number of other purportedly “new” features in Sublime Text 2 are decades old, well-worn and loved in many other text editors. I’ll admit that most of the mouse-based, cursor-insertion-point, GUI text editors don’t offer these types of features in any usable or convenient way; they just seem to lend themselves much better to terminal-based editors like Vim and Emacs. (Example: passing selected text through a shell command and reinserting it into the file.)
In fact, many of these older text editors offer way more functionality than Sublime Text. It doesn’t even come close. The find-and-replace in Vim, for example, is way better than the dialog-based functionality in Sublime Text, or nearly any GUI editor for that matter. Not to mention the documentation; Vim’s documentation and help system is breathtaking, but Sublime Text’s is… uninspired at best. You can compare terminal-based text editors to Sublime Text on a bunch of dimensions and it comes up way, way short. Again, this is just some rambling thoughts — I repeat, I bought the license. And I’m sure Sublime Text is going to continue improving rapidly, as it has been the whole time I’ve been aware of it.
And now we come to my point: it appears to me, from the enthusiastic response to Sublime Text, that a large proportion of the developer population either uses a weak-sauce text editor or is utterly untrained on using a powerful one. How else can we explain the enthusiasm? I honestly can’t think of anything. And this is a really saddening thought, because it means that thousands of programmers have completely neglected one of the most important things they could do: become truly proficient, if not expert, with their text editor. The text editor is to the programmer as the wrench is to the mechanic, as the compass is to the navigator, as the shoe is to the runner. It is arguably the single most important tool you’ll use as a programmer.
There’s just no excuse. If you aren’t using a powerful text editor (and I would count Sublime Text as one), get one. And if you aren’t at least an advanced user of that editor, get a move on it. I’m not the first to say this, but I can’t remember or locate the quotation about this topic that I’m trying to recall. Maybe someone can help out in the comments.
What’s your favorite text editor? What’s your favorite resource for becoming an amazing wizard with it, so that you regularly do the kinds of tricks that make your friends say “hey, what editor is that?”
Better performance is important in everything, not just MySQL. I don’t want to wait for my text editor to open a file or perform syntax highlighting. I don’t want to wait for my version control system to compute diffs or update my copy of the code with other peoples’ changes. I don’t want to wait for my code to compile. I don’t want to wait, period.
Two tools I have enjoyed recently are Git and the Go language. Both are fast — very fast. It’s a welcome change after suffering from bzr and launchpad over the last couple years. If there is a slower or less efficient revision control program than bzr, I’m not aware of it.
Go compiles fast enough that it’s even a good scripting language. If Gentoo were written in Go, it would be no fun for its regular devotees to use — who wants to use an operating system that doesn’t give you enough time to savor that satisfying feeling of watching Xorg or LibreOffice compile for hours? You can probably tell that I don’t live for the thrill of watching “> /dev/null 2>&1” scroll up my terminal all day.