Re^6: Improving p5p: Perl is going to stay Perl (Backwards Compatibility)

in reply to Re^5: Improving p5p: Perl is going to stay Perl
in thread Improving p5p: Perl is going to stay Perl

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:

sub reverseWords {  join ' ', reverse split(' ', shift)  }
[download]

... 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
... writing something new is cognitively less demanding (and more fun) than the hard work of understanding an existing codebase, at least initially ... if you build new things in Go but have to maintain a sprawling 20-year-old C++ codebase, can you rank them fairly? I think this is actually what the survey question is measuring: dreaded languages are likely to be used in existing brown-field projects. Loved languages are more often used in new green-field projects.