Slashdot Mirror

I know there'll be issues with experimental stuff and bugs. I was talking about some bigger issues like this one :
http://blogs.perl.org/users/le...

I've been noticing a growing number of ill planned changes in perl5 since (roughly) the 5.18 time frame. In that particular case, I think it's nasty that a use statement doesn't protect against the incompatibility. It would break your suggestion of using the use statement. I don't use Modern::Perl because most of the systems I use don't have it, I don't have root and don't like virtualenv type stuff (not that perl really has a great virtualenv type environment. Brew is a bit heavy weight and fiddling with the PERL%* vars is fiddly.)

I find targeting core perl 5.10 to be the safe bet for now when I'm at work. At home I'll target want I have.

Ah, so you mean like C::TinyCompiler?

So, I ask again, what libraries are missing for Perl?

Or is your aversion to Perl not fact-based?

Perhaps when people see a question unanswered, they offer their suggestion even if it's not directly responsive.

Why, then, does the question remain unanswered by a sed fanboy? Perhaps because sed, while useful for some trivial work, is not very friendly for more complex tasks. Thus, there are probably very few sed fanboys because they graduate to richer languages if they have an interest in doing more complex work and relegate sed to only the very simplest of tasks.

If the question is "text processing", Perl is likely the best bet so those are the answers you get when no one provides a sed response. Programmers don't really expect to have to "explain" a Perl script that is fairly short -- Perl has rich RE support which can quickly look like line noise at first glance but it's well documented (for example: perlre, perlretut, perlrequick). It's impractical to explain in every post how, for example, back-references work in conjunction with grouping or how the 'm' and/or 's' modifiers work. Programmers expect that one can, if they care, dig through the RE and, with the help of the documentation, tease it apart (and, that's a good way to expand one's knowledge of Perl REs as well).

I use Perl for most scripting on personal projects. In part this is because long ago I was working in a multi-vendor world (our product ran on, IIRC, about ten different vendor variants of Unix -- if you paid us to port our product to your platform to enrich the library of products that ran on your platform, we were happy to take your money). At the time, Python was not reliably available on all the platforms but Perl was and there was no question that Perl beat bash (or csh) + command line utilities for almost everything. I probably would have switched to Python being my primary scripting language but I absolutely hate the "white space is meaningful" thing for delineating blocks.

That said, I really don't care for Perl but I have 20+ years of Perl scripts sprinkled throughout my personal environment so inertia plays a role as well.

Perhaps when people see a question unanswered, they offer their suggestion even if it's not directly responsive.

Why, then, does the question remain unanswered by a sed fanboy? Perhaps because sed, while useful for some trivial work, is not very friendly for more complex tasks. Thus, there are probably very few sed fanboys because they graduate to richer languages if they have an interest in doing more complex work and relegate sed to only the very simplest of tasks.

If the question is "text processing", Perl is likely the best bet so those are the answers you get when no one provides a sed response. Programmers don't really expect to have to "explain" a Perl script that is fairly short -- Perl has rich RE support which can quickly look like line noise at first glance but it's well documented (for example: perlre, perlretut, perlrequick). It's impractical to explain in every post how, for example, back-references work in conjunction with grouping or how the 'm' and/or 's' modifiers work. Programmers expect that one can, if they care, dig through the RE and, with the help of the documentation, tease it apart (and, that's a good way to expand one's knowledge of Perl REs as well).

I use Perl for most scripting on personal projects. In part this is because long ago I was working in a multi-vendor world (our product ran on, IIRC, about ten different vendor variants of Unix -- if you paid us to port our product to your platform to enrich the library of products that ran on your platform, we were happy to take your money). At the time, Python was not reliably available on all the platforms but Perl was and there was no question that Perl beat bash (or csh) + command line utilities for almost everything. I probably would have switched to Python being my primary scripting language but I absolutely hate the "white space is meaningful" thing for delineating blocks.

That said, I really don't care for Perl but I have 20+ years of Perl scripts sprinkled throughout my personal environment so inertia plays a role as well.

Perhaps when people see a question unanswered, they offer their suggestion even if it's not directly responsive.

Why, then, does the question remain unanswered by a sed fanboy? Perhaps because sed, while useful for some trivial work, is not very friendly for more complex tasks. Thus, there are probably very few sed fanboys because they graduate to richer languages if they have an interest in doing more complex work and relegate sed to only the very simplest of tasks.

