From: John 'Z-Bo' Zabroski <email@example.com> To: firstname.lastname@example.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.20070908T025508email@example.com> (raw) In-Reply-To: <alpine.LFD.firstname.lastname@example.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.
next prev 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 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.20070908T025508email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.' \ /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
Code repositories for project(s) associated with this 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).