Why no TextMate for Linux?

I spent some happy development time in "VisualAge" for Smalltalk +
Java and I sure do long for better support than "just an editor".
Seems like Java fit with that IDE amazingly well. So many great
features, and that was 14 years ago now!

So, does anybody know why there is no version of TextMate for Linux?

Seems like they should have a "little brother" version for the rest
of the rest of us?

Thunk

I spent some happy development time in "VisualAge" for Smalltalk +
Java and I sure do long for better support than "just an editor".
Seems like Java fit with that IDE amazingly well. So many great
features, and that was 14 years ago now!

So, does anybody know why there is no version of TextMate for Linux?

There is, its called redcar and it is built entirely in ruby.
The problem is that i needs more development.
You can get the code on github.

Andrew

···

On Fri, Mar 5, 2010 at 7:10 PM, thunk <gmkoller@gmail.com> wrote:

Seems like they should have a "little brother" version for the rest
of the rest of us?

Thunk

Ask the TextMate author. In fact, it's in the FAQ:

http://wiki.macromates.com/Main/FAQ

Keep in mind that TextMate is proprietary, and as far as I know, is not
written in Ruby, so your question is a bit like asking why there's no version
of Photoshop for Linux -- kind of offtopic for this list, and the answer is
that the developer didn't port it.

A better question might be why so much of the Ruby community has embraced a
proprietary editor which is only available for a proprietary OS.

···

On Friday 05 March 2010 07:10:05 pm thunk wrote:

So, does anybody know why there is no version of TextMate for Linux?

I spent some happy development time in "VisualAge" for Smalltalk +
Java and I sure do long for better support than "just an editor".
Seems like Java fit with that IDE amazingly well. So many great
features, and that was 14 years ago now!

So, does anybody know why there is no version of TextMate for Linux?

There is, its called redcar and it is built entirely in ruby.
The problem is that it needs more development.
You can get the code on github.

Andrew

Seems like they should have a "little brother" version for the rest
of the rest of us?

Keep in mind that Textmate is not free software.

Andrew

···

On Fri, Mar 5, 2010 at 7:12 PM, andrew mcelroy <sophrinix@gmail.com> wrote:

On Fri, Mar 5, 2010 at 7:10 PM, thunk <gmkoller@gmail.com> wrote:

Thunk

David Masover wrote:

A better question might be why so much of the Ruby community has
embraced a
proprietary editor which is only available for a proprietary OS.

Probably because its very good software on a very good OS? Using
proprietary technology actually does not stop the progress of open
source.

(That being said, I code with Vim in Linux, so...)

···

--
Posted via http://www.ruby-forum.com/\.

David Masover wrote:

A better question might be why so much of the Ruby community has
embraced a
proprietary editor which is only available for a proprietary OS.

Probably because its very good software on a very good OS? Using
proprietary technology actually does not stop the progress of open
source.

Because it is derived (completely legally) from one of the soundest
and best open source projects there have ever been, openBSD. I feel
that David's concern is very reasonable in a world in which Apple and
Google are about to rival for domination. I am using gmail, r ight and
I am not criticizing anyone who uses MacOS and Textmate. However
wondering why seems legitimate.
I also feel that I can do much more with gvim than Textmate will ever
be able to do, but I am aware that much, much setup work is needed to
get there. (Probably the same is true for emacs). Textmate is
incredibly powerful out of the starting blocks, but vim is almost like
emacs an OS.
Ruby integration into VIM is very basic but powerful enough to get us
anywhere :).
Because after all this ML is about Ruby and not editors (well at least
when I checked back last time)

cheers
R

···

On Sat, Mar 6, 2010 at 5:05 PM, Paul Harrington <xenogenesis@gmail.com> wrote:

(That being said, I code with Vim in Linux, so...)
--
Posted via http://www.ruby-forum.com/\.

--
Learning without thought is labor lost; thought without learning is perilous.”
--- Confucius

That much is true, most of the time.

There are notable exceptions -- for instance, the fact that people are
starting to incorporate textmate URLs into HTML stacktraces and such, so that
you can just click on something and have it pop up in TextMate, but those
aren't portable at all. Far better would be to come up with some sort of
standard "Go to this line of this file in a text editor" URL scheme that the
open source community could adopt also.

