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

I've thought of Perl for a long time like the PL/I or Ada of the dynamic, getting things done languages. Useful, but huge. I forget the exact quote and I can't find it to get it perfect or to credit someone. I don't even remember which language it was originally about, but I'm thinking it was PL/I. It goes something like "It's a number of complete programming languages each struggling to get free".

  • Comment on Re^3: Improving p5p: Perl is going to stay Perl

Replies are listed 'Best First'.
Re^4: Improving p5p: Perl is going to stay Perl
by jdporter (Chancellor) on Jun 28, 2021 at 17:31 UTC

    That reminds me of this Bjarne Stroustrup quote:

    Within C++, there is a much smaller and cleaner language struggling to get out.

      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.


        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:

        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]

      I'm fairly sure the quote I was thinking of was a play on that quote.