http://search.cpan.org/perldoc?perl5100delta
Has anyone played with these new features? I personally haven't touched Perl in years. Python and Ruby have superseded it entirely for me.
I noticed 5.10 adopted Python's named regex captures, which made me laugh. They seem to have finally added some form of switch statement, too... never mind that people have been asking for that one since what, Perl 4? Although they're being strangely careful about not calling it "switch". Maybe because for all this time they've insisted that anything you want to do with switch can be done just as easily with a chain of && and || or a mess of if/else blocks.
The two things I really don't get at all are the //= operator (what exactly does it do that ||= doesn't?) and that ~~ thing that apparently is like the switch without the switch clause. (When would it ever have been useful to put a random case statement in the middle of a block of C code, I don't know.)
The file test operator stacking looks useful: if (-r -w -x $filename) instead of if (-r $filename && -w $filename && -x $filename). Although I suspect it may be partly because some perl developer wanted to improve his golf score.
There's a couple bits on the change log that just bewilder me, though.
> Sorting arrays in place (@a = sort @a) is now optimized to avoid making a temporary copy of the array.
> Likewise, reverse sort ... is now optimized to sort in reverse, avoiding the generation of a temporary intermediate list.
I'm honestly surprised that those weren't done ten years ago. Especially the first bit.
And then there's this, which just made me wtflol:
> Traditionally, eval 'syntax error' has leaked badly. Many (but not all) of these leaks have now been eliminated or reduced. (Dave Mitchell)
Traditionally, Perl leaked.
Your post is nothing but bashing, but I'm replying anyway because I enjoy the new features :)
The new switch, // operator and stacking are my features I like a lot.
> Although they're being strangely careful about not calling it "switch"
Perl has had a switch statement through the module Readonly. Calling it the same would cause problems.. The new switch is also much more powerful than switches in most other languages.
The ~~ operator is nice. Now I can do
die "evil" unless $user_input ~~ @valid;rather than
die "evil" unless grep { $user_input eq $_ } @valid;> I noticed 5.10 adopted Python's named regex captures, which made me laugh.
Why? Cross-pollination is a wonderful thing.
my perl 5.8.8 already has // and //=~~ looks nice, but the switch thing looks pretty useless to me.
>>3
I'm amused that it took so long for the Perl people to admit that someone else added a useful feature to PCREs.
>>6
more complicated syntax that doesn't do anything you couldn't do before is useful now?
>>6 Perl is like the English of the programming world. To paraphrase James Nicoll: Perl is about as pure as a cribhouse whore. It doesn't just borrow features; on occasion, Perl has persued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary.
Python is like the French of the programming world. It's not good enough for Python programmers unless they invented it.
Frankly, named captures are good for very complicated regular expressions; the kind that look like lots of noise. The kind that no self-respecting python programmer would let muddle up their program. The kind that fast perl programs have a lot of. I'm surprised python programmers would admit to having such a feature, so it doesn't surprise me at all that it took Perl a whole version number to adopt it (5.8 was released shortly after python 2.1 which was when the feature was introduced IIRC)
>>8
what
If you use extended regexes with /x (or in Python, re.VERBOSE) you can... omigod... PUT COMMENTS IN THEM, and use proper indentation to delimit subgroups. Which is what any decent python programmer who's using a complex regex would do.
Not that most Perl programmers have even heard of that /x flag, because they're scared of readability.
Really?
You think anyone is scared of readability?
You don't think it's just more likely that they don't care about readability? That maybe they understand the costs associated with it, and decide it's just not worth it?
>>10
I can't count how often I've had Perl code that (to me, at least) was written cleanly and elegantly, and someone helpfully sent me a rewritten version with all whitespace removed, most variables changed to use $_ and @_, etc.
At first I thought it was a joke, but I have become convinced that Perl programmers are in general dead set on making their code impossible to understand.
The other side of this is, terse code can be easier to deal with because you can fit more on-screen/in your mind at a time.
If the abbreviations used are automatic and second nature to those programmers, possibly the rewritten version appeals more to them because it's short.
(Personally I put a lot of blank lines in my code... and I've noticed I'm much more productive using a 50-line screen than a 25-line one.)
>>11 That's too bad.
It's been my experience that many perl programmers are inexperienced, but happy that they're accomplishing goals and getting their jobs done. Those fewer experienced perl programmers are simply lisp programmers in disguise.
Python programmers on the other hand must be more proficient because their language is harder to use. As a result, you see a lot more mid-level programmers using python because it's just too hard for inexperienced programmers, and simply too labor-intensive for expert programmers. In a lot of respects: it's a better Java. It's also a worse Java.
>>12 I do something similar; I use narrow-to-defun and widen to make things a little easier.
Switch has been available for a long time as a module. It's just been incorporated into the core language now.
> Python programmers on the other hand must be more proficient because their language is harder to use.
I'm not sure I concur. My own experience was that gaining some degree of proficiency was easier in Python than Perl. Some things caused me grief in the beginning, like $_, automatic flattening of lists (thus requiring understanding references), and the implicit conversions.
Perl's concept of DWIM means that it has exceptions to every rule. Python has its own problems (hohoho, does it ever!), but it's explicit without trading off much flexibility.
>>15 I wasn't saying that tounge-in-cheek: Python is certainly easier to learn, but harder to use. The distinction becomes evident when you see how long it takes expert programmers to produce X result in each language, versus how long it takes beginner programmers to become comfortable.
Most python supporters don't dispute this either; they dispute the value of this. To them, maintainability is more important than speedy results.
Hmm. I haven't noticed much difference in development time between the two. Writing functions/methods, creating lists and using loops all have similar overhead.
Of course, I've used each in wildly different conditions, and I tend to stay away from fancier things (e.g. tr///), so that really isn't worth much.
Maybe staying away from fancier things is part of the problem.
If you write python in perl, you don't see any benefits of perl. That's just how it is.
I'll give you an example: I have a routine called find-extremes which finds the largest and smallest values in a list. In python, it might look like this:
def find_extremes(set):
smallest,biggest=None,None
for x in set:
if smallest is None or x < smallest:
smallest=x
if biggest is None or biggest < x:
biggest=x
return (smallest,biggest)If I write this in lisp, I can use the same constructs:
(defun find-extremes (set)
(let ((smallest nil) (biggest nil))
(dolist (x set)
(if (or (not smallest) (< x smallest))
(setf smallest x))
(if (or (not biggest) (< biggest x))
(setf biggest x)))
(list smallest biggest)))or I can write it more CL-ish:
(defun find-extremes (set)
(loop for x in set
maximizing x into biggest
minimizing x into smallest
finally (return (list smallest biggest))))Obviously, it's impossible to see any benefits of CL if you write it like python. Such is the same with other languages- including perl. Consider what this perl-fragment looks like in python:
#!/usr/bin/perl -pi
y/\200-\377/\0-\177/;Any Python programmer would certainly write something like this:
def find_extremes(i):
return min(i), max(i)Obviously, it's impossible to see any benefits of Python if you write it like C.
And your Perl example is contrived; it would occupy a microscopic portion of any real program.
(By the way, you shouldn't call a variable "set". You're shadowing an extremely useful built-in data type by doing so.)
>>19 That python programmer would be an idiot. Why turn a perfectly good O(n) into an O(2n)? If it didn't matter, then find_extremes shouldn't be written at all- you'd just use the min() and max() functions directly.
Additionally, the perl example isn't artificial. It's a real demonstration of something that the shell doesn't provide, but that was needed. Perl made it easier than writing it in other languages, and so it got written in perl; This is something that perl does well. There are things that python does well- you've just demonstrated it gains readability by turning an O(n) into an O(2n) which I think is my point.
> By the way, you shouldn't call a variable "set". You're shadowing an extremely useful built-in data type by doing so.
Normally I agree (when writing python; although shadowing is not directly the reason). I wanted to demonstrate that the logic could be implemented in both CL and python- and started from the CL. In CL you have separate namespaces for types, variables, and functions so bugs of this sort simply don't exist. In fact, it increases readability because you can have variable names like list and function and stream without colliding with other things having the same name.
> If you write python in perl, you don't see any benefits of perl.
I certainly agree, but then there's the question if all the goodies in Perl actually improves productivity. If you know which function or built-in to use, you'll no doubt get a boost. But can you remember all of them? Will you be able to remember all of them later?
Once upon a time I used to know a large amount -- perhaps even most -- of Perl5. Then I promptly forgot most of it and stuck to a subset I found useful. There were too many corner-cases and exceptions for every rule for me to successfully remember them all, and a common cause of grief was when a rule I had forgotten or wasn't aware of applied.
I think cognitive load is an important concern in the design of languages and APIs. Theoretically you could provide the perfect language construct for every conceivable problem, but nobody would be able to understand or use more than a subset. Sprawling libraries are a good example of this too.
I don't pretend to know the solution to moving around complexity, but if most of code that appears in practice for language X and Y is generally comparable in LOC/cyclomatic complexity/<pick some metric>, I'd argue the languages themselves are comparable even despite the more esoteric corners each contains.
> there's the question if all the goodies in Perl actually improves productivity.
Why would you think you need to know all of perl to see any benefit to perl? Do you think someone needs to know all of python to see some of python's benefits?
We know that knowing enough perl increases productivity for small programs or over short development lifetimes. Most python programmers won't dispute this- they dispute whether this productivity gain is important - especially at the cost of readability and future maintainability.
> I think cognitive load is an important concern in the design of languages and APIs.
Do you think having batteries included in libraries accomplishes this better than having them included into the language itself?
> Theoretically you could provide the perfect language construct for every conceivable problem, but nobody would be able to understand or use more than a subset.
How is that different than having a perfect library construct? Why do you need to know all of them in order to receive benefit from any of them?
> Why would you think you need to know all of perl to see any benefit to perl?
This brings us back to my anecdotal comment that I haven't noticed much difference in productivity between Perl and Python. If I knew all or even most of Perl that likely would not be the case.
Of course, I don't. I just can't remember all of it. Rechecking Perl's (wonderful) man pages rather than recalling it won't help me get something done quicker.
> How is that different than having a perfect library construct?
As I said, I don't pretend to know the solution to moving around complexity. Particularly in languages like the Lisps (ignoring special forms) and Forths there isn't any difference.
I'll argue however that using libraries probably gives better conceptual modularity. A language feature can -- for most languages -- be used in any scope and in any file with wild abandon, while that doesn't apply to libraries.
> As I said, I don't pretend to know the solution to moving around complexity.
The connection to libraries is important: Win32 is gargantuan. You'll note that on the whole Win32 programmers tend to be either much less capable or much more capable than the average UNIX programmer. This makes sense, as UNIX is much easier to learn, but what's surprising is that it's also better for prototypes! This suggests the size or complexity isn't always related to its usefulness in rapid development!
So no, I don't think you need to know all of perl, but you at least need to think in perl.
> I'll argue however that using libraries probably gives better conceptual modularity. A language feature can -- for most languages -- be used in any scope and in any file with wild abandon, while that doesn't apply to libraries.
It certainly does in CL- as well as most other lisps. That's probably a big contributor as to why it's so good for prototyping.
> It certainly does in CL- as well as most other lisps.
Could you clarify what you mean by this? Depending on the interpretation I either agree or disagree! ^^;
>>25 I was referring to this:
> A language feature can -- for most languages -- be used in any scope and in any file with wild abandon, while that doesn't apply to libraries.
In CL, a library can and usually does introduce language features using defmacro and/or reader macros.
Sure, but that's the library. If you don't include the library, will it pollute your namespace? If you don't include it, do you need to know anything about it?
Lisp has a few special forms and its braces. That's it. That's all you really need to know when you first dig into any codebase. If there are any differences it's thanks to the libraries. Libraries which have a common basis (the language), making it easier to read.
The language is the basis of everything. It's everywhere. You can't escape it. Therein lies a difference.
I think the English words language and library summarize the situation well. Good luck understanding a library if you do not understand the language.
Hogwash.
Libraries aren't simply black boxes that you can ignore, and language features don't have to be builtin to the interpreter: The language can be mutable. CL has readtables and Perl has source filters which can locally introduce new language features.
A language isn't just syntax, but it is also purpose, semantics, practice, and implementation. Language features can exist in all of those things, and if those features are mutable they can be encapsulated.
> Libraries aren't simply black boxes that you can ignore
If you don't need them, they are. How many people know most of Java's or Python's or Ruby's standard libraries? Nobody.
> CL has readtables and Perl has source filters which can locally introduce new language features.
And how do you read those? It's not turtles all the way down.
> If you don't need them, they are. How many people know most of Java's or Python's or Ruby's standard libraries? Nobody.
Then exactly how is this different than with language features?
Or are you suggesting that nobody can write in C++ because nobody knows all its language features?
> And how do you read those? It's not turtles all the way down.
What exactly do you mean by this?
> Or are you suggesting that nobody can write in C++ because nobody knows all its language features?
We come back to me not seeing much difference in productivity between Perl and Python.
Writing modern C++ properly is something of a challenge too; only template metaprogrammers need to know what SFINAE is, but what happens if you're someone else trying to understand why some template magic isn't quite working the way you'd expect?
> What exactly do you mean by this?
Once you dig past all the abstractions at some point you come across the essentials of the language. The axioms upon which everything is built, so to speak.
> We come back to me not seeing much difference in productivity between Perl and Python.
We come back to you failing to distinct between language features and libraries. You insist that libraries are better than language-features because they are cleaner and "easier to read".
If your point is that fewer language-builtins are better, why are you using python instead of CL or (god forbid) scheme?
If your point is that you aren't familiar enough with perl's language-builtins to be more proficient than with python, then well duh, the question becomes why don't you want to increase your productivity?
> if you're someone else trying to understand why some [C++] template magic isn't quite working the way you'd expect?
Frankly, C++ programmers don't use those features, and they chose a different algorithm. Honestly, I've never seen any other language- not even BF- where the programmer spends more time cajoling the compiler than either thinking about the task domain, or actually implementing it.
> Once you dig past all the abstractions at some point you come across the essentials of the language. The axioms upon which everything is built, so to speak.
What exactly do you think are the "essentials" of a language like CL, if not its mutability?
> You insist that libraries are better than language-features because they are cleaner and "easier to read".
Insist is overly strong. I readily admit this is a murky area, especially with languages like the Lisps and Forths where the boundary between language and library blur and you can change almost anything. Most sane programmers won't go around redefining basic Forth words, but there's nothing stopping them. Likewise with Lisp and atoms.
Also, I think that C++ has utterly fucked itself up because the community insists on pushing as much as possible into libraries when the language clearly isn't capable enough to properly leverage them. C++ has a problem with threads as a result of this -- if I recall some recommendations about it in C++0x still aren't accepted -- and the obtuseness of something as simple as a hash map is maddening.
I am arguing that a simpler basis is easier to comprehend though. Less language-specific knowledge is needed to read any one piece of code.
> the question becomes why don't you want to increase your productivity?
I'm not sure if the cognitive load of knowing -- and maintaining that knowledge -- of most of the tricks that Perl offers will compensate with enough additional productivity. As I mentioned before, Perl has an exception to almost every rule, and they're easy to forget. Unless you're a Perl monk this will creep up and cause problems.
> why are you using python instead of CL or (god forbid) scheme?
I'm not using Python, I don't particularly like it, nor am I arguing for it. Be happy. :)
Alright, well it sounded like something else. I'm still unclear exactly how to apply this:
> Less language-specific knowledge is needed to read any one piece of code.
to lispish and forthish languages? Obviously you "read" them quite differently than algol-style languages.
> I'm not sure if the cognitive load of knowing -- and maintaining that knowledge -- of most of the tricks that Perl offers will compensate with enough additional productivity. ... Perl has an exception to almost every rule, and they're easy to forget.
I disagree. Whenever you're typing tabs, or braces, or dots, or for(;;), or any other syntactic noise- even if you're typing over 100wpm, your brain shuts off and you're no longer thinking about the problem. It's not exactly rest, but it's not exactly productive either. Most of those exceptions are syntactic and not data-related which means they rarely cause problems with real data (as opposed to test data). The few corner cases (defined/undefined/0/1/0e0, for example) are common enough that almost anyone who spends any time in perl is familiar with them.
> Unless you're a Perl monk this will creep up and cause problems.
On the other hand, its not like striving toward perl monk-like status would do anything but make you a better programmer.
>>34
lol what