But that's a ridiculously trivial, almost contrived example. Most of the time,
using proprietary technology doesn't cause problems for open source -- so long
as the open source project remains independent of said proprietary technology.

I'm much more interested in it on a personal level. Switching text editors at
this point might be, for most of us, far trickier than switching OSes, and
could be almost as bad as switching keyboard layouts. (Dvorak, anyone?) By
picking a proprietary technology, you're doing several things that I can't
really see being worth the risk:

* You're locked-in to a single provider -- in this case, a single _person_.
   - If Allan Odgaard doesn't want to implement a feature you want, you're
SOL.
   - If Allan Odgaard can't fix a bug that's annoying you, you're also SOL.
   - if Allan Odgaard wants money for a new car, you might find the next
version of TextMate costs significantly more.

* You're tied to an OS which is notorious for breaking backwards-
compatibility.
   - The next version of OS X is as likely as not to break the current version
of TextMate. It's entirely up to Allan whether there will be a fix, and how
much such a fix would cost -- maybe it's only available in a new version of
TextMate.
   - 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.
   - If you don't like the new OS X, for whatever reason, some new version of
TextMate might force you to upgrade anyway.
   - Switching OSes -- to Linux, to Windows, to Plan9, to whatever -- is out
of the question for you.

* You're a programmer, yet you can't program your own programming tools.
   - I don't care how extensible it is, you don't have the source.
   - Look at the tricks tools like Diakonos can do. Can TextMate do that?
   - Basically, TextMate may be at the top of the heap now (though there's
certainly room for debate), but if it continues to innovate, you can't be a
part of that. I would hope tools like Diakonos would win out in the long run,
because people who use them would inevitably contribute needed changes -- if
there was ever a "scratch your own itch" app, a text editor is it.

* Again, a SINGLE PERSON is responsible for the destiny of this editor.
   - If Allan should be hit by a bus (not that I am wishing this on anyone),
what happens to TextMate development?

Now, I don't personally hack on my own text editor. It's also MUCH less of a
commitment than, say, a framework -- if you were on ASP.NET, for instance,
you'd be tethered to Microsoft for the lifetime of your app or until you port,
and it's much harder to port an entire app than to learn a new text editor.

Still, think about it. Would you choose a proprietary programming language?
Library? Framework? If not, why not, and why would you use a proprietary text
editor, or debugger, or _any_ proprietary programming tool?

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.

But this is just my own curiosity. If you were using IE6, I'd hate you
forever, and this rant would be much longer, and it would never stop until you
stopped using IE6. If you're using TextMate, I think you're making a mistake,
but it really doesn't affect me that much.

···

On Saturday 06 March 2010 10:05:04 am Paul Harrington wrote:

Using
proprietary technology actually does not stop the progress of open
source.

My earlier statements apparently went totally ignored.
Redcar is making a lot of progress. It is a JRuby text editor that is
attempting to be a complete clone and fully compatible with the text mate
snippets. It has been stable enough to begin to code with for a little while
now.

It is a shame that this editor doesn't get more attention. The idea of the
editor its self being ruby is pretty hip.
You could theoretically meta program the editor much in the same way you can
IRB.

Redcar if I am not mistaking is bsd licensed.
Andrew

···

On Wed, Mar 10, 2010 at 7:39 PM, David Masover <ninja@slaphack.com> wrote:

* Again, a SINGLE PERSON is responsible for the destiny of this editor.
  - If Allan should be hit by a bus (not that I am wishing this on anyone),
what happens to TextMate development?

I'm much more interested in it on a personal level. Switching text editors at
this point might be, for most of us, far trickier than switching OSes, and
could be almost as bad as switching keyboard layouts. (Dvorak, anyone?) By
picking a proprietary technology, you're doing several things that I can't
really see being worth the risk:

Just as a data point, I still use vi as my primary editor (nvi by preference,
I dislike vim). And yet... I have TextMate, and BBEdit, both, on my Mac.

* You're locked-in to a single provider -- in this case, a single _person_.
   - If Allan Odgaard doesn't want to implement a feature you want, you're
SOL.
   - If Allan Odgaard can't fix a bug that's annoying you, you're also SOL.
   - if Allan Odgaard wants money for a new car, you might find the next
version of TextMate costs significantly more.

