Hacker News Reader

Comment by eli | Hacker News Reader

I really like Allan and I'm a proud Textmate user, but I can't help thinking about Joel's essay: Things You Should Never Do (http://www.joelonsoftware.com/articles/fog0000000069.html) about how rewriting software from scratch is almost always a huge strategic error.

Why is a complete rewrite implicitly being considered a good thing? Code doesn't get stale, there's a very active community around Textmate 1, and most people are just asking for incremental features, not something totally different. If people wanted something totally different they'd surely have ditched Textmate by now.

View on HN

There are actually a few nagging bugs in Textmate which require fundamental changes to address. Allan also seems to be somewhat of a purist, given this rewrite and the fact that he can't get a simple blog post "good enough" to put out there. He likely considers it a good thing because he wants to do it.

Code very much does get stale, at least to the developer looking at it every single day, and sooner or later almost everybody wants to throw everything out and start over. We generally don't do that because we can't justify it in terms of the business, but when you're a solo developer I suppose you can do whatever the hell you want ;)

Yup, I think you're probably right.

We generally don't do that because we can't justify it in terms of the business

True, but Joel's point is that a rewrite can actually be bad for the code not just the business, because you throw out years of real-world testing and bugfixes.

And to be honest, unless Textmate 2 is significantly worse than 1.x, I'll buy an upgrade license.

because you throw out years of real-world testing and bugfixes

Very true, but you also get to trade in on the experience and information gleaned from the use and development of a product over many years. I think it is safe to say that Allan knows far more about Textmate now than he did when he started it, and perhaps that insight has allowed him to bring some significant improvements to the text editor as a whole.

Maybe I'm just biased; I tend to rewrite stuff before I've even written it once.

True, but Joel's point is that a rewrite can actually be bad for the code not just the business, because you throw out years of real-world testing and bugfixes.

I think that applies on project with multiple developers and whose developers are not in the company anymore. When it's a solo developer, he still has the experience and doesn't lose so much from throwing out the code

There's truthyness in that statement... but I've re-written code from years before that I wrote myself; it's easy to forget all corner cases you handled in old code. It forces you to take a step back from your new, clean, way to solve the problem and make sure it really does cover those forgotten cases too. The added uncertainty really hurts the predictability of a re-write.

That's why you should write automated tests for your corner cases (and of course not only the corner cases). If all corner cases you knew about are properly tested, your rewrite should function properly.

A little offtopic, but I would say this is the reason that vigilantly commenting your code is essential, especially for a one man shop.

I've learned this the hard way enough times to make it stick to the point now that even when I'm just writing regular, mundane CSS, I make sure to comment in every workaround I write, no matter how routine. It takes longer, but it's worth saving me from myself.

Let me counter with Fred Brooks' "Build one to throw away."

Even just the fact that TextMate is a one-man project is good reason to think that Odgaard knows best whether a rewrite was appropriate.

I remember that Textmate 1.0 was partially driven by DHH - I wonder to what extent that external influence had on Odgaard.

Do you have a source for that?

From http://www.loudthinking.com/arc/000270.html:

Disclaimer: I know the programmer. I've been pretty heavily involved with the development process by helping to determine, prioritize, and test features. I have no financial involvement, however. All my work and hype are small tributes to the awesome archievement that is TextMate. I feel blessed to be able to help it gain traction

Brook's isn't always right. I think that quote is one example.

I think so long as 2.0 maintains backwards-compatibility with 1.x (possibly include 1.x with the 2.0 app?), and it doesn't hamper at all from the user experience, a re-write might be a good thing. Or, allow easy plug-in migration from 1.x to 2.x (kinda like what Python did going from 2.0 -> 3.0).

There are plenty of examples where complete re-writes, or partial re-writes, have led to bad things. Windows Vista and Winamp 3.0 come to mind.

Good examples include Mac OS X, Linux 2.x (I believe this was a major re-write over 1.x - could be wrong as my Linux history isn't up to buff). Starcraft was completely re-written mid-development (originally it was built on the Warcraft II engine, which didn't scale).

I would tend to agree with you, though, that major re-writes typically yield worse things. But, that depends a lot on the product, its audience, and the developer. Perhaps Allan, who has likely been writing code for a very long time, knows of some bottlenecks and what-not that he feels should be incorporated into 2.0, which necessitates a total re-write.

If worse comes to worse, the 2.0 codebase bombs and 1.x continues going on strong. That's exactly what happened to Winamp 2.0 when 3.0 came out.

And I should mention, to clarify any possible bias in my opinion, that I'm a very happy Textmate user. :)

