Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re^5: Improving p5p: Perl is going to stay Perl

by hippo (Bishop)
on Jun 28, 2021 at 22:36 UTC ( [id://11134411] : note . print w/replies, xml ) Need Help??

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

Yes indeed - we call that smaller, cleaner language, "C". :-p

I just happened upon this quotation from ken the other day which nicely sums up his feelings about C++:

[C++] certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and itís just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether itís personal or corporate, selects a subset and these subsets are different. So itís not a good language to transport an algorithmóto say, "I wrote it; here, take it." Itís way too big, way too complex. And itís obviously built by a committee. Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said "no" to no one. He put every feature in that language that ever existed. It wasn't cleanly designedóit was just the union of everything that came along. And I think it suffered drastically from that.


Replies are listed 'Best First'.
Re^6: Improving p5p: Perl is going to stay Perl (Backwards Compatibility)
by eyepopslikeamosquito (Archbishop) on Jun 30, 2021 at 01:54 UTC

    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) }
    ... 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.

    See also:

Re^6: Improving p5p: Perl is going to stay Perl
by choroba (Cardinal) on Jun 30, 2021 at 10:37 UTC
    I attended Stroustrup's talk at Curry on Prague 2015. At the end, someone asked him what he would have done differently if he had been able to start the whole project again. Among other things, he replied he probably wouldn't have standardised the language under ISO to prevent feature requests from people not involved in the development.

    Off topic note: I also liked his answer to the question "Do you follow development of new languages? What has surprised you recently?" He said: "Yes, I follow a lot of new languages. In the last 15 years, nothing has really surprised me."

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]