Sure.

But if the CURRENT version meets my needs, great!

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.

* 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.

I'm not seeing a real issue here.

- 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.

   - 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.

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?

Oh, wait. That actually *happens*, so we don't worry about it.

   - If you don't like the new OS X, for whatever reason, some new version of
TextMate might force you to upgrade anyway.

But you don't have to get a new version, if the one you have works.

   - 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, but by and large,
the default I expect is that any given program will probably be specific
to a target platform.

* You're a programmer, yet you can't program your own programming tools.
   - I don't care how extensible it is, you don't have the source.
   - Look at the tricks tools like Diakonos can do. Can TextMate do that?
   - Basically, TextMate may be at the top of the heap now (though there's
certainly room for debate), but if it continues to innovate, you can't be a
part of that. I would hope tools like Diakonos would win out in the long run,
because people who use them would inevitably contribute needed changes -- if
there was ever a "scratch your own itch" app, a text editor is it.

I have never found myself with any complaints about the available options,
preferences, or features in either BBEdit or TextMate. I use vi because I
like the raw speed, and don't need the flashy stuff, but I've never found
myself wishing to extend either of them.

* Again, a SINGLE PERSON is responsible for the destiny of this editor.
   - If Allan should be hit by a bus (not that I am wishing this on anyone),
what happens to TextMate development?

Presumably it goes to the estate. I dunno. I don't see this as a big deal.
Again, if the current version works for me, I don't care about future versions
for a long time.

Still, think about it. Would you choose a proprietary programming language?

If it was the right tool for the job, yes.

Library?

If it was the right tool for the job, yes.

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. So I'll use Objective-C (not
technically proprietary, but functionally so), a number of proprietary
libraries, several proprietary frameworks, and a series of proprietary
development tools. Because they let me do what I want.

If not, why not, and why would you use a proprietary text
editor, or debugger, or _any_ proprietary programming tool?

I would use them because they had features I wanted or needed which justified
their cost. If I were doing something that was targeting Intel chips, and
I needed the best possible performance, you BET it'd be using the Intel
proprietary compiler. If I were targeting Cell, and I needed the best
possible performance, you BET it'd be using the IBM compilers. If I had a
short deadline for debugging something, and a proprietary tool had a feature
that would let me debug it, yes, I'd use a proprietary tool. Purify does
stuff that most other allocation checkers I've tried didn't. If I desperately
needed to fix an allocation bug, I might well tell management "get me a
license for Purify or move your schedule". (Well, probably not, since I'm
pretty good at those anyway...)

I don't have a problem with proprietary tools, IF they do their job well
enough to justify the hassles.

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 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. ...Which is gonna go
away now that the two people who had Windows machines have moved out. But
I'll still probably use OS X Server, because it does what I want and stays
out of my face. Good enough.

-s

···

On 2010-03-11, David Masover <ninja@slaphack.com> wrote:
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
| Seebs.Net <-- lawsuits, religion, and funny pictures
Fair game (Scientology) - Wikipedia <-- get educated!

I'm much more interested in it on a personal level. Switching text editors at
this point might be, for most of us, far trickier than switching OSes, and
could be almost as bad as switching keyboard layouts. (Dvorak, anyone?) By
picking a proprietary technology, you're doing several things that I can't
really see being worth the risk:

To be honest with you I find your arguments weak at best. At the end
of the day the data it spits out (the files you work on) are simple
text files. How you got there doesn't matter, and I don't see why it
should. Yes, it may cost some retraining time to move to another text
editor but so what: should I stop using it on the off chance that the
developer takes it in a direction I don't like? Personally I didn't
buy textmate for what will be added in 1 year, but for what it is now.
And just like I moved to Textmate even though I wasted a few hours
learning to be comfortable in it, so I will in the future if I have
strong objections.

Do you make your own car on the off chance that the car makers will
make a car you won't like? Or maybe create your own mobile phone
because you are worried that tomorrow Nokia et al. will produce phones
you don't like?

Everytime you move from one product to another you need to retrain
yourself. Those of us who bought Textmate did it for what it is, and
that will not change. And as any other complex product in life if the
future Textmate will not be good enough, we will not buy it and get
something else.

Diego

