From: David Masover Date: 2010-03-21T13:50:39+09:00 Subject: Re: Why no TextMate for Linux? On Saturday 20 March 2010 11:40:09 pm Seebs wrote: > On 2010-03-21, David Masover 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.