Working on It (TextMate)
blog.macromates.com
blog.macromates.com
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.
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)
Only if they bother to make it fast and 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)
But I agree, a rewrite with performance and accessibility in mind is what makes it faster, not cocoa itself (should've reworded that).
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. :)
OSX is more like a rebranded descendant of NextStep/OpenStep, just the same as a would-be Microsoft Windows 10 derived from FreeBSD code.
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.
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.
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.
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.
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.
in terms of text editors on Mac, nothing else is really that close
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.
People that know how to read?
- 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)
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 ;)
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.
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.
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
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.
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".
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.
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
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.
Of course, I've long since found my home in MacVim, so maybe I'm simply enjoying my lack of expectations from him.
This is why open-source editors have made closed-source editors all but extinct. There are just too many things to do for one person, or even one group of people.
Microsoft Visual Studio seems to be doing OK
The "Open source killed closed source" argument doesn't really apply to Mac OS X. Sure, there's Smultron or MacVim or Aquamacs, but they're not really the most popular of text editors (looking at GUI-based ones).
I tend to think of editors like TextMate, emacs, and vim to be chosen by people who invest some thought into making the decision, rather than by people that are forced to use something for work.
Huh? What about NetBeans or Eclipse? There is tons of open software for Windows.
Coda is doing well, and Espresso had a pretty big release recently.
I liked what I saw 18 months ago, in particular the overview pane, but the author seemed to let it ... rest. The website main pages still give that impression, but I just looked and the author is active in the forum and pushing out betas.
I just want a simple, easy to use, easy to learn, UI based editor with syntax highlighting.
Maybe I should try harder.
I do like the way TextMate opens a directory tree and has it to the left or right of the edit pane, can jedit do that?
The basic advance over something like an Emacs-Lisp package is that he built a declarative system (based on context-dependent regexps) for handling arbitrary languages, rather than making you write all the code to do so from scratch.
And he built things in such a way as to be able to handle languages nested inside other language contexts (e.g., Ruby inside HTML).
Couple that with a pretty powerful templating facility, and you have something that advances the state of the art.
I don't think anyone else has really taken as fresh a look at text editing for a long time.
I will check how syntax highlighting is implemented in Emacs to check if something like this can be done and learn some Lisp in the process.
I keep hearing people state their love for TextMate but since I don run OSX and there is no Linux version, I am out of luck.
They could use their rewrite to make it compilable against GNUStep...
I would not worry too much about this. Assuming you are willing to use Google and edit your .emacs file, Emacs can do everything TextMate can. It also has the potential to do many things that TextMate can't. (I don't see Slime for TextMate.)
It's already useable, if you can deal with the pain of the installation process.
Emacs does not make you do this. (setf font-lock-keywords '(("some-regexp" . whatever-face-you-want-that-to-be) ...)). There are several other forms that font-lock understands, including custom functions that do highlighting.
Emacs also has something called the "syntax table", which allows you to declare what comments and string literals look like. Emacs can then use this information to syntax highlight those elements, and not do other syntax highlighting inside them.
cperl-mode uses this combination of features to correctly highlight nearly 99% of Perl constructions correctly. (Keep in mind that Perl and C++ have the dubious honor of not being parseable with a formal grammar, so it is somewhat impressive that syntax annotations + regexps is enough to do a good job.)
I find it amusing that people are downmodding this post that contains correct information. There is no editorializing here; just information about how the syntax-highligting works, and my experience with working on a major mode for a very complicated language (using said tools).
If you must downmod, downmod the parent which contains untrue FUD.
I realize Emacs does a lot of the work for you. It's just that I've worked with some of these mode packages over the years and have been impressed with the complexity they embody and the size of the code involved.
Textmate seems to avoid most of that complexity with its declarative system, and still give you syntax highlighting and auto-indenting, etc.
If you look at cperl-mode, for example, syntax highlighting and indentation support is only a small part of its line count. The rest is things like auto-documentation of core features, including 100s of lines of documentation strings for Perl core functions.
I'd quite like split-screen editing, that's my main bug-bear, but I've actually structured my use of TextMate around that - I basically just have several Textmate windows open. I've been meaning to switch to Emacs for that, but I suspect that managing buffers (and making sure they end up in the right pane) will take as much effort as dragging a few windows around.
I think you'd be surprised. In my experience I have a fixed set of windows (not os windows, but panes, as you called them), and easily and quickly switch between them with Iswitch-buffers: http://www.emacswiki.org/emacs/IswitchBuffers
this add-on gives you incremental-search to choose among open buffers, and usually it only takes a couple of keystrokes to get the one I want - so instead of moving the mouse around and clicking somewhere small and dragging things around, I am back in business after something like 'C-x b sh' - control-x, b to invoke iswitchb, and 'sh' to get me to my shell buffer...
e.g. in a Django project it'd be common to have users/models.py, events/models.py, polls/models.py - you press Command+T and you can only search on models.py, if you type "pmod" you don't get polls/models.py. Highly annoying when hopping between files is so common.
http://repo.or.cz/w/MacVim.git?a=tags
and their Google Code updates list:
http://code.google.com/p/macvim/updates/list
MacVim has seen a huge number of changes in the 2+ years that TextMate has been under development: not least Leopard support, Vim 7.2 integration, and a ton of interface and speed improvements. They're on Snapshot 45 right now...
Two examples that come to mind right away is the fact that TextMate cannot handle large files (tsk, tsk... ) and the inability to edit in hex mode.
Thanks for reminding me why I don't want to do Ruby.