Slashdot Mirror
Perl Features of the Future - Part 1
Kevin writes "This story
highlights some of the features being included in Perl 6. "There will be substantial changes in the move from Perl 5 to Perl 6. We've been hamstrung for a while by the need to maintain backward compatibility all the way back to Perl 1. There are some things we want to remove, because they seemed like good ideas when they were introduced but they're more trouble than [they're worth] now."
Hey, it's perl. It's not like you can read it.
I'm so f**king tired of hearing how perl is hard to read.
ITS NOT HARD TO READ UNLESS YOU MAKE IT HARD TO READ!!! and this is true for ANY and EVERY language out there. I can read perl all day long without problems, as long as it wasn't meant to be hard to read, but if you put a C program in front of me it might as well be some made up language that doesn't work, i woudln't be able to tell the difference.
I've come to the conclusion that those of you that say perl is hard to read either a) don't have a single solitary clue about perl at all, b) are trying to stir people up, or c) are trying to convince everyone else that your favorite language is "better" for each and every circumstance, which isn't true of any language at all, not even perl.
Hey, its Slashdot. I'm voting for all three.
NFA's (and Deterministic FA's. They're mathmatically the same thing) are the math backend that define regular expressions.
They're state machines. They're in a given state, and they know how to go to the adjacent states. So given the string 'abc', if you're currently looking at the 'b' (having already seen the 'a'), you know that you'll have a valid match iff the next character is a 'c'. If it's not, you have no match. if you have 'ab[cd]', and are looking at the 'b', you know you have a match if the next char is a 'c' or a 'd', you've got a match. 'c' and 'd' then are the 2 next valid states.
The nifty thing (and the limiting thing) is that true RE's require no memory. Just the knowledge of what state they're currently in. For this reason, no true RE can be written to see if a given string is a palendrome (you can write a RE to match a specific palendrome, but not an arbitrary one).
The difference between a NFA and DFA is that NFA's allow 'null transitions'. This basically says that there are more than 1 state that you can leap out of when you see the next character, because you can go to these special adjacent states without seeing a character, and then leap out. There's also a proof out there that any NFA can be written as a DFA.
All of that said, Perl's extended RE's are not true DFA's. They have some features that can not fit into the DFA model. This is one of Larry's reasons for wanting to make Perl's RE's into true CFG's (context free gramers).
This model is much more powerful than RE's, but at a greater cost, since you have to have memory too. The mathmatical definition of a CFG is a state machine that drags around a stack of memory. The state machine may at arbitrary times push data onto the stack, and later pop it off. It must be done in order though (to match the math model. If you add a second stack, you have the definition of a 'turing machine' (aka the computers on our desk)).
A CFG can be written to match arbitrary palendrome's for example (just push each letter onto the stack, and when you hit the middle, start poping off, and matching each letter. Yes, this is over simplified. The true algorithm is left as an exercise for the reader)
Zapman
I agree.
I think every computer scientist worth thier pay should realize that language advocacy stinks. Every language has its niche--a reason for why some guy sat back and said, "I need to write a shortcut language to do this" or "wouldn't it be great if I could have a better correlation between the way I think/design and the language I write in" and it evolves from there. Perl was designed as a glue language heavily modeled after awk/sed and other unix tools and the concept of following natural language and "having more than one way to do/say it" so you need to have a good feel for the language pieces as you do when you become a master of english and understand different connotations and methods of stating something.
That being said, it is unfortunate that because there are large groups of people who either A) get religious about the language they choose or B) choose not to learn other languages to a point of knowing thier true niche we take every language and bloat it out and take it out of its scope. And in turn that makes it that much harder to grasp each new languages niche because you have to sort through a bunch of crap that trys to make every language the universal language.
Well, it's human nature I guess. Easy to point out as a problem but not easy to fix...but remember that the next time you are about to tell your coworker that they should "write that in _____" instead of answering thier question. Or, be careful when you complain that "____ is bloated or is too hard to understand" because you are just adding fuel to the fire my friend. It is better by far to state why you chose a certain language on a certain project than to be a universal advocate of "_____".
Advocacy is a clear mark of inexperience.
I need a TiVo for my car. Pause live traffic now.
Maybe I won't get invited to the PERL hacker parties any more, but I have to agree. PERL 5's hacks for object oriented programming have always seemed unnecessarily complicated and ugly, and I don't see things getting any better in PERL 6.
...)
I too looked at Python. Like you, I decided that basing your language's syntax on differing amounts of whitespace was a really, really bad idea, not because it's ugly, but because I have enough trouble keeping tab damage under control on a single platform.
So I'm looking at Ruby. In fact, the only thing stopping me ditching PERL for Ruby tomorrow is lack of time for re-learning, given all the other new stuff I'm learning right now (J2EE, Objective-C, Cocoa, OpenGL,
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I meet none of a, b and c. Here's my opinion:
Python is easier to read than the equivalent Perl code, even if the latter well-indented. Now before you close your mozilla tab, or mark this as "Flamebait", please hear me out.
Yeah, I agree that bad code is bad code, regardless of the lang.
But compare these two equivalent statements of good code:
pythonNumber = 1
my $perlNumber = 1;
Do the "$", the "my" and the ";" look necessary, or extraneous and confusing? They are the latter to me.
What about $_ and @_ ? Those don't seem very sensible. Nor does "<>", the backtick "`" or several other common Perl paradigms such as the fact that it makes a big difference whether you have single quotes or double quotes around a string.
Yes, I agree that some of Perl's "hard-to-read" reputation is deserved, but not all of it.
Why do reasonable people think Perl is hard to read? Because it has lots of unneeded, non-alphanumeric characters and there are lots of conventions that don't make sense (e.g. '<>' meaning a line of standard input).
Joe
http://www.joegrossberg.com
If it's not hard to read, then why are the designers of perl 6 making a lot of efforts to make it a lot easier to read than perl 5?
Quoting Larry Wall from the Apocalypses:
- In fact, regular expression culture is a mess, and I share some of the blame for making it that way. Since my mother always told me to clean up my own messes, I suppose I'll have to do just that. [emphasis mine]
- But Perl has often been tagged as a language in which it's easy to write programs that are difficult to read, and it's no secret that regular expression syntax that has been the chief culprit. [emphasis mine]
- there's a lot of regex culture that needs breaking.
- [Read all of Apocalypse 5 to learn exactly why perl 5 sucks to read. Even the extended syntax ain't really the most readable syntax.]
- As a specific example, there are various ways things could improve if we muster the courage to break the ``weird'' relationship between @foo and $foo[].
... the botch that in Perl 5 requires us to distinguish $foo[] from $foo->[]
- I think length(@array) should be equivalent to @array.length(), so if there's a length method available, it should be called.
- Legacy Perl $pkg'var Should Die.
- odd looking constructions like: $foo->[1][2][3]
- We're definitely killing Perl 5's slice syntax
- Various special punctuation variables are gone in Perl 6
- Typeglobs are gone.
- I'd like to get rid of the gratuitously ugly \E as an end-of-scope marker.
- I've always thought qw() was kind of ugly, so I'd like to replace it with something prettier.
- Angle Brackets Should Not Be Used for File Globbing. Indeed, they won't be. In fact, angle brackets won't be used for input at all, I suspect.
- This allows us to simplify the special case in Perl 5 represented by the _ token, which was always rather difficult to explain.
- The basic underlying question is "What exactly do those curlies mean?" For Perl 5 and earlier, the answer to that question was, "Too many things". Or rather, too many things with inconsistent rules.
- curlies are so extremely overloaded in Perl 5
- The old use integer pragma was a hack.
There's more, but I got tired of skimming the Apocalypses.I agree. I was unduly influenced by Ada syntax here, and it was a mistake.
Just for a point of reference, I'm a perl programmer who doesn't fit your categories (a), (b), or (c), but still finds perl code hard to read fairly often.
With all that said, I'll close with one more quote from the Wall: