Re: [Caml-list] stl?

[Jon Harrop <jon@ffconsultancy.com>]

On Wednesday 04 March 2009 16:48:18 Yoann Padioleau wrote:
> I don't think so. I've read the last "history of C++" by Stroustrup
> in HOPL-III, who discusses quite a lot about the STL and Stepanov,
> and from what I remember unboxing was a big issue
> and having "generic" (which is slightly different from polymorphic)
> algorithms without introducing performance
> penalty that object-solution has with dynamic dispatch was also
> a big issue. Those people are not stupid.

If they were not stupid, why were their innovations were dropped, e.g. Java, 
C# and even VB.NET provide parametric polymorphism from ML (aka generics) 
instead of C++ templates?

> They know about ML.

IIRC Alex Stepanov claimed to know ML but then made a series of factually 
incorrect statements about it, e.g. "phantom types do not exist". His 
published work includes nothing on anything related to ML:

  http://www.stepanovpapers.com/

I do not believe they knew about ML.

> C++ even has some advanced dependent types in some way (array<n>).

I would not call it "advanced". C++'s type system was accidentally Turing 
complete in a very practically limited way.

Haskell is similar in this respect: check Oleg's 600-line GHC-extended Haskell 
equivalent of the OCaml code:

  `a

That's what the "power" of Turing completeness buys you.

> I hate C++ with a passion, but the C++ designers are far from stupid.

C++ is the pedagogical example of bad language design. I've learned about 20 
programming languages now and every one taught me something new. C++ taught 
me what happens when you let idiots loose on programming language design and 
get industry to hype the result regardless of its objective value.

I'm very happy to see C++ dying.

> > Scripting languages were not so hot at the time, short of Perl, but
> > Ruby would easily fit well into the STL idea, just like Lisp also did.
>
> No, because of the performance penalty of dispatch. Again, those C++
> designer guys have strong requirments on performance.

Their performance requirements were: destroy the performance of anything we 
are not familiar with in order to preserve the performance of familiar 
features regardless of the relative merits of the different approaches. That 
is really stupid and very counter productive, of course.

> Most of us can live with those overheads, but apparently they don't.

No, we don't just live with the overheads. We reap the benefits of objectively 
well-engineered features like fast exceptions and fast garbage collection 
that C++ is incapable of.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e