Slashdot Mirror
Perl's Glory Days Are Behind It, But It Isn't Going Anywhere
snydeq writes "Deep End's Paul Venezia waxes philosophical about Perl stagnancy in IT. 'A massive number of tools and projects still make the most out of the language. But it's hard to see Perl regaining its former glory without a dramatic turnaround in the near term. As more time goes by, Perl will likely continue to decline in popularity and cement its growing status as a somewhat arcane and archaic language, especially as compared to newer, more lithe options. Perhaps that's OK. Perl has been an instrumental part of the innovation and technological advancements of the last two decades, and it's served as a catalyst for a significant number of other languages that have contributed heavily to the programming world in general.'"
So let me get this straight: A programming language that found a niche, became massively popular, and is now widely used... is a failure in your eyes because it's not in a constant state of change?
You're kidding, right? The epitome of a successful programming language is that it has become flexible enough to meet the needs of its users without requiring more than maintenance fixes. This is like saying "grep is useless because nobody's completely redesigned in in the last few months!" Dude, stop drinking the Web 2.0 kool-aid. There are things in the computer world that aren't meant to change every day. I know it's hard to imagine when every pundit is screaming "release early, release often" from every rooftop, but speaking from experience... If you go mangling your programming language every few months like (cough, .NET) some companies do, you're going to find your developers bailing out like rats from a sinking ship.
#fuckbeta #iamslashdot #dicemustdie
Should also compare the frequency of remotely exploitable flaws in the "replacement" language/framework (e.g. php) versus that of perl.
When was the last actual exploitable perl flaw, anyway?
#DeleteChrome
The fact is that Python today is taking over where Perl would have dominated in the past. That is applications, front-end scripting and where integration of both would be beneficial. If it weren't for Python, I doubt legacy apps that are being migrated away from Perl would have had that path ahead of them. It's a much muddier road through Ruby (not criticism of the language itself, but things are too... different than Python).
If computers were people, I'd be a misanthrope.
"The fact is that Python today is taking over where Perl would have dominated in the past. "
And the reason for that is that python has equivalent functionality to perl (unless you really need to compose an entire program in 1 line of regexp and a loop), can also be used for quick-n-dirty tasks but is actually readable and structured and while its OO system isn't perfect its a damn site better than the nailed on dogs dinner that is Perls.
...Perl will just as dead as Fortran and COBOL.
My opinion? See above.
I decided to learn Perl since I got the impression it was the best scripting tool for a sysadmin dealing whit Windows and Linux environment.
So I have to ask, is Perl still the best tool for me (I love Perl) or should I move on to something else?
Love many, trust a few, do harm to none.
For a long time, Perl was one of the first things I installed on any new systems. I wrote tons of stuff in it, from sysadmin scripts to complete web sites.
But over the last 10 years I've moved totally to Python. Increasingly a lot of extensions to Perl felt like hacks. Whereas Python code is very clean by comparison. And consistent. TMTOWTDI sounds a great idea, but for code people depend on, consistency matters more.
while its OO system isn't perfect its a damn site better than the nailed on dogs dinner that is Perls.
It's not really object oriented until it can do true multiple inheritance. Otherwise, it's just like naugahide... it looks like leather, feels like leather, but it ain't leather and you probably overpaid. That said... yeah... Perl's attempt at OO makes Python look downright sexy.
#fuckbeta #iamslashdot #dicemustdie
With a bit of luck, awk will outlive perl.
But I (and others) can write structured, OO code in Perl (while having non-OO code where it makes more sense)
And since I'm allowed to lay it out logically, rather than the structure being part of the logic, it is far more readable.
Perl allows you to think, which is why I'll continue to use it.
Perl is a historically a combination of bash, awk and sed. And for purposes well suited where people would use the former three tools to implement shell scripts to help administration tasks on a daily basis. However, Perl is not so well suited for other purposes, like small and medium sized web applications. Therefore, it will not gain any more ground in that area, as better tools are available. The first Perl enemy was PHP. While PHP sucks in many ways, it was better designed to write simple dynamic web pages. Today it is used for medium sized web applications, which is clearly a dangerous thing, but still it restricts the growth of Perl in that direction, as younger coders came first in contact with PHP and all the hosters support PHP, but not everyone is supporting Perl. Also things like Joomla or Typo3 are PHP based and many people start coding by extending them.
For custom application or other mostly larger system Java-based or .NET-based technologies are used. Perl has nothing to do in that area. It lost its job there many years ago. InterShop was once coded in Perl, but - well - who cares?
As the Unix command shell is only a limited realm (in number of installations), Perl will never become that widespread again. At least that is my assumption considering today software base and structure, as well as the education in programming languages.
Whadayamean, "mis"read?
Oh, in the literal sense.
Then again, this is Paul Venezia, a hack columnist who forgot an "off" somewhere.
No. Just no.
I've noticed a strong industry bias against anything that actually works and gets results. If it isn't an inscrutable functional language or a top-heavy abstract framework, pundits and observers always put it down. Perl is a perennial punching bag because you can get results with it.
I agree 100%. Python sets a new standard in simplicity and readability. I don't think Perl 6 will be an improvement upon Python in this area. Python now absorbs all the new users. It even has a big traction in the CS education now (Perl never quite got there). Suffice to mention that big CS departments like MIT and Berkeley have started using Python in their intro to CS courses instead of Lisp. It's on clear to me why anyone other than Unix sysadmins should use Perl for new projects instead of Python. In fact, Python is probably just as fine as a sysadmin tool.
You know where Perl's nailed on OO system came from don't you? That's right, Perl's nailed on OO system was lifted from Python. Just without forcing upon the user a single shiny one true way syntax. Underneath the have the same guts. And on those same guts have been developed many OO systems, some of which put Python's to shame. And guess what, my old Perl code runs as well on the Perl of today as it did on the Perl of 15 years ago. How well is your 15 year old Python code doing today?
can write structured, OO code in Perl (while having non-OO code where it makes more sense)
... just like Python.
Perl allows you to think
... just like any language.
When confronted with one problem, some think "I'll use recursion". Now they are confronted with one problem.
On the one hand, with Perl, you can't even create and use a multi dimensional array without barely comprehensible hacks. On the other, the language itself leans too sharply towards gibberish instead of natural language. But it's powerful, and mostly (excepting a few outliers like multi-dim arrays) complete.
I speculate that the only reason that it's as popular as it is, is because people stick with what they know, especially if what they know is complex, functional, and esoteric doesn't hurt either -- it's rather like a form of job security. And a lot of people know Perl.
For myself, I learned Perl first, but was still interested in languages, and so continued with Python, PHP, Java, and so on. For a scripting language, I settled with Python, and feel that it is far superior to Perl in just about every way imaginable (and yeah, I'm a fan of the indentation, too, though I can see that if that's not similar to how you formatted your code in the first place, you'd not be likely to appreciate it. Me, I come from a C background where indentation far more formal than the K&R style was required.)
Anyway, if you're not a language bug, it may well be that one (or two) languages is quite enough. I don't expect long term Perl users to be looking to change, and that's why, I suspect, Perl is still so popular.
I've fallen off your lawn, and I can't get up.
while pythons OO system isn't perfect its a damn site better than the nailed on dogs dinner that is Perls.
Yes, the default OO system in Perl sucks, so take a look at this clean perl object interface called Moose: http://search.cpan.org/~doy/Moose-2.0604/lib/Moose.pm
use it properly and your perl code will be beautiful, usable and maintainable.
just usually not with perl...
I like Perl, I'm just not very good at its subtilties yet, but when I get there I'll probably be another fan like many are. Perl's glory days aren't behind it, it just takes a lot longer to appreciate what Perl offers.
My ism, it's full of beliefs.
...darn near anything in Python. :)
For those of you unwilling to click through, that's a custom auroral-photography / astro-photography condition reporting system. Even the graphics are generated by Python. It not only lets me look at current conditions, it texts me in case I'm not paying attention when conditions are right for auroral photography. Which leads to photos like these.
I've fallen off your lawn, and I can't get up.
Ruby and Python combined are doing less than Perl.
Whenever I write something new these days, I make a bee line to Python (outside of systems type of stuff). Python offers everything I could possibly want. If there's something missing, I just break out the 'C' compiler and design something.
I divorced Perl for a younger, thinner, prettier and smarter language.
Perl has gotten fat, old, and ugly.
When's the last time you used duct tape on a duck?
but I s/t?$/k?$/
My ism, it's full of beliefs.
Perl is still tremendously useful as system scripting language (one may prefer bash iif does not know Perl) and text processing. Perl was extended beyond its natural scope because in a certain time lapse, it was the only tool available to do quick prototyping and an aid to quickly deploy complex web applications (particularly). Maybe its true that it has come to the final developement phase. Other languages, more focused on specific purposes and without the limitations/quirks of Perl (TMTOWTDI - There's more than one way to do it - is a problem more that an advantage), have picked up its most useful characteristics, so Perl is no more so central in application development and it will go back to its original scope. If Perl will go extinct it would mean that other , better languages have took its place, but this is not a problem, it's normal evolution.
In 1994, I first found Perl. And it completely rocked my world. It ain't '94 any more, and Perl is the *same major version* it was in '95. Perl 6 is due "RSN," and currently holds the award for longest-running vaporware. Perl has completely lost its direction, Larry Wall hasn't been heard from in ages, and nobody cares. Perl's OOP is a joke, hastily retrofitted, to be done right in Perl 6.
Don't get me wrong. I *still* like Perl, and frequently use it. But unless someone injects life into it, yes, it's moribund, and on its way out. I don't say this because I don't like it, but, rather, because it's the simple truth.
PHP, honestly, suffers from many of the same problems -- but unlike Perl, has a direction, hasn't been forked into 73 different competing future versions, and is actively used for what it was made for: web. Python and Ruby rule the roost for new languages that fill in many (most?) of the things Perl 6 would have addressed.
Get me *one* Perl 6 with the Larry Seal of Approval(tm), and I will be willing to retract my words -- because they might no longer be true. But the way things look from where I'm standing, and it's got nowhere to go.
Really? Python after Ruby? Ruby is a couple years newer than Python, and Python has been popular for much longer than Ruby.
Perl is a very nice piece of engineering and a good programmer will instinctively love it for that. I am using it to to quickly build validation code for checking the output of a C++ data analysis program. Plus, I use it to instrument the C++ code for memory leak detection. Works much better than Purify, because the C++ program runs at nearly normal speed in memory leak detection.
I once interviewed with a small company who develop and sell an ERP system. They use C++ for the core stuff and allow customers to extend/modify the system using Perl. They said their system is much leaner than the competition in terms of hardware requirements.
Regarding the "unreadable" argument, that is 99% bullshit - it is up to the programmer to use the strict Perl modes and to use a proper coding style to create readable code. Just use explicit variables with proper names, for starters. Use a more verbose style and so on.
Perl is indeed a perl of the software engineering community and I will take it over resource-devouring monstrosities like Java any day. I bet it will be around in 2100, when the crapper languages like PHP and Ruby have faded away.
I wouldn't be so proud. Python's OO system is Perl's OO system.
In my view Perl's greatest success was its influence on other languages. Its pattern matching capabilities are a key part of Python, Ruby, and more and are even bolted on to Java. Perl may be on the very slow decline but the best bits are still increasingly in use
My exposure to Perl was inheriting the maintenance of a utility written in it after the original developer left the company I was at. That lasted a few years and also went through a few functional enhancement requests from the users until I too moved on; so I'd say I was reasonably adept with Perl.
However, despite it being quite handy for some things, I never felt the inclination to use Perl for something developed from scratch. Even something that would have aligned well with Perl's strengths. I just didn't like it.
By separating variables to a namespace new keywords could be introduced anytime. Just try this in a language without sigils. So, it's a cool feature guaranteeing compatibility of nowadays Perl scripts with Perl interpreters in 3012.
... except that it's not, despite several similar obituaries having been published.
With all due respect to "language companies" and all the script kiddies coming out of universities today, C and Perl are the stable tools. They will remain important for any work requiring stability.
Most "alternative" languages mentioned in this discussion have broken backwards compatibility at least once, have serious performance and other internal problems, and don't come close to the practical effectiveness of C and Perl.
Perl 6 is a new language. I have played with it and I think it is evolving with the right principles.
The next big challenge to serious programmers is concurrency. Functional programming is the only solution, but let's acknowledge that functional programming is nowhere near becoming the norm. It's very difficult to master, especially for OOP-damaged, pattern-deranged programmers and their IDEs of Desperation.
Having said all this, I'll add that tools will change. Fads come and go, but the tools that do the real work in the most efficient way are always at the top of a smart coder's tool box. Including a Fad Detector.
Rich And Stupid is not so bad as Working For Rich And Stupid.
Just as with COBOL and Fortran, with the language being less popular, it's more difficult to find people who really know the language, so that they can maintain and develop existing systems.
Most of the people with strong knowledge aren't looking for new work. Those who still know Perl 4 are around, as are inexperienced folks who can write C in Perl. (you know the type -- using
vs.
or delaring and initializing every damned variable on its own line. Or keeping 4 parallel arrays around, when an array of hashes or array of arrays would make the code easier to work with. Ie, not knowing the shortcuts & efficiencies of a given language).
Some of what's in the perl 5 planning have me genuinely excited (see Jesse Vincent's many talks on the future of perl) ... perl 6 is a good idea, but the focus on was like Netscape deciding to rewrite Navigator from the ground up ... so much momentum was lost. We'll be better off when it's finally done, but the energy might've been better spent elsewhere.
Build it, and they will come^Hplain.
A variable's type and variable sigils are not the same thing. The sigils help create context for the data operations that will occur. an @ tells the interpreter to prepare for list context, while $ tells the interpreter to prepare scalar context. Arguably one of the nicest contexts in Perl is the Hash (known as associative arrays in PHP, and sometimes called dictionaries in other lingos) context, which uses the sigil %.
When you mix contexts from variables, you actually perform operations, because in Perl no symbol is merely a decoration, they are operators--including sigils. This shorthandish sort of approach has enabled the Perl language to really master data manipulation. You can treat a hash like a list, using hash slices, or take scalar context of a list and Perl will return the list size.
Ironically, I find Perl to be one of the most consistent and deep languages available and in use these days.
The problem with Perl is that it is its own language and programmers are lazy and want to program in languages that force them to do a lot of unnecessary busy-work not because they like it, but because that's what they've been taught to do. Managers are even lazier, and everyone wants to be able to understand your code, even if they haven't actually taken the time to learn the language.
Learning Perl is a great way to improve your own coding approach, even if you don't use the language regularly, because it opens the mind to possibilities.
http://www.beanleafpress.com
It's not about OO or syntax.
Unlike Perl, Python simply has more up-to-date feature set. And better support for Windows.
For example. Literally everything uses Unicode/utf-8 now - but Perl still defaults to binary/ASCII for everything. And Python defaults to utf-8 for the text.
That's how it happens. 10-15 years ago, Perl was 100% useful out of the box. Now you have to pile up some options just to make it realize the default encoding of you environment. Inevitably, to spare the nonsense, one starts using the new tools - like Python - which are more in line with the current defaults.
All hope abandon ye who enter here.
Articles about Perl's demise aren't going anywhere either.
Sanity is the trademark of a weak mind. -- Mark Harrold
Telnet's Glory Days Are Behind It, But It Isn't Going Anywhere
FTP's Glory Days Are Behind It, But It Isn't Going Anywhere
Technology moves forward and life goes on. It does not mean something was the wrong tool at the time.
Sanity is the trademark of a weak mind. -- Mark Harrold
Simplicity and Readability?
You mean interpreting whitespace and a culture of know nothings that think only having one way to do a task is a good thing. A pox on your house.
I wrote this a while ago, but I find it's useful to post it here:
The precondition that you can write terrible code in any language is a mental diversion. You must design languages for people that believe in intelligent design.
If there is low hanging fruit in your garden of eden, people are going to assume that someone vastly smarter then they are placed it there for plucking.
Not even God himself coming down from on high and face to face telling every member of the human race not to touch it is going to keep it from being abused.
That is the true nature of humanity and by inclusion programmers.
perl: An unorganized, but sprawling garden full of almost every imaginable fruit. Regex is a shiny sinful apple at eye level on every single tree. The only way to navigate the garden is to ask the snakes.
python: An organized garden that has one of each kind of fruit. But it's half way through being dug up and replanted into an even more organized garden.
ruby: A newer garden. Heaps of fertilizer make everything grow incredibly fast, but the trees are getting tangled and there's a problem with weeds.
c#: Someone spent a lot of money crafting this garden correctly. They also planted trees that emit a hypnotic pollen that will murder you if you try to leave the garden.
java: A beautiful garden but only when viewed from space. Every tree has exactly 1 fruit, and getting anywhere takes forever. Recently taken over by someone interested in c#'s hypnotic pollen trees.
c++: An industrial farm complete with tractors and combine harvesters, but no safety equipment. As a bonus 98% of the farm does not contain buried land mines.
c: A plot of land and a barn full of seeds. Get to work.
javascript: There's only 1 tree and it grows upside down, but you can find it resurfacing in all the other gardens. It's also sentient, growing rapidly, and trying to murder you.
I agree, and in fact find its "decline" natural and healthy. Perl was the only option for many things for too long, and so it was used. It may not have been the best option, but it worked. Since then the world has developed better options for certain applications, like Ruby or Python. As a result Perl is no longer used for some classes of applications, but that's a good thing. It keeps the language from being pushed and morphed in bad ways to solve non-core problems. While in absolute terms Perl may have "shrunk", the result is a strong, vibrant core of things it's good at, and a developer community focused on those things.
I love reading all the comments from people who see perl written in the 1990s and believe that Modern Perl is the same.
I love how all the other popular scripting languages claim they invented X, when Perl had it years and decades prior.
I love how people claim that Perl isn't good to create a small website, when Dancer does this extremely well and easily.
I've created a CRUD website in 4 lines of easily understood Perl-Dancer code.
Modern Perl isn't the crap that everyone remembers. It is elegant, fast, pretty, and light on system resources. It lets you do complex things too and it lets you break rules if you need to.
Doesn't that stuff matter anymore?
I use the right tool for the job and very often Modern Perl is still the right tool, though I will use Ruby for toy websites and python when I pick up someone elses script.
If I'm creating a toy or extremely complex program, Perl is my tool of choice. It fits and it gets the job done. It also pays very well, if you are skilled.
A few years ago, I started trying to learn Ruby, but I quickly changed my mind because the project at large kept changing, and I didn't have time to follow it. Perl's stagnation has made it much easier to use as a resource in places where stability is key.
Why is Perl great? Very small foot-print, minimal resources for outstanding performance, and flexibility.
After abandoning Ruby (until they calm down), I started exploring Perl and C/C++ with much better results. In my experience, Perl can be very user-friendly, or it can be cryptic... just like most other languages.
:) Perl will be around for decades...just like Cobol.
I use Python (and C, C++, C#, Java, etc), but love Perl.
It allows me to be as eloquent or dilinquent as I want to be.
If I want to blast out a concept, nothing gets there faster than Perl.
Learning Idiomatic Perl requires a shift in the way one approaches programming. To do it well, it does require learning Perl from a Perl-perspective, and I think that's where most new programmers stumble. They want a C-based language that won't require them to change how they think about programming code--because they all code in C even when they're using Java, or Python.
C programmers can program Perl too, of course... (that's how I started). Perl allows that, but you'll never really touch its brilliance if you stick to that approach. A great way to get started learning it is to find a community like http://perlmonks.org/ and start reading and posting questions about how to approach problems with a Perl-brain, rather than a C(Python, Java, whatever)-brain.
I believe doing so will actually make you a better C(Python, Java, whatever) programmer as well...
http://www.beanleafpress.com
Right now, we're in a bubble of web trends. This will not last, because people are realizing that (a) web programming isn't rocket science and (b) most people need modifications of existing off-the-shelf blogs, CMSs, etc. and not much else.
The rare site that does require hardcore programming is more likely to use a language like Perl because it's more stable than the newer, trendier alternatives, and is more favorable to those with a classic CS education.
The trendy people want us to think that Perl is dying, but the converse is true: the trends are dying, and they're trying to improve their own position by denigrating otherwise great languages.
I read it as "glory hole days".
Weird how Perl has completely disappeared from the web hardly anyone uses it maybe for old slow rickety web sites no one uses anymore that are constantly down like Craigslist and whatnot
Funny I should read this article just before ssh'ing into a server to write a little clean-up script. Guess what I used? Perl.
It might be fading, there may be newer languages doing more magnificent things. But today Perl is all I needed to do what I needed to do, and that script will now run nightly until the server falls into the sun ... so goodbye and thanks for all the fish.
If this were Usenet, I'd killfile the lot of you.
That's fine, it means while your snake charmer is out sick someone else can come in and actually fix (rather than introduce new) bugs.
I've come in to real, live perl that glues together millions of dollars worth of data processing and it was not easy to understand and update. I didn't botch the changes I had to make, more thanks to good testing on my part than the quality and readability of the perl.
Good luck doing that when your perl wizard gets a pox on his house.
Slashdot Patriotism: We Support our Dupes!
It's not (just) about OO...
You're right...OO is not the end-all be-all of programming...it's also about proper closures and the ability to do functional programming almost as easily as LISP. I'm sticking w/Perl.
In a nutshell, I still use Perl heavily because I get paid to produce software - mostly embedded realtime telecom s/w but also a lot of tools as well. Pragmatism dictates that I use the tools with which I am proficient and which are universally available. Twenty years ago, I had to use Bourne shell more than I liked because I could only count on the availability of /bin/sh. Now, I have the luxury of being able to expect /bin/perl (version 5 no less). This counts for a lot in an environment where my hundreds of colleagues and I use hundreds of different servers with different operating systems, distributions, versions, and architectures.
Yes, there is a lot to complain about with Perl but at the end of the day, Perl is still an excellent tool for many many problems and won't disappear from industrial applications any time soon.
Actually, plenty of other languages have language-level RegEx literals and either match operators or string methods that match against them, and don't require separate "creation" and "test" statements to match a string against a regex. JavaScript and Ruby come immediately to mind.
And plenty that don't have regex literals as a language features can still do one-line define+test using their standard library (e.g., Python). So, no, it doesn't take more lines in other languages.
First Perl isn't declining in popularity, it just isn't growing. It is PERCEIVED to be declining but that has been the case for years. If anything I'm seeing more interest in Perl. I know I've seen more Perl related Slashdot stories in the past couple months than in the last few years.
I'm curious what exactly you would replace Perl with? PHP? Only if you wrongly thought Perl was about web stuff. Python? ewww.. that's disgusting!
Python can be either interpreted or compiled. As is the case with most languages. Interpreted/compiled is a feature of implementations, not languages, and even in implementations isn't really a bright-line distinction.
You can't transform from "an interpreted language" to "a compilation target", because whether or not a language is implemented via an interpreter is orthogonal to whether or not some other language is compiled to it.
This is not true except in the trivial sense in which it is true of every language, including JavaScript.
Google would probably be surprised to learn that Python can't handle that use case, which is the prime use case for AppEngine.
So, also, Python (JVM and CLR via Jython and IronPython), Ruby (JVM, CLR, and JavaScript via JRuby, IronRuby, Opal/HotRuby/Ruby2js), etc.?
yEah, bUt aLl tHose dAmn fUnny cHaracters rEak oF hUngarian sYntax, wHich i fInd eXtremely aNnoying tOo.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
"The fact is that Python today is taking over where Perl would have dominated in the past. "
And the reason for that is that python has equivalent functionality to perl (unless you really need to compose an entire program in 1 line of regexp and a loop), can also be used for quick-n-dirty tasks but is actually readable and structured and while its OO system isn't perfect its a damn site better than the nailed on dogs dinner that is Perls.
Python and Perl were both released in the late 80's. It is now 2013. As far back as I can remember from the mid 90's people were making these same arguments for Python being more readable and OOIsh. CS departments even then were pushing Python while ignoring perl.
Did something meaningful between Perl and Python change recently or are these essentially the same observations and arguments from 20 years ago?
So for approximately 10 years I did an IT job that involved 50% writing new perl to do ETL operations and 50% sorting out other peoples perl programs and fixing the bugs / extending the functionality.
What I learned was that it's possible to write perl that's ultra compact, very efficient and utterly utterly unreadable. On more than one occasion I was presented with perl programs that were so utterly incomprehensible that my only solution was to discard the whole damn thing and write it all over again.
Doing crap like constructing SQL statements by pushing and popping pieces of text onto $_, while possibly efficient, make modification nearly impossible and the code incomprehensible. You know you've written bad code when a year later when presented with the same piece of code you can't comprehend what it does.
I'm not even going to start my diatribe regarding perl's horrifying bolt on object model!
Five years ago I changed jobs and was nominally forced to use python. I was specifically told "You can write your tools in any language you like, as long as the output is python..." Initially I was skeptical but decided to dive in. Many of the ETL tools I'd written in the past I decided to rewrite in python so I'd have some perspective and it's night and day. The object model is cleaner, the syntax makes more sense (getting used to the indent syntax took getting used to, but you deal)
While I'm not entirely convinced that python is the answer to every answer, I'm pretty convinced at this point that perl is NOT the answer. At least to any question I've had to ask lately.
With that all said, to each their own. I've met and for a while was a person who could write really clean modular perl code. However for all the perl I ever saw in the wild, I was an anomaly.
Conversely, As I've dug deeper into my job I'm yet to discover a piece of python that wasn't immediately readable and without some study wasn't understandable.
I've even seen some of the code that the EVE online people have made publicly available and it's just readable.
Yes Francis, the world has gone crazy.
while pythons OO system isn't perfect its a damn site better than the nailed on dogs dinner that is Perls.
Yes, the default OO system in Perl sucks, so take a look at this clean perl object interface called Moose: http://search.cpan.org/~doy/Moose-2.0604/lib/Moose.pm
use it properly and your perl code will be beautiful, usable and maintainable.
Indeed, and if you still don't like the syntax then MooseX::Declare is there to save you.
So Smalltalk is not OOP, right?
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
What exactly is a "web programming language"? Something that can spit out HTML, I imagine. Perl does that with the best of them and, since it is a general-purpose language, it does it exceptionally well.
There's still an unfilled need for an OSS MS-Access-like product. O.O.Base still sucks (even more than Access).
Table-ized A.I.
If you really want to do massive math work in Perl, have a look at PDL. It started out in astronomy, but didn't stay there. Quite similar to IDL, I've been told.
Once a language is not perceived as "in", its growth flat-lines and then it slowly sinks on the popularity charts. It has happened to almost every "past" language* and will probably happen to the "in" languages like Ruby.
* Except perhaps Lisp. It's still a niche favorite because of its flexible syntax and constructs.
Table-ized A.I.
Have a look at http://moose.perl.org/ - it ain't your grandaddy's Perl.
Compare this simple Python class with the equivalent post-modern Perl
package OurClass;
use Moose;
has ‘arg1’ => (
is => ‘rw’
);
has ‘arg2’ => (
is => ‘rw’
);
sub printargs {
my $self = shift;
say $self->arg1;
say $self->arg2;
}
no Moose;
Official languages are:
- C/C++, considered one language
- Python
- JavaScript
- Go, or whatever the internally developed flavor of the month is
If you are going to try to target your skills, stick to the first three.
"I think this is in error. Perl is less maintainable than other languages, due to the myriad of "correct" was to implement solutions to various problems"
I know myriads of correct wa[y]s to implement solutions in any of the dozen languages I know. Are you saying you know only one?
(this complaint about Perl has never failed to puzzle me)
Here are the attributes of a language which are the most important in a commercial environment:
o Long term maintainability
o Ease of debugging
o Ability to replace one programmer with another when the first one is hit by a bus
o Ability to replace one programmer with another halfway through a project when the first's skills are strongly needed elsewhere
o Rapidity of development
Perl is only a win on the last one. This has its place in business:
o Creation of throw-away scripts which will be used once to bootstrap
o Creation of very small scripts for data crunching/analysis; small is eventually understandable
o Creation of prototypes for the purposes of obtaining initial funding (I'd argue Perl is not the best choice here, but it's viable)
The commonality of all these things is that they are effective when you need a "Mr. Right Now"; when you need a "Mr. Right", then they lose their value. In the interesting case, which is the last one (the other two cases can be handled in any language by any code monkey, and can be thrown away and rewritten id the current implementation is too dense), that's good enough for angel funding. But if you are going for first round funding, there are other things which the investors are going to value more, and that goes back to the first list:
o If six months in the main prima donna throws a hissy fit and leaves, will it be possible to continue?
o If six months in, we have to replace parts of the team because they are not product focussed, will it be possible to continue?
o If the plane crashes on the way to a trade show taking 3 people with it, will it be possible to continue?
o If it's necessary to liquidate the startups assets in order to recoup investment, will there be any value in them to others?
o If we need to scale rapidly without incurring huge hardware/rack rental/power expense, can we switch to a compiled language?
o If we need to bring in a lot of new coders to achieve scale, while they be able to communicate effectively?
For Perl code, the general answer to these questions is almost uniformly "no", unless you have an extraordinarily disciplined Perl programmer in the first place - in which case, you'd probably be using a more disciplined language. The answer to the last one, even if an extraordinarily disciplined programmer were able to answer "yes" to the other items, has to be a qualified "no", unless you have a readily available (read: not willing to pay above average market rate) talent pool from which to obtain more extraordinarily disciplines Perl programmers.
Perl programmers rarely work in teams; when they do, it's almost unheard of them to work in teams on the same code base -- instead, they interface between chunks of code using system interfaces, rather than perl interfaces.
It's OK to find joy in side effects, and it's OK to find joy in being able to go years without having to invoke system(3) using the same syntax/coding pattern, but in doing do, realize you are only finding joy for yourself, not your employer.
Like I said originally: as long as CPAN is healthy, it's a good canary for Perl; I don't think the language is going away. But I still disagree with the OP as to why the metrics indicate that it's falling into disuse: it has nothing to due with the rapidity of releases or the rapidity of churn in language features, and everything to do with other intrinsic factors which are not as controllable as those.
I don't think anything meaningful has changed. Sure both languages have been updated. Python 3 is an improvement over Python 2. New Perl modules let you access an improved object system and features backported from Perl 6. Still, Perl remains great for writing short powerful disposable scripts in short time. Python is more suitable for writing large applications. Python is used for teaching computer science because of its dead simple syntax rules so that instructors can concentrate on teaching algorithms and concepts instead of programming language idiosyncrasies.
When choosing a programming language, which inevitably requires a high level of commitment, serious developers and contributors take licensing freedom into consideration. Perl's artsy-fartsy license is not copyfree, and much of CPAN is downright GPL. This gave perl's competitors a definite advantage (especially after Ruby switched to BSD). Why marry a language that comes bundled with legal threats, that you can't embed into your app, and that will require hours of legal study to figure out what else you cannot do?
FreeBSD was right to boot perl out of their base system, and I'm looking forward to when other UNIXen will do the same.
--libman
It's not really object oriented until it can do true multiple inheritance
... and with that, Java weenies all over the world are crying into their milk.
+1
Not everything that can be measured matters; Not everything that matters can be measured.
That's true: PHP's preg_replace just requires ugly escapes of the regexp metacharacters, and requires the human to do the hard parse. This also means that IDEs only see a bare string, so no coloring of the regexps. I don't see how this is an improvment.