Redcar is making a lot of progress. It is a JRuby text editor that is
attempting to be a complete clone and fully compatible with the text mate
snippets. It has been stable enough to begin to code with for a little
while now.

Looks interesting.

The only reason I mention Diakonos is that if I was going to start learning a
new editor, I might want a console one if I can make that work -- it'd be
something I can actually run over SSH, on remote machines, without having to
mount the filesystems first via sshfs.

Right now, I just use Kate, and vim when I have to ssh.

You could theoretically meta program the editor much in the same way you
can IRB.

That's the idea.

And yes, more power to Redcar, and Diakonos, and anything else. My rant was
specifically against relying on a single piece of proprietary software for
your development -- if there's actually a reasonable replacement by now, so be
it, though if I went that route, I'd suggest Redcar on OS X as well.

···

On Wednesday 10 March 2010 07:55:09 pm andrew mcelroy wrote:

While I have not tried, the linux version of e-texteditor (originally only
for Windows) is free and available here:
http://wiki.github.com/etexteditor/e/\.

It takes advantage of TextMate's bundles and is one of the editors I use on
Windows. You just have to build it.

"The editor could not have been build[sic] without the support of a lot of
open source projects (most notably wxWidgets <http://wxwidgets.org/&gt;\). So to
give back, the Linux version will be totally free (as in beer)."

···

On Wed, Mar 10, 2010 at 20:55, Seebs <usenet-nospam@seebs.net> wrote:

On 2010-03-11, David Masover <ninja@slaphack.com> wrote:
> I'm much more interested in it on a personal level. Switching text
editors at
> this point might be, for most of us, far trickier than switching OSes,
and
> could be almost as bad as switching keyboard layouts. (Dvorak, anyone?)
By
> picking a proprietary technology, you're doing several things that I
can't
> really see being worth the risk:

Just as a data point, I still use vi as my primary editor (nvi by
preference,
I dislike vim). And yet... I have TextMate, and BBEdit, both, on my Mac.

> * You're locked-in to a single provider -- in this case, a single
_person_.
> - If Allan Odgaard doesn't want to implement a feature you want,
you're
> SOL.
> - If Allan Odgaard can't fix a bug that's annoying you, you're also
SOL.
> - if Allan Odgaard wants money for a new car, you might find the next
> version of TextMate costs significantly more.

Sure.

But if the CURRENT version meets my needs, great!

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.

> * 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.

I'm not seeing a real issue here.

> - 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.

> - 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.

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?

Oh, wait. That actually *happens*, so we don't worry about it.

> - If you don't like the new OS X, for whatever reason, some new
version of
> TextMate might force you to upgrade anyway.

But you don't have to get a new version, if the one you have works.

> - 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, but by and
large,
the default I expect is that any given program will probably be specific
to a target platform.

> * You're a programmer, yet you can't program your own programming tools.
> - I don't care how extensible it is, you don't have the source.
> - Look at the tricks tools like Diakonos can do. Can TextMate do that?
> - Basically, TextMate may be at the top of the heap now (though
there's
> certainly room for debate), but if it continues to innovate, you can't be
a
> part of that. I would hope tools like Diakonos would win out in the long
run,
> because people who use them would inevitably contribute needed changes --
if
> there was ever a "scratch your own itch" app, a text editor is it.

I have never found myself with any complaints about the available options,
preferences, or features in either BBEdit or TextMate. I use vi because I
like the raw speed, and don't need the flashy stuff, but I've never found
myself wishing to extend either of them.

> * Again, a SINGLE PERSON is responsible for the destiny of this editor.
> - If Allan should be hit by a bus (not that I am wishing this on
anyone),
> what happens to TextMate development?

Presumably it goes to the estate. I dunno. I don't see this as a big
deal.
Again, if the current version works for me, I don't care about future
versions
for a long time.

> Still, think about it. Would you choose a proprietary programming
language?

If it was the right tool for the job, yes.

> Library?

If it was the right tool for the job, yes.

> 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. So I'll use Objective-C
(not
technically proprietary, but functionally so), a number of proprietary
libraries, several proprietary frameworks, and a series of proprietary
development tools. Because they let me do what I want.

> If not, why not, and why would you use a proprietary text
> editor, or debugger, or _any_ proprietary programming tool?

I would use them because they had features I wanted or needed which
justified
their cost. If I were doing something that was targeting Intel chips, and
I needed the best possible performance, you BET it'd be using the Intel
proprietary compiler. If I were targeting Cell, and I needed the best
possible performance, you BET it'd be using the IBM compilers. If I had a
short deadline for debugging something, and a proprietary tool had a
feature
that would let me debug it, yes, I'd use a proprietary tool. Purify does
stuff that most other allocation checkers I've tried didn't. If I
desperately
needed to fix an allocation bug, I might well tell management "get me a
license for Purify or move your schedule". (Well, probably not, since I'm
pretty good at those anyway...)

