Re: Why no TextMate for Linux?

On 2010-03-15, David Masover <[e-mail]> wrote:
> On Saturday 13 March 2010 12:05:06 am Seebs wrote:
>> It is not obvious that "buying" a thing necessarily in all cases entails
>> the right to manipulate it in arbitrary ways.

> Actually, that in particular was blatantly obvious until very recently.

Not necessarily for the best.

Consider what happens when you buy, say, a cat.  Do you have the right
to torture it to death over a long period of time?  Most people would say
you don't.

If you buy a house, do you have the right to, say, set fire to it?  Probably
not, especially if it's near other houses.

> However, I also occasionally speak up and make people question the tradeoffs 
> they're making.

And that's a good thing.  I think the reason this started out more
confrontational than it otherwise might have been is that, although it
may not have been intended that way, your posts came across as implying
that no one who had questioned those tradeoffs could possibly have
ended up choosing a proprietary editor.

> Again, take cell phones. I could simply refuse to buy a cell 
> phone, or I could get on my soapbox and try to convince others to stop buying 
> into these contracts. If enough people actually did start demanding cheaper 
> unlocked phones and shorter (or purely monthly) contracts, the end result 
> would be better terms for me.

I'm not sure of this.  It might be that the result would be more expensive
phones with shorter contracts, because the subsidies really do reduce the
cost of the phone.  Many cell phones are sold for less than they cost to
produce -- with the excess being covered out of the contracts.

I'd like to see more variety there, and conveniently, Google already did
the first variant -- if you buy an unlocked phone, you get a LOWER monthly
rate.

> It depends how much I care about it. You cited, as an example, hideous UIs. I 
> don't mind ugly UIs, as long as they're usable and get the job done.

I don't care much how they *look*, but when I talk about a "hideous UI", I
mean one that makes it harder to get things done.

For the canonical example, consider QuickTime 4, which introduced the worst
volume control ever implemented in a piece of software:  A virtual thumbwheel.
You clicked on it and dragged to move volume up or down, but it was a
thumbwheel, so you couldn't cover the whole range in a single drag the way
you could with a slider.

Interface features can make a HUGE difference in the usability of a program.
One of the reasons I use Pages, rather than OpenOffice or Word, is that it
is much more likely that I can get something done reasonably well, reasonably
quickly.  (If I need a lot more than that, I go to a markup language.)

>> But for some users, that upgrade treadmill may be worth it -- especially
>>  if, say, you gain enough benefit from a particular Windows-only app that
>>  it is more efficient to upgrade frequently than to make do with something
>>  else.

> The problem is, again, how frequently, and how much do you trust Microsoft?

I trust Microsoft roughly as far as I can throw them.

But here's the thing.  Right now, if an app that did something Very Important
To Me ran on Windows, and not on anything else, I might well run it anyway.
I wouldn't expect it to survive, but as long as "using it for a while" isn't
worse than "never using it at all", that's okay by me.

> For example, if your app broke on Vista, it now becomes a somewhat more 
> expensive proposition...

Sorta.  I have XP licenses around.

> It's not directly about the cost. It's about the risk, and about being forced 
> to trust a single external vendor -- which becomes that much worse when it's a 
> single person.

Okay, imagine this.  Imagine that I'm guaranteed that TextMate will cease to
exist as of Jan 1, 2011.  I mean, actually stop working, because this is
a hypothetical scenario.

And imagine that using TextMate to write Ruby code improves my productivity
by about 10% over any other tool I have access to, and that I write a lot of
Ruby code.

Long story short:  Buying a Mac mini, and a TextMate license, and using it for
those nine months, is probably a much, much, better deal than any other
alternative.

And if 10% sounds high to you, lemme tell you, it is not unreasonable at all.
I once ended up with a project which genuinely HAD to be done using Microsoft
Word.  I'd guess that it increased the time it took me to get anything written
by about 30%, maybe a bit more, compared to writing in anything else I can
think of; nroff, HTML, XML, SGML, Pages, OpenOffice, you name it.  It was
unbelievably bad.  I'm still amazed at how much it sucked.  And it cost me
a HUGE amount of time.  I'd guess that, of any given hour spent writing, at
LEAST 15-20 minutes was spent just fucking around with Word, and that's to
say nothing of the extra time introduced by crashes, compatibility issues,
and so on.

So, yes.  If I have convincing evidence that a tool's a big enough upgrade,
I'll use it even if I *know* that I'll stop being able to use it in a bit.
And in the case of TextMate, I would guess that the version I have right
now, with no further upgrades on my part, will still be usable to me five
years from now.

