On Saturday 20 March 2010 11:40:09 pm Seebs wrote:
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.
