I don't care how un-sexy perl is by current standards. It's damn efficient, even for new projects. Also, it's not hard for a developper worth its salt to get productive in perl.
At the moment I'm playing with some threaded perl to parse very large text files - part of the code was developed by a C++/Java/js fan, who just realized it was the best tool for the job, and created that after a few days of playing with perl.
But is that really unique to Perl these days? It may have been true in the mid-1990s, but things have changed since then.
Python and Ruby both have a much cleaner syntax, yet still offer very comparable functionality, excellent portability, ample standard and third-party libraries, excellent documentation, supportive communities, great regex support, and basically everything else that Perl offers.
Since everything positive about Perl is also offered by alternative languages today, and those alternatives are themselves much better than Perl in some respects, Perl seems like a less and less enticing option each day.
>>It may have been true in the mid-1990s, but things have changed since then.
Hardly anything has changed. No language has taken scripting that seriously. You are likely confused between dynamic languages and scripting langauges. There is a big difference. If you haven't noticed, well then that's the whole point behind Perl. You really need to use it to see what it is.
>>Python and Ruby both have a much cleaner syntax
Its not about having a cleaner syntax. Making it easy to learn, only means the complexity is left to the programmer to handle now. Either way some one needs to handle the complexity, Its either the programmer or the language. If you make the language simpler, the complexity burden shifts to the programmer.
>>yet still offer very comparable functionality, excellent portability, ample standard and third-party libraries, excellent documentation, supportive communities, great regex support, and basically everything else that Perl offers.
Python takes great care to purposefully avoid offering every thing that Perl offers.
>>Since everything positive about Perl is also offered by alternative languages today, and those alternatives are themselves much better than Perl in some respects
You will have to substantiate that point with some evidence.
>>Perl seems like a less and less enticing option each day.
Perl is a great tool for scripting, but calling it "unmatched" is hard to justify. Knowing Python or Ruby well, you can be efficient scripting with them, and that's what scripting is all about, getting the job done fast.
Higher Order Perl is one of the best books I've read, but I feel that's much more about software development than scripting, teaching the fundamental techniques in functional programming.
Short answer: python is perl for bureaucrats and computer scientists. Ruby is perl for people who realised php is awful.
Perl fits the same niche as English does for natural language - used everywhere, easy to learn for simple cases,very tough to master. The way I like to say it is that while most programming languages help you think more like the computer, perl helps the computer think more like you do.
Those books look pretty general. Could you perhaps give just one or two examples which make Perl great specifically for scripting, to someone who does not know any Perl at all?
I was really just asking for a couple of short examples of scripts that demonstrate your point, based on Perl as it is now, not anything regarding its history.
"Scripting" is a pretty vague term. If you mean quickly writing one-off programs, then there are many languages that are just as good as Perl, if not significantly better.
It's pretty clear that Perl does not hold the prominence it once held in the 1990s. So, yes, it is clearly becoming a less-enticing option for a lot of people, whether you're willing to admit this or not.
It could be familiarity, but for small- to medium-scale "scripts", I still find Perl to be the best alternative to bash+sed+awk+grep thrown in, when I want to go to something more conventionally programming-ish. Basically its original use-case, before Modern Perl.
You can use Python for that, but the jump from Unix shell to Python feels bigger; everything is more verbose and less awk-y in Python. Which can be good for maintainability of bigger scripts, but feels heavyweight for some stuff.
Yeah, it's not just about shelling out, but about being able to write Perl that works sort of like an awk script, just with more of a real language attached to it. Functions that implicitly work on the current line, lightweight regex syntax, the <FILE> magic, bash-style file tests (-e/-r/-d/-f), etc.
Perl has reader macros and a meta-object protocol upon the object system is built with. Ruby and Python don't have either AFAIK. That is an example of what the OP is saying with Perl is an extensible language.
> Perl has reader macros and a meta-object protocol upon the object system is built with.
More specifically, Perl has advanced features with which meta-object protocols can be built with. See Class::MOP on which Moose is built.
> That is an example of what the OP is saying with Perl is an extensible language.
I think the difficulty with Ruby and Python is that both are fully object-oriented, which means it is difficult to create something that is truly orthogonal to the object model.
I generally use a graphical debugger in Eclipse. I have used Python and Perl, and can't see too much difference between them. Whats better about the Perl one?
Cleaner syntax than the declarative class mentioned in the article?
> Since everything positive about Perl is also offered by alternative languages today, and those alternatives are themselves much better than Perl in some respects, Perl seems like a less and less enticing option each day.
To my mind though the benefit is in mutability of the language. Yes, there are other languages in this category (rebol, red, lisp), Perl is somewhere between these and Python and Ruby. If I were to order them from most mutable to least, I would go lisp, rebol, red, perl, (python and ruby). This is a powerful thing and of course with great power comes the possibility of misuse.
Every time I try and write python or ruby I get an hour or so in and find that I'm writing 5x as much code as I would in Moo/Moose just to express the object design I want.
I've been known to say "perl5 is a lot like ruby except with usable OO" and it's very much a "ha ha only serious" sort of comment.
I used to sell software to very large corporations, and for enterprise-wide deployment. You won't sell them anything written in Perl, nor will you find them automating systems with it (there are domain specific languages for performing OAM&P on large numbers of systems.
If you want "no questions asked" in this environment, you need to pick Java ... and as of JavaEE6/7, it's a much more efficient language. Granted that it's not as dense as Perl, but it's also type-safe and with good conventions, readable.
If you're developing SaaS, use what you're most productive with (assuming you're not productive simply because you're creating crap). I've see people who can write in beautiful Perl, and I have no problem reading it. I've also seen people who write whole programs on one line just because they can ... and a couple months later, they can't read it either. Note that I've also seen bad Java, Python, etc programming.
True on the sales point. And it's getting harder and harder to find coders who want to spend all their time writing perl, as great as it is. That makes it tough for enterprises to maintain perl codebases.
Also, more CPAN libraries seem to be in a state of atrophy these days and I think the long-looming specter of perl 6 has had a depressing effect on that community.
The post talks about Moose, which is a behemoth with huge and varied dependencies and must be be tougher to maintain these days. Every time I've tried to write a project in Moose, I've regretted it in the long run.
However, I've written plenty of big, enterprise-class projects in perl instead of buying them from major vendors. Over the years, we were almost always able to beat the value proposition of Big Software precisely because we had a solid team of perl coders.
Don't underestimate the effect that the Perl 6 disaster has had on the reputation of Perl as a whole, even if Perl 6 is a rather different language in many ways, and generally promoted by a separate community.
Even if the Perl 5 community has generally admitted that Perl 6 was a failure and has moved on, a lot of people first think about how disastrous Perl 6 was well before they think about anything positive involving Perl 5.
> The spectre of perl6 stopped bothering us about 2006
From a practical usage standpoint, sure. But wouldn't you agree that an effective major version freeze has had a chilling effect on the progression of the language?
I'd argue it's had a deleterious effect to varying degrees, even since 2006. It's not enough for a community to be not bothered. They need to be energized, and it's tough to make the argument that the perl6 snafu has been helpful to the perl movement.
> CPAN uploads have been up every year since.
CPAN traffic was down over 10% last year, according to Alexa. In fact, many perl popularity metrics were down at least 10% in 2013. [0]
My experience, admittedly anecdotal, is that CPAN packages in general are not maintained with the same vigor as in years past. But why would they be, if people are moving their focus to other languages?
Regarding Moo, thanks - I'll definitely have a look.
2006 is when the energy around perl5 / new wave of cpan development became palpable to me.
Have a look at Task::Kensho - you'll find a fair chunk of the stuff mentioned in there originates from 2006-2009 or so (and has been actively developed since).
> My experience, admittedly anecdotal, is that CPAN packages in general are not maintained with the same vigor as in years past. But why would they be, if people are moving their focus to other languages?
That or the CPAN packages you've been using have been superceded but you've not found the replacement.
We're fairly terrible as a community at communicating when that happens.
If the OS is Windows, as it often is in these environments, C# seems to strike the best balance between safety, ease of recruitment, and flexibility. I have not used it in several years, but I still look back and miss awesome elements of the language like linq, the selection of super polished UI frameworks, Visual Studio, the ability to use dynamics when you needed to, the lack of drama in the community, and the ease of finding answers to obscure questions on SO. Of course, I left the platform for a lot of the same reasons, but in the context of being increasingly involved with OSS. That said, the positives still hold true for the enterprise space you are describing.
> Granted that it's not as dense as Perl, but it's also type-safe and with good conventions, readable.
The argument for Java is that there is a wide developer base, and lots of libraries. Perl, with appropriate frameworks, can be remarkably typesafe too (see Moose, etc). It's still loosely typed under the surface, but you have good error handling of invalid type syntaxes as long as you don't break encapsulation.
The big things I am looking at though are:
1. Maintenance and testing.
2. Readability
You can write unreadable crap in any language. What Perl excels at is allowing you to improve readability and maintenance/testing by building mini-dsl's in your framework which reduce testing footprints.
It's really hard to write unreadable crap in Java. Even if you do, there's automated refactoring to fix it. That's the thing about Java. It makes it really hard for clever bad programmers to do a lot of damage to a project. With Perl the sky's the limit.
People say the same about Python, but it is completely possible. Deeply nested hashes with no comments explaining the structure. Variable names such as 'Indexes' and 'indexes' in the same function. I have had to rewrite code like that.
As long as function and variable names are arbitrary, you can write code that appears to do one thing and does something else. Far more damage can be done that way than by straight obfuscation.
> Also, it's not hard for a developper worth its salt to get productive in perl.
Unfortunately, it's productivity gained at a very high cost, which becomes apparent once you try to debug and maintain that piece of software.
Sure, Moose and other modern helpers will fix that to some extent, sometimes with other tradeoffs (performance). But the "malleability" of Perl feels silly at some point where you get a bloated, slow and lacking simulation of a type-safe language when you could use a much faster modern language with real static type checks and great maintainability (like Go) instead.
> Unfortunately, it's productivity gained at a very high cost, which becomes apparent once you try to debug and maintain that piece of software.
You can write untestable, unmaintainable software in any language. I will agree with you that the default scoping of variables has some real costs in terms of maintenance and debugging that are not initially apparent to too many programmers though.
> Sure, Moose and other modern helpers will fix that to some extent, sometimes with other tradeoffs (performance).
Moose has performance impacts. If you want something less heavy, use Moo, or Role::Tiny. These offer fewer features and better performance. Also as I recently learned, lexically scoped variables are faster, so use strict can in fact sometimes flag possible performance improvements there.
> But the "malleability" of Perl feels silly at some point where you get a bloated, slow and lacking simulation of a type-safe language when you could use a much faster modern language with real static type checks and great maintainability (like Go) instead.
To be honest, the other languages I really like in this regard are red and rebol, which are, if anything, more malleable. The malleability is important because, done properly, it allows:
You need coding standards for all languages. Most (afaik) Perl shops use Conway's "Perl Best Practices" with some local changes. Go read "Modern Perl" etc. Are you not aware of those developments? PBP isn't exactly new.
I don't think there are references of these problems while following good practices? Considering all the trolls which show up when Perl is mentioned, I ought to have seen such a link a long time ago...
But sure, we could assume without support (I don't know) that using Perl forces you to read a few more pages of coding standards. That is, as percentage of work time over a long project, not a problem.
>> [Go preaching]
Today, I don't see much practical difference among the usual scripting languages (they tend to port the successful stuff from each others). Also their niches are partly different compared to the niches for Go. So there is no need to preach.
One big advantage with Perl is that I am not often embarrassed by fan boys and/or language war fanatics, as you find in some other environments...
What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them? Why would you use a language if you don't agree that the designers did a good job? That's like going to a burger joint and ordering a salad. Only someone hell-bent on maintaining an emotional connection to a worn-out old programming language, would even consider that.
I've never seen a project that could enforce its coding standards in every case. Things always slipped through. Turns out, machines are much better at enforcing arbitrary coding standards than humans. Maybe we should let the machines do the machines' job, and the humans do the humans' job.
Perl has all the problems of an old language. No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object." References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references). All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not.
Just about the only thing Perl did right was regular expressions. That, and avoiding the version hell that Python got itself into.
Perl was fun in the early 90s, but it's time to let go. Only a masochist would use it today. Only a sadist would recommend it to newcomers.
What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them?
Because the real world comes with edge cases. Just because 99 times out of 100 you're better off with the agreed upon standard, doesn't mean that other way doesn't have it's distinct time and place that it can shine, and clearer, cleaner and or faster. I would much rather be constrained by convention than by capability.
no single object framework
No, but the reason for that's been a good one historically (experiment and see what comes out on top). That ended up being Moose and it's ilk (Moo, Mouse). I can't think of a single case I've heard about where people used something else and it wasn't driven by some external factor.
References are confusing and unnecessary
I've always liked references. It seems to make clear exactly what's going on. Maybe it's just me.
Only a masochist would use it today. Only a sadist would recommend it to newcomers.
You should have started your comment with this. Then I could have stopped reading there. Are you here to participate in an informed and enlightened discussion or to show everyone how brilliant you are for not liking something?
> References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references).
Perl references combined with its nested list semantics make it extremely convenient to flatten arrays and hashes when you need to. Doing the equivalent in Python and Ruby is verbose and ugly by comparison. I know in Ruby you can get it down to one line, but it lacks the cleanliness of Perl (if you can believe that).
> What's the point of programming in a language that has 100 ways to do something, and then banning all but 99 of them?
Two points in this. You might not want to ban all 99 in all cases. For example, you may want to do things one way in one aspect of a project and a different way in a different aspect.
This sounds dangerous (and power is dangerous), but done right it allows teams to focus on doing things right with the right interfaces between them.
For example, it's one thing to contribute to Moo, Moose, and PGObject in one way, but have a different coding convention internally for the programs which use these libraries. This is where those other 99 ways really come to be powerful.
> Why would you use a language if you don't agree that the designers did a good job?
I like the design of Perl 5. However, it took a lot to get to the point where I saw the beauty in it, and saw how to use the power properly.
In a larger project however, that's not so much of a problem. Once you get the core code started, people can grow within it. Different levels of the project may handle things differently, and that's fine. People can branch out over time.
> I've never seen a project that could enforce its coding standards in every case.
And sometimes the responsible decision is to let the coding standards violation occur and plan to fix it later. There are times I have done that and regretted it, only to later realize it was a net positive anyway.
> Maybe we should let the machines do the machines' job, and the humans do the humans' job.
Absolutely. Now to tell which is which.
> Perl has all the problems of an old language.
Evidently every 5 years or so we need to all jump on the bandwagon to a new language?
> No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object."
There are lots of object structures but you probably shouldn't list Role::Tiny there. The basic point there is you have Moose, of which Mouse was an attempt to make it smaller for performance sensitive applications (now largely superceded by Moo). Role::Tiny is an attempt at a minimalist piece of Moose aimed at specific applications. Moo/Moose/Role::Tiny are best thought of as aspects of a single object system rather than separate ones. In fact Moo and Role::Tiny were authored by the same individual.
The Perl world has largely gone to Moose and friends. Pretty much everyone that uses anything else does so for legacy reasons or external constraints IME.
> References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references).
And yet I have been bitten by the lack of such a distinction in Python.
> All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not.
Meh, my test cases in any language use up more code than my production code anyway. There is no substitute for clear code contracts.
parsing text files is literally the only thing Perl is the best tool for. Of course, every single person who needs to update it would have a 20 hour RTFM session before they could do so. (fairly conservative; this is 3 hours per day for 7 days from a standing start to maintaining Perl.) Perl has a ton of context, and that context is really hard to learn (just try writing a Perl parser/interpreter), and it applies best to text files and configuration scripts from 1987-1997.
I am not saying it's not an appropriate tool for anything else. But as a tool to be learnt, it wouldn't be the 'best' tool for a new person to learn from scratch.
> parsing text files is literally the only thing Perl is the best tool for
To be honest, Ruby has built-in regexps also and Rebol has built in recursive descent parsing (and has no regexp support at all). So I disagree with you on two counts, the first is that Perl is the best tool always for parsing text files. To some extent it depends on what you are doing.
What I do think that Perl is really good at is building frameworks and the reason here is that what you can do (and what I highlighted in the article) is create mini-dsl's for common tasks which can then be seamlessly worked into the general purpose programming environment. Lisp can do this too, as can Rebol, but these each have other tradeoffs (I found the Lisp learning curve to be rather steep, Rebol 2 is not open source, Rebol 3, though open source, is still in alpha, and has no Linux GUI support yet).
> But as a tool to be learnt, it wouldn't be the 'best' tool for a new person to learn from scratch.
I don't know that there is a best tool for a new person to learn from scratch. One should generally apply tools I think with an intent of doing something with them. IMO, Perl excels at very big projects and very small projects. It's in the middle that things get less than ideal.
Yes that's correct. Atronix efforts have been towards producing 64-bit versions + the Linux GUI from the Saphiron code base (which was 32-bit and Windows GUI).
I believe you can consider this as the official build for Rebol3 View/GUI because Saphiron took over the RebGUI/R3-GUI project from Rebol Technologies.
But yes some of the Rebol 3 Core stuff that Saphiron/Altronix have done do need merging back into main open source core [1], which itself as moved on from the Saphir codebase (Saphiron Rebol build) [2].
The best I've come up with so far searching for information on MOPs (of the explicit, controllable sort) in those languages is sort-of/almost for Ruby and no for Python. Is there some other name they go by in those languages that I should be aware of?
* Some of the best languages for producing an internal DSL (dialects) don't have a "native MOP". For eg. Lisp, Rebol or Forth.
* Python & Ruby don't have native MOP's anyway :)
NB. I wonder what you mean by "native MOP" is baked-in OO? Python & Ruby OO systems do come with MOP like abilities. However for full blown (metacircular) MOP (http://en.wikipedia.org/wiki/Metaobject#Metaobject_protocol) you need to look at things like CLOS & Perl's Moose/Class::MOP.
By "native MOP" I really mean things like Python's metaclasses and descriptors (and whatever Ruby's equivalents are called), as opposed to an add-on library to simulate them like Moose.
A bit of apple & oranges going on here because you don't need Moose (or more precisely Class::MOP) to simulate Python metaclasses and descriptors. Because you could, if you so wished, build a Python metaclasse/descriptor based OO system in Perl's native OO.
To clarify things:
* Python comes with a pre-defined OO system with metaclasses/descriptors for dynamically building new Python classes/objects.
* Perl comes with OO lego blocks from which you build you own OO system.
* Class::MOP is a metacircular MOP mainly written in Perl using these lego blocks (it's turtles all the way down).
* A MOP (like Class::MOP) provide an API for building & managing extendable OO systems.
* Moose is an advanced OO system built on Class::MOP.
* Moose provides features like Roles, Method Modifiers, lazy attributes and many more.
There have been two attempts, that I know of, to bring (a subset of) Moose to Python:
> Don't languages with native MOPs, such as Python and Ruby, create better internal DSLs than Perl?
Why would you say that?
It seems to me that a DSL's function is at least reasonably decoupled from the method it uses behind the scenes, and that there is no real difference between a native MOP (like that in CLOS -- I don't really see an equivalent in Python or Ruby) and a non-native one like Class::MOP in Perl in this regard.
It helps you strip out code that isn't related to the DSL. For example, the mechanisms of class definitions in things like MongoEngine or Django's ORM. You end up with something that looks a lot more declarative.
the additional context involved with knowing Perl isn't enough IMHO to learn Perl just to parse text. I would do that with a 'more popular' language and its regex library, especially for new users.
Careful though. There's a lot of parsing that folks want to use regexps for that don't do that well.
Why Perl really shines for text file parsing is that you have a fairly large set of tools as appropriate, which fall into largely three categories:
1. regexps (great for some things, lousy for others. DO NOT use these for parsing HTML)
2. Recursive descent parsers. You could write an HTML parser in one of these if you need to.
3. Dedicated format parsers (CSV, XML, JSON, etc).
It's the combination of the three that makes Perl a very good tool for parsing text files. One thing going for Perl is a strong community of people who can help point people to the right tool for the right job.
For example, I am in the process of writing a library to do PostgreSQL tuple parsing and serialization. It is sort of like Text::CSV with some differences. In this case, regexps are the right tool. But if I was writing something else, I would probably go with recursive descent.
Anyway, Perl referencing an deferencing syntax is a mess. I regret any time I start a new program on it, as it always lead to a long debugging session where I remove all the parse errors. I use no other language with a syntax as complex (and can't really remember of any).
Hmmm. so it always takes you a long time to debug a language that you clearly don't actually know?
What a terrible language!
I don't know Python very well. I've worked on some python code but every time I do I have go read the manual for the most basic stuff (what does an "if" statement look like in Python, again?). But I wouldn't ever dare to blame Python for the fact that I don't actually know it!
> Anyway, Perl referencing an deferencing syntax is a mess.
It's not too bad. It is amusing however to see someone with twelve years of experience doing something like: somefunc(\%$someobject); Um, wtf?
I personally found the reference/dereference syntax close enough to C's I had no trouble with it but far enough away I didn't get references and pointers confused.
I've used Perl extensively inside the BBC, Credit Suisse First Boston and a few other big corps. Also was a dev on a global warehouse management system written in Perl. But saying your startup is using Perl is not going to get you funded or laid anymore (and I miss grunge too) so there's not much love for it in Valley/Incubator circles.
These days I'll drop into coding in Perl for the regex syntax and backticks. But the reality is there's not much difference between it and PHP in terms of features. Used to be that it was better than Ruby because of performance and stability but they're about par now. So I don't think there's much point in evangelism or debate about Ruby vs Perl vs PHP or even Java anymore because they all get the job done in pretty much the same way. From a practical PoV I'm more interested in languages that actually do something well that other languages suck at e.g. node. I wrote a FSM/Long Polling web server implementation in Perl using epoll() before Node came along and now I love node more than most (and still wear the scars from a particularly tough hashref autovivification bug).
> and still wear the scars from a particularly tough hashref autovivification bug
As an infrequent perl programmer[1], I'm curious about the bug. Googling tells me that perl if($foo->{bar}) will always pass, which is pretty goofy to me. Was it something like that?
[1] Well really, a bad perl programmer. I've occasional had to make minor edits to legacy perl. I don't write perl. And, as the mistake in this post shows, that's probably a good thing :)
No, it's a combination of allowing hash refs to be automatically created on access or assignment for complex data structures where it's implied.
# False, key doesn't exist, doesn't print and doesn't create anything at that key location
my $h;
say "foo" if $h->{foo};
# Creates an empty hash ref at $h->{foo}, so $h->{foo} now evaluates to true in boolean context.
$h->{foo}{bar}
# True, prints "foo";
say "foo" if $h->{foo}
# creates empty hash refs at bar and baz.
say "what does this do?" if $h->{foo}{bar}{baz}{quux};
Works with array refs as well.
Personally, I find once you understand it, it's fairly easy to guard against (even if it requires more code. e.g. say "foo" if $h->{foo} and $h->{foo}{bar}; # Assuming we know $h is a hash ref already.
I almost got a patch pushed through to Perl to add a new operator that would help that problem (and the similar problem of nested objects who might be undef). Someday I'll have to dust it off and try again.
Yes, you auto create variables in a hash when you reference then, so autovivification is just a fancy word meaning automatically declaring and setting a null value. So $myvar->{speling} would create that in a hashref silently. Creates horrible hard to find bugs.
One of the things that's always impressed me the most about Perl is the degree to which modules can play with the language. Modules can add control structures (Try::Tiny), introduce new metaprogramming syntax (Moose), add operator overloading (overload)... it's very flexible.
> One of the things that's always impressed me the most about Perl is the degree to which modules can play with the language.
That's exactly the point of the article, btw.
> Modules can add control structures (Try::Tiny), introduce new metaprogramming syntax (Moose), add operator overloading (overload)... it's very flexible.
Technically they add functions, and the language allows you to use imported functions as control structures. This isn't so much to correct you as to clarify it for less familiar readers.
Basically to describe the relation between perl and PHP, take all the good things out of perl 5.005 and you're left with PHP. Perl's internals to my knowledge are insane in a mad genius kind of a way. I would imagine that PHPs internals are pathalogical in a 'tramp smelling of urine' kind of way.
Perl, above all, is an incredible cluster of experiments in language design, and a work of art.
Despite that, it's also a relatively practical and reasonably popular language (else it would end up among esoteric languages).
The very richness, intricate ornamentality, flamboyant conceptual exuberance and non-orthogonality that make it an art object also make it unsiutable [for me] for real development. I like my tools compact and precise.
Interesting. I like my use of those tools to compact and precise, which is why I value Perl. I find the expressiveness lets me convey the meaning of the code with a minimum of boilerplate.
In Canada, you have to be an accredited professional to use the word Engineer in your title. This means being a member of a specific association, meeting professional standards in your work and qualifications. This is enforced in part by a trademark on the word "engineer".
In the U.S., there is no such requirement. Anyone can "be an engineer". Now that I work in the US, I call myself a software engineer or a software developer or a programmer, as interchangeable terms.
If there is an actual distinction here I would really like to know it. I also wonder how much these terms may have different meanings in other countries/regions.
I actually have a strong opinion about the distinction between "software engineer" (someone who has a real computer science background and a disciplined approach), and "developer" (someone who knows a bit of Javascript/Ruby/etc). Developers don't know the difference, because they don't know what they don't know.
It's fine to have a strong opinion about those two types of people -- I have an opinion about it, too -- but the words aren't used consistently which is the lame joke I was making that you totally missed.
Bah. I learned Perl with Perl 4, which was a lovely little regularization of sed, awk, sh, and unix system calls. Absolutely fantastic, loved the heck out of it.
It was `man perl4` that gave me one of the best fair warnings I ever encountered in a software product: "Generally [these features] work as you'd expect, unless you expect consistency".
It helped me enormously in understanding the philosophy behind Perl.
I don't know why this guy thinks it's a good idea to create his own idioms and language features which inhibit the ability to understand the code by pretty much anybody else.
> I don't know why this guy thinks it's a good idea to create his own idioms and language features which inhibit the ability to understand the code by pretty much anybody else.
First, there are two ways to read that last example:
1. Literally as Perl code: has() and dbmethod() are functions. There is no difference between
has id => (is => 'ro', isa => 'Int');
and
has(id => (is => 'ro', isa => 'Int'));
If that doesn't occur to you, you have no Perl experience ;-).
2. as language extensions: has and dbmethod define new aspects to the class in a declarative way.
The thing is, these are both simultaneously true, and that means you can read them as #2 when coding and fall back to #1 when debugging.
Since they are simultaneously true, there's no difference between writing new functions and what we do here, except that this allows (and does not require) one to think about the code in additional ways.
As a note, exactly what people I know like about working with Lisp on large projects is the mutability and the ability to create very useful and readable idioms for the project.
That wasn't his own language features, he used Moose in the last example, it is the standard OO environment in Perl. To simplify a little, most new Perl code use Moose.
The author did discuss a bit how Perl is extendable, which is where Moose comes from.
To be clear, I am also the author of the PGObject::Util::DBMethod which adds the dbmethod() syntactic sugar used in the third class.
One thing to note is that this was done specifically in the way it was so that it would fit in with Moose-like idioms, so it is more a matter of extending the Moo(se) way than it is creating a whole new idiom.
"The .. point is that Perl 5 gives you a way to build .. (DSL's) that can be seemlessly worked into a general purpose programming environment."
"Perl is a language many people love to hate. Here's an example .. of sloppy coding"
"It is very hard to modify safely."
"it is possible to do this sort of thing in any language."
"Let's try this newer Perl code"
"This .. is easier to maintain, and is easier to understand."
"The above two examples ..neither one really shows what Perl is capable of doing"
"Perl itself is a highly malleable language and .. allows you to define domain-specific languages for parts of your program"
"Here's a small class for handling currency records."
"Now the code above .. is effectively entirely declarative."
"What differentiates the examples .. is .. readability, testability, and maintainability."
"How does that work?"
"Perl is a very flexible .. you can add functions that behave .. like keywords."
"The example here uses two modules which provide DSL's for specific purposes."
"The first is Moose"
"The second is PGObject::Util:DBmethod"
"Why is this Powerful and Productive?"
"Compare a framework built as a mini-DSL specification language to one built as an object model."
"In an object model framework one .. has to juggle object-oriented design .. with the desire for greater flexibility."
"DSL's .. allow you to define the object model orthogonally to the framework"
"Other Similarly Powerful Languages"
"Lisp"
"Rebol and Red,.. implementations are still very immature"
"Metaprogramming helps to some extent..in Ruby and Python .. but .. makes it much harder to build a framework that is truly orthogonal to the object model."
" Perl isn't just a programming language, but a toolkit for building programming languages inside it. "
The full statement from the article was - Rebol and Red, whose open source implementations are still very immature
To clarify this…
1) Rebol 2 is a very mature product. But while free to download & use it remains closed source with no long term future.
2) Rebol 3 is an alpha/beta opensource rewrite of Rebol 2. While Rebol 3 isn't has mature as Rebol 2, it is robust and does run about 2 times faster than Rebol 2 and with other significant design & implementation improvements. However it is incomplete and missing some Rebol 2 features.
3) Red could be viewed as "very immature" because the implementation was only started in 2011. However it is looking very promising and I believe the aim is to get to version 1.0 by end of this year.
Check out http://mojolicio.us/ for a more modern take on web dev in Perl -- the most common deployment is a nginx reverse proxy in front of the built-in (non-blocking and preforking) web server -- just like suggested setups in node/python/ruby/etc.
One cool bonus that mojo provides is hot deployments, so there's no need to restart the server process to get new code.
I run LedgerSMB over fcgi. Plack and Mojolicious are both good frameworks for that (I use Plack).
One of the neat things you can actually do in this environment (we do this for old code we inherited from SQL-Ledger due to scoping issues) is preload dependencies, then when a request comes in, fork, execute, and die. This allows you to fairly easily run fcgi-unsafe code in a fcgi environment caching what you can safely cache and disregarding the rest.
This can be a big deal for improving performance of legacy cgi code.
At the moment I'm playing with some threaded perl to parse very large text files - part of the code was developed by a C++/Java/js fan, who just realized it was the best tool for the job, and created that after a few days of playing with perl.