> Doesn't matter. Unless you've actually disabled it (or unless it's disabled by 
> default), I can still give you a malformed txtmt URL, so you still need to 
> either pay attention to the potential vulnerabilities (and actively disable 
> functionality like that) or keep yourself patched.

Well, yeah.  But disabling functionality I don't want is one of the first
things I do with most programs.  :)

>> What leads me to Ruby in the first place is that it's pleasant
>> to work with.  If I wanted something less vendor-dependant or less likely
>> to be suddenly changed out from under me, leaving me with no practical
>> support, there are probably half a dozen languages I'd be better off with.

> Interesting. I wonder what it is about those other languages that makes them 
> more suited to that purpose?

Well, as an obvious example, I use C because I can be pretty confident that
any OS out there will be able to run simple C programs.

But.  Note that this was qualified; *IF* I wanted something less
vendor-dependent...  (Actually, I wrote "less vendor-dependant", showing
that I still can't !*#@!@# spell.)  And in many cases, I'm willing to
accept some degree of risk because the payoff is good.

For instance, I use Ruby in preference to PHP, not because Ruby is less
vendor-dependent, but because it doesn't make me want to bleach my brain
after I have to read code in it.

> However, as Michal Suchanek pointed out, you can hire someone else to do so. 
> That is something which, again, is not necessarily an option for a proprietary 
> app.

Sure.  But it may not be an option for me in general, either.  I couldn't
afford to hire someone to mess with that driver, so the theoretical option
doesn't do me much good.

> The other advantage is one that a healthy community provides -- even if you 
> don't personally have the skills to, say, maintain a Ruby 1.8.6 fork, chances 
> are that if 1.8.7 really changed that much, _someone_ will have the skills and 
> inclination to make 1.8.6 continue to work.

Maybe.  But that brings you right back to the risk issue, and honestly, I
don't think it's enough better for me to care.

I've seen very, very, few "forks" that were viable enough to be worth the
hassle.

> On an open source platform, I guarantee that at some point, sheer 
> determination would've led me to patching it myself, or working around it. 
> Fortunately, it usually doesn't come to that, as I can switch easily enough 
> from KDE to GNOME to Fluxbox to whatever else -- more an incidental benefit 
> than a direct benefit, I'll admit.

Heh.  I've got one of those right now; there's an X.org bug that breaks
key repeat, and every Linux system available to me has a buggy version, and
none of them appear to plan to fix it.  Since rebuilding X is wayyyy too
much hassle, I've compromised on patching in a dodgy patch to WINE to
work around it for the one app I care about.

>> I got a jabber server up and running... It was a pain.  The
>> next time I do server stuff, I'll put in OS X server, click "enable chat
>> server", and have a working jabber server.

> Again, YMMV. For me, this was along the lines of:

> sudo apt-get install ejabberd

I was doing this a couple-few years back, and at the time, I had to
compile erlong and ejabberd myself.

>> It won't crash.

> Hasn't crashed for me yet.

ejabberd hasn't.  I tried the "official" jabberd before that, and it
was crashy.

>> It won't
>> have a mysterious bug that took me a dozen reboots to track down causing
>> it not to start up when started from /etc/rc.local even though it starts
>> fine when invoked from the command line.

> It starts from somewhere else, not rc.local, but it starts automatically when 
> installed and on every reboot.

Once there's a package for it, yes.  I was doing this before that, and it
was on a BSD machine, and there was some weirdness that made it not work
when started from rc.local until I fixed it.

>> I won't have to replace it with
>> a different one due to a crashing bug that no one cares about, or build
>> a programming language environment before I can use it.

> Nope, and nope. Erlang was auto-installed as a dependency.

See above.

> I did some initial research before picking ejabberd. I suppose that's also 
> worth some money.

Yup.  When I did this, ejabberd was new enough (and erlang was new
enough on the BSD machine) that I had to do some of that research myself.

> I'll agree with that, but this happens a lot more often when I consider 
> whether they're equivalent for my needs. I'll freely admit Photoshop is 
> probably still far better than The Gimp, but I'm also not a graphic artist, so 
> open source plus price wins. For most things I'll have to print, OpenOffice 
> wins -- some people need certain obscure features of Word, I like a big 
> "export to PDF" button, and again, open source, open format.

Yup.  One of the things I like on the Mac -- it is extremely difficult to make
a program for the Mac which can print, but can't export to PDF.  I don't think
I've ever seen it done.  And that's one of the cases where the proprietary OS
makes up for the weaknesses of a lot of software -- I am not dependent on
software vendors supporting PDF.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / [e-mail]
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!