git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: John 'Z-Bo' Zabroski <johnzabroski@yahoo.com>
To: git@vger.kernel.org
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Date: Sat, 8 Sep 2007 00:56:54 +0000 (UTC)	[thread overview]
Message-ID: <loom.20070908T025508-792@post.gmane.org> (raw)
In-Reply-To: alpine.LFD.0.999.0709070203200.5626@evo.linux-foundation.org

Linus Torvalds <torvalds <at> linux-foundation.org> writes:

> 
> And if you want a fancier language, C++ is absolutely the worst one to 
> choose. If you want real high-level, pick one that has true high-level 
> features like garbage collection or a good system integration, rather than 
> something that lacks both the sparseness and straightforwardness of C, 
> *and* doesn't even have the high-level bindings to important concepts. 
> 
> IOW, C++ is in that inconvenient spot where it doesn't help make things 
> simple enough to be truly usable for prototyping or simple GUI 
> programming, and yet isn't the lean system programming language that C is 
> that actively encourags you to use simple and direct constructs.
> 
> 				Linus
> 

I want code that is Correct, Explicit, Fast, and in that order.

I'm 23 years old and learned C++ when I was 13.  Back then, my compiler didn't
even support "bleeding edge" C++ language features like namespaces.  I'm not a
C++ expert, and I don't have the ego to call myself a superb programmer.  The
largest program I've written is 10K SLOC in C.  Yet, I'd like to participate in
this discussion, if that is OKay =)

I do think I am capable of an honest critique of the downside of C++:

_Problems_ _With_ _C++_

 *size*
    On my bookshelf, most recent editions of the canonical C++ _books_:
        Accelerated C++: Practical Programming by Example (336 pages)
        The C++ Standard Template Library: A Tutorial and Reference (832 pages)
        Effective C++: 50 Specific Ways to Improve Your Programs and Design (288
pages)
        More Effective C++: 35 New Ways to Improve Your Programs and Designs
(336 pages)
        Exceptional C++: 47 Engineering Puzzles, Programming Problems, and
Solutions (240 pages)
        More Exceptional C++: 40 New Engineering Puzzles, Programming Problems,
and Solutions (304 pages) 
        The C++ Programming Language (1030 pages)
        Modern C++ Design: Generic Programming and Design Patterns Applied (352
pages)
        C++ Templates: The Complete Guide (552 pages)

    Altogether, that is 3918 pages.  K&R, the canonical C _book_, is 272 pages.
 Becoming a C++ language lawyer is much harder than becoming a C language
lawyer.  Language lawyers know "how not to hang oneself" while programming in
the language.  I don't know how many of these titles are translated to other
languages, however, I am sure the *effort* required to translate all of them is
significant.  Open source is more successful if there is a lingua franca for
programming, and that is C.  Now, it may move away from C over time, but it will
*never* be C++ because it's encyclopedic.

 *hidden complexity*
    (1) it's hard to say what code will compile down to.  viz., constructors can
be elided, but there is no fitness warranty; profiling your compiler to find out
whether it is elided is tedious and "searching for secrets" that should be
_explicit_
    (2) people don't understand static polymorphism and compile-time dispatch;
people are used to objects sending messages dynamically (run-time dispatch)
    (3) coercion
    (4) networks of objects are not explicitly laid out, hiding quadratically
complex patterns of communication between objects
    (5) data structure and data flow come before algorithms.  Sometimes, data
structure dictates data flow (ad-hoc networks of objects); sometimes, data flow
dictates data structure (one of life's most disagreeable tasks - waiting in line
- is characterized as FIFO).  This, I feel, is the most important point, because
the first rule of programming is to figure out what you want to say before you
figure out how to say it.  In C++, ad-hoc networks of objects with cyclic
message paths are all too easy to create [see (4)] which means _code_ _is_ _not_
_explicit_ and as a result _code_ _is_ _not_ _fast_.

 *transfer semantics on objects are not robust*
    this ties into (1) in hidden complexity
    the code author needs to specify a lot of boilerplate to achieve desired
transfer semantics on objects.  Similarly, the code audience, be it reviewer,
maintainer or merger, needs to read a lot of boilerplate to understand how
objects get moved around in memory.  Moreover, most of these concepts are
intuitively declarative in nature, such as a parent object/child object relation.

 *poor re-use of effort*
    "code re-use" is a misnomer; when programmers speak of code-reuse they mean
re-use of effort.  There is no benefit to polymorphism if effort cannot be
consolidated easily.

 *C++ Standard iffy*
    Some things just disappear quickly for *frantic* reasons (strstream was
removed for aesthetics), indicating not enough foresight into what is important.
 I do not want to pick a language where I have to worry about features in it's
"standard library" becoming deprecated mainly for aesthetics.  As Dijkstra
preached, programming is _not_ supposed to be a frantic exercise.

 *usually, better options*
    See C++??: A Critique of C++ and Programing and Language Trends in the 1990s
 by Ian Joyner http://web.mac.com/joynerian/iWeb/Ian%20Joyner/CPPCritique.pdf