I don't have a problem with proprietary tools, IF they do their job well
enough to justify the hassles.

> 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 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. ...Which is gonna go
away now that the two people who had Windows machines have moved out. But
I'll still probably use OS X Server, because it does what I want and stays
out of my face. Good enough.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach /
usenet-nospam@seebs.net
| Seebs.Net <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology)&lt;http://en.wikipedia.org/wiki/Fair_Game_(Scientology)&gt;&lt;\-\- get educated!

hey, I agree with the whole post of yours, but this is the key message:

But if the CURRENT version meets my needs, great!

Fear of some bad thing to happen (and most of which are not very
likely) should not
stop you from using the tool you consider best for the job right now.
And most of us a probably using several editors anyway, so switching to some
alternative already familiair won't be that huge cost.

Regards,
Rimantas

···

--
http://rimantas.com/

> I'm much more interested in it on a personal level. Switching text
> editors at this point might be, for most of us, far trickier than
> switching OSes, and could be almost as bad as switching keyboard layouts.
> (Dvorak, anyone?) By picking a proprietary technology, you're doing
> several things that I can't really see being worth the risk:

To be honest with you I find your arguments weak at best. At the end
of the day the data it spits out (the files you work on) are simple
text files.

Yes, I acknowledged this, and it's why I care much more about people using IE
than people using TextMate.

Yes, it may cost some retraining time to move to another text
editor but so what:

So, that's a nuisance and a cost, and depending on how much you find yourself
relying on a given tool, it may start to be significant.

Do you make your own car on the off chance that the car makers will
make a car you won't like?

Bad analogy -- I don't have to "make my own car," there's things like RedCar,
Diakonos, and others.

But there isn't really a lot of choice in cars. If I want a decent car at an
affordable price, I pretty much want something manufactured, probably
something used. It's entirely impractical to build it myself.

If you want a better car analogy for this sort of thing, I recommend Neal
Stephenson's "In the beginning was the command line":

···

On Thursday 11 March 2010 06:50:07 am Diego Virasoro wrote:

Or maybe create your own mobile phone
because you are worried that tomorrow Nokia et al. will produce phones
you don't like?

Everytime you move from one product to another you need to retrain
yourself. Those of us who bought Textmate did it for what it is, and
that will not change. And as any other complex product in life if the
future Textmate will not be good enough, we will not buy it and get
something else.

Diego

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.

···

On Wednesday 10 March 2010 10:55:11 pm Seebs wrote:

In general, yes. The key thing there is that, no matter what happens
to TextMate in the future, I can use the current version. Contrast with,
say, the recent kerfluffle with Ubisoft introducing a "DRM" scheme whereby,
if their servers go down, the program you ALREADY HAVE stops working. In
that case, it's certainly quite reasonable to be concerned.

The key thing to evaluate is what happens to you in the case where things
go "poof". If the guy selling TextMate goes away tomorrow, I still have
an editor that does a bunch of stuff pretty well and which I find basically
friendly. I can live with that.

-s

···

On 2010-03-11, Rimantas Liubertas <rimantas@gmail.com> wrote:

But if the CURRENT version meets my needs, great!

Fear of some bad thing to happen (and most of which are not very
likely) should not
stop you from using the tool you consider best for the job right now.

--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
| Seebs.Net <-- lawsuits, religion, and funny pictures
Fair game (Scientology) - Wikipedia <-- get educated!

While I have not tried, the linux version of e-texteditor (originally only
for Windows) is free and available here:
http://wiki.github.com/etexteditor/e/\.

Another vote for E Text Editor here. It's coming along nicely on Linux:

Read about the author's own unique style of open source here, which is an interesting story in its own right:

> A better question might be why so much of the Ruby community has
> embraced a proprietary editor which is only available for a
> proprietary OS.

I think that could be a classic case of a 'Tipping Point'[1] moment. The original Rails screencasts by David were done in TextMate on a Mac. At the time, I remember being allured and wowed by the editor as much as Rails (and Ruby) itself. I had already come across Ruby before, but this frankly /sexy/ demonstration was what swung me over to it wholeheartedly. From there - that original sales pitch - the epidemic spread through the mavens and connectors (bloggers and influential 'web 2.0' people). To get on board and be like David one had to have TextMate and, of course, a Mac. I suppose, in a way, it's a bit like kids wanting the same boots as their favourite soccer stars.

Having said that, I still don't have either a Mac or TextMate, so go figure. :slight_smile:

[1] The Tipping Point - Wikipedia

Charles

···

On 11/03/2010 07:17, sl4m wrote:
On 06/03/2010 04:31, David Masover wrote:

Steve Kim wrote:

While I have not tried, the linux version of e-texteditor (originally
only
for Windows) is free and available here:
http://wiki.github.com/etexteditor/e/\.

It is free but unless you register will give you a popup at startup time
saying "your license has expired" (then allowing you to continue) :slight_smile:

The only open source textmate clone I'm aware of is Redcar. It just
released a new version with snippets now :slight_smile:

http://redcareditor.com/2010/03/redcar-034dev-released/

-r

···

--
Posted via http://www.ruby-forum.com/\.

Sorry for the double-post... accidentally hit ctrl+enter before it was
finished.

> > I'm much more interested in it on a personal level. Switching text
> > editors at this point might be, for most of us, far trickier than
> > switching OSes, and could be almost as bad as switching keyboard
> > layouts. (Dvorak, anyone?) By picking a proprietary technology, you're
> > doing several things that I can't really see being worth the risk:
>
> To be honest with you I find your arguments weak at best. At the end
> of the day the data it spits out (the files you work on) are simple
> text files.

Yes, I acknowledged this, and it's why I care much more about people using
IE than people using TextMate.

> Yes, it may cost some retraining time to move to another text
> editor but so what:

So, that's a nuisance and a cost, and depending on how much you find
yourself relying on a given tool, it may start to be significant.

> Do you make your own car on the off chance that the car makers will
> make a car you won't like?

Bad analogy -- I don't have to "make my own car," there's things like
RedCar, Diakonos, and others.

But there isn't really a lot of choice in cars. If I want a decent car at
an affordable price, I pretty much want something manufactured, probably
something used. It's entirely impractical to build it myself.

If you want a better car analogy for this sort of thing, I recommend Neal

Stephenson's "In the beginning was the command line":

http://www.cryptonomicon.com/beginning.html

> Or maybe create your own mobile phone
> because you are worried that tomorrow Nokia et al. will produce phones
> you don't like?

Again, I don't have to create my own -- but Android helps. I wouldn't buy an
iPhone, for instance, no matter what it can do now.

···

On Friday 12 March 2010 05:39:29 pm David Masover wrote:

On Thursday 11 March 2010 06:50:07 am Diego Virasoro wrote:

But if the CURRENT version meets my needs, great!

So long as the current version continues to work.

Well, yeah. You know, some of the computers I've bought in the past
don't work anymore, either. Doesn't mean I was ripped off.

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.

Non-comparable. No fundamental civil rights are infringed when I'm told
I can't burn *someone else's* American flag. My right to write software
is not infringed by my lack of a right to modify someone else's without
permission.

> * 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.

So? I've got code which has been broken by just about every Linux system
revision since RHEL4 or so. However, the bulk of my stuff keeps working,
and the same is true of OS X; the bulk of the code out there continues to
run.

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...

That's backwards. Obviously, when developing, you tend to target a relatively
recent system. That doesn't mean that a version of VLC which had been built
for 10.2 wouldn't still work on 10.4. Your claim was that it was "as likely
as not" that any given upgrade would break TextMate. But all you've shown so
far is that at least one group of people who were actively updating software
for new systems released something that ran on a previous system and the
current system, but not on systems before that -- but that could be just
because they linked against that system's libraries.

> - 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.