If the question is "text processing", Perl is likely the best bet so those are the answers you get when no one provides a sed response. Programmers don't really expect to have to "explain" a Perl script that is fairly short -- Perl has rich RE support which can quickly look like line noise at first glance but it's well documented (for example: perlre, perlretut, perlrequick). It's impractical to explain in every post how, for example, back-references work in conjunction with grouping or how the 'm' and/or 's' modifiers work. Programmers expect that one can, if they care, dig through the RE and, with the help of the documentation, tease it apart (and, that's a good way to expand one's knowledge of Perl REs as well).

I use Perl for most scripting on personal projects. In part this is because long ago I was working in a multi-vendor world (our product ran on, IIRC, about ten different vendor variants of Unix -- if you paid us to port our product to your platform to enrich the library of products that ran on your platform, we were happy to take your money). At the time, Python was not reliably available on all the platforms but Perl was and there was no question that Perl beat bash (or csh) + command line utilities for almost everything. I probably would have switched to Python being my primary scripting language but I absolutely hate the "white space is meaningful" thing for delineating blocks.

That said, I really don't care for Perl but I have 20+ years of Perl scripts sprinkled throughout my personal environment so inertia plays a role as well.

Can you please highlight the multi-threaded support in Perl6?

Also, can you highlight the international language support for all of Perl? http://perldoc.perl.org/perlun...

Care to discuss Âcperl the high-performance perl5? http://perl11.org/cperl/ Runtime performance of perl seems to have been decreasing over the years. Any consideration for following the Intel method of even/odd releases with features/performance optimizations being the even/odd primary efforts?

Have yet to attempt use perl6. Just trying to Âhave the appropriate amount of fun with my coding. ;)

how can we strategically pull the PERL language into the browser?

The Perl Foundation has funded a grant to extend Rakudo, the preeminent Perl6 compiler, so that it can generate JavaScript.
  http://news.perlfoundation.org/2016/02/ian-hague-perl-6-grant-applica.html

You can see the repo for the work here: https://github.com/pmurias/rakudo-js

and read updates from the developer's blog here: http://blogs.perl.org/users/pawel_murias/

FYI, It's either "Perl" or "perl". Perl is not an acronym.

It did not take 15 years to complete the last release. During the last 6-7 years, Perl 5 had a yearly new release. At the moment, people are using Perl 5.22, and it has been updated to 5.22.1. Work on 5.24 is on it's way, will be released somewhere next year. Stuff like this is public knowlegde, it's not hidden away.
http://perldoc.perl.org/perlhi...

Until it gets here
https://www.perl.org/
I ain't bothering.

That's the site for Perl 5. Perl 6 is a different language and has its own website.

So, he's saying that he'll never bother with Perl 6.

Sounds like a reasonable position to me!

I only had trouble with the $-somethings, but here you go, in order of appearance:

http://perldoc.perl.org/functi...
http://perldoc.perl.org/perlop...
http://perldoc.perl.org/perlva...

You're not supposed to understand that intermediate-level mess just by looking before having learned a bit of Perl, anyway. Like regular expressions, Perl code was never designed to be self-explanatory.

I only had trouble with the $-somethings, but here you go, in order of appearance:

http://perldoc.perl.org/functi...
http://perldoc.perl.org/perlop...
http://perldoc.perl.org/perlva...

You're not supposed to understand that intermediate-level mess just by looking before having learned a bit of Perl, anyway. Like regular expressions, Perl code was never designed to be self-explanatory.

I only had trouble with the $-somethings, but here you go, in order of appearance:

http://perldoc.perl.org/functi...
http://perldoc.perl.org/perlop...
http://perldoc.perl.org/perlva...

You're not supposed to understand that intermediate-level mess just by looking before having learned a bit of Perl, anyway. Like regular expressions, Perl code was never designed to be self-explanatory.

The below from http://perldoc.perl.org/thread...

WARNING

The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help.

The use of interpreter-based threads in perl is officially discouraged.

What's next, support for long integer arithmetics?

perl 5 already has built-in support for 53 bits integers on 32 bits builds (check perl -V:nv_preserves_uv_bits on your platform). If you want more your can use the bigint pragma.

See http://jobs.perl.org/

A couple of years back, I was trying to hire someone ... although we were hoping for OO Perl skills. We ended up hiring someone with database skills to train up in Perl, instead.

