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."
If not for "my", what else would you use to declare variables? Nearly all structured languages require you to declare your variables, and it's just good programming practice.
Maybe "my" is an poor choice of a word to use (same with "use vars", "our", or "local"), but automagically creating variables is asking for trouble -- really unreadable trouble too.
Also, perl 5.8 (and I'm pretty sure earlier versions) have full UTF-8 support.
If existing software can parse HTML or VB with its lexical parser, what makes you think any other parser would be unable to do the same?
Although strictly speaking from a computer science perspective, matching parenthesis cannot be done with regular expressions (finite automata). But you can do it in perl with backreferences.
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.
The whole idea of perl is that you can write quick scripts or real applications without learing a new language without having a deep understanding of programming.
The only problem is when people who write quick scripts decide to try and make real programs, and the result is unreadable spaghetti. The same thing used to happen when sysadmin "gurus" strung together unreadable combinations of shell, sed, and awk...
If you to do "serious" programming, "use strict;" is your friend. Or waste time with C or Java.
Conformity is the jailer of freedom and enemy of growth. -JFK
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
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