41–50 of 57 posts
Perl is also one of the fastest things out there - if your problem is doing lots of string handling. I have this little test that does a lot of string concatenation and garbage creation, which I recently pulled out of the closet to compare Javascript on Node and Javascript on Nashorn (and also native Java, since it was already there). Even on Java 8, Perl still blows it away. That said, I hate working with references…
I believe what's even more impressive in the Perl ecosystem is CPAN testers.
When you upload a module to CPAN, lots of neat things happen. Of particular interest is all of the testing that gets done. For example:
http://www.cpantesters.org/distro/M/Message-Inform.html
As you can see, that's a pretty wide swath of OS and Perl versions.
This is an example of a failure report: http://www.cpantesters.org/cpan/report/e93a7034-cf3f-11e5-96...
This is an powerful resource. I've had random people approach me with suggested fixes to test failures on CPAN in the past. It's amazing!
I believe the Perl community is serious about testing and reliability in ways that few others are. For example, the default module installation command ($ cpan or $ cpanm ) will NOT install if there are failures in any of the tests.
By modern standards, Perl5 has some silly characteristics, no doubt. But as others have said, the community is rock solid, and more lively than ever:
Earlier quoted context omitted.
I think the fastest way to convince yourself that Perl is obsolete is to try to hire for good Perl programmers. It's a fine language if you treat it well, but it's going the way of COBOL.
Perl programmer here of 17 years. I'm happy to look into new projects.
Earlier quoted context omitted.
In much the same way that PHP has a reputation for being "bad", Perl has a reputation (ill-deservedly!) for being line-noise, or obsolete. I've continued to be productive by writing applications, microservices, and websites in Perl. Though these days it seems few people care to hear about the details as it isn't the flavour of the day. Mojolicious is cool, although I've usually stuck with Dancer instead (which is its…
I think the fastest way to convince yourself that Perl is obsolete is to try to hire for good Perl programmers. It's a fine language if you treat it well, but it's going the way of COBOL.
Module growth is strong, and accelerating.
Not quite the hallmarks of something going the way of COBOL.
Note also that Fortran is also in heavy use in various science fields. Rumors of its impending death have also been greatly exaggerated.
This is one of the first articles that clearly and consistently lays out the actual concrete benefits of microservices instead of the cargo cult Medium drivel that usually plagues the ecosystem. (Of course, these are still only arguments for SOA and there's no clear differentiation between SOA and microservices, because there is none.)
The term SOA was poisoned by the baroque standards that spun up around it several years ago. There's nothing wrong with the concept of a service oriented architecture...but, when someone said SOA a few years ago, it usually meant something that was very "enterprisey", for lack of a better word (and enterprisey isn't a very good word, either). Big XML schemas, extremely complex APIs, etc. were the hallmarks of the fir…
Earlier quoted context omitted.
> what ORM to use (or not to use an ORM) do you have something to recommend ? used Rose::DB in the past, then I discovered SQLAlchemy and it's difficult to look back...
1 point by ashimema 0 minutes ago | edit | delete Love DBIx::Class.. but it's not a good/perfect fit for Mojolicious by a long way.. it's blocking by nature and thus doesn't play too nicely if your aiming to write a non-blocking mojo app. reply
I think my question is: Is there an SQL ORM in any language that is non-blocking during queries, without the programmer having to wrap it in some sort of promise/callback/whatever? I really have no idea about ORMs, so I don't know anything about the state of the art. I'm trying to imagine what such a creature would look like...it seems like if your queries are going to potentially make you wait for any amount of time, you'd need to account for that at the caller side, even if things happen on the ORM side.
Earlier quoted context omitted.
Yeah, some of the modules are great. But, I mentioned my current paint point, which is user accounts. There's a couple of half solutions on CPAN, but nothing comparable to accounts support available in Rails or Django, or almost any of the other "big" frameworks. Admittedly, Mojolicious isn't really trying to be that kind of framework, and that's great...but, this one is such a common task. It feels weird to have to…
Then why not put yours on CPAN?
Perl is also one of the fastest things out there - if your problem is doing lots of string handling. I have this little test that does a lot of string concatenation and garbage creation, which I recently pulled out of the closet to compare Javascript on Node and Javascript on Nashorn (and also native Java, since it was already there). Even on Java 8, Perl still blows it away. That said, I hate working with references…
Can you expand on what you've run into with references in the Perl debugger?
REFERENCE$HASH
Or something like that, it's been a while. I'm spoiled by the Javascript debuggers built into Chrome & Firefox, although I'm not sure about the Node.js debugger.
Is there a shell (either graphical, or "Borland Turbo Debugger for DOS" style) for perl -d ?
(even the "view locals" command in gdb for C presents data more quickly than the built in perl debugger)
Earlier quoted context omitted.
> what ORM to use (or not to use an ORM) do you have something to recommend ? used Rose::DB in the past, then I discovered SQLAlchemy and it's difficult to look back...
I'd need someone suggesting anything other than DBIx::Class to present some ironcast arguments for that choice
DBIx::Class
Kavorka / Function::Parameters / Method::Signatures (take your pick)
Moose / Moo (or use Moops and get Kavorka above built in!)
Mojolicious
Notable mention: Path::Tiny (and Try::Tiny, but everyone should know that one).
It's taken me awhile to find the happy medium where I'm not sticking too much in DBIC ResultSet methods, but being able to define complex search methods that chain is awesome:
my $rs = Schema->resultset("Foo")->unprocessed->rows(100)->order_by([-desc=>'time']);
$rs = $rs->for_user($user) if $user;
$rs = $rs->recent_entries; # Limit to the last week
Earlier quoted context omitted.
In much the same way that PHP has a reputation for being "bad", Perl has a reputation (ill-deservedly!) for being line-noise, or obsolete. I've continued to be productive by writing applications, microservices, and websites in Perl. Though these days it seems few people care to hear about the details as it isn't the flavour of the day. Mojolicious is cool, although I've usually stuck with Dancer instead (which is its…
I think the fastest way to convince yourself that Perl is obsolete is to try to hire for good Perl programmers. It's a fine language if you treat it well, but it's going the way of COBOL.