Re: Why no TextMate for Linux?

On Wednesday 10 March 2010 10:55:11 pm Seebs wrote:
> But if the CURRENT version meets my needs, great!

So long as the current version continues to work.

> It's not as if most people can realistically get a real feature change
> into vi.  Even most programmers would be unlikely to find it worth the
> time and effort.

Most likely -- but having the ability is important.

I'm unlikely to ever want to, say, burn an American flag, but it is important 
to me that I have that right.

> >  * You're tied to an OS which is notorious for breaking backwards-
> > compatibility.
> 
> lolwut?  I have things from OS X 10.0, written for PowerPC systems, which
> still run on Intel in 10.6.

And I've seen things break from 10.3 to 10.4 to 10.5.

> > - The next version of OS X is as likely as not to break the current
> > version of TextMate.
> 
> You have any evidence for this?  I've been using OS X as one of my desktop
> platforms for about a decade now, and thus far, I've had VERY few programs
> broken by upgrades -- and those were always things which I would have
>  expected to break, like low-level hacks into the window manager or
>  something similar.

It's been long enough since I've used OS X that it's possible I'm remembering 
low-level hacks. Then again, I remember even things like VLC would require at 
least 10.3, and this is when 10.4 was the latest. So...

> >    - Once you do upgrade, the new version of TextMate is as likely as not
> > to refuse to work on old versions of OS X, so you'd better upgrade all
> > your boxes at once.
> 
> Again, this claim "as likely as not" seems pretty implausible to me.  It's
> extremely unusual for anyone to make a tool like this not work on at least
>  the two or three most recent revisions.

Two or three is nice, still means you're going to have to upgrade when it's 
four, five, or six revisions out of date -- either the program or the OS.

Again, I don't mind this so much in open source, because in cases where an old 
version had some merit, and we think they screwed up the new version too much, 
we can fork the old version and maintain it. In particular:

> Do you have any kind of data to back this claim up, or is this just generic
> FUD?  If we're gonna be doing FUD, how about I warn people that they
>  shouldn't be relying on Ruby, because a new version of Ruby might break
>  existing scripts?

1.9 might, yes. But Ruby is open source. Don't like 1.9? Fork 1.8.7, or even 
1.8.6. I believe someone is currently maintaining a stable 1.8.6.

With proprietary software, that's not an option -- Microsoft wanted to force 
Vista on everyone, so they threatened to pull support for XP. That would've 
meant security vulnerabilities, among other things, making life difficult for 
those of us wanting to stay on XP -- no chance of any bugfixes. Microsoft 
maintains support for old version of Windows, but to a point -- beyond which, 
the community CANNOT take over.

Now consider the case of a killer app developed by a single individual. What 
are the chances he's going to expend significant time and energy maintaining 
old versions of TextMate when he could be working on a new version (and 
charging for it) instead?

Can you see why I might be more inclined to trust a popular open-source 
project developed by dozens (hundreds?) of people around the world, rather 
than a proprietary project developed by a single person?

> >    - Switching OSes -- to Linux, to Windows, to Plan9, to whatever -- is
> > out of the question for you.
> 
> I would consider that pretty normal for a lot of tools.  I expect to have
> to switch tools when I switch OS's.  There are exceptions,

My text editor of choice right now is Kate, and the entire KDE project is 
cross-platform. My other text editor of choice is vim, and it even runs on 
Windows, with some help. For school, I'm forced to use Java, so I use Eclipse, 
which is also cross-platform. Ruby is cross-platform. Rails is cross-platform.

My web browser of choice is Google Chrome, which is cross-platform. My other 
web browser of choice is Firefox, which is cross-platform. Third would be 
Konqueror, which is as portable as KDE.

For writing and publishing, I'm using OpenOffice and Scribus, which are both 
cross-platform.

For image editing, Krita or Gimp -- cross-platform, and cross-platform.

For remote management, I use ssh and rdesktop -- cross-platform, and... oh, 
there it is. I bet rdesktop doesn't have a Windows version, huh? That's OK, I 
can use Windows' native Remote Desktop client.

Whew. That was hard to find the one tool which isn't portable, and I'm not 
even sure about that -- it might run under Cygwin!

> > Framework?
> 
> If it was the right tool for the job, yes.
> 
> I'm making myself an iPhone app.  I dunno if I'll ever even get it to the
> point where I'd submit it to the app store.  I want it for my own use.  It
> is heavily tied to several proprietary frameworks.
> 
> So what?  Nothing else lets me do what I want.

Really? Android doesn't? That's interesting.

> > If not, why not, and why would you use a proprietary text
> > editor, or debugger, or _any_ proprietary programming tool?
> 
> I don't have a problem with proprietary tools, IF they do their job well
> enough to justify the hassles.

I tend to agree, yet I notice, again, a trend where people like that 
everything Ruby is open source, yet don't care to look for the same in their 
OS or editor.

And that is a big if...

> > I generally don't bother people about developing on OS X. It's annoying,
> > but most of the Ruby stuff is going to be general Unix stuff anyway, not
> > Mac- specific. But then, switching OSes is easy when your tools are
> > portable.
> 
> It is usually a bit of a tradeoff.  I'll accept some non-portability of
>  tools to get jobs done sooner and with less effort.

I'll do that, if it's enough sooner and enough less effort to justify the loss 
of flexibility. I'd much rather spend a bit more time and get it right the 
first time, using portable, flexible, open tools, so that I don't have to 
completely redo it if something needs to be changed.

There's always a tradeoff, I just find it interesting where people draw the 
line. For example:

> I am a moderately experienced Unix geek, but the shared disk used by the
> various computers in my house is attached to a box running OS X Server,
> because the cost of my time to set all that stuff up correctly is an
> order of magnitude more than the cost to have something where I click the
> "yes, make this available to Windows too" button.

sudo apt-get install samba

A fileserver is about the easiest thing to set up. I have to ask how much 
you're being paid where half an hour or so of your time is more valuable than 
the hardware markup for an OS X server.