Slashdot Mirror

numpy, matplotlib, any of the neural network libraries

I suggest you read this posting

In Perl we have these same capabilities and tools if not more:

        PDL - The Perl Data Language, which has:
                N-dimensional array objects
                integrated scientific computing libraries for science, mathematics engineering
                integrated 2D plotting libraries via PGPLOT and PLplot
                integrated 3D graphics libraries via OpenGL and TriD
                and much more...
        Statistics::R, Statistics::useR - basic integration between Perl and R for statistical computing
        ExtUtils::XSpp and SWIG - interoperability between C++ and Perl
        Countless other libraries on CPAN for math, science, engineering (just look at Math::*, Statistics::* namespaces for example)
 

As for neural networks, try this

Oh, I mistook it for Perl ;-)

This Perl or this Perl?

Oh, I mistook it for Perl ;-)

This Perl or this Perl?

A lot of people think mod_perl is the Perl equivalent of what mod_php is. I did at first too. It isn't.

It's made to extend Apache with Perl. Write filters and handlers and stuff for HTTP requests. Not for serving simple HTML pages. If you tried to read its documentation, you'd realise that.

You were apparently always supposed to use Perl with FastCGI or (in the modern times) Plack/PSGI.

See CGI::Alternatives for a bunch of popular modern web frameworks. None of them need mod_perl.

if it's merely a simple regex then they can use something like Unicode::Regex::Set to get the unicode character sets they want.

• Javascript Cryptography Considered Harmful (probably the most widely cited article on this topic)
• Cryptographic nonce (specifically the "Hashing" subsection)
• Key derivation function (with attention to the NIST citations)

Without trying to delve too deeply into some of the more frustratingly complex (and full of subtle pitfalls, much like applied cryptography in general) aspects of this topic in a single Slashdot reply, I'll try to offer a basic synopsis of some immediate concerns. When you hash the password on the client, especially (and quite dangerously) if you're using a known and/or easily guessable salt, the hash you transmit to the server simply becomes a markedly weaker authentication token. A few frequently cited (and each interrelated) resulting drawbacks would include known fixed token length, dramatically reduced computational search space, heightened traffic analysis potential, inescapable and severe credential entropy reduction, much more easily executed simple {dictionary, precomputation, preimage} credential recovery attacks, etc.

Once the token arrives at the server, per your scheme it would be rehashed, but with what salt? Server side salt reuse here yields the same concerns, and in fact would only serve to further dramatically worsen the utility of the credential in question. Properly formed salted hashes are not validated via textual equivalence comparison, but rather via feeding the salted hash and the original secret into the hash's validation algorithm. You might find the basic Perl implementation of Crypt::SaltedHash illustrative in this regard.

As I mentioned earlier, this isn't an exhaustive list of of the issues associated with this topic. In the best case, the system you've proposed would add no substantive security margin to weak passwords, and would seriously weaken stronger passwords. If you like, please feel free to email me for further discussion. -PCP

Captcha: certify

Sounds an awful lot like the WordNet similarity vector which is commonly used in semantic analysis and is a measure of the 'relatedness' of words - http://search.cpan.org/dist/Wo...

hm, it doesn't seem to provide a binary read method for some reason. Odd.

Sorry, the binary read was read, of course. It was typeset differently in the perldoc which is why I didn't see it.

Well npm does seem to have caught up on module availability. Though I just checked and the excel parser is actually just a wrapper around the Python library. Also these APIs are pretty skeletal and the documentation is almost non-existent.

Compare: (just picking the modules with high star ratings)
    http://search.cpan.org/~dougw/...
    https://www.npmjs.com/package/...

    http://search.cpan.org/~phred/...
    https://www.npmjs.com/package/...

Well npm does seem to have caught up on module availability. Though I just checked and the excel parser is actually just a wrapper around the Python library. Also these APIs are pretty skeletal and the documentation is almost non-existent.

Compare: (just picking the modules with high star ratings)
    http://search.cpan.org/~dougw/...
    https://www.npmjs.com/package/...

    http://search.cpan.org/~phred/...
    https://www.npmjs.com/package/...

The only thing they should fix in Perl is support for unicode filenames in Windows platforms.

In the past, I could work it around using the Win32::OLE (with CP_UTF8) and the host scripting interfaces.

But if I recall correctly, with Strawberry Perl, in couple of cases, I had no problems with the unicode file names.

Do you not know how to write reusable code and classes? What are you, a PERL dweeb?

... did you seriously just say that Perl programmers don't know how to write reusable code? Just save yourself the pain and give up on life now.

The thread support has been the same for a long time. I'm not fond of its model, but I can't say it's bad either.

I can't really work much with the very vague description of 'sucked' though.

Perl uses a different thread model than most programming language: variables are explicitly shared (everything is thread-local by default), rather than implicitly (everything is shared). The implicit model gives you concurrency problems (race conditions). The explicit model gives you high memory usage.

I hear that some new programming languages [citation needed] are designed with the explicit model, so it's likely a matter of opinion which one is better.

You can also use the CPAN module of forks. It's a drop-in module that gives you higher performance / lower memory usage at the cost of slower cross-thread communication.

I've not significant experience with Perl's threads (as I said, I'm not fond of them), so take of this what you will.

The perldelta mentions that there were a number of fixes/enhancements to floating point numbers handling implemented.

I'm not sure why the hex fp (a rather obscure feature) was singled out for the summary.

Other posters have already demolished the idea that banks will do this voluntarily or by edict.

The engineering approach is to not involve them. The Finance::Bank collection is the closest you're going to find to a workable solution.

Anybody who has money to spend on a government "solution" should send it to these developers instead.

That's just a stemmer.

Try this: http://search.cpan.org/~dconwa...

I was going to make a joke about a CPAN module for Esperanto, but lo and behold:
http://search.cpan.org/~patch/...

How does this differ from Smalltalk's Seaside? It, too, has coroutine-ish interaction with the client.

There's also a Perl module implementing the same sort of client-server discussion.

Actually there are already several programs and a bunch of libraries (ex: http://search.cpan.org/~lkundr...) that can handle the binary format. More are being written. The situation you are describing doesn't exist now and will rectify quickly.

Mod parent up --- Awesome!!

Reminds me of the Coy module and proves once again that Perl is the most bestest language ever.

What I personally would generally include would be a comment along the lines of "this struct represents the KillAllHumans message body as per " where the struct is defined, and then a comment along the lines of "overlay our message structure over the buffer to extract our data". This way even if someone wasn't familiar with the bitset notation, they could probably infer it.

I agree, comments are for the information you add, although well thought out variable names go a long way to making code understandable:

/* as per some specification */
struct KillAllHumans_Body {
...
}

I'll grant you that perl is very organic, probably the best "code as you think" language that I know of, but the vast collection of syntax and the functional density one can achieve (and some seem compelled to do so) makes it a pain to read if you didn't write it.

I am not disputing that it is easy to write obfuscated Perl but Perl style guidelines have come a very long way with Perl Best Practices by Damian Conway and the Perl::Critic module and the perlcritic program. There is a lot of Perl code written by other people that I find very easy to read. The key is to write clear code and use good variable and function names. The sigils provide context (and higher information density) which is what makes good Perl code easier to read than good Java or C code. YMMV.

Gregory Chaitin, one of the founders of algorithmic information theory once said in jest:

The LISP interpreter is about three-hundred lines of Mathematica code. Then I redid it in C, and it's a thousand lines of C, and the program is incomprehensible, which means that I'm a good C programmer!

Perl does tempt you to show off by writing incomprehensible (and perhaps incompressible) code. The style guidelines and experience can help you avoid this temptation.

IMO, the Camel Book is informationally dense. One reading was not nearly enough for me. I probably have read it all at least a half dozen times. I haven't used it in years because it is almost all on-line now and also part of the perldoc system.

[...] how do you iterate through an array of hashmap references [...]

for my $hash_ref in (@Array_of_hash_refs) {
... $hash_ref->{$key} ...
}

IMO, with descriptive variable names this construct is both easy and clear. I think it is beautiful. If you want to access just one element then use:

$Array_of_hash_refs[$index]->{$key}

For nested data structures like this I prefer to make the top level structure a reference so this becomes:

$Array_of_hash_refs->[$index]->{$key}

Which I think is a little more consistent.

I've taught Perl in college and I admit there are some (perhaps many) people who will never master it. OTOH, I once wrote a CSM system in Perl in the time the Java folks said they would need to come up with an estimate for how long it would take them to do it.

What I personally would generally include would be a comment along the lines of "this struct represents the KillAllHumans message body as per " where the struct is defined, and then a comment along the lines of "overlay our message structure over the buffer to extract our data". This way even if someone wasn't familiar with the bitset notation, they could probably infer it.

I agree, comments are for the information you add, although well thought out variable names go a long way to making code understandable:

/* as per some specification */
struct KillAllHumans_Body {
...
}

I'll grant you that perl is very organic, probably the best "code as you think" language that I know of, but the vast collection of syntax and the functional density one can achieve (and some seem compelled to do so) makes it a pain to read if you didn't write it.

I am not disputing that it is easy to write obfuscated Perl but Perl style guidelines have come a very long way with Perl Best Practices by Damian Conway and the Perl::Critic module and the perlcritic program. There is a lot of Perl code written by other people that I find very easy to read. The key is to write clear code and use good variable and function names. The sigils provide context (and higher information density) which is what makes good Perl code easier to read than good Java or C code. YMMV.

Gregory Chaitin, one of the founders of algorithmic information theory once said in jest:

The LISP interpreter is about three-hundred lines of Mathematica code. Then I redid it in C, and it's a thousand lines of C, and the program is incomprehensible, which means that I'm a good C programmer!

Perl does tempt you to show off by writing incomprehensible (and perhaps incompressible) code. The style guidelines and experience can help you avoid this temptation.

IMO, the Camel Book is informationally dense. One reading was not nearly enough for me. I probably have read it all at least a half dozen times. I haven't used it in years because it is almost all on-line now and also part of the perldoc system.

[...] how do you iterate through an array of hashmap references [...]

for my $hash_ref in (@Array_of_hash_refs) {
... $hash_ref->{$key} ...
}

IMO, with descriptive variable names this construct is both easy and clear. I think it is beautiful. If you want to access just one element then use:

$Array_of_hash_refs[$index]->{$key}

For nested data structures like this I prefer to make the top level structure a reference so this becomes:

$Array_of_hash_refs->[$index]->{$key}

Which I think is a little more consistent.

I've taught Perl in college and I admit there are some (perhaps many) people who will never master it. OTOH, I once wrote a CSM system in Perl in the time the Java folks said they would need to come up with an estimate for how long it would take them to do it.

For me one of the most annoyingly strange things about Perl is the post-if. (apparently the official name is "Statement Modifiers") You can do something like "statement if (condition); WHY? They just tend to make it harder to read the code flow.

Shrug. I oftentimes find it reads much better. if (expr) { statement; } requires silly braces.

I think the even more crazy part is that this language feature (and others, fwiw) can be disabled by code written in the same language. Yep, just include a few blocks of code, and the basic features of your programming language change.

That doesn't disable the construct. It's a Perl::Critic policy to make the Perl::Critic lint tool to warn on those constructs.
Also, Perl::Critic is moreorless an advertisement for Conway's book. I personally find many of its default policies stupid.

That's fairly unusual, but it's not quite as strange as Perl's $[, which you can assign to to select where arrays count from.

For me one of the most annoyingly strange things about Perl is the post-if. (apparently the official name is "Statement Modifiers") You can do something like "statement if (condition); WHY? They just tend to make it harder to read the code flow.

A lot of strange things in Perl have explanations in its origins, where it merges grep/sed/awk style with sh/ksh/bash style and C style, but I have no idea where post-if came from, unless it was just stunt programming. ("Hey, look at this, I put the if at the end of the statement!")

I think the even more crazy part is that this language feature (and others, fwiw) can be disabled by code written in the same language. Yep, just include a few blocks of code, and the basic features of your programming language change.

http://www.freedesktop.org/sof...
People are already starting on wrapping it: http://search.cpan.org/~lkundr...
so far writes log.

For Europe at least, you can get RIPE IP blocks from their web site or through their RIPEstat Text Service. I use it for one of my servers to get daily lists for one country, and feed it to ipset. Maybe others like ARIN etc. also publish lists? Or you can get GeoIP databases. Or you could try a (Perl) module like IP::Country?

just use English;!

More telling is how utterly fast Perl is compared to the other languages.

The test is ridiculous.

In any (Perl) program more complicated that helloworld (and in Perl terms that could be already pretty sophisticated piece of code) most of the time would be spent on calling functions.

All the test accomplishes, is testing how well Perl itself is implemented. And that we know already. (This test is basically biased against Java, or in fact, any language with immutable strings. Java just tops it off with slow IO.)

I use Perl still when doing scripting tasks. I love Perl, always have. I don't, however, necessarily think it's the right choice for building a medium to large web-based application any more. Sure the performance is there [...]

That's the problem: performance of Perl5 with any kind of largish framework would be pretty miserable because Perl's interpretation model is not designed to handle it.

Literally all interpreters decades ago went with p-code interpreters - and only Perl5 is still stuck with the traditional interpretation by (slightly optimized) syntax tree.

In my personal tests I have seen a clear dependency between performance and the size of optree: larger the optree, slower the code.

With any kind of sizable framework, the optree would be enormous. While bytecode allows for more aggressive optimization (inlining or IPO or profile based optimizations; after all, bytecode is just data), optree is very hard to modify (it is structured and inter- and intra-linked).

Those things are happening or planned except for the version number change.

Tweaks to make complex data structures less of a nightmare: http://search.cpan.org/dist/pe...

better integrate the object model: https://github.com/stevan/p5-m...

I've been building open-source classes for Forms, Datasheets, and Reports for many years now. Check out my stuff on CPAN: http://search.cpan.org/~dkasak... I primarily use Gtk+ and Perl. The libraries on CPAN use Gtk2, but I've got Gtk3 ports ready to release now. The amazing advantage to moving to Gtk3 for me is the 'broadway' HTML5 backend. Email me @ d.j.kasak.dk@gmail.com and I'd be happy to work with you on this.

I can solve a traveling salesman problem using Perl with not too many lines.

No you cannot for arbitrary N. You can only make an approximate solution.

But that's an important distinction to make. These solutions are demonstrating good library support. Not the syntax of the basic language itself. Are those libs even written in Wolfram?

I can solve a traveling salesman problem using Perl with not too many lines.

Here's a link to a module listed on cpan:

http://search.cpan.org/~mallen/Net-Amazon-EC2-0.23/lib/Net/Amazon/EC2.pm

Unless you know what you're doing and have a very good reason to use the modules under the Crypt namespace directly, you should generally be using Crypt::CBC with them, at least for most common purposes.

The actual Blowfish cryptography core of Crypt::Blowfish is written in C. You can verify this by downloading the tarball and looking at the source. There is a pure Perl version available as well, but it's slower.

The cores of Crypt::DES, Crypt::Rijndael, etc are also written in C.

Unless you know what you're doing and have a very good reason to use the modules under the Crypt namespace directly, you should generally be using Crypt::CBC with them, at least for most common purposes.

The actual Blowfish cryptography core of Crypt::Blowfish is written in C. You can verify this by downloading the tarball and looking at the source. There is a pure Perl version available as well, but it's slower.

The cores of Crypt::DES, Crypt::Rijndael, etc are also written in C.

I do most of my work in Perl, and I happen to heavily utilize Blowfish and Twofish. Perhaps you should think about what your application pipeline requirements actually need in terms of crypto and then look into the various modules that interoperate under the umbrella of Crypt::CBC.

In addition to my last reply, more astute readers might notice that the filenames for images served from screen.palegray.net might be cryptographic hashes. Indeed, they're Whirlpool hashes, which means in addition to the content being served over HTTPS, someone who really cared about verifying that the content hadn't been altered in transit could simply compare the Whirlpool hash of a downloaded file to its name. There's even a handy Perl Whirlpool module for such purposes.

Are you familiar with Inline::C? It lets you write Perl functions in C. The C code lives in the same file as the Perl code and is transparently compiled on an as-needed basis. Best of both worlds kind of thing. BTW, I write my image processing code the same as you: C for heavy lifting and Perl for all the rest.

reserving manual escaping for things like the right side of operator IN that would need a large, variable number of placeholders.

It can lead to the parameters getting out of order relative to the placeholders; the care needed to keep the order straight is close to the care needed to escape all dynamic arguments.

SQL::String

Oh, you were using PHP? Sucks to be you.

Boost has on the order of 100 libraries , each of which undergoes a peer review
CPAN allows anyone to upload their own code and has on the order of ~120,000 libraries.

Boost is a lot less like cpan and more like the development branch of the next standard library.

http://www.awaresystems.be/imaging/tiff/tifftags/privateifd/exif/datetimeoriginal.html

"For a digital still camera, this is the date and time the picture was taken or recorded. The format is "YYYY:MM:DD HH:MM:SS" with time shown in 24-hour format, and the date and time separated by one blank character (hex 20)."

Anyone who's travelled much has discovered this one - the timestamps on your camera are stuck in one timezone. No really, the standard *mandates* doing this wrong, resulting in pain and anguish for devs who have to deal with it:
http://search.cpan.org/~porridge/Image-EXIF-DateTime-Parser-1.2/lib/Image/EXIF/DateTime/Parser.pm

This date format was grandfathered into the first version of freedesktop.org's file metadata spec, but after some shouting in the feedback, it changed to using the saner ISO8601 format *with* timezone.

No oxymoron here. Perl frees you to create real messes, but that's mostly because it's very expressive, which also helps you code with less temp variables, shorter loops, etc., which can be actually easier to read if you know the language (Perl has a higher "cognitive load" than other languages that may alienate casual participants).

OTOH there are best-practices and style guides to ease things for the next lucky person to read your masterpiece (possibly a future you). So don't blame the language; hell, there's even a module that critiques your code.

So with some discipline and common programmer smarts you can write succint code that may be more readable than "fluffier" implementations. In practice, I've found that in any language, superfluous steps and variables, bad naming, and not-so-logical flow is a bigger penalty to readability than anything else. No language forces good style on you.

This is like saying "grep is useless because nobody's completely redesigned in in the last few months!"

You're not still using grep are you? I almost always use ack, myself. It is, of course, written in perl, and is up on CPAN.

(It sure is weird that a "stagnant" language like perl has so much stuff going up on CPAN all the time.)

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.

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.

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.

And then he should look at you and say, "You know, I bet I just duplicated a CPAN module."

Yup.

What I found in using Perl was that no two Perl programmers could read each others code.

That's silly. I'm just a medium-grade Perl jockey and I read and understand other projects' code. I find bugs and submit patches.

Perl doesn't force good style on you, but if you follow the guides of Perl Best Practices and check yourslelf with Perl Critic you're going to produce code that most programmers can follow.

Some people aren't comfortable with 'enough rope to hang yourself', which is fine. Others think that forced indentation is the answer to good code style (I think semantic analysis is better). There are lots of options.

That's why there's Mouse. And if that's still too large for you, there's Moo. And when even that's still to large, there's Mo

And you can select which one has the features you need, without the bits you don't care about ... but they've all got basically the same general API, so you can change it up as needed.