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

Hi Ben,

"Ben Tilly" <[e-mail]> wrote:

> 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 [-ally typed system] avoids by putting off the type-check later.

Saying that everything is an object says nothing. Saying that you can have a
'generic container' because you can make a list that stores Object
references is just plain stupid. You are just passing around pair<void *,
type>.

Consider Java's 'generic' container system. They are horrible. You can add
*anything* to such containers (except built-in types!). Then, to be sure,
you *must* test the type of each object in the container as you traverse it.
That makes ugly, slow code. Sure, it is 'dynamically type safe'. But it is
ugly, slow code.

To clarify, I am arguing against the position that templates are simply a
means to 'get around' the lack of 'dynamic typing'. OTOH templates (more
accurately, static typing) remove the need for having to manually test type
at runtime, so in that sense it is true.

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

A most excellent post, thanks for the reference.

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

Not true. Sure, templates allow you to stamp out huge masses of code
needlessly (the most evil thing you can do is store pointers in containers).
But no-one can stop you from stubbing your toe, and in any case you
shouldn't blame the rock that you kicked. C++ now has RTTI, so you can do it
at runtime when you can't do it at compile time. I am growing weary of
defending/propounding C++.

Slightly off-topic (hey, it hasn't stopped me before): why can we not have
an interpreted language that is based on C++, not C? Python is C, Ruby is C,
Perl is C. What about a language that is built using C++ and C++ principals,
where we can extend and enhance in C++? Is there one?

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

I've added this to a list of things to investigate in Ruby (including
Method, Continuation, instance methods, the limits of code blocks,
etcetera). I have a full-page document that lists all the things I want to
know about Ruby, all gleaned from this thread. Indirectly attacking a
language or its premise really has been the best way to get to the bones of
the language.

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

Hehe, yes that is effectively what I have done, consciously or not. To drop
to a personal level momentarily, I find that my collegues are intelligent
but not very interested in talking about deeper issues. So I jumped in feet
first, and have enjoyed the refreshing water immensely.

I try not to have super-fixed opinions. It is just an opinion after all.
That said, one shouldn't be wishy-washy.

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

What I meant was that it is a trap to think that any language is a silver
bullet. I have previously claimed that there is not much need for anything
other than C++ (given Managed C++). Of course, I was being facetious (the /.
term is troll).

However I did and do feel that worrying too much about language is
pointless, all that matters is solving problems. The trick is that the
language you use assists or hinders you in solving problems. Arabs have over
20 words describing sand, but they probably dont have many describing snow.
I want a language system that both Eskimos and Arabs can use efficiently.

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

True enough.

> I also submit that good programmers tend to outright get
> their accounting wrong more often than overall designs.

Absolutely not true :). Spelling is easy, composition is difficult and
requires maturity, experience, tools and intelligence. There are many 'good'
programmers that implement bad designs really well.

> Conversely when you make an accounting error it tends to
> be harder to spot than code which did not fit in your
> overall design.

I had trouble understanding this. Are you saying that off-by-one errors are
harder to identify than superfluous systems? The search spaces are
unrelated.

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

True enough. But in my experience permissive languages like Ruby are,
paradoxically, better suited for experts than novices, although this is not
an obvious point. You need to understand type before you can ignore it. Some
of the most excellent programmers I know are Python hacks. They can write 20
lines of code that are so deep it takes me days to understand it.

> Given the
> profile I just gave above, this generally makes it
> easier to produce a working program that does what you
> want.

Trivially true. And good enough for many circumstances. But it is just like
rock cocaine. It is good at first, you get a high and instant gratification.
In the long term, you are fubar. Comapre to meditation, where it takes more
time to get the same sense of elation, but it is healthy and you can get it
at any time -- it is part of you, not external. This is a bad analogy, but
hopefully my point is not too obscure.

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

I anticipated this, and matz's analogy of a chef, ingredients and balance is
well taken. However it is not very interesting. Topologically, relative
proportions of things are irrelevant.

> 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 nice summation. Are you familiar with Plan9? That was very influential to
me.

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

Again, this is quite insightful. Unix pretends to be general and flexible,
but in reality it is fixed and brittle. Linux is the worst thing to happen
to computing since Java.

[snip insightful comments regaring Perl and UNIX]

[snip good synopsis of Ruby's relationship to Perl]

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

Not a good sell :). Accounting (spelling) is trivial. I am not concerned
about that -- spell once, use many times. I am scared that there are
concepts (compositional techniques) out there that I do not possess that
would make my life easier.

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

There must be more to Ruby than just a nice wrapper for Perl. What about
coroutines, meta-programming, genericity, interface and scope?

> >I am not interested in sugar -- I want substance. Perhaps the substance
is
> >the language as a whole, including the developmental process it
encourages.
>
> A lesson from Perl.  There is true value in syntactic
> sugar.  Don't knock it until you try it.

I take the point, although I am not convinced. += is nice, but it doesn't
affect my design. In fact, it can add complexity where none previously
existed (if I overload + I also must overload +=).

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

This is a little contradictory, and serves to illustrate my point.

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

I don't. I'm just wondering why we need to start at all. Of course, I am
exagerating to make a point. Translation != Solution. I am also aware that
if we have any chances of a GUT we need higher dimensions and the ability to
translate from lower dimensions to higher dimensions, a set of rules to
apply in those higher dimensions, then a translation back to our world
before they can be practical. What are these higher-dimensional laws that
languages like Ruby supply? Perhaps then I could distill those laws and
apply them to my current context without needing to make the drastic step of
learning and practically using another language. Occams Razor is very sharp.

> A digression if I may.

I am very grateful that you do.

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

Nods. This is a notion that is clearly very important to me at the moment. I
simultaneously recognise the efficacy of restating a problem in a different
domain, as well as being derisive of simply re-labelling. Your text is very
interesting to me.

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

I get frustrated that I can't just sit down and write something that
directly solves my current problem. Instead, I have to rephrase the problem
in terms of what is understood by the tools I use. The level of enjoyment is
directly proportional to the pain levels associated with the translation
from real-world problem to computer-problem. I want to make that transition
as painless as possible. Which is why a general language like C++ is the
best I can offer. I also take onboard the wonderful analogy of motor bikes
and cars that Steven White [ruby-talk:9375] offered earler.

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

It all comes down to group theory, right? At least, please correct me,
category theory concerns itself with the translation from one ring to
another. Another way of putting it, ignorantly, is to be concerned with the
translation from wood to marble, or the notion of a phase transition.

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

I am on shaky ground until you clarify my understanding of category theory.
But it all smacks of labels: a river is something other than the word
'river': it is wet, it flows, it has fish and it looks pretty in the
morning.

To say that I have reservations about OO is an understatement. I've seen
(and built) too many rigid, awkward, inappropriate, and limiting class
hierarchies to think otherwise. The notion of a virtual method is required
but is very very much overused. Has-a is stronger than is-a.

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

A man after my own heart :). Patterns are for ignorant prats that can't
think for themselves and need some artificial formalism in order to supply
some borrowed sense of rigor and methodology.

Patterns are funny.

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

For some perspective, my formal training was at RMIT, a dual-degree course
in electronics and computer science. It wasn't until I saw Virtua Fighter
that I decided on the 'soft' science of software vs. hardware. But I am very
grateful for my understanding of math pertaining to electronics and signals
and systems, especially Fourier analysis and circuit analysis (notably
transfer functions and discrete filtering). I found CS trivially simple, and
electronics very hard but equally (or even more) rewarding. So you are
right, altough I retain immense respect for hardcore algebra.

> Welcome.

Thank you.

> Cheers,
> Ben

Christian.