Perl 5.14 Released 187
chromatic writes "Pumpking Jesse Vincent has just released Perl 5.14, the latest stable version of the venerable Perl 5 programming language. The list of changes in Perl 5.14 includes several enhancements, including performance tuning, Unicode improvements, and updates to the core libraries and documentation. Perl 5.16 is on track for a release next April."
The question nobody wants to ask.... (Score:4, Funny)
.... does it have any new operator? :-P
And before you tell, it was just a joke, I know you should now add operators in a minor release.
Re:The question nobody wants to ask.... (Score:4, Interesting)
In a string context (in Perl, it would have to be something besides ===, but we'll get to that later), it would be "visually equal to" - any characters that are visually equal would be considered equal (useful mainly when using Unicode). So the Cyrillic "e" (0435) would be considered equal to Roman "e" (0065). I'm not sure how to handle complexities like "is the single character 'small a with macron' equal to the sequence 'small a' and 'combining diacritic macron'". We'll need a committee for that, probably. And since Perl uses different operators to determine context, we'd need something else for that. "veq", maybe?
This would, ideally, not just be a Perl construct. I can think of a lot of higher-level languages that could use that. Python. Ruby. Lua. Stuff like that. Lower-level languages probably would be better off without it - C does not need such an operator.
Just something I've always felt could be useful to have. Sure, there's probably some library that can do those things, but it would be nice to make things simpler.
Re: (Score:3)
Re: (Score:3)
Er, no it wouldn't because Perl is neither Javascript or Python.
Re: (Score:3)
Re: (Score:2)
What about ~ ellipsis =, eg: (1.01 ~0.1= 1.00) == True?
Re: (Score:2)
oops, epsilon not ellipsis.
Re: (Score:2)
bite_me() if abs($x-$y)> $epsilon;
$t =~ tr/e/e/;
eat_me_raw() if $t eq $s;
Re:The question nobody wants to ask.... (Score:4, Interesting)
I somewhat agree, however the floating point implementations SUCK at powers of ten -- you should specify epsilon in terms of powers of two. Hell, even my correct decimal text to float/double parsing function is 8 times more complex than the same in hex Why, even C has a hex float/double literal that goes something like this:
/[+-]?0x[0-9a-f]+\.?[0-9a-f]*p?[+-]?[0-9a-f]*/i )
The "p" in there stands for "times Nth power of two" similar to the "e" in decimal floats meaning "times Nth power of ten". eg: 0x123p-8 == 0x1.23
Note, hex decimal places act like decimal's do eg:
0x1.23 == (dec) 1 + 35 / 256 == 1.13671875 or (hex) 0x1 + 0x23 / 0x100 == 0x1.23
Specifying floats in the language of the computer's math (binary representable fractions) allows you to actually use equality properly ;-)
Some of my languages have the === operator already, similar to JS's exact match, perhaps ~=~ or =~= or "approx" would be better?
I've thought of adding an "approximate" operator -- esp. for physics simulation & game DSLs.
Although, what's wrong with specifying your required precision? Define your own epsilon (error factor).
print "$a is approx $b\n" if ( $a > ($b - $epsilon) && $a < ($b + $epsilon) );
# Compared to:
print "$a is approx $b\n" if ( $a approx $b );
# Oh, great, now we need another obscure magic special variable to contain epsilon...
# Perhaps $ë would do? Our English users won't mind using character map...
Re: (Score:2)
You can already do that in the language. More to the point, why 10 times? That's a bit decimalist isn't it? Shouldn't that be configurable, and if so, surely you would do so via a function. So now we have a function controlling the behaviour of an operator.. yuck! As for unic
Re: (Score:2)
if ( isApproximatelyEqual(10.356, 10.356) ) { }
if ( isVisuallyEqual('a', 'a') ) { }
Wow that was easy. Do you have any other brilliant ideas for new operators?
Re: (Score:2)
Re: (Score:2, Interesting)
it means you probably shouldn't be writing software that uses floating point.
Since I'm not a scientist or graphics programmer Floats are as damned useless and destructive as needing pointers to do string manipulations in C.
BCD should be the default data type for decimal arithmetic.
Re: (Score:2)
Ignorance would be simply testing for equality and wondering why your code sometimes doesn't work. Clearly he's aware of the issue, or he wouldn't have raised it.
I don't like his idea of having a fixed limit, but why couldn't it be done with a te
Re: (Score:2)
why couldn't it be done with a ternary operator?
It could but imo that wouldn't be all that much of an improvement over writing abs(a-b) tolerance (especially if your language makes abs an operator rather than a function).
Re:The question nobody wants to ask.... (Score:4, Insightful)
The big problem with an approximately equals for floats operator is that it provides no way for the user to specify the acceptable margin of error. So the language designer has to guess a value that they thing is "big enough" to avoid (possibly heavily compounded) rounding errors while not being so big as to cause unwanted matches. IMO that kind of judgement call should be something consciously made by the programmer (and they should be having the releated thought of "should I really be using a floating point type here at all" not something hardcoded into the language.
Similarly for strings "approximately equals" sounds like a nice idea but it's very hard to define in a robust way. Again probablly not something that should be in the core of a langauge but something provided by a library that can give options on what exactly constitutes approximately equals.
Finally using === to signify approximately equals seems like a bad idea given that many dynamic languages are using it for something closer to "exactly equals".
Re: (Score:2)
Re: (Score:2)
I assume eps is the threshold difference. That's "red cunt hair" in which language?
Re: (Score:3)
This is version 14 of Perl 5. It is a major release. (Perl 6 is [rakudo.org] a new language)
Re: (Score:2)
.... does it have any new operator? :-P
Of course. Not every possible key combination has been used yet.
With previous versions of perl, a cat could walk over the keyboard and accidentally create valid perl code.
Now a cat walking over the keyboard will for sure create valid perl code.
Re:The question nobody wants to ask.... (Score:4, Informative)
BEFOREHAND: close door, each window & exit; wait until time.
open spellbook, study, read (scan, select, tell us);
write it, print the hex while each watches,
reverse its length, write again;
kill spiders, pop them, chop, split, kill them.
unlink arms, shift, wait & listen (listening, wait),
sort the flock (then, warn the "goats" & kill the "sheep");
kill them, dump qualms, shift moralities,
values aside, each one;
die sheep! die to reverse the system
you accept (reject, respect);
next step,
kill the next sacrifice, each sacrifice,
wait, redo ritual until "all the spirits are pleased";
do it ("as they say").
do it(*everyone***must***participate***in***forbidden**s*e*x*).
return last victim; package body;
exit crypt (time, times & "half a time") & close it,
select (quickly) & warn your next victim;
AFTERWORDS: tell nobody.
wait, wait until time;
wait until next year, next decade;
sleep, sleep, die yourself,
die at last
That's actually valid Perl (only Perl 3, though - it breaks in later versions). And yes, I'm aware most of you have already seen it.
Perl is alive! (Score:2)
Perl is alive!
Last time I checked Slashdot still runs on perl...
My company does too.
Now that ActiveState is providing Perl for Cloudfoundry, it's going to be good times in Perl land.
Re: (Score:3, Insightful)
Re: (Score:2)
What does UI have have to do with the backend implementation? The UI goes in a bunch of template files, which could theoretically be language agnostic.
Any task (with regards to web apps) a modern language can do, Perl can do (and visa versa). One may be easier than the other for certain things, but Perl isn't a choice. Maybe not the best choice, but certainly far from unusable.
Re: (Score:2)
I do much coding as part of my job, haven't seen anyone choosing Perl for project in last decade, and my clients are huge municipal, state, and county IT operations with budget from millions to over a billion dollars. Perl is dying, it is undead.
Re: (Score:2)
I'm sitting here writing a Perl 5 application right now. In fact, it's comprised of several daemons that work cooperatively to handle various tasks, all written in Perl. The user side is delivered via a pool of FastCGI daemons (served by nginx, fwiw), written in Perl. My "day job" employer uses Perl. I've got friends working as programmers in the public sector in a variety of areas of state and federal government and education, and they write Perl code frequently. I've got other friends in the financial ser
For me Perl is alive and well. (Score:4, Informative)
Re:For me Perl is alive and well. (Score:4, Interesting)
I agree completely. As a UNIX sysadmin I frequently write scripts. For short and simple things, shell is preferred. But if I anticipate any complexity, I reach for Perl. I've had the experience of getting deeply into a shell script and thinking "I should have used Perl". Perl has never let me down, although I confess at times the programs have that write-only, line-noise appearance. But that's just because I've learned to use the idioms, and I comment on the complex stuff for the benefit of those who follow me--which could include myself six months later.
I'd write Ruby if I could. The syntax is cleaner, and objects are built-in, not bolted on. But Ruby is just not available where I need it. Does anybody know of an AIX LPP package for Ruby?
Also, I've been deeply disappointed at the progress of Perl 6--but Perl 5 does everything I need, so I really don't miss it. Of all sad words of tongue or pen, the saddest are these--it might have been.
Re: (Score:2)
I agree. I can always find Perl installed (most of the *nixes come with this by default due to dependencies), but python is less frequently installed, and ruby is almost never installed. Perl works fine for those hack-type scripts, so I don't see a pressing need to go start installing ruby or python everywhere. If ease of use is the deciding factor for choosing the language, then Perl is certainly the easiest to deploy of the full fledged scripting languages.
I see dead languages (Score:2)
I see dead languages, languishing in the default installs of OS mostly as wrappers for menial tasks, taking command line arguments and making output in some cron and admin jobs, and they don't even know that they're dead! 8o
A more readable changelog (Score:5, Informative)
A more readable changelog, with formatting, hyperlinks etc applied (rather than a raw pod file) can be seen here [cpan.org]
It Lives! (Score:3)
Internet Yiddish LIVES!
Syntax improvements are a huge step forward (Score:2)
There are some really good changes going into 5.14. Worth highlighting for anyone with Perl experience.
The Array/Hash reference mess has been greatly improved. You can now perform [cpan.org] most builtin operations directly on array references. So no need to mess around with dereferencing things all over the place. This is a huge improvement in the syntax surrounding complex data structures.
The eval exception handling mess has been cleaned up so that error handling modules such as autodie [cpan.org] can function properly
Re:What about Perl 6? (Score:5, Funny)
I was just going to say that back in about 2001 someone gave me advice not to learn Perl 5 because a Perl 6 release was imminent.
Re:What about Perl 6? (Score:5, Insightful)
"I was just going to say that back in about 2001 someone gave me advice not to learn Perl 5 because a Perl 6 release was imminent."
It's a shame that this 'Osborne effect' has hung over Perl for the last decade. I wonder how Perl 5 would now be perceived if Perl 6 had been given a different name and announced as a research project into language development, rather than the next version of Perl? With better PR, Perl 5.10 could easily have been 'Perl 6'.
All this tends to obscure the quet evolution of Perl 5 programming into what 'chromatic' and others are calling 'Modern Perl', using an idiomatic style that takes full advantage of recent language features (some borrowed from Perl 6) and CPAN to write efficient and maintainable code:
http://www.modernperlbooks.com/ [modernperlbooks.com]
http://onyxneon.com/books/modern_perl/ [onyxneon.com]
As always, a lot of the most active development is happening outside the core language. Anyone interested in some of the directions Perl 5 is going in today ought to check out projects like these:
http://www.iinteractive.com/moose/ [iinteractive.com]
http://plackperl.org/ [plackperl.org]
http://www.catalystframework.org/ [catalystframework.org]
http://mojolicio.us/ [mojolicio.us]
Re: (Score:2)
No, I didn't mean forget about re-designing the language (and its implementation) altogether and just carry on building on the old, flawed foundation. The goals of Perl 6 seem entirely laudable. I just think that the way this has all been presented to the wider community over the past decade hasn't done Perl any favours. Somehow a (false) impression has been created that Perl 5 is in some sense deprecated, while Perl 6 is not ready. If Perl 6 had been presented from the start as an experimental 'sister lang
Re:What about Perl 6? (Score:5, Informative)
Perl 6 is out. But it's a diffent language in the same way that python 3 is not like py 2.7
The thing I really like about perl is it's the shortest oreily pocket reference. it's even shorter than c++. Yet you can do vastly more than python without importing a single lib. that is to say it's surprisingly concise for encompassing such a lot of capabilities in the core language.
Re: (Score:2, Informative)
No, Perl 6 is not "out". I can't use it on my production servers, because there's no good implementation yet, even after ten years.
I know there have been a few attempts, but none of them are seriously usable like Perl 5, Python, Ruby, Tcl, or Lua are.
At least when developing Python 3, the Pythonistas built a production-grade implementation. Even if its adoption hasn't been as fast as was initially hoped, at least those of us who do want to use it can actually use it, and we can do so for serious uses. The s
Re: (Score:3, Insightful)
Re: (Score:3)
With Duke Nukem Forever being released next month, I think we shouldn't lose faith in Perl 6 either.
It's taken 10 years, yes, but sooner or later they'll realize that what people are waiting for is a _native_ perl 6, not one on top of parrot, haskell, perl 5 or any other external engine. Cause if you virtualize, you might as well use the underlying langauge - it has to be at least as powerful as perl 6.
Re: (Score:2)
I want it fast. If they can get javascript to run fast, why can't they make perl faster? Heck get perl5 to run fast now and I don't mind "waiting for perl6" for another 20 years
Re:What about Perl 6? (Score:5, Informative)
Perl 6 has 140+ different operators! That is absolutely insane. While I support being concise, Perl has far more complexity in the language core than any other language I have ever seen.
but the power (Score:3, Insightful)
With Perl, that complexity gives you power. If one does lots of programming, and their mind is in good shape, Perl can be used to rapidly dispatch programming problems.
Re:but the power (Score:5, Insightful)
Re: (Score:2)
You should really document your code, then.
Re: (Score:2)
Re: (Score:3)
You should document your code in a non-shitty way. Seriously, if you can't figure out what you did six months later, your doco sucks.
Re: (Score:3, Interesting)
Perl 6 has 140+ different operators! That is absolutely insane. While I support being concise, Perl has far more complexity in the language core than any other language I have ever seen.
I like this about English too. Can't tell that Larry is a linguist by training, can you?
Come to think of it, I bet Python developers tend to be fond of Esperanto too. Some similarities there.
Re:What about Perl 6? (Score:5, Insightful)
Re: (Score:2)
have you ever seen a program that did not have a "print" statement in it? well those don't exist. And ignoring that whopper, I can tell you that it's not the big ones that really screw up legacy programs, it is the tiny tweaks that only go wrong one in a million times. Perl5.6 to 5.8 had some really really subtle changes to regrular expressions that broke programs in almost impossible to detect ways. Python 3 is death for legacy python.
Re: (Score:3)
Re: (Score:2)
So trivial that 2to3.py, which comes with Python 3, will do it automatically.
Python 3 is death to Python (Score:5, Informative)
Python 3 is barely different from Python 2
It's different enough to break the language for legacy code.
When you have code by the million lines, it's impossible to have a script that can reliably convert programs like Guido thinks it can. It's not just adding parentheses to print, there are some beastly things, like giving the division operator a different behavior. In Python 2.7, the result of (3 / 2) is 1, in Python 3 it's 1.5. I have absolutely no way to pore through those million lines and checking every division to see which operator should I use, keep the '/' or change it to '//'.
Besides, the changes from Python 2 to 3 are *all* in the direction of making it a more verbose language. I couldn't find any example of code that would be shorter in Python 3 than in 2. That goes against the philosophy of a scripting language, the last thing we need is a new Java.
I had gradually changed from Perl to Python over the years, but this P3k made me reconsider if this was wise. Apparently, there's no good-for-everything language left. So, in the scripting side, where quick results count, I've been considering switching back to Perl. Conciseness is king here, and nothing beats Perl at that.
As for large projects, thank god C is still there, still running K&R style code almost unchanged. Looking back over the years, I find that, for big projects, no language has given me less trouble than C. Once you get it running, it runs forever.
Re: (Score:3)
In Python 2.7, the result of (3 / 2) is 1, in Python 3 it's 1.5. I have absolutely no way to pore through those million lines and checking every division to see which operator should I use, keep the '/' or change it to '//'.
When the // operator was introduced - over 10 years ago - they warned you that this change was coming. Ever since then, it has been prudent to use // wherever you want the answer of 3 divided by 2 to be 1. So if you had been coding according to best practices, you wouldn't have to look through all your code for divisions.
Re: (Score:2)
I think you are missing his point. So you create a syntax that is an error that will be accepted. Billions of programs have this error. Then one day the syntax changes and no error messages are generated.
Consider is some language had = and == be the same thing, then they changed it so that = meant copy a pointer and == meant copy a value. your head would explode trying to track all that down.
Re: (Score:2)
I think you are missing his point. So you create a syntax that is an error that will be accepted.
Reasonable people should not have "accepted" the integer / operator, and they didn't have to. On integers, the operator didn't do what anybody would expect it to, and this was clearly just about the biggest flaw in Python 2.X. It's unfortunate that the flaw was there and needs to be fixed, but life isn't perfect.
Seeing the mistake, 10 years ago the Python developers gave you the tools to avoid using integer '/', and they told you the planned fix. If you simply followed their advice, you'd be fine now. Perso
Re: (Score:2)
Y'know I never got the memo. Seriously I never heard of this before today. I don't think this is my fauly either. I own dozens of books on python and am well read. As a check to see if I'm the lone idiot, I just went through a bunch of random files in python libraries I've downloaded over the years. Only one of them had // in it. So apparently no one else got the memo either.
Re: (Score:2)
Here's your memo: PEP 238 [python.org]. I believe that it's frequently referenced in the "what's new" section of various point releases of Python since the PEP was published.
Re: (Score:2)
I think that Python needs a __past__ module for those nostalgic features like bracket-free print statements. Perhaps it could be a new PEP, and we could use a bizarre import statement like from __future__ import __past__ in Python 3.3.
Re: (Score:2)
Some would argue that this is a bad thing.. :-) It's not an accident that python without any libraries is completely useless.
In answer to the comments a bit further down about how languages getting more mature makes them harder to extend - well python has about 30 keywords. Perl has about 600. Python usually just has to replace a few libs. Python 3000 mostly fixes some 10 year old issues which date back to the infancy of the languag
Re: (Score:2, Funny)
Re: (Score:2)
Indians using proper Microsoft Certified development tools.
Did you write that with a straight face? Enjoy spending Microsoft's money, you pathetic shill!
Re:Perl - the COBOL of scripting languages (Score:4, Interesting)
We still use Perl to develop our products (commercial and open-source.) Perl may be maligned, but it's still a good tool for a lot of purposes and if you pick and choose carefully, CPAN is an awesome resource. Perl has modern frameworks (eg, Catalyst) for Web development that are competitive with anything out there, and DBI is superior to most alternative languages' database libraries.
While I'm bullish on Perl 5, I'm not so optimistic about Perl 6. I think it's suffring horribly from second system syndrome and may never see the light of day as a useful production tool.
Re: (Score:3)
Your company has history with Perl, but I don't think it will be chosen for new things now, PHP alone is mostly eating its lunch. Web serving the stats are something like 75% PHP5.x and 20% dot-NET but only 1% Perl with J2EE 5% (some overlap as sites run multiple langauges, but still....). Compare that to over ten years ago (when I was developing in Perl), it's really fallen.
Re: (Score:3)
PHP alone is mostly eating its lunch
Interesting you say that... our product's Web interface is written in PHP and I rue the day I made that decision. For all of Perl's faults, PHP is about 100 times worse. No proper namespaces, completely wild-west wacky naming "conventions", no decent DBI-like library, crappy add-on modules (just try finding a decent YAML parser for PHP.)
If I had to do something new, I'd probably look at Python. I have very little experience with it, but it seems quite easy to use
Re:Perl - the COBOL of scripting languages (Score:4, Interesting)
Our entire API framework is Perl and has been for a few years now. Seemed like every time we needed to add a new format to return values in (originally was XML) like JSON, there always seems to be a perl module "for that".
The best part of things is the fact that while we've added new functionality, we haven't had to do any maintenance work on the script in almost 5 years now.
Biggest change we made from 5.8.x to 5.10 was rewrite some nasty els if statements and made them switch statements.
The original web based management tool was originally written in PHP and that is what took all the time to maintain. It seemed like with each dot release of PHP some little thing broke and we were always fixing something every few weeks because of it.
Re:Perl - the COBOL of scripting languages (Score:4, Insightful)
Excellent troll... really first rate. Did you get federal funding from the Ministry of Trolling for that gem? I've been working professionally in unix/linux environments for about 12 years and believe me perl is still quite alive and well doing real work in lots of different kinds of companies. Php is somewhat painful to code in by comparison but both have their place. Except for java.. it has no sane place but you still find it in use everywhere which just goes to show anything can succeed in this world with enough marketing dollars behind it.
Re: (Score:2)
Re:Perl - the COBOL of scripting languages (Score:5, Insightful)
All I'll say to that is that the entire computing world does not revolve around websites... or programming certification mills. =] Perl is the duct tape that holds the networked world together... and it's not dying any more than actual duct tape is. It's a refined tool used by professionals to do the jobs that have always needed done in a minimum of time and that don't cater to the latest buzz word laden development methodology.
Re: (Score:2)
Exfuckingactly. Whilst the buzz-word slavering IT managers and their Java sycophant underlings hype around in Brownian motion fiddling feverishly with websites, the rest of the professional world maintains the foundation and glue that really makes all the shit "just work."
With the possible exception of Python, nothing else comes close in satisfying it's intended purpose (talking toolkit/scripting/etc). Perl bashing reminds me of kids with snot-shiny upper lips whining about the "complexity" or "shortcomin
Re: (Score:2)
Re: (Score:2)
I often have people asking me why C is still getting used.
C#/Java is all you need, right? Right?
Re: (Score:3)
that "minimum of time" is only until the next poor SOB has to modify some code. Then it's time to go a-wadin' through the whale guts.....
Re: (Score:2)
New startups using perl, courtesy of Quora:
blekko
nabbr
selectablemedia.com
goba.mobi
socialflow.com
duckduckgo
Big companies writing lots of new perl, also courtesy of Quora:
Lokku (makers of Nestoria), BBC, LJ, IMDB, Salon.com, Typepad, Zappos, Craigslist, FriendFinder, Ticketmaster, Slashdot
I think you're really confused about the role Larry plays in the community. He's slowly creating a new language, which has little to do with perl 5. Perl 5 is actively maintained and has a large community of users.
Re: (Score:2)
I respect your opinion, but my experience has been different. I forced myself to learn Perl twice and never could quite get the hang of it. So much of the language is context sensitive (e.g., this arbitrary symbol means a certain thing, except in some cases where it means something completely different) and there are so many features that I always felt overwhelmed. Sure, I always managed to get the code working but it felt hackish an
Re: (Score:2)
Perl has some nifty frameworks that can make you as productive as PHP for small web projects, and it also does large projects well.
But hey, if you're comfortable with PHP and Java, and want to pay to have your app completely rewritten, then more power to you.
Re: (Score:2)
COBOL is still alive and kicking. It still does some things better than any other language. As Scotty once said "Use the right tool for the job, laddie"!
Besides, COBOLScript is the COBOL of scripting languages:
http://www.computer.org/portal/web/csdl/doi/10.1109/EDOC.2000.882363 [computer.org]
You should really do a bit more language evaluation. I don't know if you are ready to leave your parents' basement yet.
Re: (Score:2)
So many superior (e.g. python) ...if memory efficiency isn't on your requirements list...
or just simpler (e.g. php5) ... if you can remember to use different string function calls depending on the encoding of your variable (you always know this ahead of time, right?)...
while Larry vainly struggles on trying to turn Perl 6 into a swiss army knife
Larry's not involved in the most likely successful implementation effort (Rakudo). Heck, I'm not even sure there have been any language specification updates of not
Re:Perl - the COBOL of scripting languages (Score:4, Interesting)
The new search engine blekko is written in perl - wrote our own NoSQL database in it, too. We found CPAN to be an awesome resource; we use 600 distros from CPAN, and only found a couple of bugs in them.
It's Java that's the new COBOL. (buh dum, ching!)
Re: (Score:3)
Python has some advantages over Perl -- cleaner syntax, a better REPL, none of the legacy shell-script-derived cruft that makes it so easy to write terrible code in Perl. It also has quite a few disadvantages that make it harder to write robust code, such as its lack of any equivalent to Perl's extremely useful "use strict" and its poorly designed scoping rules.
I see a lot of new development taking place in both languages. I don't see much PHP, but that's a niche language restricted
Re: (Score:3, Funny)
In Perl:
curl -sL 'http://slashdot.org/index.rss' |perl -ne 'm/<title>(.+?)</ && print "- $1\n";'
Same thing in PHP5:
curl -sL 'http://slashdot.org/index.rss' |php5 -r '$h = fopen("php://stdin","r"); while(! feof($h)){$line=fgets($h); if(preg_match("/<title>(.+?)</",$line,$match)){echo "- ".$match[1]."\n";}}'
... and if you say "well, php5 is simpler for what *I* need," I'mma gonna poke you for thinking that everyone else has the same n
Re: (Score:2)
$troll =~ s/BSD/Perl/g;
print SLASHDOT $troll, "\n";
Re: (Score:2)
If Larry really had pushed Perl6 it would have been ready a long time ago. He wanted Perl6 to be community designed; that's why it's taking forever.
I had to work on a mediawiki installation a while ago and had my first time encounter with PHP. Verdict: Brain dead.
Perl5 is still my first choice for anything that doesn't have to be efficient because it's only called every now and then. And the programs still start up faster than Java. By the time my vendor's Java code finally starts to run my Perl scripts are
Re: (Score:2)
Re:Perl - the COBOL of scripting languages (Score:5, Insightful)
Re: (Score:3)
in
add_user and rm_user scripts
apxs (apache extension DSO builder / installer)
pkg_chk, pkg_delete, pkg_info, pkg_create, pkg_merge (our simple and crude package manager)
in
afmtodit font file creator for groff
c2ph/pstruct dump c structure with offsets from debugger stabs
find2perl convert find comm
Re: (Score:2)
Although I do agree that most of that could be rewritten in sh or even in C, rather easily. And the package manager does suck.
Re: (Score:2)
had to check, but the c2ph/pstruct is in the base49.tgz
heavily audited chrooted 1.3 apache is in the default install,
,
It's sour grapes, I used Perl in development as was and fanboy over a decade ago. Major disappointment for me the way things went.
Re: (Score:2)
Perl might be a bit antiquated and awkward but it's the right tool for a number of jobs.
Re: (Score:2)
Neither should Cobol, and yet, as with Perl, sometimes there is a thing called historical momentum. Perl is still used in a lot of places, and there is a helluva lot of Perl code out there.
Re: (Score:3)
Re: (Score:2)
If Perl's "wind down" is anything like Cobol's, then it's still got many years left.
Re: (Score:3)
Re:Perl vs Python, in OS scripts (Score:3)
A recently installed server in a small company (Debian Squeeze):
$ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'perl .*script' | wc -l /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'python .*script' | wc -l
196
$ find
46
My notebook (Ubuntu 10.4):
$ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'perl .*scr
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
'Stuck in their ways?'
It's people like me who have to clean up the mess people like you make because you'd rather use the hyped up tool than the tool that is suited to the job.
You are a prisoner of hype.