From: "Eleanor McHugh" <eleanor / games-with-brains.com>
> 
> I don't enjoy it so I probably shouldn't recommend it, but C is  
> definitely the place to see how not to solve most programming problems  
> and hence a necessity for any multilingual programmer's toolkit.

:D awesome

What I periodically daydream about is a portable
subset of ruby within ruby which is geared toward
displaying 1_000_000+ polygons on the screen at
60Hz (for example.  {As we can do currently in C.})

I love the concept of RubyInline, (or the integration
of JRuby with Java), but instead of Java or C I would
die for being able to write some little loops in some
ruby sub-language (where things were as static typed
as necessary, but speed was #1 priority however it was
achieved.)

If I could write, like

  gofast {
    def (float) bsp_trace((BSP)game_level, (Vec3D)start, (Vec3D)dir)
      (float) dist
      # ....
      return dist
    end
  }

... and during the gofast { } ruby would drop into 
a mode where it would either produce warnings or
errors if *anything* were dynamic... (at compile time)

Meaning Vec3D and BSP would in turn be required to
provide their own 'gofast' methods, ... 'till we got
down to primitive types. . . . ..

Of course, I'd still value knowing C 'cause there's 
so much of it out there, but I'd love to be able to
avoid dropping into it in my own apps......... :)


Regards,

Bill