[ruby-talk:9598] Re: 101 Misconceptions About Dynamic Languages

I've really backed myself into a corner here. Witness my Houdini act.

"Ben Tilly" <[e-mail]> wrote:
> [the assertion that Ruby does not support first-class functions] is
patently false.

Nods.

> See class Continuation.  Or the callcc function in the
> kernel.  You can call it with its call method.

I understand that now. It is patently obvious that I am regurgitating
unlearned knowledge. I am interested in class Continuation, and will read
up.

> I think that there is probably more to Ruby than you
> currently think.  Now to throw fat on your C++
> discussion, a friend who used to love C++ and then grew
> to detest it summarized his beefs with the language
> somewhat like this:
>
>    If you have a God's eye view of the problem, then
>    you can construct breathtaking solutions in C++.
>    When you don't then it is easy to go very wrong
>    very fast.

True enough on both counts -- there is more to Ruby than I currently
understantand, and  C++ can be 'dangerous'. Witness witless abuse of
operator overloading, and ridiculous use of class hierarchies and virtual
functions. Then again, one must be optimistic. As Bjarne says, "Don't remove
a feature just because it /may/ be misued". As your friend infers, C++
provides the possibility of a path (solution) that efficiently solves
problems.

Now, it is true that the flexibility provided by C++ (even I am getting
tired of this) also leaves a door open to misadventure and pain. But, to
quote Rage Against the Machine, "if ignorance is bliss / then slap the smile
off my face". I'm a big boy now, I can look after myself. Garbage
collection? Who tells me when to delete something? I can specify that
myself, implicitly (smart pointers) or explicitly (delete). Removing the
option reduces the scope of my solutions. Of course, it also allows "delete
this".

It is clear that there are horses for courses -- GC is a problem that may
not be an issue in your soluion. I wouldn't be here, being an argumentative
prat, if I didn't, deep-down, recognise the need for and importance of
simpler methodologies and systems. Perhaps a nail /is/ just a nail,
afterall.

However, one must be careful not to judge a language by it's common use --
just because Ruby is interpreted doesnt mean that it is a toy, and just
because C++ is compiled doesnt mean that it cant be used to prototype.

> Now perhaps you are in a specialized industry.  But
> most of the rest of us don't actually get much of a
> chance for that God's eye view of the problem.

Although it would be flattering to think so, I cannot believe that a "Gods
eye view" is special to either game development or myself. It is exactly the
attitude that languages like Ruby make anything fundamentally 'easier' that
fires me up to write posts like those I made previously.

Ruby is Just Another Language. If it has value, that value is contained
within a set of new concepts and their interaction (which is in itself
expressible conceptually). I'd like to extract that information, and use it
in different contexts. I've already gained a lot of new information
(regarding Ruby and not) just by being involved in this (off-topic,
apologies) thread.

We must pay homage to Godel and recognise that there is no one single
solution or framework that is both completely general and completely
self-consistent.

I am interested in Ruby not because it makes things easier, or because it is
a sandbox, or because it is 'dynamic' or 'interpreted'. I am interested in
it because it is it's own world, and I must continuously learn from
different approaches and concepts, or stagnate.

Important question: What concepts are unique to Ruby?

I am not interested in sugar -- I want substance. Perhaps the substance is
the language as a whole, including the developmental process it encourages.
But surely there is more. Or not. That's what I came here to find out.
Arrogant? Sure. Stupid? No.

When I see people asking mundane questions (how to read a file into a
string, how to interface to GTK, etc), I wonder. Why bother? This isn't
solving problems, its just asking the same questions in a different way. The
problem exists irrespective of the solution. To quote Bradd Pitt in Fight
Club, "I'm starting to wonder if another woman is really what we need".

We aren't addressing problems, we are addressing the questions. Pardon the
French, but fuck the questions, solve problems. Translating a problem to
another space doesn't solve the problem, it simply renames it. Conversely,
Fermat's Last Theorem wasn't solved until the problem was placed in a new
and different space. If I sound confused it is because I am.

> Instead we have constantly changing specs, legacy
> code, and things adapted to do stuff they were never
> intended for.

Excepting legacy code, that is my world. Imagine designing
graphics/networking systems for modern games in the current PC market .
Imagine when your 'client' is a game designer that has only a passing
knowledge of programming, and even they don't (can't) know what they want.
An obvious (partial) solution is an interpreted scripting system. I've
written a few, with varying degrees of success (measured by practicality,
not just elegance). Hence my presence.

> Ruby is designed to be usable by mere mortals like us.

I would almost resent that, except for the fact that I am merely mortal as
well.

> Cheers,
> Ben

Christian.