The problem with age isn't so much that you have less portable skills, it's that you have a less portable life -- if you have a sponse & kids, you don't want to move the kids in the middle of a school year and away from their friends ... if you have a spouse, you have the problem of trying to find a place that's convenient for both your jobs.

If you're single with no kids ... Booking.com is hiring in the Netherlands. It's effectively an English speaking country these days (although it's been 30 years since I've been there).

(I have no affiliation with booking.com, other than they were a sponsor for many years of the DC-Baltimore Perl Workshop, which I help to organize)

I was also going to mention the perldoc, Larry Wall (et al.) wrote some really entertaining stuff, a real pleasure to read. http://perldoc.perl.org/perl.h...

The phrase might be true, but we're seeing the effects of insufficient eyes. In reality, how many sets of eyes are actually reviewing these libraries at a source code level? I rather strongly suspect that in most cases they are simply used under the assumption that "well, everyone uses it, it must be okay".

You don't even need source code level. Look at the mess Perl is with CGI and lists,

http://perldoc.perl.org/CGI.ht...

And since the undocumented feature is to return a list of parameters as "single value" if you get multiple instances of parameters, you can produce various fun in perl code that expects single values, not lists.

https://plus.google.com/+Krist...

with a nice link on how to use a 20-year-old holes in Perl core libraries to generate CVE in tons of software using perl. And no, I have not checked if slash is vulnerable.

So please, how many eyes do you need in this case? Bugs that can be exposed by unit tests by end users, yet, here we are, 20 years later.

So brilliant programming languages do not permit eval($ENV["FOO"])?

Correct, because good programming languages don't have anything like eval().

Normally, in a decent programming language, if you're convinced you really need to execute unknown-until-runtime code, the first step is to get over your misconception. If you're unable to get over the misconception, then you do something like fopen('tmp.c'); fwrite... fclose, system('cc variousflags tmp.c'); system('tmp'); and then you spend the next few weeks worrying about how awful what you did was, and rethink your unnecessary "need" to run generated code.

eval() is not C or C++. It's Bourne Shell, and it's a necessary evil for a Shell language to have. That said:

• Java - http://docs.oracle.com/javase/...
• C# - http://msdn.microsoft.com/en-u...
• Python 2 - https://docs.python.org/2/libr...
• Python 3 - https://docs.python.org/3/libr...
• PERL - http://perldoc.perl.org/functi...
• Windows Powershell (via invoke-expression) - http://en.wikipedia.org/wiki/E...
• and more - http://en.wikipedia.org/wiki/E...

So what again was your point?

IEEE shows "PERL" at number 11. IEEE, It's Perl, not PERL.

http://www.nntp.perl.org/group...

I've done PHP for 10 years, and then switched to C#, and I'm never looking back. EVER. Not only is the language shit, but look at the implementation: http://use.perl.org/use.perl.o... If the value of the variable is larger than INT_MAX .... do this... there we go, overflow averted... -_-

When referring to the Perl programming language, the correct usage is Perl. Given the fact that you're apparently in a position to make hiring decisions on programmer positions, you would be well advised to be well versed in proper naming conventions. Incidentally, I've been coding in multiple languages, although predominantly in Perl, for twenty years. I'm not looking for a job, though.

I refuse to do business with Netflix, because they send spam. Yes, I have personally received unsolicited commercial E-mail from Netflix, like the people writing at the two links I cite. Any company that uses and/or promotes spam should be boycotted and shunned.

I prefer docs like this: http://perldoc.perl.org/functions/open.html
If you're a noob - the first bit is good enough. If you want more, you scroll down and you see more advanced stuff.

Microsoft's documentation has become rather terrible. Often there are no examples. On a related note - go try to find out how to compile VB.Net and C# stuff using multiple cores on Visual Studio and see how bad the documentation on that is.

Worse are the social technet forums where Microsoft's reps answer questions. Many of them give wrong or unrelated answers. Maybe they are answering merely to meet some sort of quota. The end result is you have lots of wrong and crap answers to questions.

Yes, Perl is a paragon of structure and consistency:

Exactly what the EXPR argument to when does is hard to describe precisely, but in general, it tries to guess what you want done. Sometimes it is interpreted as $_ ~~ EXPR, and sometimes it is not. It also behaves differently when lexically enclosed by a given block than it does when dynamically enclosed by a foreach loop. The rules are far too difficult to understand to be described here. See Experimental Details on given and when later on.

- Perldoc

Now please tell us what you think about PERL. I'd really like to know.

http://learn.perl.org/faq/perlfaq1.html#Whats-the-difference-between-perl-and-Perl-

"Perl" is the name of the language. Only the "P" is capitalized. The name of the interpreter (the program which runs the Perl script) is "perl" with a lowercase "p".
You may or may not choose to follow this usage. But never write "PERL", because perl is not an acronym.

Ha. As a programmer in at least two handfuls of languages over 40 years from IBM 1130 ASM, FORTRAN, ALGOL 68, Pascal, Basic (ick), APL, etc., and long time programmer in PHP, I am presently in the process of hacking up someone else's Perl.

Nobody who writes in Perl can have anything to say about the structure, style or consistency of PHP. PHP may have grown like topsy and it could certainly use some revision of function argument order, but it at least uses a syntax that is remotely similar to other common imperative languages - java, c, etc. From my first look at Perl in 1995 I always thought Perl looked like sneezing, and now I'm working with it, my first impression was correct. (Although in fairness I use PCRE in PHP quite a lot!)

This is my most recent 'fave' quote from perlsyn - on 'when', which is part of Perl's attempt to rethink (or something) the switch/case pattern:

Exactly what the EXPR argument to when does is hard to describe precisely, but in general, it tries to guess what you want done. Sometimes it is interpreted as $_ ~~ EXPR, and sometimes it does not. It also behaves differently when lexically enclosed by a given block than it does when dynamically enclosed by a foreach loop. The rules are far too difficult to understand to be described here. See Experimental Details on given and when later on.

Pathologically Eclectic Rubbish Lister indeed!

Since I'm on a role here, I will complain about one thing in Python, though I've only programmed a bit in Python. Python's much vaunted 'indent' based nesting is a mistake, because it only uses one invisible marker (which may be instantiated by several symbols - spaces and tabs, at least) to do this. All other common languages I can think of use different markers for begin and end, which acts as a kind of 'double entry bookkeeping' for the parser. Without a closing marker, Python's parser has no way to catch errors in leading spaces.

A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'. This is the cause of innumerable bugs in both languages. This could be fixed by requiring assignments inside a conditional to be surrounded by block markers: "if ({$foo = 1 + $bar})".

But I like all 'scripted' languages better for my purposes (entirely applications, no device drivers or kernel work) than C and other 2nd generation languages. I've had exactly one segfault working with PHP, in nearly 20 years.

Ha. As a programmer in at least two handfuls of languages over 40 years from IBM 1130 ASM, FORTRAN, ALGOL 68, Pascal, Basic (ick), APL, etc., and long time programmer in PHP, I am presently in the process of hacking up someone else's Perl.

Nobody who writes in Perl can have anything to say about the structure, style or consistency of PHP. PHP may have grown like topsy and it could certainly use some revision of function argument order, but it at least uses a syntax that is remotely similar to other common imperative languages - java, c, etc. From my first look at Perl in 1995 I always thought Perl looked like sneezing, and now I'm working with it, my first impression was correct. (Although in fairness I use PCRE in PHP quite a lot!)

This is my most recent 'fave' quote from perlsyn - on 'when', which is part of Perl's attempt to rethink (or something) the switch/case pattern:

Exactly what the EXPR argument to when does is hard to describe precisely, but in general, it tries to guess what you want done. Sometimes it is interpreted as $_ ~~ EXPR, and sometimes it does not. It also behaves differently when lexically enclosed by a given block than it does when dynamically enclosed by a foreach loop. The rules are far too difficult to understand to be described here. See Experimental Details on given and when later on.

Pathologically Eclectic Rubbish Lister indeed!

Since I'm on a role here, I will complain about one thing in Python, though I've only programmed a bit in Python. Python's much vaunted 'indent' based nesting is a mistake, because it only uses one invisible marker (which may be instantiated by several symbols - spaces and tabs, at least) to do this. All other common languages I can think of use different markers for begin and end, which acts as a kind of 'double entry bookkeeping' for the parser. Without a closing marker, Python's parser has no way to catch errors in leading spaces.

A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'. This is the cause of innumerable bugs in both languages. This could be fixed by requiring assignments inside a conditional to be surrounded by block markers: "if ({$foo = 1 + $bar})".

But I like all 'scripted' languages better for my purposes (entirely applications, no device drivers or kernel work) than C and other 2nd generation languages. I've had exactly one segfault working with PHP, in nearly 20 years.

I don't care how advanced Netflix's architecture and infrastructure are, they still use unsolicited commercial E-mail--spam--to advertise their services. I've seen it. Other people have seen it. I do not do business with spammers. Period.

On a not unrelated note, what's the general view of the current state of Perl 6? I can look at http://planet6.perl.org/ for the view of those close to the project, but what's the word on the street? I think "word on the street" is a really important metric as to how well a project is doing. Trends are a major determiner of which product potential new users will find. Rather like bank runs: it can be irrational to trigger one but nevertheless rational to follow one.

I'll put it on the table: I have a Bachelor of Science (B.Sc. - 4 year degree) in Electrical Engineering (more like a CE/EE/CS degree) from The Technion in their Haifa, Israel Campus, and graduated cum laude, and I have a qualified engineer certificate which theoretically allows me to write software for guiding missiles (or other flaw-free software) and give my signature that it is flaw-free. Nevertheless, right now I'm looking for part-time jobs as a seller/vendor in icecream parlours, candy/snack stores, cafés/restaurants/bars/etc. or even as a street sweeper. Lots of places in Tel Aviv, Israel are now advertising for this, and this seems like a good way to earn some money, as well as interact with other people and get inspired which will really help me with my creative writing and my essays. And I can buy an Android smartphone (nothing really better now and some people have successfully installed GNU/Linux chroots there) so I can type stuff for later incoporation into my desktop and laptop devices.

So why not work as a software developer? I don't mind getting a job as a software developer or a hardware developer or whatever, but lately employers in Tel Aviv and vicinity have become extremely picky: you go to an interview, answer most technical questions nicely, and don't get hired. Furthermore, even if they like you they are often very domineering: don't work from home, work 10-12 hours a day, only full time, don't play computer games at all (I only played some card Patience/Solitaire and Sokoban and not for long and still got flack), don't go to Facebook/Twitter/Google-Plus, we don't want you accessing imgur.com (too muchu traffic to there so let's firewall it) etc. etc. Thing is - the junior developers are kings (see the link for the Joel article), and you should leave them alone to their elements to get shit done at their own pace, and using their own resources instead of being a control freak. If, as a boss, my developer watched porn for 6 hours a day, while still being available on the forums for questions, and spent 2 hours creating great code that is functional and beautiful, I would be happy, and give him a full salary. But finding such enlightened employers is a big problem.

Software was the first field where workers were in constant demand, but now it seems that other fields are headed the same way here in Tel Aviv and other major centres of commerce worldwide: the food outlets, the music industry, photography, and soon - writing, acting/drama/film and then hopefully also modelling, and then if we can get past the normal and silly legal barriers - also more brick-and-mortar industries. Right now I've decided to make a transition from a software developer to a writer/Internet-entertainer/amateur-philosopher - a field where I feel I produce better results and also something that people will find cooler and sexier (although like I note in the article, the fact that I wrote a Freecell solver has impressed some really cute and intelligent chicks), and will have a larger influence. I still see knowing programming and other software development as an absolutely necessary means for that, just like I can no longer survive without knowing how to read and write English. Everyone should know at least HTML/XHTML/etc.

What I'm trying to say is that one should avoid Fatalism. People can improve for the better. I spent six and a half year doing my Elec. Eng. degree in the Technion and it cost me a lot of frustrations, but I'm still alive and have constantly become a better person - more competent, more able, smarter, wiser, and with a greate

Seriously? Perl Platforms

A little bit of troll food here: There is a roadmap and a vision for the future.

Get informed/involved at perl.org

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;

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.

The problem is that people look at Perl - without having learned it - and say "unreadable!"
That really is the kind of circular thought only stupid people can achieve - "I dunno Perl, so I can't read Perl, so I don't know Perl, so I think it's unreadable (...)"
Now, anybody seriously considering reading large arrays into Perl can ask the Bioinformatic guys how Perl is cutting it for them, or also choose to use the Perl Data Language which seems good enough for some guys in an Astrophysics department.

I write a good amount of Perl. When I need to do serious number crunching I still use Perl! That is I use PDL.
PDL is a fantastic replacement for Matlab and Octave. Especially in those situations where you have part of the project already written in Perl.

Perl can do web Like CGI math system admin Perl has syntax rules, but it doesn't limit you to an imaginary box, that's its power, and some would suggest its flaw.

It rather depends on what you call a "big feature" - syntactically not much is likely to change, that's true. On the other hand if you look at the list of changes from the latest stable release it's clear that many things continue to be improved, even more so if you look at the sum of all changes from 5.12 forward (aka the modern perl5 era).

On the one hand, with Perl, you can't even create and use a multi dimensional array without barely comprehensible hacks.

Unimpressed.

http://perldoc.perl.org/perldsc.html#ARRAYS-OF-ARRAYS

$AoA[0][0] = "Fred";

print $AoA[0][0];

I will give you that iteration syntax over a AoA can look a little weird to the uninitiated.

I pretty much stopped using multidimensional arrays as a complex data structure when I learned OO except for the obvious mathematical applications. Although for hard core math I tend to take advantage of octave. I've used Inline::Octave from cpan but thats kinda weird.

I wouldn't do massive scale text processing in Octave unless I had a really good reason, much as I wouldn't do massive math work in Perl unless I had a really good reason.

The easiest "hack" on AoA is not to use them, if the application is simple enough. If you just need a crude data store just make a simple hash. So instead of [2][3][4] as a 3-dimensional coordinate, just store "2 3 4" as a hash key.

From perlfaq1:

What's the difference between "perl" and "Perl"?
"Perl" is the name of the language. Only the "P" is capitalized. The name of the interpreter (the program which runs the Perl script) is "perl" with a lowercase "p".
You may or may not choose to follow this usage. But never write "PERL", because perl is not an acronym.

From wikipedia:

Though Perl is not officially an acronym, there are various backronyms in use, such as: Practical Extraction and Reporting Language.

From Learning Perl, 2nd Ed:

Perl is short for "Practical Extraction and Report Language," although it has also been called a "Pathologically Eclectic Rubbish Lister." There's no point in arguing which one is more correct, because both are endorsed by Larry Wall

Either way, typing the name of the language in all-caps is wrong.

That's not a good example. You want a good example of PHP core team competence, check this saga about fixing an integer overflow bug, for example.

Or just contemplate about how 20 year old language didn't have the ability to chain method calls and field lookups on objects returned by functions until release 5.4 - it was a _syntax_ error before.

Or how strings are compared as numbers in unexpected places. I'm not talking about "42" == 42, I'm talking about "42" == "42.0", or "10" == "0xa". Well, using == in PHP is discouraged for reasons like this one anyways (which in itself is quite telling), but check this one out - if we have $x = array('42'), in_array('42.000000000000001', $x) will be true. Can't check this at the moment, but IIRC it's still there in PHP 5.4

It's bad design through and through. It was OK when it was an hobby project for templating a small homepage, but then it started growing and instead of designing features it got ad-hocs piled on ad-hocs.

An integer overflow bug in the PHP core was originally fixed with a test like this:

if (size > INT_MAX)

When this didn't work they used a float. I'm not making this up.

http://pdl.perl.org does lots of math and is still going strong...

Learning Perl
Schwartz & Christiansen

Or just send him to http://perldoc.perl.org/

Having multiple sessions over the same connection speeds up repeat connections: http://blogs.perl.org/users/smylers/2011/08/ssh-productivity-tips.html It's well worth setting up.

There's a small PDL user map and use cases are also listed there.

Obviously, I forgot to include a link to the the actual PDL site. Sorry about that.

I'm personally using PDL in the context of environmental noise measurements; I get long series of numbers and need to sum (and handle them in other ways) efficiently. Why, then, PDL and not numPy or something else? It stems from the fact that I had used Perl for scripting and text handling earlier. Also, I wasn't required to use something else. So laziness is a rather strong reason. Perhaps I was also a lost cause (that's perhaps a wrong phrase?) because I had started with Perl already.

I'm a firm believer in "use a tool suitable for the purpose", so I use R for statistical things. I shudder at all the things Excel, a prime example of a tool exploitable for multiple purposes, is used by my co-workers...

Epic leaks? For the better part of a decade?

better part of a decade - 8 years
22121 memory leaking in perl_destruct and perl_free ? open perl5 Nobody 0
Haili.Ma@netiq.com 8 years ago 8 years ago 0


Not sure on the legitimacy of the actual leak or the value of its epicness but it appears that 8 years is the better part of a decade. So yes, for the better part of a decade.