Re: Ruby 1.8 vs 1.9

On Sunday, November 28, 2010 04:29:34 pm Phillip Gawlowski wrote:
> On Sun, Nov 28, 2010 at 9:19 PM, David Masover <[e-mail]> wrote:
> > 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.

Sounds like we don't actually disagree.

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

Then why the fsck is he CTO of anything?

> and probably doesn't care.

This is the part I don't get.
How do you get to be CTO by not caring about technology?

> Together with the usual
> bureaucratic infighting and processes to change *anything*, you'll be
> SOL most of the time. Alas.

Which is, again, a point I'd hope the free market would resolve. If there's a 
way to build a relatively large corporation without bureaucracy and process 
crippling actual progress, you'd think that'd be a competitive advantage.

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

In each case, there wasn't really a better option, and likely still isn't.

Still, I don't know about Windows, but on Linux, there seems to be a push to 
keep the kernel as small as it can be without losing speed or functionality. 
There were all sorts of interesting ideas in filesystems, but now we have 
fuse, so there's no need for ftpfs in the kernel. Once upon a time, there was 
a static HTTP server in the kernel, but even a full apache in userspace is 
fast enough.

And the reason is clear: Something blows up in a C program, it can affect 
anything else in that program, or any memory it's connected to. Something 
blows up in the kernel, it can affect _anything_.

I'm also not sure how much of that knowledge really translates. After all, if 
an organization is choosing C because it's the "safe" choice, what are the 
chances they'll use Git, or open development, or any of the other ways the 
Linux kernel is managed?

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

So what happens if they cancel your project?

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

Shaving a couple seconds off is beside the point. The question is whether 
there's some fundamental way in which the process can be improved -- something 
which can be automated which actually costs a large amount of time, or some 
minor shift in process, or small amount of knowledge...

Another contrived example: Suppose financial records were kept as text fields 
and balanced by hand. The computer still helps, because you have all the data 
in one place, easily backed up, multiple people can be looking at the same 
data simultaneously, and every record is available to everyone who needs it 
instantly.

But as soon as you want to analyze any sort of financial trend, as soon as you 
want to mine that data in any meaningful way, you have a huge problem. The 
query running slowly because it's text is probably minor enough. The problem 
is that your data is mangled -- it's got points where there should be commas, 
commas where there should be points, typo after typo, plus a few "creative" 
entries like "a hundred dollars." None of these were issues before -- the 
system did work, and had no bugs. But clearly, you want to at least start 
validating new data entered, even if you don't change how it's stored or 
processed just yet.

In a modern system, adding a validation is a one-liner. Some places, that 
could take a week to go through the process. Some places, it could be pushed 
to production the same day. (And some places arguably don't have enough 
process, and could see that one-liner in production thirty seconds after 
someone thought of it.)

To retrofit that onto an ancient COBOL app could take a lot more work.

I don't know enough about steel to say whether it's relevant here, but I have 
to imagine that even here, there are opportunities to dramatically improve 
things. Given an opportunity to make the change, in choosing whether to 
rewrite or not, I'd have to consider that this isn't likely to be the last 
change anyone ever makes.

The depressing thing is that in a modern corporation, this sort of discussion 
would be killed reflexively by that conservative-yet-short-term mentality. A 
rewrite may or may not be a sound investment down the road, but if it costs 
money and doesn't pay off pretty immediately, it's not worth the risk at 
pretty much any level of the company. Not so much because it might not pay off 
ever, but more because investors will see you've cost the company money (if 
only in the short term) and want you gone.

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

Cool.

I can only wonder how well that works when the veteran cookers retire. Does 
that knowledge translate?

I've definitely learned something about steel today, though. Interesting 
stuff. Also good to know what I want to avoid...

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

Which is kind of my point. Why did they upgrade? While it's true that it's 
relatively cheap, and they may also be monetizing their customer's data, I 
have to imagine at least part of the reason is that they were feeling the 
pressure from Gmail.

> And you'd be surprised
> how... stubborn non-techies can be.

Not terribly. I'm more surprised how stubborn techies can be.