OS X wasn't a complete rewrite. It was a "Our rewrite is going to hell, lets buy a new OS to use." Go look up the history of Copland from Apple, its mildly interesting.

Its a rewrite in that they threw out nearly an entire codebase and built it on top of something different. If tomorrow Microsoft said "lets get rid of Vista and build something new on top of Ubuntu", I think it would be fair to call that new version of Windows a rewrite despite them not having written the underlying code. Also, lets not forget that a fair amount of work (understatement) went into Mac OS X post NeXT.

I think this stretches the definition of a rewrite a little beyond the point it should break.

OSX is more like a rebranded descendant of NextStep/OpenStep, just the same as a would-be Microsoft Windows 10 derived from FreeBSD code.

"Windows Vista and Winamp 3.0 come to mind."

Vista is not a rewrite of XP - its a new bunch of kernel code grafted on top of the XP kernel, which is more or less the same as the 2000 kernel, which is an improved NT 4 kernel, which is more or less 3.5 with some stuff moved from user space into kernel space, giving a whole lot of stability problems due to low-quality driver software. It seems no full rewrite occurred between 3.1 and 7. The only rewrite I heard of was the one between the PDC 2003 video when Microsoft realized they would not be able to finish what they promised (managed code throughout the OS, the eye candy from the Longhorn concept video), threw a=out what they were doing and went back through a less ambitious route.

As far as rewrites go, Win7 seems more or less a rewrite of the Vista cruft that was added on top of the XP kernel.

Windows Vista and Winamp 3.0 come to mind.

There's a big difference between these two examples. Vista was still developed by Microsoft but Winamp 3.0 was started after Nullsoft was acquired by AOL.

