Perl 5.26.0 released(nntp.perl.org)
nntp.perl.org
Perl 5.26.0 released
http://www.nntp.perl.org/group/perl.perl5.porters/2017/05/msg244573.html
164 comments
Yes, impressive community effort for a language that... Well... I have heard nothing good about in any "at the water cooler" conversation that I was ever in, over the past fifteen years or so. Except, of course, that Perl is awesome at regular expressions, an advantage that most languages must have caught up on, no? Not for nothing Perl shows up in most hated-lists all around town (top 10 at Stack Overflow).
Perl 5 isn't a 'cool' language, because it isn't trying to rapidly change itself, instead it just works. I use it just about every day (by my own choice!) and it can be a fine language to develop in. The libraries available in CPAN contain support for pretty much any task you could think of.
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?
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?
As a long time Perl programmer myself who has been doing Python for the last three years, I have to say that it is much easier to write unintelligible Perl code than Python. Not that you cannot write some gross things in Python if you try, but the language defaults towards readability and the community strongly encourages it.
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.
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.
The one thing that I miss in Python is true anonymous functions. Perl has them. JavaScript has them. Ruby has them. Python just has lambda functions which can only evaluate an expression.
Meh. In Python you can put a def inside of any scope you want and do anything that you want with it. The fact that it winds up with a name in that scope doesn't stop it from being anonymous everywhere else.
At that point the difference is just syntax.
At that point the difference is just syntax.
You're declaring the function within that scope. You can do this in other languages too. In Javascript, I can declare a function within a scope too:
> 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.
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.
I think the parent poster was referring to the fact that the critical thing is that a) you can define a function within the scope of another function, and b) you can return the inner function. To do this requires something called a closure, which in general involves some of the local variables being transferred to the heap.
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.
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.
Right. Anything that you could want to do with an anonymous function, you can.
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.
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.
>You're declaring the function within that scope. You can do this in other languages too.
>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).
>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).
> And BTW they are quite powerful so you can do a lot with them.
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.
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.
>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.
Ok, I get what you mean now, and think you have a point there.
Ok, I get what you mean now, and think you have a point there.
And better clarity---I've seen anonymous callback hell in .js, no thanks.
That's not a requirement of anonymous callbacks. That's just a symptom of poor coding standards. It can happen in Python too.
And yet the two go hand in hand. Have never seen it in Python, though have never used twisted either.
> And yet the two go hand in hand.
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.
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.
The trend toward limiting ultimately counter-productive language flexibility is getting stronger, not weakening.
See static typing, golang, and functional languages.
See static typing, golang, and functional languages.
I think perl invites a kind of mindset from how the language is and how the initial community was.
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.
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.
I'm biased, I've release bits for Moose but ... Django, React, Rails, Spring, : can you tell what they are used for from the names? Does this mean that Python, Javascript, Ruby, and Java are "drawn towards unreadability than readability by attracting a kind of mindset that wanted [them] to be more 'fun'"?
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.
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.
"Why does it have something called 'say' instead of something more intuitive like 'println'."
'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.
'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.
... which is basically just blessed hashes.
Blessed anything, really. One could bless a scalar or array if one so chooses (not that I would recommend doing so, but whatever).
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.
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.
> Why does it have something called 'say' instead of something more intuitive like 'println'.
"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.
"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.
Exactly. "Print" originally made me think of an ink printer. "Say" makes alright sense. Strangest I've seen is the basic language PBASIC's "debug" statement for the BASIC STAMP controller.
Why does it have something called 'say' instead of something more intuitive like 'println'.
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!
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!
>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.
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.
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.
EDIT: Please, before you get fixated on 'say', consider that perl already has 'print'. So, it has "print" and "say" - where "print" is "print" and "say" is "println".
> instead it just works
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.
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.
> I have heard nothing good about in any "at the water cooler" conversation that I was ever in, over the past fifteen years or so.
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.
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.
> 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.
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.
There is a feature I'd like to have in other languages. CPAN Testers. It's actually a really simple ideas. You randomly (or not) download packages and run their tests. The result will be uploaded.
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).
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).
CPANTS is the bane of my existence as a module author, it's also extremely rad to automatically get a test failure report for every possible combination of platform/language version.
Perl's regex matching is faster than Go's, last I checked. At my work, we have a few large perl (and python) legacy codebases that are processing billions of messages a day. We are replacing them with far more performant Go. It is great to work with a senior Perl guy who can slam out solutions way faster than I can in any other language. However, for us, concurrency (and readability) is important. I like perl's AnyEvent better than python's Twisted, and python's Gevent better than both of those (in general). But these are nowhere near as awesome as Go's native concurrency primatives.
Go's regex implementation is inferior to Perl's, feature-wise. For performance Go eschew's a certain amount of backtracking as far as I remember. If you want Perl regex compatibility in Go you have to add a PCRE lib.
Perl is still awesome at regular expressions compared to other languages. It has better Unicode regex support than almost any other language. If you need to do intricate Unicode regexes, then your main choices are Perl and libraries for other languages which port Perl features, not always well-supported.
Unicode regexes is a pretty small edge case. Is it because Perl is awesome, or because Unicode sucks?
> Unicode regexes is a pretty small edge case
Except for any other language than english.
Except for any other language than english.
Most people who understand what a can of worms those systems are start leaking a little grey matter from their ears when someone mentions the phrase "Unicode Regex".
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...
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...
Yes, and that's the reason why it's important to choose a tool that gets Unicode correctly. Perl is an example of such a tool.
Even if the language handles it correctly the lowly programmer is playing with white hot fire. Unicode adds so many edge cases it's basically a serrated knife in the middle of your code.
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.
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.
How many of those "water cooler" conversations you had with someone who actually knew and used perl for at least a few projects? Most of perl hate I hear is from people who've seen like 2 perl one-liners in life and got scared by $, @, and %'s in syntax...
> Except, of course, that Perl is awesome at regular expressions, an advantage that most languages must have caught up on, no?
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.
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.
Perl is still the only language I've seen that has a dedicated syntax for regular expressions. Every other language requires you to write your regexes as strings, which puts you squarely in backslash hell.
(I'm sure there must be other languages with dedicated regex syntax, but I'm not aware of any.)
(I'm sure there must be other languages with dedicated regex syntax, but I'm not aware of any.)
Ruby is a direct descendant of Perl and borrows its regex syntax.
Ruby used Oniguruma (and now Onigmo) for RegEx https://github.com/k-takata/Onigmo
Yes (well, for MRI at least; I'm not sure other implemebtations use the same regex engine) and it used a different regex engine before Oniguruma. But engines and syntax are unrelated; Ruby has a dedicated regex literal syntax which was directly inspired by Perl.
As far as I can make out these regex engines are very close to Perl5.
Javascript has regex literals
/foo\sbar/i;
new RegExp('foo\\sbar', 'i');One thing that annoys me a bit about the JS syntax though: As far as I know, JS regexp literals don't have custom delimiter support. For instance in perl you can do this:
$str =~ m{/some/path/\w+}
/\/some\/path\/\w+/
Regexp("/some/path/\\w+")Some other languages have a "raw string" syntax which disables backslash processing. For instance, Python (see https://docs.python.org/3/library/re.html and https://docs.python.org/3/reference/lexical_analysis.html#st...) and Rust (see https://doc.rust-lang.org/reference/tokens.html#raw-string-l...).
> Perl is still the only language I've seen that has a dedicated syntax for regular expressions.
So, you've never seen Ruby?
So, you've never seen Ruby?
I've done a very small about of ruby programming which did not involve regular expressions.
Javascript is like Perl: /foo/i.test('foobar') is valid JS.
> Perl is awesome at regular expressions
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.
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.
I wouldn't call it impressive. 2 months too late, too many bugs, horrible security, not much improvements, still doing more destruction than good.
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
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
Mmm, it'd be more honest to point out that "the effort" is your effort
Reini, aren't you the sole dev working on cperl, the fork you set up because you disagreed with some of the patchs perl-porters accepted/rejected?
A single +1 developer is better than -5 developers. cperl got 10x more done in 2 years than p5p in 15 years, and the 10x factor is ongoing. In a few years nobody will use perl5 anymore, everybody will use cperl instead.
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%.
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%.
"In a few years nobody will use perl5 anymore, everybody will use cperl instead."
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).
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).
Perl 6 is a different language, no chance for a replacement. It's also much slower and unusable for professional usage.
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.
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.
"It's also much slower"
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.
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.
extern sub is actively being worked on. The technical problem is not the ffi, this is trivial, but to fix the broken attributes architecture beforehand. They are not usable at runtime (variable arguments) and Attribute::Handlers only makes it worse.
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.
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.
Are you open to taking patches to that blog entry?
Of course not. Only typos.
Blog entries are one-time discussion entries,
written by the author, not by chromatic.
You are free to add comments.
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).
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).
Rieni, what happened to perl11 and p2 on potion? It looked like a very interesting project.
p2 was too much work to come up with a backcompat p5 library with all its problems. And I saw no easy way to add multithreading. Forking perl5 was easier in the short run.
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.
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.
Reini, more importantly, do you like memes?
Looks like a good job.
Reading through the changes it becomes abvious how rich a language Perl is. Just look at all the edge cases and fine tunings that this long time of development and improvement has generated. Its impressive. Anyone starting their own little programming language should really consider how big a task that actually is. This is not to stop anyone or discourage them.
Isn't the point of that comment precisely to discourage someone who might otherwise think the task to be smaller than it is? It's okay to discourage if it helps people understand scope.
Guys I am genuinely asking this and I have zero intent on bashing on Perl. What is the position of Perl industry right now? how much it can compete with Python. Where does it compete? is it on losing side ?
P.S. I am student and I have no real perspective on what is going on in industry right now.
P.S. I am student and I have no real perspective on what is going on in industry right now.
I've been using Perl for years, it's a pretty neat language. It can seem a little esoteric at first, but once you get into Perl it's pretty intuitive. I don't know how many times when I was learning it the I thought "this seems like this should work", tried it and it did. I'm not bashing any other languages (I think it's pointless, the "best" programming language it the one that makes you productive) but Perl definitely has it strong points:
- Great for sys admin stuff. Working with files and external programs is a breeze. *NIX administration is how I got into Perl. Perl is a devops friend.
- Handy for processing anything text based. Tedious tasks like screen scraping is straight forward.
- Versatile. Don't like X in Perl? Someone else probably thought the same thing and made a module for it. Even low level stuff like Perl subroutines and OO have alternatives. As they say in Perl TIMTOWTDI (there is more than one way to do it).
- So many modules! Write less code and get stuff done fast.
- Low level voodoo is easy. Perl exposes many of the internals of the interpreter so things like adding grammars and making DSL's doesn't seem like voodoo.
- Multi-paradigm. Doesn't force a programming style on you.
- Complex data types.
Not that everything is unicorns and rainbows in the world of Perl.
- Some features/syntax can feel outdated or seem "clunky" for lack of a better term.
- Versatility is a double-edged sword. You can write code so bad/evil it can summon an elder god and Perl will happily execute it.
- So much punctuation!
If your new to the world of Perl, try out Perl 6. It has all the cool features of Perl 5 and ditches most of the weird stuff but has all the modern features you would expect from other new(er) languages.
- Great for sys admin stuff. Working with files and external programs is a breeze. *NIX administration is how I got into Perl. Perl is a devops friend.
- Handy for processing anything text based. Tedious tasks like screen scraping is straight forward.
- Versatile. Don't like X in Perl? Someone else probably thought the same thing and made a module for it. Even low level stuff like Perl subroutines and OO have alternatives. As they say in Perl TIMTOWTDI (there is more than one way to do it).
- So many modules! Write less code and get stuff done fast.
- Low level voodoo is easy. Perl exposes many of the internals of the interpreter so things like adding grammars and making DSL's doesn't seem like voodoo.
- Multi-paradigm. Doesn't force a programming style on you.
- Complex data types.
Not that everything is unicorns and rainbows in the world of Perl.
- Some features/syntax can feel outdated or seem "clunky" for lack of a better term.
- Versatility is a double-edged sword. You can write code so bad/evil it can summon an elder god and Perl will happily execute it.
- So much punctuation!
If your new to the world of Perl, try out Perl 6. It has all the cool features of Perl 5 and ditches most of the weird stuff but has all the modern features you would expect from other new(er) languages.
Companies who are already using a technology such as Perl usually already have both some senior people who only know that technology and/or have a big codebase on that, such that migrating the code would take considerable resources.
Basically, sometimes it's not a choice.
Basically, sometimes it's not a choice.
[deleted]
[deleted]
The only big company I know that uses Perl extensively is booking.com, and I think that has more to do with any technical merit from the language, and just that is what they started and it was working for them.
To be honest, I think Perl still powers a whole lot of systems, and certainly is a powerful tool for someone who is a Unix sysadmin, but this kind of job is dying. And as a language, I think Perl has nothing on Python or even Ruby, or even PHP nowadays.
To be honest, I think Perl still powers a whole lot of systems, and certainly is a powerful tool for someone who is a Unix sysadmin, but this kind of job is dying. And as a language, I think Perl has nothing on Python or even Ruby, or even PHP nowadays.
> Unix sysadmin, but this kind of job is dying
I don't think this job is dying, but rather evolving. Of the Unix admins I learned under, only the ones who were also okay programmers and adapted have a great job right now. The writing is on the wall for those that can't/refuse to program. I had an interview with Facebook and they were bragging about laying off 100's of sysadmins with a machine learning model.
Also, this is anecdotal, but of my friends who are software engs only, I make more as a "Systems Engineer" or "DevOps Engineer" or whatever buzzword by knowing systems and a moderate level of programming, but it is the same skills from the 90's applied to the "cloud".
I don't think this job is dying, but rather evolving. Of the Unix admins I learned under, only the ones who were also okay programmers and adapted have a great job right now. The writing is on the wall for those that can't/refuse to program. I had an interview with Facebook and they were bragging about laying off 100's of sysadmins with a machine learning model.
Also, this is anecdotal, but of my friends who are software engs only, I make more as a "Systems Engineer" or "DevOps Engineer" or whatever buzzword by knowing systems and a moderate level of programming, but it is the same skills from the 90's applied to the "cloud".
I still think CPAN has more coverage than the equivalent in python
Which python module lets me declare object methods like:
method foo(bar):
self.do_foo(bar+self.baz)
There isn't one, because "explicit is better than implicit". Personally I've always found that Java's optional-self syntax to be incredibly confusing when reading code.
You could try to monkeypatch it by creating a decorator that will mess around with the closures of methods to make it work, but I don't understand _why_ you would want to do that.
You could try to monkeypatch it by creating a decorator that will mess around with the closures of methods to make it work, but I don't understand _why_ you would want to do that.
…is the answer 'the downvotes module'?
Downvoters: ok I get it: never post anything that's not a glowing recommendation of Python or an attempt to learn more about available modules/distributions.
Complaining about downvotes won't get you any praise in this community. It comes off as whining and is against the guidelines:
> Please resist commenting about being downvoted. It never does any good, and it makes boring reading.
> Please resist commenting about being downvoted. It never does any good, and it makes boring reading.
Why do you think unix sysadmin function is dying? Just curious.
As an ex-sysadmin I find that a lot of what I used to be responsible for is now outsourced to "the cloud" and most of my old tasks are being handled by other people as a secondary responsibility. Back when I started it wasn't uncommon for a 20-50 man company to have a dedicated sysadmin, whereas now I hardly ever see that.
I see this too, and i think it is a shame/mistake, i'd recommend to keep such people on board, and expand their workload/responsibilities when sysadmin work is on the low. (though when needed they should be able to dedicated their full time on sysadmin related work).
I then see it happen they no longer have any knowledge about systems and their processes, just outsourcing. And often, things then go downhill quite fast in service which leads to less happy customers which leads to lower company/employee moral etc.
People not knowing what computing power certain processes need or what its worth in money (over/under specced nodes), or backup processes not properly monitored or setup.
I then see it happen they no longer have any knowledge about systems and their processes, just outsourcing. And often, things then go downhill quite fast in service which leads to less happy customers which leads to lower company/employee moral etc.
People not knowing what computing power certain processes need or what its worth in money (over/under specced nodes), or backup processes not properly monitored or setup.
DevOps duh
In all seriousness I'm glad with these changes. I'm paid more to be NIX sysadmin, with minimal working knowledge of AWS/Azure/GCP.
All hail buzzword!
In all seriousness I'm glad with these changes. I'm paid more to be NIX sysadmin, with minimal working knowledge of AWS/Azure/GCP.
All hail buzzword!
I saw a talk at FOSDEM where a developer who worked at Booking said something along the lines of
- Big company bought lots of different hotel sites
- Big company decided to consolidate them into one system
- Booking (the Perl shop) won out
So I don't think it's necessarily just that "it started in Perl", if so then it could easily have been consolidated based on one of the other platforms that were not Perl based
- Big company bought lots of different hotel sites
- Big company decided to consolidate them into one system
- Booking (the Perl shop) won out
So I don't think it's necessarily just that "it started in Perl", if so then it could easily have been consolidated based on one of the other platforms that were not Perl based
Honestly, you are asking the wrong question. How can two turing complete programming languages even "compete"? I though about this a long time and came to the conclusion that it's not worth the effort to come up with an answer unless objective metrics are beeing found.
Good luck finding Ioke jobs then.
Even now I start web-projects with Perl.
It's not "cool", it's not "sexy", but there package collection (http://cpan.org/) is __huge__.
I find it unlikely that new people will suddenly rediscover perl, in the golang/node.js/python-centric state the world is in. But the people who love it, do continue to love it, and do continue to do useful and essential things with it.
It's not "cool", it's not "sexy", but there package collection (http://cpan.org/) is __huge__.
I find it unlikely that new people will suddenly rediscover perl, in the golang/node.js/python-centric state the world is in. But the people who love it, do continue to love it, and do continue to do useful and essential things with it.
The CPAN argument for choosing Perl was relevant about 10 years ago but if you look at http://modulecounts.com you'll find Ruby, Python, PHP, JS and Java have an order of magnitude more libraries to choose from. CPAN is not __huge__ by today's standards. Drupal alone has the same number of modules. The declining community also means many of the libraries on CPAN are unlikely to be maintained.
Hum, depends upon your definition of what's a module. from cpan.org front page:
The Comprehensive Perl Archive Network (CPAN) currently has 186,953 Perl modules in 35,278 distributions, written by 13,095 authors, mirrored on 248 servers.
The Comprehensive Perl Archive Network (CPAN) currently has 186,953 Perl modules in 35,278 distributions, written by 13,095 authors, mirrored on 248 servers.
[deleted]
Yes, "stableperl" maintains a small number of backported bugfixes to Perl 5.22: http://blog.schmorp.de/2015-06-06-a-stable-perl.html
The author cites a couple of issues as the motivation behind the release.
The author cites a couple of issues as the motivation behind the release.
CPAN has never failed me. I love it.
I don't use Perl for anything that I suspect will amount to more than 1,000 lines of code.
But for smaller scripts that automate tedious tasks or massage data to connect two otherwise software systems or generate a report-ish overview of a database/table, it is very hard to beat. Ruby comes close, but then again, Perl has been relentlessly optimized and fine-tuned over the last ~15 years, so for the stereotypical use-cases it is actually very fast, even compared to what one could cook up in C without weeks of hand-optimization and tweaking.
Someone once said that Perl is to batch-processing of text what Emacs is to interactive editing. I think the comparison is somewhat accurate.
But for smaller scripts that automate tedious tasks or massage data to connect two otherwise software systems or generate a report-ish overview of a database/table, it is very hard to beat. Ruby comes close, but then again, Perl has been relentlessly optimized and fine-tuned over the last ~15 years, so for the stereotypical use-cases it is actually very fast, even compared to what one could cook up in C without weeks of hand-optimization and tweaking.
Someone once said that Perl is to batch-processing of text what Emacs is to interactive editing. I think the comparison is somewhat accurate.
Exactly. I have dozens of scripts in production and most are 30 lines or less. Most of them read various files and load them into our databases. I do this in perl, because I can cook them up in minutes. Java, which is the official language around here, is just too much of a bother.
This week I realised that a script I wrote about ten years ago has become an indispensable part of my company's infrastructure: it converts Office documents to PDF using OLE. It's about 30 lines long of very clear code.
This week I realised that a script I wrote about ten years ago has become an indispensable part of my company's infrastructure: it converts Office documents to PDF using OLE. It's about 30 lines long of very clear code.
and I think it has replaces a lot of code that back in the day would have been written in, bash sed and awk
on the contrary perl5 has been relentlessly de-optimized and destroyed over the last ~15 years by its maintainers. how did you get to this interesting opinion? do you really believe the p5p marketing hype?
perl5.6.2 still blows away all newer releases performance and memory usage wise. 15 years ago the author was still active.
perl5.6.2 still blows away all newer releases performance and memory usage wise. 15 years ago the author was still active.
It's sad you're being downvoted. I've found similar sentiment elsewhere, and I'm interested to learn more.
stableperl (http://blog.schmorp.de/2015-06-06-a-stable-perl.html) is a fork of perl 5.22 with a couple of tiny reversions that re-enable access to some internal state required by certain CPAN modules.
The author talks in other blog posts (http://blog.schmorp.de/2016-12-29-griefing-the-perl-api.html, http://blog.schmorp.de/2015-11-12-tidbits-why-coro-crashes-o..., http://blog.schmorp.de/2015-12-15-tidbits-cgipm-a-data-point...) about the decline of Perl's cohesion.
It's sad to see.
--
EDIT: And now I'm being downvoted.
I have no problem with Perl, I watched the Perl 6 presentation when it was released with great interest.
Perl remains on my list of languages to learn (I know, I know...). It's up there. And that's why I said I was sad to see datapoints like the one I linked. I want Perl to keep going strong, and I hope it lasts another 20 years. I guess I added this comment because I wanted to find out if there was anything I could do.
stableperl (http://blog.schmorp.de/2015-06-06-a-stable-perl.html) is a fork of perl 5.22 with a couple of tiny reversions that re-enable access to some internal state required by certain CPAN modules.
The author talks in other blog posts (http://blog.schmorp.de/2016-12-29-griefing-the-perl-api.html, http://blog.schmorp.de/2015-11-12-tidbits-why-coro-crashes-o..., http://blog.schmorp.de/2015-12-15-tidbits-cgipm-a-data-point...) about the decline of Perl's cohesion.
It's sad to see.
--
EDIT: And now I'm being downvoted.
I have no problem with Perl, I watched the Perl 6 presentation when it was released with great interest.
Perl remains on my list of languages to learn (I know, I know...). It's up there. And that's why I said I was sad to see datapoints like the one I linked. I want Perl to keep going strong, and I hope it lasts another 20 years. I guess I added this comment because I wanted to find out if there was anything I could do.
Mark Lehmann and rurban are considered... let's just say, a vocal minority in the Perl community. Their opinions are not widely shared.
Oh. That's unfortunate. Thanks very much for the headsup.
I wouldn't mind learning more about this, perhaps via email (as an alternative to public discussion that might(?) start a flamewar).
I wouldn't mind learning more about this, perhaps via email (as an alternative to public discussion that might(?) start a flamewar).
There are still jobs specially on the banking sector, but these are not the kind of jobs you want. Its position in the industry is somewhat dying as I'm not aware of many new projects being written in it. I am myself in the process of phasing out a significant Perl codebase in exchange for Java.
I think it cannot compete with Python at its current state. This has nothing to do with the language (I consider Perl to be vastly superior) but rather its ecosystem and lack of momentum.
Concerning scientific programming, PDL used to be among the first choices but I'm not even sure if it's being used in bioinformatics anymore.
Its last nail in the coffin was missing the DevOps hype-train (Puppet, Chef...)
So even though the language is awesome I wouldn't recommend a developer in 2017 to learn it
I think it cannot compete with Python at its current state. This has nothing to do with the language (I consider Perl to be vastly superior) but rather its ecosystem and lack of momentum.
Concerning scientific programming, PDL used to be among the first choices but I'm not even sure if it's being used in bioinformatics anymore.
Its last nail in the coffin was missing the DevOps hype-train (Puppet, Chef...)
So even though the language is awesome I wouldn't recommend a developer in 2017 to learn it
> I think it cannot compete with Python at its current state. This has nothing to do with the language (I consider Perl to be vastly superior) but rather its ecosystem and lack of momentum.
In this specific case, these are contradictory.
Perl and Python had roughly the same amount of corporate backing (almost none) and Perl had a huge head start.
If Perl as a language would be "vastly superior", Python would have never developed its ecosystem and wouldn't have ever gathered enough momentum.
In this specific case, these are contradictory.
Perl and Python had roughly the same amount of corporate backing (almost none) and Perl had a huge head start.
If Perl as a language would be "vastly superior", Python would have never developed its ecosystem and wouldn't have ever gathered enough momentum.
Python's growth in popularity is largely due to its superior data science libraries and the backing of Google. Without these it wouldn't be where it is today. Perl's stewardship is largley responsible for its decline. If Perl6 hadn't taken 15 years to complete Perl's popularity might be different. Perl6 is far superior to Python and most popular languages. It's just not performant at string/regex handling which is ironic considering regex was Perl's forte.
> Python's growth in popularity is largely due to its superior data science libraries and the backing of Google.
Both are false. Data science libraries are quite new development that happened because Python got popular, not the other way around. Backing by Google (whatever you mean) was irrelevant, as the main selling points for Python dozen years ago was simple and readable syntax and nice web toolkits (a movement that followed Ruby with its RoR).
> If Perl6 hadn't taken 15 years to complete Perl's popularity might be different.
Perl6 didn't compete for popularity with Perl, because it was essentially non-existent back then. Perl popularity decline cannot be attributed to Perl6.
The thing is, Perl is a very complex language, but has competiton that is simpler grammar-wise and similarly powerful and expressive: Python and Ruby. It's easier for newcommers to learn Python or Ruby than Perl, so they rarely dig into Perl. This means that the number of people leaving the language (a normal thing for any language) is not matched by the number of young programmers, which leads straight to decline.
Both are false. Data science libraries are quite new development that happened because Python got popular, not the other way around. Backing by Google (whatever you mean) was irrelevant, as the main selling points for Python dozen years ago was simple and readable syntax and nice web toolkits (a movement that followed Ruby with its RoR).
> If Perl6 hadn't taken 15 years to complete Perl's popularity might be different.
Perl6 didn't compete for popularity with Perl, because it was essentially non-existent back then. Perl popularity decline cannot be attributed to Perl6.
The thing is, Perl is a very complex language, but has competiton that is simpler grammar-wise and similarly powerful and expressive: Python and Ruby. It's easier for newcommers to learn Python or Ruby than Perl, so they rarely dig into Perl. This means that the number of people leaving the language (a normal thing for any language) is not matched by the number of young programmers, which leads straight to decline.
Ruby 1.0 was released in 1996 and Python 1.0 in 1994. If Perl's demise was due to the simpler syntax of Python and Ruby why was Perl ever popular? Answer: Perl CGI at the dawn of the WWW. I'd date Perl's decline from around 2005 so Django and Rails might have more to do with it than languages and syntax.
Perl was popular because it had a huge head start. Perl 5 was released the same year as Python 1.0. CPAN launched in 1995, PyPI in 2003.
Python began to pick up momentum around 2000. It was able to break out of the "scripting" niche because it had good OO support and encouraged a consistent style that made it easy for several developers to work on a large project.
Rails probably marked the tipping point, but it wasn't just the framework. A lot of Perl programmers found out they liked Ruby. You're right that Perl 6 was part of the problem; it might be where Ruby is today if it had come out in 2003.
On the other hand, Ruby probably wouldn't exist if Perl 5 had a better object system.[1] It's "Ruby on Rails" because DHH fell in love with Ruby.[2] The creators of Django learned Perl before falling in love with Python.[3] So that has something to do with the languages too.
[1] http://www.linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.ht...
[2] https://www.quora.com/Why-did-David-Heinemeier-Hansson-choos...
[3] http://www.akitaonrails.com/2008/01/01/chatting-with-adrian-...
Python began to pick up momentum around 2000. It was able to break out of the "scripting" niche because it had good OO support and encouraged a consistent style that made it easy for several developers to work on a large project.
Rails probably marked the tipping point, but it wasn't just the framework. A lot of Perl programmers found out they liked Ruby. You're right that Perl 6 was part of the problem; it might be where Ruby is today if it had come out in 2003.
On the other hand, Ruby probably wouldn't exist if Perl 5 had a better object system.[1] It's "Ruby on Rails" because DHH fell in love with Ruby.[2] The creators of Django learned Perl before falling in love with Python.[3] So that has something to do with the languages too.
[1] http://www.linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.ht...
[2] https://www.quora.com/Why-did-David-Heinemeier-Hansson-choos...
[3] http://www.akitaonrails.com/2008/01/01/chatting-with-adrian-...
For me it's quite the opposite: knowing Perl I have little incentive to learn Python; the syntax is quite different, it uses significant whitespace that can easily change the logic. With Ruby it's different because Matz was inspired by Perl and the language is quite ellegant. Too bad it's equally slow. Maybe if mruby/crystal changes that it would be a nice language to learn.
With TruffleRuby, Graal and Substrate VM all aimed at improving Ruby's speed I wouldn't write-off Ruby purely on performance. JRuby has also recently made great strides in performance.
Well okay but Jruby/Truffle is a JVM language. I just want an interpreter + code, or a binary to drop anywhere. Mruby is fast but you have to build modules into it at compile time. It would be nice if it had something like LuaRocks. Anyway, Ruby is doing fine, there is much innovation going on.
Perl is not more readable than Python.
I know that "readable" is a subjective trait, but Python is 1 cm away from being pseudocode.
And when a programming language is basically the thing we write when we don't have any tools to assist us, that says a lot about the language's syntactic quality, including its readability.
Both the data science libraries and Google's backing come from this. And to be honest, I don't really see how Google's backing mattered that much... 99% of the popular Python libraries have nothing to do with Google, especially Django.
I know that "readable" is a subjective trait, but Python is 1 cm away from being pseudocode.
And when a programming language is basically the thing we write when we don't have any tools to assist us, that says a lot about the language's syntactic quality, including its readability.
Both the data science libraries and Google's backing come from this. And to be honest, I don't really see how Google's backing mattered that much... 99% of the popular Python libraries have nothing to do with Google, especially Django.
[deleted]
I don't know how I feel about that. We're talking about subjective measurements here.
There are many languages that are "better" than JavaScript for example, yet not many that enjoy its share of success.
There are many languages that are "better" than JavaScript for example, yet not many that enjoy its share of success.
That's why I chose my words carefully in the previous comment.
Perl and Python are perfectly comparable regarding origin, corporate backing, marketing, platform restrictions, etc. Javascript isn't.
Perl and Python were both started by a BDFL, acquired a grass-roots community that promoted them and never really had 1 major corporate backer or sponsor that outshined all the others. They also didn't become the main or even the only suppported language for a platform.
They had a really similar trajectory, just with different peaks. Perl peaked earlier and IMO lower.
Perl and Python are perfectly comparable regarding origin, corporate backing, marketing, platform restrictions, etc. Javascript isn't.
Perl and Python were both started by a BDFL, acquired a grass-roots community that promoted them and never really had 1 major corporate backer or sponsor that outshined all the others. They also didn't become the main or even the only suppported language for a platform.
They had a really similar trajectory, just with different peaks. Perl peaked earlier and IMO lower.
[deleted]
Mostly legacy. perl5 is not developed anymore, just managed to death compared to the other big 3. Of the big 4 only php managed to improve itself significantly, but it's still only php.
perl5 is still top 10, runs tons of code, has one of the hugest library codebases (CPAN), and is much easier to use than e.g. python or php. ruby is better, but slower. You cannot use simply a repl in whitespace formatted language (python), and trivial scripts get soon overly large. with perl sysadmin tasks or extending bash scripts is trivial. why gdb chose python over perl is not a technical decision (perl would have fit much better), but more a management decision. perl5 is going nowhere, and python is also stagnating, just slower. with ruby there still is a bit of hope. php done everything right, but still got its legacy coders and the horribly designed old stdlib.
perl5 is still top 10, runs tons of code, has one of the hugest library codebases (CPAN), and is much easier to use than e.g. python or php. ruby is better, but slower. You cannot use simply a repl in whitespace formatted language (python), and trivial scripts get soon overly large. with perl sysadmin tasks or extending bash scripts is trivial. why gdb chose python over perl is not a technical decision (perl would have fit much better), but more a management decision. perl5 is going nowhere, and python is also stagnating, just slower. with ruby there still is a bit of hope. php done everything right, but still got its legacy coders and the horribly designed old stdlib.
They're all stagnating. Nim for Python & Crystal for Ruby are the logical steps forward to get speed (GCC & LLVM respectively for compilers).
I moved from Perl to python around 6 years ago. There are more jobs available for Python, though probably more competition as well.
I regularly see Perl jobs posted in London, but the wages are surprisingly poor, compared to what I could get for my Django knowledge.
I regularly see Perl jobs posted in London, but the wages are surprisingly poor, compared to what I could get for my Django knowledge.
I think your comment on wages is astute, and it's the same everywhere. There are Perl jobs around, but they're on legacy codebases in (parts of) organizations that are basically too dysfunctional / under-resourced / incompetent to upgrade them, and if you take the job you'll just be putting out fires and stagnating.
When you take that into account, the salary would need to be at a real premium to make it worthwhile, and the premium just isn't there.
When you take that into account, the salary would need to be at a real premium to make it worthwhile, and the premium just isn't there.
The 2017 SO Developer Survey has Perl in 6th place for highest compensation in the world. https://insights.stackoverflow.com/survey/2017#technology-to...
Interestingly, Perl places 5th in the USA for highest compensation, and it doesn't even make the lists of France, Germany, India, and the UK.
Hmm, I am pretty surprised by that, but I'll take it at face value.
I suspect there is too much else going on for a comparison of salaries by language to be meaningful. Those Perl programmers are probably highly paid mainly because they have 20ish years of experience, and lots of other valuable Linux/Unix experience. There are probably lots of fresh graduate and entry level JavaScript / Java / C++ developers bringing down those averages.
I always get a good laugh when I see job ads for a "Junior Perl developer" paying 25k GBP or something. They stopped making those 20 years ago.
I suspect there is too much else going on for a comparison of salaries by language to be meaningful. Those Perl programmers are probably highly paid mainly because they have 20ish years of experience, and lots of other valuable Linux/Unix experience. There are probably lots of fresh graduate and entry level JavaScript / Java / C++ developers bringing down those averages.
I always get a good laugh when I see job ads for a "Junior Perl developer" paying 25k GBP or something. They stopped making those 20 years ago.
I learned Perl back in the Perl 4 days, and still write one-off scripts in it. Lately, though, I do most new work in Python, since the young seem more likely to know that than to know Perl.
Local companies using Perl have all migrated to Python or are 90% on the way. I know a few Perl guys who are employed just to keep legacy systems working while the customers are migrated over to the new Python systems.
I interviewed for a Perl gig at a biotechnology company recently. There's still people using perl out there.
Modern Perl pretty much has feature parity with python. Don't listen to the "perl bigots".
My Indeed.com API client, which eliminates duplicates, shows 39 Perl jobs by title search in London compared with 405 Python and 166 Ruby. For the UK it's 64 Perl to 741 Python and 274 Ruby. So most of the Perl jobs are London-based. To put it in perspective, the same stats show Golang with only half the number of Perl jobs.
We are using it in production. It gets the job done.
Looking forward to a Perl6 stable release. It is stable but Rakudo still needs a bit of polush. Also it doesn't have the amount of modules Perl5 has. What it does have however, is precise arithmetic because numbers in Perl6 are internally represented as rationals.
https://docs.perl6.org/type/Rat
Looking forward to a Perl6 stable release. It is stable but Rakudo still needs a bit of polush. Also it doesn't have the amount of modules Perl5 has. What it does have however, is precise arithmetic because numbers in Perl6 are internally represented as rationals.
https://docs.perl6.org/type/Rat
Part of Perl 6's current problem is that it doesn't have a real CPAN equivalent yet. Hopefully that'll be fixed soon.
https://modules.perl6.org/
Although it's merely a list. But you have zef, an installer that pulls and installs modules.
Although it's merely a list. But you have zef, an installer that pulls and installs modules.
"Although it's merely a list"
Hence why I feel that a proper CPAN equivalent does not currently exist. The Perl 6 website even admits such.
Still, it does work reasonably well for now.
Hence why I feel that a proper CPAN equivalent does not currently exist. The Perl 6 website even admits such.
Still, it does work reasonably well for now.
I am also not a Perl programmer (anymore). I used to program in Perl decades ago and mostly switched essentially because of the hype. I've now many years of professional experience with Python and while I really like the language and will continue to use it I have to say that Perl gets too much bashing and Python sometimes not enough.
I think there are a number of reasons for this. One is that a lot more Perl code got written by non programmers (sysadmins) than Python code. People know Perl for regexes and "golf" (writing extremely short code), which looks like "compressed" (as in Closure/uglify compiled) JavaScript: Ugly.
The main thing that I disliked about Perl is something I also dislike about C, which is writing arrows. Other than that using other languages like Python didn't get me a lot.
You can and will write ugly, unmaintainable code and long unreadable lines in both Python and Perl. The main thing that makes Python look prettier seems to be forced indention, but believe it or not Perl can be indented too. The other thing probably are sigils, which are also a rather powerful feature.
There are of course different tradeoffs. Perl is more on the Ruby/JavaScript side, where people prefer expressiveness of code, where Python people prefer simplicity. And while I always for simplicity I don't think whether the community in large sets a bit more focus here or there there doesn't seem to be a great indicator for whether to choose one or the other language.
When comparing Perl with Python or Ruby, which I think are maybe other than JavaScript make the most sense in terms of use cases I think Perl influenced both of them more than a lot of programmers realize.
Despite the others being very mature I think Perl would wins on the edge of having solid modules and infrastructure. It certainly doesn't win in terms of image and popularity. What is nice about Perl is that the shortcomings of the languages have been largely compensated via modules. That includes modules that add changes to the syntax or add really big features like Moose, adding a lot around the topic of Object Oriented Programming, more than you have available in other languages.
Another thing I want to point out is, that Mojolicious is by far the best web framework I've seen so far. It's my personal opinion, but it beats everything available in the Python and Ruby world by far. And at least with Python I've used Django and Flask for multiple years, as well as taken a look at others.
The eco system in general is really good. There is a lot in regards to testing. If you really are into test driven development that alone might be a reason to give Perl a shot and be it simply to steal some ideas around this topic. That includes many modules around the topic of testing as well as CPAN Testers and other things.
For the bad side. Other than reputation, the learning curve is higher. This has a multitude of reasons. One is that Perl was designed after natural languages, which explains many of its oddities. That's why it isn't as easy to pick up as other languages. Knowing other languages simply might not help you as much.
Another is that a lot of very old and bad Perl tutorials are around. So one might want to look at something that in one way or the other mentions Modern Perl.
One might think to know and understand Perl really quickly, but it simply takes longer than knowing how to write Perl. This is why it makes a lot of sense to read Perl code from some "big people" in the community.
In terms of industry usage. I think the big names here are DuckDuckGo, Craigslist, eBay (I think), Amazon (I think).
However that probably is very outdated.
A good reason to not learn Perl is if you want a simple language. Perl simply is not that. I changed to prefer simple languages, which might be the reason I am now sticking mostly to Go and Python. However, it might open your eyes about different ways of simplicity here and there.
It's also good to know the other side and know how "simple" certain more complex tasks can be, if you just approach them with another tool.
Okay, this wasn't so much about the industry. It's certainly around, both for older and newer projects. I've seen it both in the Enterprise and Startup scene and not just online.
It's more quiet, but then most projects that have been around for a while don't have any big news. Debian, Postgres, various OSs, etc.
Oh one more reason: If you like it boring to get stuff done then use Perl. I think the Perl5/Perl6 thing is over and everyone agrees they are two different languages, so it's not like in Python where you still have so many projects supporting just a subset of Python in order to keep compatibility.
I think if you have Perl developers, which certainly exist, even in large quantities, choosing that one rather than Python certainly won't give you a big downside or so.
I think they are pretty much the same in that regard, even though I am pretty sure that neither community would agree on that statement.
I chose Python and Go for everything I do, mostly cause I haven't been programming Perl in ages and so my development setup, my muscle memory, etc. and money is all there, still I don't think other than that Python really has an edge over Perl. Again. I know people will disagree.
I haven't touched Perl in 10+ years. At all in fact. So if anything I am biased towards Python.
I think there are a number of reasons for this. One is that a lot more Perl code got written by non programmers (sysadmins) than Python code. People know Perl for regexes and "golf" (writing extremely short code), which looks like "compressed" (as in Closure/uglify compiled) JavaScript: Ugly.
The main thing that I disliked about Perl is something I also dislike about C, which is writing arrows. Other than that using other languages like Python didn't get me a lot.
You can and will write ugly, unmaintainable code and long unreadable lines in both Python and Perl. The main thing that makes Python look prettier seems to be forced indention, but believe it or not Perl can be indented too. The other thing probably are sigils, which are also a rather powerful feature.
There are of course different tradeoffs. Perl is more on the Ruby/JavaScript side, where people prefer expressiveness of code, where Python people prefer simplicity. And while I always for simplicity I don't think whether the community in large sets a bit more focus here or there there doesn't seem to be a great indicator for whether to choose one or the other language.
When comparing Perl with Python or Ruby, which I think are maybe other than JavaScript make the most sense in terms of use cases I think Perl influenced both of them more than a lot of programmers realize.
Despite the others being very mature I think Perl would wins on the edge of having solid modules and infrastructure. It certainly doesn't win in terms of image and popularity. What is nice about Perl is that the shortcomings of the languages have been largely compensated via modules. That includes modules that add changes to the syntax or add really big features like Moose, adding a lot around the topic of Object Oriented Programming, more than you have available in other languages.
Another thing I want to point out is, that Mojolicious is by far the best web framework I've seen so far. It's my personal opinion, but it beats everything available in the Python and Ruby world by far. And at least with Python I've used Django and Flask for multiple years, as well as taken a look at others.
The eco system in general is really good. There is a lot in regards to testing. If you really are into test driven development that alone might be a reason to give Perl a shot and be it simply to steal some ideas around this topic. That includes many modules around the topic of testing as well as CPAN Testers and other things.
For the bad side. Other than reputation, the learning curve is higher. This has a multitude of reasons. One is that Perl was designed after natural languages, which explains many of its oddities. That's why it isn't as easy to pick up as other languages. Knowing other languages simply might not help you as much.
Another is that a lot of very old and bad Perl tutorials are around. So one might want to look at something that in one way or the other mentions Modern Perl.
One might think to know and understand Perl really quickly, but it simply takes longer than knowing how to write Perl. This is why it makes a lot of sense to read Perl code from some "big people" in the community.
In terms of industry usage. I think the big names here are DuckDuckGo, Craigslist, eBay (I think), Amazon (I think).
However that probably is very outdated.
A good reason to not learn Perl is if you want a simple language. Perl simply is not that. I changed to prefer simple languages, which might be the reason I am now sticking mostly to Go and Python. However, it might open your eyes about different ways of simplicity here and there.
It's also good to know the other side and know how "simple" certain more complex tasks can be, if you just approach them with another tool.
Okay, this wasn't so much about the industry. It's certainly around, both for older and newer projects. I've seen it both in the Enterprise and Startup scene and not just online.
It's more quiet, but then most projects that have been around for a while don't have any big news. Debian, Postgres, various OSs, etc.
Oh one more reason: If you like it boring to get stuff done then use Perl. I think the Perl5/Perl6 thing is over and everyone agrees they are two different languages, so it's not like in Python where you still have so many projects supporting just a subset of Python in order to keep compatibility.
I think if you have Perl developers, which certainly exist, even in large quantities, choosing that one rather than Python certainly won't give you a big downside or so.
I think they are pretty much the same in that regard, even though I am pretty sure that neither community would agree on that statement.
I chose Python and Go for everything I do, mostly cause I haven't been programming Perl in ages and so my development setup, my muscle memory, etc. and money is all there, still I don't think other than that Python really has an edge over Perl. Again. I know people will disagree.
I haven't touched Perl in 10+ years. At all in fact. So if anything I am biased towards Python.
> The main thing that I disliked about Perl is something I also dislike about C, which is writing arrows
You're in luck. Perl6 dropped the arrows. It's using dots just like everyone else. It also dropped the floating point math, so you can now do precise calculations natively which is a big deal for financial and scientific software.
I can second Mojolicious being one of the best web frameworks. We are using it for our web infrastructure. Basically we did a full rewrite from CGI.pm to Mojolicious. It is however Sinatra inspired, so let's give credit where credit is due.
You're in luck. Perl6 dropped the arrows. It's using dots just like everyone else. It also dropped the floating point math, so you can now do precise calculations natively which is a big deal for financial and scientific software.
I can second Mojolicious being one of the best web frameworks. We are using it for our web infrastructure. Basically we did a full rewrite from CGI.pm to Mojolicious. It is however Sinatra inspired, so let's give credit where credit is due.
Perl has great Unicode support. Not just Unicode regexes, but a lot of built-in Unicode support ( https://perldoc.perl.org/perlunicode.html ). I have no idea if other languages have caught up, though.
Perl doesn't have anything like Python's GIL. People have other complaints about threading in Perl, but you can count on things running in parallel more often.
I believe Larry Wall is correct that he borrowed more from Lisp than Guido did. Perl built in functions are also often modeled after POSIX functions (that may not mean a lot to you, but I like it).
On the other hand, Perl 5 doesn't have anything like Python's "yield", and the closest it gets to list comprehensions is a Lisp-style "map" that is NOT lazily evaluated. And I've never managed to get a job where I was expected to write Perl (I've written Perl utilities at plenty of jobs, but Perl was never on the official job description).
Perl doesn't have anything like Python's GIL. People have other complaints about threading in Perl, but you can count on things running in parallel more often.
I believe Larry Wall is correct that he borrowed more from Lisp than Guido did. Perl built in functions are also often modeled after POSIX functions (that may not mean a lot to you, but I like it).
On the other hand, Perl 5 doesn't have anything like Python's "yield", and the closest it gets to list comprehensions is a Lisp-style "map" that is NOT lazily evaluated. And I've never managed to get a job where I was expected to write Perl (I've written Perl utilities at plenty of jobs, but Perl was never on the official job description).
Your comment about list comprehensions reminded me of an old, interesting Perl book, "High-Order Perl", which explores functional programming techniques in Perl. One of the chapters implements a lazy map - which, turns out, is actually quite easy to implement in a few loc, since Perl supports closures and high-order, first-class functions.
http://hop.perl.plover.com/
http://hop.perl.plover.com/
What do you mean by Perl functions being modeled after POSIX functions?
My only points of reference are POSIX being a UNIX system specification which defines both a C language reference and system userspace specification. I also have a vague notion of POSIX specifying the fundamental behavior of shells.
I'm just not quite sure which point of reference to apply.
My only points of reference are POSIX being a UNIX system specification which defines both a C language reference and system userspace specification. I also have a vague notion of POSIX specifying the fundamental behavior of shells.
I'm just not quite sure which point of reference to apply.
In addition to what others have said, perl also directly exposes errno via $!:
$ perl -E 'unlink("/etc/passwd"); say (0+$!)'
13
$ grep 13 /usr/include/asm-generic/errno-base.h
#define EACCES 13 /* Permission denied */
$ perl -E 'unlink("/etc/passwd"); say $!'
Permission denied
Wow, interesting. The language has type coercion, and makes full use of it. I likey :D
Thanks for the example too!
Thanks for the example too!
It actually goes a bit beyond type coercion. Larry Wall is a linguist. The language is actually contextual. There's numeric vs. string context for scalars and scalar vs. list context for assignments and returns.
The list of features is impressive, but taken together all at once can be daunting. I think that's why there's so much distaste for it in certain camps. It's actually possible in a function to test whether the caller wants a single value or a list and adjust your return accordingly. It has anonymous functions. It has closures. It has map() and sort(), either of which apply a custom block of code to a list. You can easily write user-supplied functions that do that, too. It has dictionaries / associative arrays (called "hashes" in the community since that's how they are implemented), regular arrays, scalar values, and a number of different object systems from which to choose.
The list of features is impressive, but taken together all at once can be daunting. I think that's why there's so much distaste for it in certain camps. It's actually possible in a function to test whether the caller wants a single value or a list and adjust your return accordingly. It has anonymous functions. It has closures. It has map() and sort(), either of which apply a custom block of code to a list. You can easily write user-supplied functions that do that, too. It has dictionaries / associative arrays (called "hashes" in the community since that's how they are implemented), regular arrays, scalar values, and a number of different object systems from which to choose.
If you want to read a directory, you use the functions opendir, readdir, and closedir. You can get a decent idea of what they do by looking at POSIX documentation. They have been modified to fit Perl better, so you still have to look at the Perl documentation as well.
If you want to fork a process, you use the function "fork". If you want to call exec, Perl has it. You can even have the parent process wait on the child's pid.
This isn't a big deal to everyone, but I like POSIX, and I like knowing that if I want to do something new, there's a good chance I can start with "how would I do it in C on a POSIX system?" I have many complaints about Java, and one is that their original standard library appears to have been modeled on early versions of MFC, even though Sun had access to a superior API, since they had plenty of experience with shipping a POSIX operating system.
If you want to fork a process, you use the function "fork". If you want to call exec, Perl has it. You can even have the parent process wait on the child's pid.
This isn't a big deal to everyone, but I like POSIX, and I like knowing that if I want to do something new, there's a good chance I can start with "how would I do it in C on a POSIX system?" I have many complaints about Java, and one is that their original standard library appears to have been modeled on early versions of MFC, even though Sun had access to a superior API, since they had plenty of experience with shipping a POSIX operating system.
I see what you mean.
POSIX was basically a committee ratifying things that a bunch of systems people had come up with. So it gets to the point, it's reasonably concise, and there's little noise to wade through to do most things.
Java was slowly designed by committee, taking inspiration from other languages.
I just thought of something. Maybe it's relevant.
IBM said "let make something totally different with this 8086 system, let's make everything open and not lock it down." Apple said "let's do something different with the Macintosh, let's enforce absolute control over the hardware and software so we can perfectly unify them."
Maybe Sun got fed up with SunOS and said "let's make a language and runtime that's totally different - something so different that it resists influence by platform architecture."
POSIX was basically a committee ratifying things that a bunch of systems people had come up with. So it gets to the point, it's reasonably concise, and there's little noise to wade through to do most things.
Java was slowly designed by committee, taking inspiration from other languages.
I just thought of something. Maybe it's relevant.
IBM said "let make something totally different with this 8086 system, let's make everything open and not lock it down." Apple said "let's do something different with the Macintosh, let's enforce absolute control over the hardware and software so we can perfectly unify them."
Maybe Sun got fed up with SunOS and said "let's make a language and runtime that's totally different - something so different that it resists influence by platform architecture."
I think Java's "all OOP, all the time" approach influenced their standard library design. I don't like the result.
"Modernism was based on a kind of arrogance, a set of monocultural blinders that elevated originality above all else, and led designers to believe that if they thought of something cool, it must be considered universally cool. That is, if something's worth doing, it's worth driving into the ground to the exclusion of all other approaches. Look at the use of parentheses in Lisp or the use of white space as syntax in Python. Or the mandatory use of objects in many languages, including Java. All of these are ways of taking freedom away from the end user 'for their own good'. They're just versions of Orwell's Newspeak, in which it's impossible to think bad thoughts. We escaped from the fashion police in the 1970s, but many programmers are still slaves of the cyber police" ( http://m.linuxjournal.com/article/3394 ).
"Modernism was based on a kind of arrogance, a set of monocultural blinders that elevated originality above all else, and led designers to believe that if they thought of something cool, it must be considered universally cool. That is, if something's worth doing, it's worth driving into the ground to the exclusion of all other approaches. Look at the use of parentheses in Lisp or the use of white space as syntax in Python. Or the mandatory use of objects in many languages, including Java. All of these are ways of taking freedom away from the end user 'for their own good'. They're just versions of Orwell's Newspeak, in which it's impossible to think bad thoughts. We escaped from the fashion police in the 1970s, but many programmers are still slaves of the cyber police" ( http://m.linuxjournal.com/article/3394 ).
Very very interesting thoughts, thanks very much for this comment. Would +10 if I could.
The article was an excellent read too.
I've noticed that a lot of people around the 18-25 demographic (and some outside that range) have mental health issues that (among other catastrophes) cause detrimental effects to emotional development. I was thankfully able to get off this train myself using alternative therapies about ten years ago, but one of the things I observed about myself was a tendency to hone in on one specific idea present in something I was thinking about and then redefine what I was focusing on on the basis of and in terms of that idea, in many situations irreversibly discarding any other possible interpretations. I essentially didn't have the capacity to wield concepts that required careful balance between a series of discrete ideas.
I wonder a lot about how much of the noise margin present in current research and work is caused by related developmental issues.
The article was an excellent read too.
I've noticed that a lot of people around the 18-25 demographic (and some outside that range) have mental health issues that (among other catastrophes) cause detrimental effects to emotional development. I was thankfully able to get off this train myself using alternative therapies about ten years ago, but one of the things I observed about myself was a tendency to hone in on one specific idea present in something I was thinking about and then redefine what I was focusing on on the basis of and in terms of that idea, in many situations irreversibly discarding any other possible interpretations. I essentially didn't have the capacity to wield concepts that required careful balance between a series of discrete ideas.
I wonder a lot about how much of the noise margin present in current research and work is caused by related developmental issues.
Perl is awesome. Its like writing a sentence or paragraph. I decide how I want to present each sentence or paragraph. Then I get to write it in Perl.
Its a very easy language to learn. My first language was C back in 1994. I was in high school and encouraged to learn C before I learned Perl.
I read my books. I kept on going after it. Then finally six years later I started learning Perl.
Perl is a great language.
I haven't touched Perl6 yet - I bet its even better. It might take me 20 years just to do a hello world in it and optimize it.
Larry gave us a great place to start. Guido is awesome too.
"I don't like big bloated snakes though" -- I heard this back in 1996 or so...
We have been focusing on languages for 20k years or so. We have built computers for about 100 years - and invented languages to talk to them.
Its a very easy language to learn. My first language was C back in 1994. I was in high school and encouraged to learn C before I learned Perl.
I read my books. I kept on going after it. Then finally six years later I started learning Perl.
Perl is a great language.
I haven't touched Perl6 yet - I bet its even better. It might take me 20 years just to do a hello world in it and optimize it.
Larry gave us a great place to start. Guido is awesome too.
"I don't like big bloated snakes though" -- I heard this back in 1996 or so...
We have been focusing on languages for 20k years or so. We have built computers for about 100 years - and invented languages to talk to them.
I'm excited for the whitespace stripping heredoc operator, it's always a bummer having to put all heredocs all the way left.
Great work! Excited about the direction Perl 5 is going!
Perl always reminds me of this guy :) https://media.ccc.de/v/32c3-7130-the_perl_jam_2
I watched the video some time ago and what bothers me is that the author pretends to have hacked Perl while in fact he just found that some people are using a commonly used Perl module (DBI) the wrong way whereas the right way is well documented. A similar thing would be to blame PHP for allowing SQL injections through unescaped user input: I am sure it happens a lot, but who would blame PHP.
Actually, he breaks examples from the manual. I think his point was that programmers inherently write exploitable Perl code as they assume certain types are secure.
The types point is actually meh. The real hilarious part is the combination of the ARGV <> "feature" and the open("...|") "feature". What. The. Fuck.
Until recently, blaming PHP was the popular approach. :)
Well, every time I meet someone and they say they use PHP for their living my inter monologue is "Don't be a jerk and don't bash PHP, its a fine choice." I usually have to make sure I don't talk with them long and move along. I am a jerk either way.
Shrugs, it pays the bills and has improved radically since 4 and even 5.
It wouldn't be my first choice but there is plenty of reasonable paying work around.
It wouldn't be my first choice but there is plenty of reasonable paying work around.
Yeah, and I discovered C is horrible because buffer overflows.
Is it really Perl best practice to assume all non-scalar data types are trusted?
Definitely not. At $work, we use Params::Validate as a standard way to normalise and validate the incoming parameters.
Btw., as mentioned in announcement. The actual changes are here, if you missed that:
https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/pe...