Re: Ruby 1.8 vs 1.9

On Sun, Nov 28, 2010 at 9:19 PM, David Masover <[e-mail]> wrote:
>
> Is there "roadmap safety" in C, though?

Since it is, technically, a standardized language, with defined
behavior in all cases (as if), it is.

Though, considering C++0x was supposed to be finished two years ago...

>> That is a problem of coding standards and practices.
>
> There's a limit to what you can do with that, though.

One of cost. Nobody wants to spend the amount of money that NASA
spends on the source for the Space Shuttle, but that code is
guaranteed bug free. Not sure which language is used, though, but I
guess it's ADA.


> In practice, it doesn't seem like any of these are as much of a problem as the
> static-typing people fear. Am I wrong?

Nope. But perceived risk outweighs actual risk. See also: US policy
since 2001 vis a vis terrorism.

> Given the same level of test coverage, a bug that escapes through a Ruby test
> suite (particularly unit tests) might lead to something like an "undefined
> method" exception from a nil -- relatively easy to track down. In Java, it
> might lead to NullPointerExceptions and the like. In C, it could lead to
> _anything_, including silently corrupting other parts of the program.
>
> Technically, it's _possible_ Ruby could do anything to any other part of the
> program via things like reflection -- but this is trivial to enforce. People
> generally don't monkey-patch core stuff, and monkey-patching is easy to avoid,
> easy to catch, and relatively easy to do safely in one place, and avoid
> throughout the rest of your program.

You know that, I know that, but the CTO of Johnson and Johnson
doesn't, and probably doesn't care. Together with the usual
bureaucratic infighting and processes to change *anything*, you'll be
SOL most of the time. Alas.

> Contrast to C -- it's not like you can avoid pointers, arrays, pointer
> arithmetic, etc. And Ruby at least has encapsulation and namespacing -- I
> really wouldn't want to manage a large project in C.

Neither would I. But then again, there's a lot of knowledge for
managing large C code bases. Just look at the Linux kernel, or Windows
NT.

>> >> Unless there is a very solid business case (something on the level of
>> Or do you care if the steel beams you buy by the ton, or the cleaner
>> you buy are produced by a company that does its ERP on a mainframe or
>> a beowulf cluster?
>
> Not particularly, but I do care if someone else can sell me those beams
> cheaper. Even just as a cost center, it matters how much it costs.
>
> And who knows? Maybe someone else just implemented a feature that actually
> does matter to me. Maybe they anticipate when their customers need more steel
> and make them an offer then, or maybe they provide better and tighter
> estimates as to when it'll be ready and how long it'll take to ship -- maybe
> it's an emergency, I need several tons RIGHT NOW, and someone else manages
> their inventory just a bit better, so they can get it to me days earlier.

Production, these days, is Just In Time. To stay with our steel
example: Long before the local county got around to nodding your
project through so that you can begin building, you already know what
components you need, and when (since *you* want to be under budget,
and on time, too), so you order 100 beams of several kinds of steel,
and your aggregates, and bribe the local customs people, long before
you actually need the hardware.

There's (possibly) prototyping, testing (few 100MW turbines can be
built in series, because demands change with every application), and
nobody keeps items like steel beams (or even cars!) in storage
anymore. ;)

Similar with just about anything that is bought in large quantities
and / or with loads of lead time (like the 787, or A380).

In a nutshell: being a day early, or even a month, doesn't pay off
enough to make it worthwhile to restructure the whole company's
production processes, just because J. Junior Developer found a way to
shave a couple of seconds off of the DB query to send off ordering
iron ore. ;)

> Granted, it's a slower industry, so maybe spending years (or decades!) on
> changes like the above makes sense. Maybe no one is offering or asking for the
> features I've suggested -- I honestly don't know. But this is why it can
> matter than one organization can implement a change in a few weeks, even a few
> months, while another would take years and will likely just give up.

Since it takes *years* to build a modern production facility, it *is*
a slower industry, all around. IT is special in that iterates through
hardware, software, and techniques much faster that the rest of the
world.

And an anecdote:
A large-ish steel works corp introduced a PLC system to monitor their
furnaces down to the centidegree Celsius, and the "recipe" down to the
gram. After a week, they deactivated the stuff, since the steel
produced wasn't up to spec, and the veteran cookers created much
better steel, and cheaper.

> Most of them, for awhile.
>
> But even granddads have grandkids emailing them photos, so there goes that 10
> megs. Now they have to delete stuff, possibly download it and then delete it.
> A grandkid hears them complaining and suggests switching to Gmail.

Except that AOhoo! upgraded their storage. And you'd be surprised
how... stubborn non-techies can be. One reason why I don't do family
support anymore. :P

-- 
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.