Why no TextMate for Linux?
in [Ruby]
|
From: David Masover on 20 Mar 2010 23:41 On Saturday 20 March 2010 06:25:08 pm Seebs wrote: > >> I lean towards letting them make whatever agreement they want, and if > >> you don't like a particular vendor's agreement, don't buy their product. > >> :) > > > > Unfortunately, again, I'm an outlier and I will continue to be, so long > > as so many people continue to, say, buy iPhones. The net result is that > > very often there's a product (or set of products) which I do want, but > > which have intolerable licenses. (Imagine if _every_ restaurant required > > people to sign a waiver not to sue for food poisoning.) > > I'm not sure this is a problem, though. My desire for something is > influenced by its licensing. I don't view it as "a product I want, with > an intolerable license", but as "a product that is similar to one I'd > want'. It's a fair point, but no less frustrating. In the case of a restaurant, you can just (almost literally) _taste_ the product you might actually want, but no one is providing it. You might see an opportunity and try to open your own, but then you either need to be successful for other reasons, or convince everyone else to share your own views about contracts. So again, it comes back to: I can see where it might make sense to legally allow such waivers, but I still find them morally distasteful, and I would argue against them. > > Maybe, but it has been tried in the past, and it's generally failed. Your > > competition now is monthly plans in which, after a certain number of > > months, you actually own the computer -- why would I rent when I can > > rent-to-own? > > Some large businesses lease computers because they don't WANT to own > computers. Personal users, of course, tend to want to buy things. > > I rent a computer right now, in fact. I think it's somewhere in Texas. > It comes with a bunch of bandwidth. It was less hassle for me to rent > bandwidth+computer than it would be for me to own the computer, and I don't > WANT to "own" that -- I want it to be someone else's job to provide the > functionality to me. Makes sense, and so do I -- or a portion of one. Then again, if I could have the option to stop paying for that computer after awhile (and just pay for bandwidth), I'd probably take it. > > I suppose it depends. I do know that the more expensive the contract, the > > better phones come "free" with it. I also know that Verizon, in > > particular, charges much more for a "smartphone" plan than a straight > > data plan, even if you're paying a certain amount up front for the phone. > > Could well be. That might be, in no small part, because smartphones tend > to use a LOT of bandwidth. In this case, that's an assumption based on the device, and it's the reason we have all this stupidity about tethering. If the bandwidth is an issue, charge per bit or raise the monthly fee. (There's also the issue that not all smartphone users want or need Internet on their phone.) Instead, we get potentially a lower monthly fee, plus some arbitrary and asinine restrictions on how we use it, in the _hope_ that we use less bandwidth. Why not simply have a lower-bandwidth plan? > > If so, I still don't see the barrier -- Ruby is a C program. You may not > > be able to install it into the system, but you can certainly compile it > > and run it locally. > > It's a lot of work, though, and I'm not sure I can compile all the things > it would require, or at least benefit from having. I've done this sort of thing before. It's not as hard as it's made out to be, and even a Ruby without everything it'd "benefit from having" would likely be better than raw C. Think about it -- Ruby without readline support (so IRB sucks), or raw C? For the cases where I'd be considering Ruby at all, the lack of readline wouldn't stop me. After all, if it's a library I actually want/need (say, OpenSSL), I'm going to need to install the same headers and such to use it from a C program anyway. > > Fair enough -- though with a brief glance, I wonder how much of it could > > be done in Ruby, and might even make sense in Ruby. > > My guess would be virtually none. Certainly, virtually none could be done > with acceptable efficiency. Configuration, at the very least. Also, I'm not sure I see efficiency as a burden here, for the most part -- it looks like the intended use here is compiling, which is already slow anyway, and is a domain where tools like make (or even rake) are used also. The part which actually builds an image/package is going to be IO-bound anyway. I can't say Ruby is a good idea there, because I just don't know enough.
From: Seebs on 21 Mar 2010 00:37 On 2010-03-21, David Masover <ninja(a)slaphack.com> wrote: > In this case, that's an assumption based on the device, and it's the reason we > have all this stupidity about tethering. If the bandwidth is an issue, charge > per bit or raise the monthly fee. (There's also the issue that not all > smartphone users want or need Internet on their phone.) > Instead, we get potentially a lower monthly fee, plus some arbitrary and > asinine restrictions on how we use it, in the _hope_ that we use less > bandwidth. Why not simply have a lower-bandwidth plan? Probably because you can't cap bandwidth -- the phone is effectively broken if you do -- and people freak out if you charge them huge amounts of money for bandwidth. > I've done this sort of thing before. It's not as hard as it's made out to be, > and even a Ruby without everything it'd "benefit from having" would likely be > better than raw C. Maybe, but not enough to justify the effort, especially since most of the stuff I want is already written and working in C or shell. > Think about it -- Ruby without readline support (so IRB sucks), or raw C? For > the cases where I'd be considering Ruby at all, the lack of readline wouldn't > stop me. The point is, it's an example of a case where I can use a program already existing, written in C, but I can't use one already existing, written in Ruby. I'm talking about *using* programs -- because I write programs in order that people could use them. So I tend to write things in C for portability if I want people to have access those things. >> My guess would be virtually none. Certainly, virtually none could be done >> with acceptable efficiency. > Configuration, at the very least. I don't see any to do. > Also, I'm not sure I see efficiency as a > burden here, for the most part -- it looks like the intended use here is > compiling, which is already slow anyway, Yeah, that's the thing. Right now, a build of the whole shebang this is being used with takes over an hour on an 8-core machine with 48GB of memory and fast disks. Running stuff inside my current library adds about 16% to everything, give or take -- more with lots of small files. Running inside a larger/slower language would be crippling. > and is a domain where tools like make > (or even rake) are used also. The part which actually builds an image/package > is going to be IO-bound anyway. You'd think, but no. Running the same tar command can take SUBSTANTIALLY longer under a wrapper like this. Adding more processing complexity noticably affects that. Yes, it's I/O bound, but I'm adding a lot of I/O to many I/O operations... -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: David Masover on 21 Mar 2010 00:50 On Saturday 20 March 2010 11:40:09 pm Seebs wrote: > On 2010-03-21, David Masover <ninja(a)slaphack.com> wrote: > > In this case, that's an assumption based on the device, and it's the > > reason we have all this stupidity about tethering. If the bandwidth is an > > issue, charge per bit or raise the monthly fee. (There's also the issue > > that not all smartphone users want or need Internet on their phone.) > > > > Instead, we get potentially a lower monthly fee, plus some arbitrary and > > asinine restrictions on how we use it, in the _hope_ that we use less > > bandwidth. Why not simply have a lower-bandwidth plan? > > Probably because you can't cap bandwidth -- the phone is effectively broken > if you do Well, its Internet functionality is. It can still make phone calls, unless you're counting phone calls towards bandwidth -- in which case, I hope you aren't charging for minutes. (If you are, you're charging them twice for the same call, which is a bit sleazy.) > and people freak out if you charge them huge amounts of money > for bandwidth. They also freak out if you charge them huge amounts for text messaging, or regular calls, or minutes of regular calls. The same simple rules apply -- offer a per-usage rate (per-minute, per-bit), offer various tiered rates, offer an "unlimited" flat-rate if your network can handle it. In fact, that's exactly what they do anyway -- they just charge an additional, arbitrary "smartphone" fee on top of it if you happen to be using a smartphone. And you're saying it's because of bandwidth? With what they're charging for bandwidth, you'd think that's already built into the bandwidth plan -- and it has to be, to some extent, given that my "non-smartphone" can already download apps, music, and video, and can message/email said music/video to others. > > Think about it -- Ruby without readline support (so IRB sucks), or raw C? > > For the cases where I'd be considering Ruby at all, the lack of readline > > wouldn't stop me. > > The point is, it's an example of a case where I can use a program already > existing, written in C, but I can't use one already existing, written in > Ruby. Well, again, it comes down to compiling Ruby vs compiling your C program. If they can compile Ruby, there's no compiling needed for your Ruby script, it just runs -- so it's still exactly one compile step. I could even argue that if your build process is more complicated than "type make" or "gcc foo.c", it might be that much easier to install something like Ruby, with a large community of maintainers and a number of people who may be able to help if you have problems compiling on a weird platform, rather than installing whatever make/autoconf/whatever you come up with. > > Also, I'm not sure I see efficiency as a > > burden here, for the most part -- it looks like the intended use here is > > compiling, which is already slow anyway, > > Yeah, that's the thing. Right now, a build of the whole shebang this is > being used with takes over an hour on an 8-core machine with 48GB of > memory and fast disks. Running stuff inside my current library adds > about 16% to everything, give or take -- more with lots of small files. > Running inside a larger/slower language would be crippling. Huh. I concede the point, then. I'd have to look much closer for opportunities to script, and you're probably right.
From: Seebs on 21 Mar 2010 01:33 On 2010-03-21, David Masover <ninja(a)slaphack.com> wrote: > Well, its Internet functionality is. It can still make phone calls, unless > you're counting phone calls towards bandwidth -- in which case, I hope you > aren't charging for minutes. (If you are, you're charging them twice for the > same call, which is a bit sleazy.) It is more complicated. For instance, one of my phones, if reset, restores its phone book from the internet. > In fact, that's exactly what they do anyway -- they just charge an additional, > arbitrary "smartphone" fee on top of it if you happen to be using a > smartphone. And you're saying it's because of bandwidth? With what they're > charging for bandwidth, you'd think that's already built into the bandwidth > plan -- and it has to be, to some extent, given that my "non-smartphone" can > already download apps, music, and video, and can message/email said > music/video to others. It may well be, but I suspect that in practice, the difference in network load between a phone that watches youtube and a phone that browses plain text web sites is pretty large. > Well, again, it comes down to compiling Ruby vs compiling your C program. If > they can compile Ruby, there's no compiling needed for your Ruby script, it > just runs -- so it's still exactly one compile step. Except that, in practice, "I need to install a new programming language" is a bigger deal than "I'll run this thing which uses existing standard tools". > Huh. I concede the point, then. I'd have to look much closer for opportunities > to script, and you're probably right. Basically, it isn't in Ruby for the same reason that libc isn't written in Ruby. It is, admittedly, arguably a special case. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: David Masover on 21 Mar 2010 02:48
On Sunday 21 March 2010 12:35:12 am Seebs wrote: > > In fact, that's exactly what they do anyway -- they just charge an > > additional, arbitrary "smartphone" fee on top of it if you happen to be > > using a smartphone. And you're saying it's because of bandwidth? With > > what they're charging for bandwidth, you'd think that's already built > > into the bandwidth plan -- and it has to be, to some extent, given that > > my "non-smartphone" can already download apps, music, and video, and can > > message/email said music/video to others. > > It may well be, but I suspect that in practice, the difference in network > load between a phone that watches youtube and a phone that browses plain > text web sites is pretty large. Certainly. But again, that's something which can be dealt with in practice, not pre-emptively. > > Well, again, it comes down to compiling Ruby vs compiling your C program. > > If they can compile Ruby, there's no compiling needed for your Ruby > > script, it just runs -- so it's still exactly one compile step. > > Except that, in practice, "I need to install a new programming language" is > a bigger deal than "I'll run this thing which uses existing standard > tools". Well, except in this case, they're pretty much the same thing. |