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

"Christian" <[e-mail]> wrote:
>
>I've really backed myself into a corner here. Witness my Houdini act.

You acknowledge it.  Whenever I see anyone do that my
respect for them rises.  Perhaps because I try to be
the first to admit when I realize that I am wrong and
and I know how hard it is.  (I also point out that the
operative word is "try", not "succeed". :-)

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

I like Unix.  I agree completely with its philosophy of
giving people enough rope to hang themselves with.  But
I still don't like leaving that rope hanging in nooses
and thin strands of it sitting around in tripwires.

Where is the line?  Hard to say.  But C++ leaves a lot
more hanging around than Ruby.  (And if you need the
freedom, Ruby makes it easy to drop back to C.)

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

I am astonished.  You dislike Ruby because it does dynamic
type-checking where when something goes wrong you are
given a clear indication (OK, at run-time) of what it was,
but you don't want your freedom to have buffer overflows
eliminated?  Take a look at security alerts on CERT and
then tell me which is the more common cause of real (and
big) problems!

I submit that C++ offers type-safety.  And then offers
quite sophisticated generic programming techniques that in
the real world are mostly used to get around issues that a
dynamic avoids by putting off the type-check later.  As I
commented about Perl's tie operator, "Which is really a
band-aid for a self-inflicted wound."  (If you are
interested, the full post is at
http://pub13.ezboard.com/fiwetheytheoryandpracticeofprogramming.showMessage?topicID=286.topic)
And when you use these features of C++, what happens?  Why
the executable gets very bloated.  But just have the
facility to do it dynamically at runtime and for a little
overhead you get a much smaller process image...

Incidentally Ruby has some generic programming facilities.
Are they as advanced as C++?  No.  But take a look at
Ruby's modules and mix-ins anyways.

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

The only way I learn it seems is to form an opinion and
then be vocal about it in a forum where knowledgable
people are to be found.  My misunderstandings generate
responses that I then analyze and form opinions about
(modifying my original if need be).  Wash, rinse, and
repeat until I either decide I didn't really want to
know that or I become competent.

So I understand what you are saying...

*grin*

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

Agreed.  See some of the rants about whether or not Perl
is a "real language"...

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

Define easier.

I submit that easier depends on both the problem and the
person attempting to solve that problem.

I also submit that good programmers tend to outright get
their accounting wrong more often than overall designs.
Conversely when you make an accounting error it tends to
be harder to spot than code which did not fit in your
overall design.

Languages like Ruby are well-designed to support styles
of programming where you do less explicit accounting and
more of your work at the overall design.  Given the
profile I just gave above, this generally makes it
easier to produce a working program that does what you
want.

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

I firmly believe that a language may have true value
from just combining existing ideas in a nicer package.
That IMHO is what Ruby does.

Let me give a parallel and relevant example.

First we had Unix.  An operating system that embodied
the idea that it is good to have a large number of
simple tools which can interact easily through a
common medium (text delimited by returns).

A problem with Unix is that there is a lot of overhead
to starting processes.  Another is that the common
tools that you have tend to make basic and common
assumptions.  If you break them you get serious trouble.
For instance a lot of Unix boxes will have very serious
problems if you create a file in /tmp whose name is
something like "foo\n/etc/passwd".  Why?  Because every
so often a shell-script is fired from a cron with root
permissions that will try to clean up /tmp, will
assume wrongly, and will see the above as 2 filenames.
Oops.  (Example provided to me by Randal Schwartz.)

Next we have Perl.  A language designed to evolve by a
linguist who is an expert in making the best of
unexpected interactions.  (Probably not coincidentally,
Larry Wall is a 2-time finalist in the International
Obfuscated C Contest.)  Well he noticed that most of
what was good in what had evolved in Unix could be made
better by encapsulating them as functions within a
language which could interact directly with native
datatypes *without* process overhead or assumptions
about the nature of text.  And indeed the power of
scripting within Unix translated very well to Perl.

However as a system without a coherent initial design,
maintained by a person with a large tolerance for
keeping track of complex systems, Perl made some
butt-ugly compromises.  (Some of which I alluded to
in the link I gave above.)

So Matz came along and noticed that most of what made
Perl good could be encapsulated in a sane language
with some room for syntactic sugar by writing the
right class library.  Matz likes OO, so his idea of a
sane language is based on Smalltalk.  While he was
out borrowing he pulled some things from other places
(like Lisp).

So Ruby is a clean, extensible language with a
feature-set that has been proven by experience in two
highly successful systems to be very effective for
scripting problems.  There is no reason that if your
ideal of a sane language is C++ that you cannot write
a library just like Matz did that encapsulates the
functionality of Perl...

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

Trivia.  Goedel's theorem says nothing interesting
about people for the simple reason that we already
knew that people are inconsistent. :-)

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

I suspect that the biggest lesson which Ruby could
have for you is that there is a real advantage to
being able to program in a style where you can push
off accounting work to the language and concentrate
on your actual problem domain in small, managable
bytes.  (Sorry.:-)

>Important question: What concepts are unique to Ruby?

Languages which are radically different from Perl on
the inside can reduce Perl to a class library.  And
there is value in that feature-set.

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

A lesson from Perl.  There is true value in syntactic
sugar.  Don't knock it until you try it.

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

In any language, particularly ones which are easy to
pick up, the majority of questions you will see are from
beginners who are confused about basic mechanics.  Given
that different languages are largely used to solve the
same suite of problems, both problems and answers will
bear a remarkable similarity.  Do not mistake these
questions as signs of anything other than the fact that
Ruby is an easy language to get started with.

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

A digression if I may.  (Now that this thread got back
on topic for Ruby, I am pulling if off.  Heh.)  I really
think it will help reduce your confusion.  And it may
help some of the OO zealots understand your point of
view.

My background is not CS, it is math.  (I have been
programming for just over 3 years.  Yes, I am a quick
study.  Besides which, mathematicians are arrogant
gits.  Apparently much like game designers that way.:-)
In math there is a wall a mile-high between two
personality types, those who like algebra, and those
who like analysis.

I like analysis.

There is an area of algebra that is practically a litmus
test for the gap.  That area is category theory.  The
entire point of the subject is nothing more than finding
canonical constructions to turn problems in one problem
domain into problems in another.  Even though the actual
translation process is pretty much trivial, often things
which are very hard to solve in one domain are radically
easier or at least doable in another.

I am competent at category theory.  I understand why it
is useful.  But while I am doing it, it feels like
meaningless symbol manipulation.  I don't enjoy it.

When I came to programming I noticed this thing called
OO programming.  As soon as I figured out what it was
and saw people doing it, a little light went off in my
brain that said, "This reminds me of category theory."
Indeed EVERY single person I have found who knows both
math and CS well enough to know what category theory
and OO programming are either likes both or dislikes
both.

Unsurprisingly, I find that I am quite capable of doing
OO.  I understand exactly why it is useful.  But when
you begin talking about things like design patterns it
feels like meaningless symbol manipulation and I don't
enjoy the process very much.

FYI, Fermat's last theorem was solved by an algebraist.

FYFI, I suspect you would enjoy analysis far more than
algebra...

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

Welcome.

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

Heh. :-)

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com