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

I will start with the expression that I find your posts most interesting
Stephen. You have a lyrical style that I both envy and enjoy.

"Stephen White" <[e-mail]> wrote:

> Christian> I am not interested in sugar -- I want substance.

> Ruby is designed for the opposite end of the spectrum,
> trading speed for extra generality. As such, you may not get what you
> want from Ruby.

You misunderstand me. I am interested in Ruby as a scripting language for my
project. To clarify my position, I am leading a team that hopes to write the
next Big Thing in massively multiplayer online games
(www.microforte.com.au/bigworld).

Clearly, we need a good scripting language (I shan't define 'good' here). I
gave one up, but concensus was that we needed an existing, 'proven' language
(that wasn't 'weird'). Personally I am not convinced, but reality is
reality. I currently use stackless Python for both server- and client-side
scripting. It was the default choice. A collegue mentioned Ruby and here I
am.

> All I'll say is that I do find writing code in Ruby to be considerably
> quicker and the option of rewriting the slow Ruby bits in C solves the
> execution speed issue for me, but I have less stringent requirements.

From my previous paragraph, you will understand that speed is not my
concern. Allowing artists and designers to describe simple object behavior
is. I am more concerned with expressiveness and safety than speed. Speed is
relative in any case, and as you say can be special-cased where required.

> Combining different forms of infrastructure strengthens and limits
> the code. Merging the hammer and screwdriver might give me a hammer
> with a screwdriver head poking out the bottom of the handle. Works
> well in most cases, but now I can't fit the screwdriver in tight
> places because the handle is too thick, and I can't twist it very
> well because the hammer head gets in the way. I'm also in danger
> of stabbing myself with the screwdriver every time I hammer.

Laffs. I take your point. You can have it both ways, but when you do you
invite disaster. Another analogy is an extra-marital affair. Well, I am
quite enamored of Ruby (all evidence to the contrary). But I am very wary of
the implications of a choice of a scripting language for a game with a $6M
AU budget. Basically, I can't fuck it up. Python is 'safe' (inasmuch as the
suits know about it), but personally I think Python is broken. Ruby seems a
good alternative (hey, and wouldn't it be nice if Ruby can claim to be the
basis for a large-scale game?). Then again, Ruby is typeless (in my world at
least), and I fear letting a bunch of artists have at it without type. But
I'm a clever guy, and the Ruby source tree seems coherent.

> OOP with dynamic typing is more like writing template code. I no longer
> have to make sure that Food and Drink are derived from the same base
> class before I can issue the "consume" command. Objects can talk
> directly to each other.

This is a wonderful way of expressing what I felt when I learned about
generic programming. Before that, everything seemed obvious, but there was a
nagging sense of limitation -- arbitrary constraint. There is no fundamental
commonality between a Square and a Circle, even if they both have a draw()
method and are nominally Shapes. A Square is a Square and a Circle is a
Circle.

> This could result in little spiderwebs of
> tightly coupled objects, so I'll have to apply the Law of Demeter a
> little more rigorously, but the number of times I want to rearrange
> objects is greater than the number of times static typing would have
> saved me. Dynamic typing tells about my mistakes anyway.

Genericity and tightly coupled objects are conceptually diametrically
opposed. I am not familiar with the Law of Demeter [Googol: Demeter n :
(Greek mythology) goddess of fertility and protector of marriage -- so I can
see some relevance to 'tight coupling'].

The remainder of the paragraph is a little unclear to me. When you say
objects you mean classes, and you imply that static typing is bad for
conceptual manipulation. But I think I understand what you mean: although
you can get burnt by the lack of static typing, the flexibility is worth it.
True enough in some circumstances.

> When considering the question of compiler vs interpreter, I have to
> ask... why did you write those interpreters? Why do you find ANTLR so
> useful, rather than just using C++ everywhere? My guess would be that
> an external call to the C++ compiler wasn't feasible, so you had to use
> an embedded language. And while you're there, why not create a domain
> specific language to handle stuff that would be difficult in C++?

This is interesting, and telling. I've had a dream of a 'dynamic C++'. I
have reems of notes written over a number of years. This was/is to be My
Project. I wanted to have the benefits and beauty of STL within the
flexibility and dynamicy of an interpreted language system. Perhaps, never
the twain shall meet.

I had a lot of good ideas, and a lot of good ole' diligence, intelligence
and research behind me. To cut a long story short, I ended up designing a
number of languages that looked like a cross between C++ and ML, but with a
"hierarchical" heap, as opposed to a "rummage sale" heap. Oh, and they used
a distributed virtual machine.

The useful things I have taken from that work are that the virtual machine
for a language is of primary importance; the heap sucks; the stack is
largely unnecessary; both static and dynamic type is necessary; syntax is
largely irrelevant; and semantics are flexible within the context of the
same machine. My notes going back to 1996 describe .NET (can I sue Microsoft
for transgression of IP?).

The notion of type is dealt with best by something between the HP-48
calculator's language, C++, and ML. I still don't know what that thing is,
although it is "two weeks" away. In the meantime, bills need servicing and I
need a scripting language. Personally, I think that C++ is-a scripting
language. But the suits must be satisfied.

> (I'm guessing) Ruby was created for pretty much the same reasons. It's
> designed to be easily embedded in existing C programs as a scripting
> language extension. It can also be used as the infrastructure for a C
> program for a higher level view. It can be the glue between C modules,
> And, of course, it can be a stand alone interpreter. [snip]

But why C? C is old. C is UNIX, and UNIX is no longer relevant. A file is a
void *, and name.extension is evil
(../relative/or/qualified/names/are/good.though). Although Ruby adds
metaphor on top of C, it still uses the C virtual machine. This is a
limitation -- the C machine is single-process, single-machine, has a heap
and a stack and absolute globals, has no meta-data, is practically typeless,
and is largely scopeless.

Get the machine right and the language will follow.

> Another difference between a compiler and interpreter is the level of
> hardware simulation. A compiler generates code that is expressed in
> the language of the real CPU. An interpreter pretends to be a CPU
> tailored for the language.

Yes, this is a key point. The notion of a virtual machine is paramount. It
is also salient, given things like the Crusoe chip.

> Ruby's interpreter understands higher level language constructs like
> OOP, continuations, namespaces, and so on. To produce the equivalence
> of this in real CPU code, a lot of wrapper code would have to be
> inserted into the machine code. This wrapper code would do pretty
> much the same stuff as the interpreter does anyway, hence compiled
> versions of interpreted languages tend not to be much faster.

Have a look at MSIL. This is one single code stream that is produced by
'compilers' for various different languages that can be executed on one
single virtual machine.

[snip interesting guitar/piano analogy]

> As a practical example, programming problems are best addressed by
> domain specific designs. The problem comes in when I want to include
> libraries written by other programmers. In C, some libraries take care
> of their own objects. Others I have to free. Some return structures.
> Others take structure pointers and modify in-place.

Can we get past the C-thing, please.

> In C++, it gets worse. Some use operator overloading. Others take
> function calls. Some use homebrew functions, others use the STL.
> I'm going to have to remember this stuff while coding. "This data
> comes from libfrob.a so it needs to be passed to frobfree(), not
> to delete(), or the program crashes".

That is not C++ code (that uses namespaces and destructors and STL), it is C
code dressed up as C++ code.

> I haven't found a GUI toolset I like yet [...]

Nor have I, because they all use OO paradigms (i.e. broken, unscalable
paradigms), or are based on typeless switch statements, or a horrible
mixture of both. I agree with you about the button.push example. The trick
is how to match code with circumstance. Typically, this dispatching is
attempted using virtual functions, or at least delegation of responsibilty
through a chain of command. Neither is satisfying, which is why I am so
interested in coroutines and continuations. Consumer/Producer is solved well
with coroutines.

Semantically, goto rocks (if you are hungry, eat), and subroutines suck (I
don't always want to go back the way I came). The more things change...

> Ruby lets me forget [issues with libraries and usage conventions] and get
on with solving the problem. I'm
> willing to sacrifice other people's flexibility for a consistent model
> that I can use in my own programs. I want external libraries to be
> written with the same mindset as my code. I've got that now.

Ahh, that paragraph is so broken I don't know where to start, so obviously I
don't understand what you are trying to say here.

Again, nice post. I sent your motorbike/car post around the office. My
collegues nodded knowingly.

Christian.