4 ms·

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 re

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.

eli 17y ago
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.
- silencio 17y ago
  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.

eli 17y ago

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.

silencio 17y ago
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.