Most of the horror stories that you'll hear about perl are from people who have tried to fix/maintain code that was written badly, which is no different from any other language. You can write horrific or easily-readable code in any language.
Perhaps perl has its reputation because it is often used as a quick kludge to do something that would be just too painful to do in shell script, and novice writers just cut & paste stuff from their searches online to get the job done?
I recall a great talk a couple years ago at OSCON that Damian Conway gave about how you could essentially turn Perl into a custom language that exactly fit your needs. I walked out of there thinking "wow! That is incredibly awesome, and yet I would never consider it for a business environment." Perl is an appealing language for people who like languages. I count myself as one of those. But I cannot deny that Python makes so much more sense for teams of more than one person.
At that point the difference is just syntax.
function myFunc () {
var myFunc2 = function () {};
return myFunc3().then(myFunc2);
}
> At that point the difference is just syntax.
Isn't that the case with most things? If I said that I missed curly braces, that's "just syntax" too.
You're right that almost all dynamic languages have this feature, but to give you two notable languages that don't: C doesn't allow defining inner functions. Pascal allows to define inner functions, but doesn't allow you to return them. C++ does allow you to define inner functions (actually functor classes) and allows you to return them, but you need to be explicit about the capturing process.
It is less frustrating for me than the fact that the scoping rules for a var in JavaScript mean that you're likely to scope to the nearest function call rather than loop. Despite having anonymous functions, doing what I would want to do with them in JavaScript is often much harder than doing it in Python.
>This isn't some Python-specific thing.
I think btilly meant that by the ability to do in Python what he described (define a nested function and then return it), you get (almost) all the same features as anonymous functions (and specifically, more than Python's lambdas give you, because they can only contain an expression, not statements) - in response to what you said:
>Python just has lambda functions which can only evaluate an expression.
In fact, IIRC, Guido (van Rossum, Python creator) has been known to say, to people who complain about the limitations of lambda in Python, to just use nested functions. And BTW they are quite powerful so you can do a lot with them.
He (btilly) was not implying that other languages cannot have nested function declarations (if I understood his comment right).
I'm not saying that they aren't powerful. I'm saying that personally, I find declaring one-time-use functions in-line to be syntactically more pleasant / organized than sticking the function definition in the middle of functional code.
I'm not a newbie to Python, but after working with it for years, it's one of those things that I still wish existed. It's not necessarily a pain point or deal breaker or anything. I'm not even sure how it could work given Python's syntax.
Ok, I get what you mean now, and think you have a point there.
It's a tool that can be abused. Saying that the number of tools available should be limited so that they can't be abused seems counter-productive.
See static typing, golang, and functional languages.
Why does it have something called 'say' instead of something more intuitive like 'println'. Then there are worse examples: carp, cluck, croak. These are commonly used. They are from the same module of course. There is also Moo, Moose. I'm not sure but was there something called 'Mo' too? Commonly used of course but as you can see from the names - you can't tell what they are for.
So, I think from some of the choices made in how the language is, it ended up being more drawn towards unreadability than readability by attracting a kind of mindset that wanted it to be 'fun' in a way that only a clique could relate to and now if the language doesn't have broad appeal, I think it shouldn't be that hard for them to accept that fact.
In fact Moose, Catalyst, Starman, etc were all projects specifically named more fun _becasue_ their authors saw other communities not naming things "DBIx::Class" or "ExtUtils::MakeMaker" and wanted to bring some of that fun to Perl.
'say' is a lot more intuitive than 'println' for me. In the former case, I'm telling my program to say something. In the latter case, I'm telling it to... print? What if I don't have a printer? And what's a 'ln'? Line? Loan? Loon?
In other words, 'println' is not "intuitive". The word you're looking for is "conventional" or "familiar", and it's only either or both of those things if the programmer is coming from a different language.
Perl was the first programming language that really "clicked" for me, though, so I'm probably a bit biased there.
(as a side note, Perl has a 'print' as well, which actually predates 'say' by a considerable amount ('say' only became a thing in, what, Perl 5.10?). 'say' is pretty much just 'sub say { print "$_[0]\n"; }'.)
"Then there are worse examples: carp, cluck, croak."
'carp' and 'cluck' are weird, yeah. 'croak', however, makes sense in the context of 'die'.
"There is also Moo, Moose."
Both of which feature the letters "oo", which usually stands for "object-oriented". Not as obvious as I'd personally like, but once you spot that it becomes clear that both have at least something to do with Perl5's object system.
But yeah. Perl 5's flavor of object-orientation is remarkable for exposing the inner workings of objects to the programmer. Fields are just hash table items. Methods are just subs that take the object as the first parameter. Classes are just namespaces/modules full of methods and constructors. Constructors are just ordinary subs that return blessed data structures.
It's all remarkably simple and elegant once you're used to it.
"Say" is a common English verb that fairly directly communicates the action performed (with a bit of metaphor, sure.)
"Println" is, well it starts out with something which might be as good as "say" and then has some extra opaque consonants glued on the end.
The latter is only "more intuitive" from the perspective of someone whose used languages which happen to use it in the past.
Why is the Unix command `ls` not `list-directory-contents`? Sure, it's a lot more for everyone to type all the time, but you could get rid of a single line in the man page, meaning the name is much, much more intuitive!
I'm not a Perl expert, but have read books on it and done a bit with it. I think Perl tends to attract the kind of people who find these kinds of names (and many other things) fun, and are not put off by it - which is fine.
>worse examples
According to who(m)? Opinions differ.
All of those other languages "just work" too. I'm not really sure what you're getting at with this comment.
I worked with Perl 5.x in for 4 years a while ago. It's not as bad as people really think it is. That said, there are a lot of things that can cause you to go wrong. For example: source filters. Super powerful, but if implemented wrong can make debugging a nightmare.
Whenever I think of something that has anything to do with batch data munging, there is usually half a dozen Perl modules that already do it. I have no opinion about Perl as a language but I like how rich the ecosystems is for that sort of project.
CPAN was way ahead of the competition - it was elegant where other languages would require you to manually download dependencies archives and wrangle them like a barbarian.
This is a really nice alternative to CI services and it makes sure that your stuff works in other environments than your standard Ubuntu LTS systems.
It's pretty much crowd funded CI and I am pretty sure that a lot of people who don't have the most common system would love to run it.
What's cool about this is that you see problems on both the platform and the library side, that one wouldn't expect.
Something similar, also from ages ago, but an anecdote I like to tell is that I used to have access to a hppa64 (64 bit PA-RISC) system and while I didn't really have use for it I as a fun project installed OpenBSD on it and ran some test suites there. Despite OpenBSD/hppa64 15 years or so ago being an alpha release Rakudo (aka Perl 6) actually compiled and was able to run its test suite. In the end this found a bug in math.floor or something like this.
The point is that something like that tends to have unexpected benefits for both sides. It's like when someone decides to compile a project using a less common C compiler. That pretty often leads to people finding bugs in the given software, because of errors or warnings emitted by that compiler. Similar things happen with different architectures, etc. So in the end cross platform software ends up way more reliable. Something that I think some projects focusing on only one OS or even just one or very few distros really miss out.
Of course reducing your project to work on just one platform might safe you some time somewhere, but often it's a bit like saying not writing tests safes some time. And usually it's really little or no effort, which results in a lot more feedback and quality code contributions (people that port a lot of software tend to be pretty good programmers).
Except for any other language than english.
I have mental images of driving a wildly overpowered monster truck with no brake lines over a minefield. And then I start to consider the implications of passing the /i flag in...
Will your regex match correctly in the case that the text shifts direction halfway through? Will the case insensitive search work in languages where case is ambiguous (where uc(lc(x)) != x)? Will you be able to match letters that are effectively identical but on different code points? Do you want to? Will it get confused by furigana?
Unicode's goal of encoding every language in the world as is means it encompasses every bizarre thing people have ever done to a written language. It is almost impossible to actually do anything with a block of unicode codepoints except treat it like a big binary blob and hope that you never have to personally deal with the strings contained therein. Most everybody gets it wrong in one way or another.
If you mean at "parsing text", for which regexes are a tool, I don't think many other languages have caught up with Perl, which had (with Perl 6) gone beyond regexes to grammars.
But, even ignoring that, I think plenty of languages have regex engines less powerful than Perl's, and poorer ergonomics for using regexes in the language independent of regex engine quality so even on regexes as such Perl has an advantage.
(I'm sure there must be other languages with dedicated regex syntax, but I'm not aware of any.)
/foo\sbar/i;
new RegExp('foo\\sbar', 'i'); $str =~ m{/some/path/\w+}
/\/some\/path\/\w+/
Regexp("/some/path/\\w+")So, you've never seen Ruby?
I don't know why Perl 1 to Perl 4 had messed up Regular Expression. Perl 5 actually redeemed themselves and returned to the normal good old regular expressions.
> Regexes in Perl are not he same as in Python, Ruby, or PHP, even if some of them call them "Perl 5 compatible Regular Expressions". https://perlmaven.com/introduction-to-regexes-in-perl
I would say the older Perl messed with RegEx and I wish everyone else would get on board. I HATED!!!!! doing my awk regex and then jumping into Perl it wouldn't work.
Compare it to the "non-community" professional effort https://github.com/perl11/cperl/releases/tag/cperl-5.26.0 http://perl11.org/cperl/perl5260cdelta.html
regular expressions are much better with pcre2, which almost work (50% faster) with https://metacpan.org/pod/re::engine::PCRE2
I didn't only disagree with some patches, I disagree with most of the feature decisions, management and bugfix handling. And esp. with their negative track record. perl5 deserves a properly managed project and the perl6 features, so I did it. At an important time, with :const, types and signatures upcoming. And perl5 should not be used in public services due to its lack of security (I am warning against it since 5.16), not talking about the feature mishandling.
See the perl11 blog.
Some numbers: In the last 2 years, p5p produced 12005 commits (2 releases), whilst I produced 6291 commits. That's >30%. The 2nd most prolific author did 3104 (unicode), the third 1689. And I squash commits into features and bugfixes and don't spread it out over 3-5 postfixes, because cperl works in branches, not posting directly to master. Of those 6291 commits you have nothing in perl5, but they continue to play stupid and take nothing. Features wise and security fixes it's more like 1000%, not 30%.
That seems like an awfully bold claim.
cperl is great, don't get me wrong, but if I'm going to move away from Perl 5 to a different Perl I'd rather just move to Perl 6 (and, in fact, I already have for some of my latest pet projects; so far, I've been very impressed).
cperl is a not a different perl, it's a perl5 replacement, which is faster, more secure, less bugs and more features. types and using a modern perl is optional. 90% of the vm and toolchain is unmaintained by p5p, and taken over by cperl.
Perl was never intended to be fast for computers. It was intended to be fast for programmers. Perl 6 does a pretty darn good job of that, and additionally already has working and easy-to-use C/C++-compatible FFI that I can use today to offload things that really do require maximum computational performance (that latter point wasn't true for cperl last I checked; "extern sub ..." is still a "todo" item AFAICT, and I don't really see an equivalent to Perl 6's "is repr(CPointer)").
"and unusable for professional usage."
By what measure? More importantly, by what measure in which cperl fares any better?
"more features"
Not at all the impression I'm getting from perl11.org/cperl in relation to Perl 6. What you're saying is certainly true in relation to Perl 5, though.
Of course cperl is lacking compared to perl6 features, user facing. Because I had to fight first p5p sloth, like broken designs for everything. cow, const, threads, attributes, regex, scalar, arrays, hashes, functions, types, lecical $_, objects, symbols, unicode, build system, warnings, exceptions, the VM, ... http://perl11.org/blog/p5p-incompetence.html is a short overview of the technical problems to be fixed.
Professional use: read cperlpod cperl. No security process and competence, lack of progress, lack of maintainance of critical modules (cpan is fine, p5p and toolchain authors are the problem), no types, no compiler, recommending worst practices to move towards Java, no technical management, just community leaders without any idea what they are deciding, loosing all competent devs in the last decades and with just the remaining dead wood vocally protecting their turf, with the usual racial and more unpleasant slurs of the leadership towards its users and co-devs. As company you wouldn't want to be associated with them, but their counter propaganda silencing and censoring the critics works well.
While you censored me from adding comments to the old official discussion channels, I will not censor you on the new discussion channel /r/cperl or here. I just don't accept illegal comments as they used to happen on the old channels (asshole and such).
In the long run switching out to a fast VM for tight loops like p2, rperl or spvm (formerly called sperl) is still being considered. Perl6 inline::perl5 is unfortunately not doing too good, and I see no way forward with their architecture.
perl11 is doing very well. Many perl6 features are already in cperl, many more not yet completed. The design is done and sound.