Re: Ruby 1.8 vs 1.9

On Sunday, November 28, 2010 11:19:06 am Phillip Gawlowski wrote:
> > Probably. You originally called this a "Mainframe", and that's what
> > confused me -- it definitely seems to be more a cluster than a
> > mainframe, in terms of hardware and software.
> 
> Oh, it is. You can't build a proper mainframe out of off the shelf
> components, but a mainframe is a cluster of CPUs and memory, anyway,
> so you can "mimic" the architecture.

When I hear "mainframe", I think of a combination of hardware and software 
(zOS) which you actually can't get anywhere else, short of an emulator (like 
Hercules).

> >> This is a very,
> >> very conservative mindset, where not even Java has a chance.
> > 
> > If age is the only consideration, Java is only older than Ruby by a few
> > months, depending how you count.
> 
> It isn't. Usage on mainframes is a component, too.

IBM does seem to be aggressively promoting not just Linux on mainframes, but a 
Unix subsystem and support for things like Java.

> And perceived
> stability and roadmap safety (a clear upgrade path is desired quite a
> bit, I wager).

Is there "roadmap safety" in C, though?

> And, well, Java and Ruby are young languages, all told. Mainframes
> exist since the 1940s at the very least, and that's the perspective
> that enabled "Nobody ever got fired for buying IBM [mainframes]".

Right, that's why I mentioned Lisp. They're old enough that I'd argue the time 
to be adopting is now, but I can see someone with a mainframe several times 
older wanting to wait and see.

> > I'm not having a problem with it being a conservative mindset, but it
> > seems irrationally so. Building a mission-critical system which is not
> > allowed to fail out of a language like C, where an errant pointer can
> > corrupt data in an entirely different part of the program (let alone
> > expose vulnerabilities), seems much riskier than the alternatives.
> 
> That is a problem of coding standards and practices.

There's a limit to what you can do with that, though.

> Another reason
> why change in these sorts of systems is difficult to achieve. Now
> imagine a language like Ruby that comes with things like reflection,
> duck typing, and dynamic typing.

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?

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.

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.

> > About the strongest argument I can see in favor of something like C over
> > something like Lisp for a greenfield project is that it's what everyone
> > knows, it's what the schools are teaching, etc. Of course, the entire
> > reason the schools are teaching COBOL is that the industry demands it.
> 
> A vicious cycle, indeed.

I have to wonder if it would be worth it for any of these companies to start 
demanding Lisp. Ah, well.

> Mind, for system level stuff C is still the
> goto language, but not for anything that sits above that. At least,
> IMO.

For greenfield system-level stuff, I'd be seriously considering something like 
Google's Go. But my opinion probably isn't worth much here, as I don't really 
do system-level stuff if I can avoid it (which is almost always). If I had to, 
I'd pass as much off to userland as I could get away with.

> >> Unless there is a very solid business case (something on the level of
> >> "if we don't do this, we will go bankrupt in 10 days" or similarly
> >> drastic), there is no incentive to fix what ain't broke (for certain
> >> values of "ain't broke", anyway).
> > 
> > This is what I'm disputing. This kind of thinking is what allows
> > companies like IBM to be completely blindsided by companies like
> > Microsoft.
>
> [snip]
>
> 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.

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.

> > Then, relatively quickly, everyone else did the same thing, because
> > people were leaving Hotmail for Gmail for the storage alone, and no one
> > wanted to be the "10 mb free" service when everyone else was offering
> > over a hundred times as much.
> 
> That, and Google was the cool kid on the block back then. Which counts
> for quite a bit, too. And the market of freemail offerings was rather
> stale, until GMail shook it up, and got lots of mind share really
> fast.
> 
> But most people stuck with their AOL mail addresses, since they didn't
> care about storage, but cared about stuff working. The technorati
> quickly switched (I'm guilty as charged), but aunts, and granddads
> kept their AOL, EarthLink, or Yahoo! accounts.

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.