(Somewhat outdated, but many of the points are intrinsic and will forever be
relevant).  You can add to the list of better options D 1.0.

  parent reply	other threads:[~2007-09-08  1:02 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-04 20:50 [RFC] Convert builin-mailinfo.c to use The Better String Library Lukas Sandström
2007-09-04 21:38 ` Alex Riesen
2007-09-04 23:01   ` Pierre Habouzit
2007-09-05 14:54 ` Kristian Høgsberg
2007-09-05 17:29   ` Matthieu Moy
2007-09-06  2:30     ` Miles Bader
2007-09-06  4:48     ` Dmitry Kakurin
2007-09-06  4:59       ` Shawn O. Pearce
2007-09-06  9:12         ` Andreas Ericsson
2007-09-06  9:35           ` Junio C Hamano
2007-09-06 10:21             ` Andreas Ericsson
2007-09-06  9:52           ` David Kastrup
2007-09-06  5:03       ` Miles Bader
2007-09-06 12:08         ` Johannes Schindelin
2007-09-06 17:50       ` Linus Torvalds
2007-09-07  0:21         ` Dmitry Kakurin
2007-09-07  0:38           ` Linus Torvalds
2007-09-07  1:08             ` Dmitry Kakurin
2007-09-07  1:27               ` Linus Torvalds
2007-09-07  3:09                 ` Dmitry Kakurin
2007-09-07  5:48                   ` David Symonds
2007-09-07  6:15                   ` Theodore Tso
2007-09-20 14:06                     ` Steven Burns
2007-09-20 14:56                       ` Andreas Ericsson
2007-09-07  6:31                   ` Andreas Ericsson
2007-09-07 22:17                     ` Dmitry Kakurin
2007-09-07 22:28                       ` David Kastrup
2007-09-08  0:37                         ` Dmitry Kakurin
2007-09-08  6:25                           ` David Kastrup
2007-09-09  0:29                       ` Andreas Ericsson
2007-09-07  6:52                   ` David Kastrup
2007-09-07 10:28                   ` Johannes Schindelin
2007-09-07 10:26                 ` Johannes Schindelin
2007-09-07  6:50               ` David Kastrup
2007-09-07  1:12             ` Linus Torvalds
2007-09-07  1:40               ` alan
2007-09-07  5:09               ` Walter Bright
2007-09-07  7:40                 ` David Kastrup
2007-09-07  8:15                   ` Walter Bright
2007-09-07  8:26                     ` David Kastrup
2007-09-07  9:14                       ` Walter Bright
2007-09-07  9:31                         ` David Kastrup
2007-09-07 20:22                           ` Walter Bright
2007-09-07 20:27                             ` David Kastrup
2007-09-07 23:16                               ` Walter Bright
2007-09-08 23:50                             ` Andreas Ericsson
2007-09-09  0:37                               ` Pierre Habouzit
2007-09-09  1:36                                 ` Andreas Ericsson
2007-09-07 11:36                   ` Wincent Colaiuta
2007-09-07  9:41                 ` Pierre Habouzit
2007-09-07 19:03                   ` Walter Bright
2007-09-07 19:31                     ` David Kastrup
2007-09-07 20:49                       ` Walter Bright
2007-09-07 19:41                     ` Pierre Habouzit
2007-09-07 19:51                       ` David Kastrup
2007-09-07 19:59                         ` Pierre Habouzit
2007-09-07 20:40                       ` Walter Bright
2007-09-07 20:56                         ` Pierre Habouzit
2007-09-07 22:54                           ` Walter Bright
2007-09-08  0:56               ` John 'Z-Bo' Zabroski [this message]
2007-09-08  6:36                 ` David Kastrup
2007-09-19 19:56               ` Steven Burns
2007-09-07  3:06           ` Wincent Colaiuta
2007-09-07  4:06             ` Paul Wankadia
2007-09-07  4:30               ` Nicolas Pitre
2007-09-07  9:19               ` Wincent Colaiuta
2007-09-07  6:25             ` Andreas Ericsson
2007-09-07 10:56               ` Johannes Schindelin
2007-09-07 11:54                 ` Andreas Ericsson
2007-09-07 12:33                   ` Wincent Colaiuta
2007-09-07 12:55                     ` Karl Hasselström
2007-09-07 13:58                     ` Andreas Ericsson
2007-09-07 14:13                       ` Wincent Colaiuta
2007-09-09  0:09                         ` Andreas Ericsson
2007-09-07 16:09                 ` David Kastrup
2007-09-07 11:30               ` Wincent Colaiuta
2007-09-07  8:36             ` Walter Bright
2007-09-07  9:41               ` Andreas Ericsson
2007-09-07 19:23                 ` Walter Bright
2007-09-07 19:40                   ` David Kastrup
2007-09-09  0:25                   ` Andreas Ericsson
2009-09-17 16:23                   ` Bernd Jendrissek
2007-09-07 11:52               ` Wincent Colaiuta
2007-09-07 19:25                 ` Walter Bright
2007-09-22 16:52               ` Steven Burns
2007-09-07  6:47           ` David Kastrup
2007-09-07  7:41             ` Andy Parkins
2007-09-07  8:08               ` David Kastrup
2007-09-07 10:21           ` Johannes Schindelin
2007-09-08  0:32             ` Dmitry Kakurin
2007-09-08  6:24               ` David Kastrup
2007-09-08 23:25               ` Alex Riesen
2007-09-24 13:41         ` figo
2007-09-24 13:57           ` David Kastrup
2007-09-25 19:19             ` Steven Burns
2007-09-25 19:55               ` David Kastrup
2012-05-22 18:30         ` Syed M Raihan
2010-06-10 19:12       ` Ian Molton
2010-06-11 12:23         ` Jakub Narebski
2010-06-11 13:33           ` Dario Rodriguez
2007-09-05 15:27 ` Kristian Høgsberg
2007-09-07 10:47 ` Lukas Sandström

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20070908T025508-792@post.gmane.org \
    --to=johnzabroski@yahoo.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).