From: Richard <RichardDummyMailbox58407@...>
Date: 2006-12-19T09:25:06+09:00
Subject: Re: does Ruby generate WINDOWS and dialog boxes?

Hi Michael,

Though I've bought and skimmed a few books on compiler design (because
I am a mathematician who likes that kind of stuff),  I don't know
enough to dispute any of the internals that you discuss here concerning
computer-language design.  I'll just respond with my perceptions born
out my experience mainly as an independent computer consultant in
business & gov't info systems.

> Point me to a single book that calls C++ "elegant" written by someone
> who, you know, designs languages.  C++ is a hack built on a hack.

Stroustrup said: My initial aim for C++ was a language where I could
write programs that were as elegant as Simula programs, yet as
efficient as C programs [Java Report, July 2000]:  Incidentally,  he
held a doctorate in Math, I believe.  And this may be a self-serving
statement;  besides,  he missed his goal in your eyes.

Herb Schildt (a prolific author on computer technology) in "STL
Programming From the Ground Up", 1999, wrote on p.5: "The combination
of Stroustrup's insight into OOP and Stepanov's vision for 'plug
compatible' software components yielded a powerful new software
paradigm."  Maybe not "elegant", but "powerful".  I'd say maybe its
just a semantic difference.

The authors of the Wikipedia article on "Template Metaprogramming"
extol C++ virtues in its ability to unroll recursive expressions, e.g.
transform a factorial definition to a number at compile time.  They
didn't say "elegant",  but I think they might agree if pressed on the
matter.

> Problem #1 with C++ (of several billion): it requires literally infinite
> lookahead to fully parse.  This is not something I would ever consider
> even remotely elegant.

No doubt every compiler of a general purpose programming language is
susceptible of failure for some well formed programs.  But I never had
a C++ compiler fail on anything I've written.  Maybe I just haven't
been working very hard :-)

> C was not great engineering.

My main reason for lauding C's engineering is the insight that creating
ever more powerful languages with compilers that translate to machine
code is a poor strategy, e.g. Fortran, then Cobol, then PL/1.  The
alternative K&R devised is a *small* language plus the creation of a
lot of tools to allow application programming at a higher level.  If
nothing else, this allowed economical porting of the whole thing hither
and yon.

> It was a high level assembler

so what?

> full of quirks based on its first implementation platform (PDP-11) --
> quirks that kill (sometimes literally) to this very day.

That flies in the face of the fact that that it's probably the widely
ported of any programming language ever.

> It is
> acceptable (barely) as a systems programming tool provided it is used
> under intensely-inspected environments.

What's wrong with that?  I'd expect anything built for use (directly or
indirectly) by a mass of people to be monitored for extreme quality
control.

>Its use in applications verges
> on the criminal culpability side of things.

Well,  I've certainly got war stories to testify to the problems of app
development with C.  But who does that anymore? C is very big for
programming in the embedded world.  The many organizations that take
that route can't all be run by idiots.

> The list of useful (and
> some necessary) features that C lacks for application programming
> includes ...

I concede that (though I don't know much about those details).  But
they can be handled at a higher level written in C, just as K&R
conceived it.  Case in point: the original C++ was built on C and
certainly has been widely adopted and no doubt address some of things
that are not in C natively.

> C++ is a hack layered on this hack.  Despite being designed for projects
> "in the large" it still has no support for automated memory management
> which, given its unnatural appetite for memory (in typical C++
> programming), is really funny.

Check out "Accelerated C++", Koenig & Moo, , 2000, pp. 182, 203, 223,
262;  "Effective STL", Scott Meyers, 2001, pp. 173-175

> Further, although an "object-oriented"
> language, things like iterators are an afterthought (and it shows!)
> added later on in the library interface instead of being a core part of
> the language.

So what?  Lots of stuff in most languages is added to languages as they
evolve.  IMHO, C++ is no different than Ruby in this respect.

> And it still sucks--despite the addition of namespaces,
> classes, etc.--at actually helping in modular programming.  You have to
> recompile, for example, if the implementation of a class you're using
> changes.  (I still shake my head at this.)  It's not enough just to
> relink to a new object file/library/whatever.  You have to recompile
> your source.  (This is, of course, again because of that filthy #include
> thing.)

Well,  I can't see why recompilation is an important issue.  I've
always treated recompilation time as coffee-break time.

> Then we have templates....  I'm not even going to begin that rant.

I loved their introduction.  I mentioned them above as a virtue.  If
you decry them in C++,  you've also got to carp about 'parameterized
types',  known as 'generics',  in Ada, Eiffel, Java, and C# (according
to Wikipedia's article on "Generic Programming").

> > Do you a good opinion of any of the high-level general-purpose
> > languages?  Any that you find elegant?

> ...Haskell and dead ones: Dylan, Modula-3

I just took a fast peek at Haskell.  I noticed Guards,  and that
brought back memories of trying to achieve provably correct programs.
As I recall,  there some proof that no system can be built to proved
the logical correctness of every program.  (Just a side note.)

But I've never heard of it.  I can't imagine any client allowing me do
develop an information system that neither of us ever heard of.  Have
you been able to use it inside any large organization?

> I would not call Ruby "elegant" but I will call it a joy to program in.

I'm with you on that!

> If it didn't have Perl's magic variables, et
> al. I'd be more inclined to call it elegant even.

Here, here!  I refuse to use any Perlisms.  I think there a Ruby Way
for all of them.

> I lack sufficient experience in Rails to call it elegant or not.  I

Rails is what won me over.  I think it's brilliant,  though I'm still
struggling to master a bunch of major issues in it and Ruby.

> There are some things which at first glance
> appear very impressive to me, but C++ templates did once too until I had
> to use them extensively.  (My first run-in with ">>" vs. "> >" pretty
> much ended my love affair with templates in a huge, bloody crash.)

Ouch!  Did you consider some abstraction that was a more palatable way
to employ templates.  Heck,  Stroustup's early compilers were "merely"
preprocessors to the C compiler.  I wonder if something like that would
have ameliorated the risky syntax.

> > Is it all just a matter of taste?
> Yes.  Bad taste and my taste.  ;)
Well,  you've got me there! :-)

Best wishes,
Richard