Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Perl's Longevity

by lacertus (Monk)
on Apr 11, 2003 at 23:50 UTC ( #250001=perlmeditation: print w/ replies, xml ) Need Help??

Howdy Monks,
My meditation for the close of this week involves the longevity and "extensibility" (gratuitous buzz-word) of the Perl language. It is inspired by this lengthly - but insightful - piece by Paul Gram, found here(paulgraham.com).

In essence, he flirts with the idea of what programming languages might look like, and how they might act, in a hundred year's time. **Spoiler**: he comes to the interesting conclusion that it is possible to formulate and create a language that will be as relevant - and _useful_ - now as it will be in 2103.

Perl is a relative new comer to the field of computer languages. This being said, it is not "green" and has very much proven its worth in applications ranging from simple CGI mailers, to complex GUI Tk programs.

With the rapid approach of Perl6, I'm curious what the other monks think concerning how Perl's longevity will pan out. I'm a firm believer in Perl, and while it's primarily a hobby language for me at the moment, I can see it becoming even more mainstream with the advent of Perl6. I'm expecting a *long* healthy life for Perl, and that is why I dedicate time to development in it; it's also why I'm a PM!

Ciao for Now,
lacertus

------------------------------------
"There is more in heaven and earth
than is dreamt of in your philosophy"

Comment on Perl's Longevity
Re: Perl's Longevity
by MrYoya (Monk) on Apr 12, 2003 at 02:02 UTC
    I thought this was a great article. Thinking about Perl's own life and future I think that predicting the future is difficult but Perl will be around for a little (I'm gonna say at least 20 years) while for three reasons that I can think of:

    CPAN: Mr. Graham talks about code reuse as being the holy grail. If so, then CPAN is the castle where the grail is kept. Users of other languages such as OCaml and Lisp always talk about how they wish their language had something similar. They're jealous.

    Community: PM or crack -- which is more addictive?

    Natural language: According to my understanding of Perl, Mr. Wall designed Perl to be like a natural language. This is in sharp contrast to Lisp, which is rooted much more mathematically and is tough for a lot of people to think in. The upside to the natural language approach is that it meshes with a human's own system of thought and the language is easier to think in for most people. Plus you can create concise idiomatic expressions -- just look at the obfuscations.

    It would be interesting to see if programmers finally cracked the elusive goal of an english language programming language in 100 years; maybe we'd all use that or a subset.

    I agree with Mr. Graham that in the future the goal of programming languages will be to reduce programmer development time at the expense of processor power and memory. To this end, Perl is part of an evolutionary step.

Re: Perl's Longevity
by tachyon (Chancellor) on Apr 12, 2003 at 10:35 UTC

    As processor speeds continue to creep up and memory becomes even more abundant the need to be efficient in terms of cycles and memory decreases. As a result it will typically be more efficient to use a very high level languague like Perl to get stuff done. This is because IMHO you can get a given task done faster in Perl than say trying to do the same thing in.....ASM, C, C++, Java in roughly that order. So it will be more efficient/cheaper to do it in a VHLL.

    If you look at the Microsoft .NET framework you will see that they are abstracting like mad adding Intermediate Languague, Bytecode and JIT compilation layers into their language model - it makes Perl look positively like a thoroughbred race horse. But then I am a firm believer in the intel/M$ consiracy. M$ write more and more bloated software in slower and slower languages to justify people having to by faster and faster intel hardware.

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

      I don't understand your argument. Are you for or against "layering" and abstracting? The way I read Paul G.'s article, he is for layering. (See the paragraph beginning "Another way to burn up cycles is to have many layers of software between the application and the hardware..." and the subsequent four paragraphs.) In my experience, it has proven to be a useful technique.

      Now, if you are arguing that layering, done badly, is a problem, then I agree (also through experience) whole-heartedly.

      ...every application I have ever worked on is a glorified munger...

      As processor speeds continue to creep up and memory becomes even more abundant the need to be efficient in terms of cycles and memory decreases.
      That's a dangerous thing to think. While it is true, to some extent, you have to be very careful that you don't become less efficient faster than the machines become faster. Otherwise you end up with software whose newer versions run slower than the older versions, even with hardware upgrades.

      It's also a dangerous thing to think as you quickly end up with software that won't run on older, or even current, machines for no particularly good reason. (Burning time and memory to give you more time to play Warcraft is not a good reason)

      And, of course, thinking "my time is more valuable than any computer's" is incorrect for a not incosiderable number of programmers...

Re: Perl's Longevity
by jonadab (Parson) on Apr 17, 2003 at 17:56 UTC

    One thing you'll note about the article is that the author (not incorrectly IMHO) measures the long-term fitness or longevity of a language not in terms of how long programs continue to be used that were written in the language or even how long people continue to write new programs in the language but in terms of how much the language itself continues to be improved and how other languages borrow from it. In other words, the two largest branches are C and lisp, since almost every language (except extreme novelties like befunge) borrows extensively from one or the other of them. (Perl of course borrows from both somewhat.)

    In this respect, Perl 5's pattern matching is probably the thing that brings it closest to what the article calls the "core". Designers of other languages are positively wetting themselves in excitement over the prospect of having Perl-style regex support. CPAN, as someone else here pointed out, has that quality too. I wish my Linux distro had an install/upgrade process as convenient as CPAN.pm

    With Perl6, it's going to be the object model, and possibly also rules.


    for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc' .'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$ p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://250001]
Approved by diotalevi
Front-paged by diotalevi
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2014-10-25 13:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (143 votes), past polls