|We don't bite newbies here... much|
Re^6: Improving p5p: Perl is going to stay Perlby eyepopslikeamosquito (Bishop)
|on Jun 30, 2021 at 01:54 UTC||Need Help??|
Wow! Tell us what you really think Ken! ;) While I don't know the gory details of the personal history between Ken Thompson and Bjarne Stroustrup, it deeply saddens me to read such public vitriol between two legendary software engineers - and workmates for many years.
I've met Stroustrup and found him to be a very humble and nice person and have long admired the way he's carefully shepherded the evolution and modernization of C++ over many years, while striving to maintain backwards compatibility. His home page provides a lot of useful history and carefully thought out rationale behind C++ design decisions (see also Re: Why so much hate?). One especially relevant Stroustrup quote re backwards compatibility caught my eye given the root node (p5p post) and recent turmoil around Perl 7:
Another reason for the unpleasantly large size of modern language is the need for stability. I wrote C++ code 20 years ago that still runs today and I'm confident that it will still compile and run 20 years from now. People who build large infrastructure projects need such stability. However, to remain modern and to meet new challenges, a language must grow (either in language features or in foundation libraries), but if you remove anything, you break code. Thus, languages that are built with serious concern for their users (such as C++ and C) tend to accrete features over the decades, tend to become bloated. The alternative is beautiful languages for which you have to rewrite your code every five years.
I remember in Five Ways to Reverse a String of Words (C#, Perl 5, Perl 6, Ruby, Haskell) effortlessly whipping up a Perl one-liner:
... while my C version took considerably more than one line of code. :) As did my C++ version. Yet I think this little example perfectly illustrates why C - though an excellent portable systems programming language (e.g. in the Unix kernel) - proves too primitive when writing huge applications in complex domains, where you really need more powerful abstraction facilities. The other C (and C++) annoyance I've experienced for many years is having to use tools (e.g. static and dynamic code analysers) and careful code reviews to catch the inevitable security vulnerabilities (e.g. buffer overflows).
Update: From Green Vs Brown Programming Languages:
It's harder to read code than to write it -- Joel Spolsky