From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 0B40ABBC4 for ; Wed, 4 Mar 2009 21:02:21 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMGAIxtrknUnwckZmdsb2JhbACCHZJmDQsDBQkPBsMGhAgG X-IronPort-AV: E=Sophos;i="4.38,302,1233529200"; d="scan'208";a="23869789" Received: from relay.ptn-ipout02.plus.net ([212.159.7.36]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Mar 2009 21:02:20 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAIxtrknUnw4T/2dsb2JhbACCHdYqhAgG Received: from pih-relay06.plus.net ([212.159.14.19]) by relay.ptn-ipout02.plus.net with ESMTP; 04 Mar 2009 20:02:20 +0000 Received: from [87.112.234.120] (helo=leper.local) by pih-relay06.plus.net with esmtp (Exim) id 1LexIK-0005aE-1v for caml-list@yquem.inria.fr; Wed, 04 Mar 2009 20:02:20 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? Date: Wed, 4 Mar 2009 20:07:43 +0000 User-Agent: KMail/1.9.9 References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <87eixdz12l.fsf@aryx.cs.uiuc.edu> In-Reply-To: <87eixdz12l.fsf@aryx.cs.uiuc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903042007.43232.jon@ffconsultancy.com> X-Plusnet-Relay: 1250f2fb68f84b84893bf86849bca3e8 X-Spam: no; 0.00; stl:01 stl:01 stepanov:01 unboxing:01 parametric:01 polymorphism:01 iirc:01 stepanov:01 haskell:01 oleg's:01 haskell:01 ocaml:01 2009:98 buys:98 passion:98 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). 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