The wikipedia article mentioned that 2.0 and 3.0 was developed in parallel (http://en.wikipedia.org/wiki/Winamp#Winamp3). I'm not sure if that means if they were made by the same coders, however...

because sometimes you realize that in the beginning you thought that what you coded would suffice, but then users started coming up with feature requests/bug reports wanting more and you just can't do it without a rewrite, however big. like textmate not supporting non-fixed-width encodings, requiring any cjk user to use half-width fonts as a pretty annoying hack. i for one can't stand half-width fonts, so i just go with a different editor when i am working in more than one language.

and while that sounds like an incremental feature (and is), it looks like it's a nontrivial change among others to be done to textmate that 2.0 is aiming for.

if i had to wait this long to get proper cjk support (hopefully!), that alone to me justifies the long wait, and i wouldn't consider it to be a huge strategic error. that is, if this and more all happens with the launch of 2.0.

Is it a fact that implementing fixed-width fonts actually requires a complete rewrite of all code and rethinking of the fundamental data structures? I think there's a pretty big gap between making a nontrivial change to an existing codebase and starting all over.

I certainly don't agree with Joel on everything, but I think he makes excellent points in the essay I linked above. I think every programmer maintaining a project hits a point where they want to rewrite everything. The code is full of hacks, the API is crufty, the requirements have evolved, etc. But that doesn't mean that such a rewrite is a good idea. And I bet we could all agree that a rewrite is not implicitly a good idea. All other things being equal old, tested code is better than new, untested code.

I don't disagree, but I can only assume Allan reached a point where maybe all the features/fixes to-be-implemented warranted a near-total rewrite as opposed to individually fixing or implementing them.

Plus, the CJK fixes in particular he's discussed literally now years ago were supposed to involve Core Text, which I believe was new to Leopard, which was then in turn a fairly new thing. Perhaps in addition to his shortsightedness/disinterest/whatever it may have been that he didn't consider that cjk would be an issue, new APIs and more made the idea of a rewrite more appealing.

well, the reason a rewrite is bad is that it gives competitors time to produce a better product. in terms of text editors on Mac, nothing else is really that close, so it seems like Allan hasn't really lost out.

   in terms of text editors on Mac, nothing else is really that close

emacs

I don't see that many textmate users dropping it for emacs any time in the near future. Yes, textmate was inspired by emacs, but it tends to appeal to a different crowd.

I did. It was actually TextMate that got me back into Emacs after all these years. I needed something at work on my not-a-Mac that was as good as TM. e and InType were close, but fell into the (sorry in advance for the cliche) uncanny valley, where any minor shortcoming relative to TM was doubly unsettling. It was actually easier to adjust to Emacs than to the also-rans.

Not emacs, but I dropped TextMate for Vim, and was very, very happy to do so. The stagnated development, the closed source and lack of portability, the annoying bugs etc. made it an easy choice.

but it tends to appeal to a different crowd.

People that know how to read?

The more I try using TextMate, the more I find myself using Aquamacs. There are some things that TM is clearly better at, but there are a lot of immature features:

- find in project is slow - window and buffer management - editing via SFTP (tho Aquamacs has horrible lag for me) - syntax highlighting crashes on really long lines and files - too many keyboard shortcuts... I often hit the wrong key and have it add a random code snippet to my JavaScript file (yes, this is probably configurable, but I expect good defaults from commercial apps)

All text editors are subsets of emacs... that doesn't make emacs more usable or productive though.

Emacs is extremely "productive" in the hands of a capable user. A "hacker", let's call him or her. "Usable"? Well, not in the hands of a beginner. If you want to just click a few things, Emacs is not for you. If, on the other hand, you live in your text editor all day long (you are, say, a programmer), what Emacs lacks in usability it makes up for 1000 times over in extensibility, flexibility, and ability to do pretty much anything you could imagine, with a bit of effort.

I didn't say it wasn't productive. I said "more productive".

The difference is setup overhead. If you discount the effort to get your environment dialed-in, then of course emacs will be the best choice. On the other hand I encourage you to consider that Emacs Lisp may not in fact be the best tool for all jobs.

I'm not sure why you put "productivity" and "usability" in quotes, or why you mention "beginners" and "want to just click a few things". We're talking about programmer tools here, so suggesting that a non-programmer couldn't use emacs is not really apropos.

Emacs is forever. In other words, 'dialed in' is a continuous process, which will keep happening no matter what language or environment is popular today.

I think at some point any piece of software requires a major rewrite (of course, when that point is depends). Whenever software is written, fundamental assumptions get made, and even the most forward thinking architects can't predict everything that will become possible or necessary. For a while, it is simply enough to build on top of what you currently have, but eventually the underlying architecture will no longer represent the main goals of the app. At this point, the spaghetti and hacks will far outnumber the well written aspects of an application and you will be spending most of your time trying to navigate the mess.

Again, that's not to say all software should be rewritten for every version. Mac OS X has been around for about 10 years and could easily go for another 10 with its current architecture. However, I think we can all agree that sometime between now and 100 years from now, something fundamental will probably have to change.

What do you think of Apple rewriting Finder in Cocoa? I'm happy about that.

How do you know you're happy with that?

Hasn't everyone tried the Snow Leopard beta?

I've tried it and am very happy with it. But even if you haven't, many people are still excited about it. A cocoa rewrite means much better performance and extensibility.

Now they just need to re-write iTunes in Cocoa (hopefully something they'll do for iTunes 9)

"A cocoa rewrite means much better performance and extensibility."

Only if they bother to make it fast and extensible.

Which they explained were 2 main focuses in the keynote. A Cocoa rewrite will make it faster out of the box.

I think his point is that it isn't Cocoa itself which makes the new version faster and more extensible: It's the rewriting process. The new codebase has presumably been better structured to be faster and more extensible.

As John Gruber has said "Cocoa is just an API. It is not some sort of magic technology where you just sprinkle a ton of square brackets in your source code and you instantly get a better UI." (http://daringfireball.net/linked/2008/10/30/cocoa-finder)

I agree 100%, but a well written cocoa app is much easier to achieve than a carbon app (one reason why the Finder has been screwed up all these years).

But I agree, a rewrite with performance and accessibility in mind is what makes it faster, not cocoa itself (should've reworded that).

If you have, you're breaking an NDA by talking about it.

I never signed an NDA, I guess I agreed to one when installing the software? I'm not a developer, the WWDC release is all over BitTorrent.

Yeah, Apple is going to cut off his access to BitTorrent now...

I guess its incorrect to assume someone might have something legitimately nowadays? :\

Look how many years it took them to finally do it though. Hell, there's practically nothing left to do...

Did they FTFF too, or did they just rewrite it? I have not tried Snow Leopard.

I think you mean "inherently" rather than "implicitly": Allan has been pretty explicit about why he considers a complete rewrite a good thing.

Assuming that's what you meant: I don't think anyone suggests that complete rewrites are inherently proper. It depends on a host of factors, and the pile of failed rewrites in the world is a testament to the risk involved.

In any case, examining what "people" are clamoring for is not necessarily the best way to make decisions. Before TextMate 1 had been released, no one was looking for anything quite like it. When you send tools into the world, it's impossible to tell before hand what will be done with them, and I don't think you should dismiss the introduction of substantial new features (so substantial that they couldn't be built on the previous architecture) with a hand-wave like "most people" not wanting something "totally different".

Reply on news.ycombinator.com