Yep. But five or six revisions is getting on towards a decade, and I buy
a lot of programs that don't run for nearly that long.

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.

Right.

Which might be a good argument against considering XP to be the basis of your
business or livelihood, unless you have some particular reason for which it's
really the best choice for you anyway.

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?

Not particularly high -- but an editor isn't comparable to an OS (unless
it's emacs). I don't have to worry about new malware targeting my editor,
I do have to worry about new malware targeting my OS.

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?

Yes.

But I can't see why you'd argue not just that this is a benefit, but that
it's such a huge benefit that anyone who would prefer ANY other combination
of features, values, or requirements over it is somehow objectively wrong.

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!

Oh, sure, tons of stuff is portable. On the other hand, having suffered
through Gaim^WPidgin for years, I *love* using Adium X. Yes, it means that
my preferred chat program is OS X only. But that's a TINY price to pay
for having a user interface that doesn't make me want to stab the developers
with every kitchen implement I can find.

My photo editor of choice is OS-specific. So are a few of the graphics tools
I use, and my preferred word processor and paint program. On the other hand,
they work a lot better for me than the alternatives, so I use them.

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.

One of the things I want is a pleasant development environment. The NextStep
design was brilliant, and I still find it pleasant to work with. I've worked
with a dozen or so UI toolkits, and this is the only one I haven't actively
hated since Intuition.

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.

Different kinds of tools have different requirements. Open source is *a*
benefit. It is not *the* benefit. There are many cases where other things
matter more.

For editing, what I require most of all is that my editor be convenient,
flexible, and stay out of my way. If Textmate does a better job for me
than the open source alternatives, then of course I should use it. That
I might not be able to later doesn't mean I shouldn't use the best tool
I can find now.

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.

I don't view choice of editor as really being a matter of "completely redo".
It's one of many tools I use, and if I switch, well, I use a different editor.
Whatever.

An editor that works enough better for me than an alternative will save me
an hour a day. Learning a new editor will take, say, a forty-hour week.
If I use an editor for over forty days, I'm probably ahead on the deal -- if
it really is that much nicer.

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

Yeah, I did actually set up samba. Three times. It was a nightmare to
get it working reliably with several different windows systems, the
documentation was crap, and it crashed fairly often. Building it is not
the hard part; *configuring* it is. Wouldn't It Be Nice if someone
shipped something that handled the basic cases ("I want to export this
filesystem to authenticated users in this local workgroup") automatically?

It may well have improved since I set it up; that was a few years back.
I did not find it a particularly enlightening experience.

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.

It's not "half an hour". It's "two hours the first time, one hour every
time I have to redo things for some reason, and half an hour a week because
of stuff going unexpectedly wrong". Whereas, with OS X, I clicked a button,
and it worked fine, and has continued to work fine (except, of course, that
the *client* machines were still unreliable).

I don't enjoy system administration. The less time I have to spend on it,
the happier I am.

With the OS X machine, it took me half an hour to get reliable file sharing
over three different (and unrelated) protocols, only one of which I could
easily have configured myself, as well as having user authentication working
for several different kinds of clients. Yes, I know how to set up
authentication services. It's a pain, it takes time, and I don't enjoy it
or find it rewarding. My interest level in learning enough about it to
correctly set up a Windows workgroup in order to authenticate users in order
to provide shared access to files which preserves user permissions between
Mac, Windows, and BSD clients? Pretty much zero. My interest level in
having it all work with a handful of clicks on clearly labeled UI items?
Pretty high.

I used to do a bunch of this stuff myself. I'd guess it cost me 20-30
hours a year. Compare to $500... That's around $25/hour, give or take.
Now imagine that the server lasts for two years. It's now only a good
deal if I make $12.50 an hour.

Since $DAYJOB is salaried, I don't have a semantically-coherent hourly wage
anymore, but this stuff all happens in my spare time, and none of the
money-related things I do in my spare time are under $75/hour. A year's
hassle dealing with the home network costs me a lot more than a mini with
OS X server would.

-s

···

On 2010-03-13, David Masover <ninja@slaphack.com> wrote:

On Wednesday 10 March 2010 10:55:11 pm Seebs wrote:

--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
| Seebs.Net <-- lawsuits, religion, and funny pictures
Fair game (Scientology) - Wikipedia <-- get educated!