From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,897417b380f5731e X-Google-Attributes: gid103376,public From: Jon S Anthony Subject: Re: The Next Microsoft? Date: 2000/05/05 Message-ID: <391328F0.1221@synquiry.com>#1/1 X-Deja-AN: 619716885 Content-Transfer-Encoding: 7bit References: <8eg37k$15n$1@nnrp1.deja.com> <8epkoa$b8b$1@nnrp1.deja.com> <8eu0ob$7qv$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii X-Trace: client 957557067 38.151.18.1 (Fri, 05 May 2000 16:04:27 EDT) MIME-Version: 1.0 NNTP-Posting-Date: Fri, 05 May 2000 16:04:27 EDT Newsgroups: comp.lang.ada Date: 2000-05-05T00:00:00+00:00 List-Id: Hyman Rosen wrote: > > Mark Atwood writes: > > Early C++, you are right. But once the committee started on it, they > > could never say no to any seriously proposed feature, so now the language > > is too big for the human brain. > > What are these features that you are talking about? What features > are present in Standard C++ that were absent in Early C++? The only > thing that comes close that I can think of is the > internationalization of stream I/O, and it was absolutely necessary > to do this or there would have been no standard at all. A few that come to mind (we are talking "early C++", say pre '90): MI, Exceptions, Namespaces, and Templates. I don't think the problem is that it is too big. "Bigness" itself is no bad thing in an industrial strength programming language and, if properly executed, can even be a very good thing as it can make the _writing_ of sophisticated programs _simpler_. No, the major problems with C++ revolve more around feature interactions and poorly thought out binding time issues. And this most likely comes from starting with a very inappropriate substrate (good ol' C) for "accreting" new constructs over it and nevertheless going ahead and making all those accretions. > > True, the STL model is nice and can fit in one competent brain. Pity > > that it's realized in such a horrible language. > > The STL model is a direct result of the desire to write high-level > algorithms on fancy containers using the exact style that C > programmers use to process arrays, namely with pointer arithmetic. Stepenov's arguments for this have never made the least bit of sense. The whole of STL (imo) is wrongheaded from top to bottom and the template stuff in support shows an equal incompetence. /Jon -- Jon Anthony Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari