Damian Conway On Programming, Perl And More 185
Andrew writes: "My host pair.com has an
interview with Damian Conway
in which he talks a lot about his upcoming modules, and what skills
a Perl programmer needs. I'm personally waiting on
Parse::FastDescent." Conway talks about some interesting modules he's working on, Perl 6, and on programming in general, too.
Most interesting (Score:1, Interesting)
At least this interview didn't try to sell me a book.
language preference (Score:2, Interesting)
Re:language preference (Score:2, Interesting)
Why does it demean both? I know there are very "strange" forms of art. I don't find calling code "art" to be demeaning as a coder, however, I think that there is elegance and style in code which definately resembles writing, which is artistic... right? After all, code should be written to be read by humans, not just the computer... Writing the story of how the program's (story's) variables (charachters) solve (defeat) the problem (the dragon/enemy/etc) is pretty artsy to me. Perhaps I'm just confused... it is nearly 3am.
Re:language preference (Score:2)
What a bunch of mindless crap (Score:3)
Craftsmen are artists, a lot of the time. Certainly you wouldn't say things like for example a table to always consider function over form. You might prefer a table that has been designed to be useful over it's appearance, but others might not.
Similarly, you might write code with esthetics a secondary concern, but others may not, witch would make their code art.
Certainly, not all code is art. And certainly some is.
Re:language preference (Score:2, Insightful)
Here's why coding is an art: it can't (yet) be done well by a computer. That is, we don't know all the rules that go into making a good program, we haven't codified them. This is in contrast to most real engineering disciplines, where it is very easy to quantify a superior solution; the only trick is to find it.
What makes something art is how it is made, not what it is ultimately used for. As long as some part of writing good code remains locked in the coder's head it is as much a deep and mysterious art as writing a symphony or creating a painting.
An artist's art != an artisan's (Score:1)
Or, to put it another way: the category of the process is not of neccessity related to the category of the product.
You appear to be suffering from homonymic category confusion
An art, as in artist, is to do specifically with aesthetically purposed construction.
An art, as in artifice or artisan, is to do with any skillful process requiring good judgement and expertise. Hence:
The process of generating science is an art.
The product, i.e. science, however aesthetically pleasing it may be to the scientist, is neither art nor its subcategory Art.
[Science, and code, may be aesthetically pleasing, but for the most part this is not their primary purpose - obfuscation competitions et cetera notwithstanding.]
As for the legal profession's antics, I guess a well written, superbly delivered oration could even be classified as a work of art. But to construct a good legal case is still more of an art than a science.
So, what of engineering and, more to the point, software engineering? Well, to me it is simple. One sense of art applies (artifice) and the other (aesthetic purpose) does not.
Sloppy coding and coding practices are neither.
Okay, I've stopped gibbering (for now). So flame me
[FWIW: I code and I daub]
Re:language preference (Score:2, Insightful)
Methinks you're confusing "art" with "fine art". Webster's entry for art doesn't mention aesthetics until the 4th definition, and even there, it doesn't make aesthetics a required component: "the conscious use of skill and creative imagination especially in the production of aesthetic objects". Note that it's 'especially', not 'only'. The skill and creative imagination appear to be much more central to the definition, and those things certainly play a role in programming.
Even if you insist on including aesthetics in your definition of art, there's a good case to be made that once a basic set of functionality is achieved in a piece of software, improvements in aesthetics can be more valuable than further increases in raw functionality: Consider two pieces of software that serve a similar purpose, one with boatloads of bells and whistles, and one with a smaller, simpler set of functionality. The former is inaccessible and hard to use -- sure, it can do lots of neat stuff, but it's so hard to figure out how to do most things that most users touch only a fraction of that functionality, and spend a lot of time frustrated with it. The latter has less raw functionality, but because it's simpler and more elegant ("elegance" clearly being an aesthetic quality), it's far more useful to most users in practice.
Your bridge example is misleading: The function of a bridge is far simpler in nature than the function of any reasonably complex software, and thus it's relatively easy to consider utility and aesthetics as distinct attributes of a bridge. It's not so easy to consider them as distinct attributes of software.
Re:language preference (Score:1)
Agreed, I got a Bachelor's of Arts (apparently I am skilled at many different forms of art ;). Most of my friends also have a BA of some kind (business, psychology, sociology [works as a waiter], english literature [works as a programmer]). One friend, however, is a painter and sculptor and got a Bachelor's of Fine Arts. There must be a distinction between Art and Fine Art; if you can't trust our intitutes of higher education get the terms right then who can you trust?
Anyway, I'm going to continue to call some of what I code "art" but I ain't gonna put on airs and call it "fine art" and I ain't gonna call myself an artist.
Re:language preference (Score:1)
I mean, icon placement is an underrated science - and the wallpaper? Sheer inspiration.
-swerve D.
scary code? hope you're not open sourcing (Score:3, Insightful)
If you have ever heard of an elegant mathematical proof or an elegant bit of code, this is something like what "artistic" is. It also could mean efficient, clear, etc.
I think you need to differentiate between
- traditional artworks like maybe oil paintings
- artworks which use digital media in some way
- making a statement with/through art
- craftsmanship
- intellectual and visual elegance i.e. of design
Hypercard? Yes, blech. But I hope you think about elegance or craftsmanship at least if you are turning your code out to the public.
We need more elegance in open source code because it tends to 1) make work fun/creative 2) make it run efficiently 3) reduces bugs 4) strong metaphor makes paradigm more powerful/extensible.
Re:language preference (Score:3, Insightful)
Oh, c'mon. You can code badly in any language.
Given Damian's reputation, the fact that the Perl community is raising money to get him to focus on Perl [perlmonks.com], and the fact that he seems to know what he's doing, wouldn't you think that the fact he chooses to work with Perl says something potentially interesting about the language?
When someone I respect praises (or consistently uses) a tool that I don't like, I try to question my opinion and find out what they know that I don't.
Re:Is Programming Art or Science (Score:1)
But it comes to mind that that most venerable CS author Knuth called his highly regarded series of books (or bibles depending on who you talk to)
"The Art of Computer Programming"
So maybe those that argue there is no Art in computer programming should take it up with him?
demerphq -> http://www.perlmonks.org
Re:Most interesting (Score:1)
Constant Updates (Score:5, Interesting)
Although slashdot loves to post Damian Conway stories, those who still haven't had their fill can follow his online diary at yetanother.org [yetanother.org].
Software as Art? (Score:1, Interesting)
Re:Software as Art? (Score:1, Funny)
Two clicks? I think not... (Score:1)
Conway is a Madman, the proof... (Score:3, Funny)
Current projects:
Good God, vi?!
Re:Conway is a Madman, the proof... (Score:3, Funny)
Re:Conway is a Madman, the proof... (Score:2, Informative)
vi is the only remotely usable text editor that is guaranteed to be available on any Unix box. It's the lingua franca of Unix text editing.
vi is a bit bizarre for anybody coming from a graphical environment, but once you get used to it, it is as efficient and powerful as any other text editor with the exception of emacs, but life's too short to learn the bits that emacs does that vi doesn't.
Re:Conway is a Madman, the proof... (Score:2)
That's funny, I didn't have vi on my PDP-11/23 based microprocessor development system that ran V7 UNIX. It just had ed and a vendor-supplied screen editor. I used that system up until a few years ago.
Re:Conway is a Madman, the proof... (Score:1)
And I have heard that ed is the only text editor that is guaranteed to be available on any Unix box (even on the relatively rare *NIXes that don't come with vi...)
Of course, that's not "remotely usable", it's in fact pretty far from casual usability, so you are still correct =)
parse::perl not that bad of an idea (Score:2)
This could actually be useful for things like self-modifying code and the sort.
Of course, writing anything in Perl in the first place is a bad idea, but beyond that, self parsing could actually be useful.
now, if the had had a self-interpreter...
Re:parse::perl not that bad of an idea (Score:2)
Isn't self modifying perl code listed in Revelations as one of the signs of the apcolypse?
--
Evan
Difficult climate (Score:3, Insightful)
I suppose he's talking about the post-dot-bomb world we live in, but these are probably important at any time. Funny, though: a majority of programmers I've known--while intelligent and relentless--place less emphasis on the "documentation, communication, teamwork" skills. Of course, that's where technical writers and project managers come in handy... (heh heh)
One thing I've noticed about Perl people is that they are often very open-minded about using other languages to solve a problem. Maybe it's because they are so used to losing the "let's develop in Perl" argument, maybe because they are more naturally inclined to use every tool available, or maybe it's because they want to figure out a way to parse every computer language known to humanity from within a Perl module...
Re:Difficult climate (Score:1)
I'm a good example of that. If I have to stop working for Perl next year, and start working for pay, I'm fairly confident I'll be able to find a good job. And *not* because I have special skills in mod_perl, XML, data mining, biotech, desktop applications, or
Someone will hire me simply because I'm a very good, very experienced, very reliable programmer. And because I'll bring with me a deep understanding of algorithms, and of program design, and of efficient code structures, and of pure problem solving. I may have to learn about XML or RPC or DNA or some other TLA, but that's okay. They're hiring me for skills that *can't* be picked up from a book, nor to a deadline.
It's obvious that he hasn't even tried to look for a job at anytime within the last year. He wouldn't even get in the door with that attitude. If you don't have exactly what a manager is looking for, you don't have a chance.
Re:Difficult climate (Score:2, Interesting)
One of the reasons for my irrational hatred of all things java is that a lot of people involved with it seem to think that java is a skill. It's not, it's knowledge. In my last company, we did a lot of programming with C and C++ and various technologies such as RPC, Corba, COM etc etc. and yet at least two people resigned because they couldn't put the magic j word on their resume. Careerwise at the time (pre dot bomb) they were right. You could have 10 years of C coding experience, a signed certificate from Donald Knuth that you were the top programmer of all time and you still couldn't get a job in a
Re:Difficult climate (Score:1)
That is so nuts, because Java was basically designed to be easy for C/C++ programmers to pick up. I went from nothing to fairly competent in Java in a month, just based on past C, C++, and OO experience.
Not hiring a competent C/C++ programmer because they don't know java is like ... well, I couldn't even think of a good example here, but trust me, it's a poor hiring decision to not hire that person.
Re:Difficult climate (Score:1)
Re:Difficult climate (Score:1)
I didn't say I was a master yet :) It may take some time to master the details of Java, but the syntax is specifically C/C++ friendly so that it's easy for a C/C++ programmer to jump into Java and start changing things around, trying things out, etc. without having to start from the ground floor. Java may not be easy for C/C++ programmers to master, but it is easy for them to jump into and almost immediately be fairly productive. I just wouldn't make that programmer your system architect for another few months :)
It's the same way that Perl was designed to be easy to pick up if you already knew sed, awk, grep, and sh. Sure, Perl has nuances that are way beyond those tools, but the Perl newbie can still dive right into Perl based on their past knowledge of those tools without too many problems.
IIRC, it was easier for me to go from C/C++ to Java than it was to go from sed+awk+grep+sh to Perl, but I had a lot more time pressures at the time I was learning Perl.
or just maturity? (Score:4, Interesting)
Re:or just maturity? (Score:1)
Re:Difficult climate (Score:1)
Hehehe, good one. =)
One thing I've noticed about Perl people is that they are often very open-minded about using other languages to solve a problem.
I only half agree here. Many Perl programmers have grown out of dynamically generating HTML to CGI to XML and whatever so they are used to working with other languages and have little aversion to doing so. Unfortunately, these open minded groups are interspersed with open source zealots who refuse to look at the problem first and then choose a tool (read: language).
Docs, communications and teamwork (Score:2)
A majority of programmers I've known are the same; not many of the good ones, though. Almost no serious programs can be written properly by a single developer these days. I'd rather have a team of 5 competent but unexceptional programmers who understand the value of communication, than a team of 5 ueberhackers who can't or won't communicate with one another. The former will typically get the job done much better.
What's this guy on? (Score:4, Funny)
By which of course he means good, gooder or goodest. Damn intellectuals.
Re:What's this guy on? (Score:1)
Except my English.
Units (Score:2, Funny)
And if you divide a sibling variable by a knife variable, perl will have none of that mess, you'll have to garbage collect the mess yourself.
Re:Units (Score:3, Funny)
//rdj
Re:Units (Score:1)
Which is, of course, the point.
I'd rather try to parse "sibling by knife divide error in random.pl at line 1456"
Than a completely random error.
Hot tip:
Don't use modules until you understand them.
You haven't thought this velocity issue through (Score:1, Interesting)
You give one velocity. Actually a moving object under acceleration will have a changing velocity. Thus do we need to then worry about:
1. sampling rate for this variable
2. precision of the variable
In programming there is always a different way toedo things. The folks who say "have to" produce kludges like Windoze or Digital UNIX where everything is a non-deterministic messaging stack.
It works for small and trivial things but quickly becomes a mess.
In the case of doing PERL to track velocities I feel that this is an exercise in futility. Here is why:
There is no general case of utilizing velocities for solving a problem. The problem is always specific for whatever is needing to be solved. Imagine a situation where you are tracking all of the airplane traffic around a city. Do you think that a silly rule like "a distance and a time need to have a velocity variable" makes any sense at all?
I can imagine N planes each with varied degrees of sampling position and time.
In any case in order to determin velocity from position and time we need at least two samples of position and time. And then the velocity we get is not real anyway, but an approximation.
And so we see your little therom is incorrect. There will always be FEWER velocity measurements than position and time samples.
Thus do we then nessecitate an further variable that tells us the acuracy of the velocity prediction?
So . . .
those hard rules that you make need to be just put away.
As someone who has done velocity measurements from time and position data I submit that your heart is in the right place thinking about this as a pattern. It is just that you shouldn't be thinking in terms of PERL, but in concept space.
One thing further: for real-time velocity and position measuring of real-world systems with N components, PERL just ain't going to cut it, dude.
Yes, PERL is good for somethings, but don't waste your time writing PERL modules that provide a bad solution for a non-exisitant problem.
;)
Re:You haven't thought this velocity issue through (Score:1)
Re:You haven't thought this velocity issue through (Score:1)
Re:Units (Score:2)
How quaint. In Haskell or Ocaml, you'll get a compile time error. Perl and python might be great for string munging, and since so much sysadmin and web work is strings, they're great for that, but if you want the rigor of typing, you're using the wrong languages...
Design Patterns in Perl (Score:5, Interesting)
Damian mentioned design patterns as one of the skills necessary to become a better programmer. As very little has been written about implementing design patterns in Perl, I've started a project [patternsinperl.com] to produce Perl implementations (and explanations) of the Gang of Four's patterns. Later, I hope that Perl-specific patterns may emerge, but for the moment I'm just trying to create interest in this important area for OO-Perl programmers.
Design Patterns don't live in a language (Score:1, Insightful)
is a recognizable form of software architecture
that we see recur and thus it is cateloged.
If you use a specific language to implement a
design pattern what you have is a
'module' or a 'class'.
One uses a language to IMPLEMENT a design pattern. The pattern exists without the language.
In the same way one can make a screw driver out of tin or out of hardened steel. One uses the steel if one doesn't want the screw driver to break.
The analogy in software is using a steel OS like LINUX or UNIX verses using a toy tin OS like Windoze.
The folks who use Windoze use it because they want to addict their users (victums) to upgrades because the Tin OS stuff always breaks.
As far as PERL goes, whatever. It is cute but not the one and only show in town.
If you are going to talk about design patterns you aren't a 'coder' but an archtitect or software carpenter.
PERL is a cute language suited for WWW work. For other things it doesn't work so well.
I like PERL, but it creates a huge footprint and you have to include the world to get a very large object that runs in an interpreter.
NOT GOOD for a lot of things, pervect for others. Design patterns don't live in a specific language. One uses a language to implement and the pattern itself is something that lives in the programmer/architects mind.
The code becomes a module or an object. It is never the design pattern itself.
Re:Design Patterns don't live in a language (Score:1)
blockquoth:
I sort of agree. The design patterns shown in the Gang of Four (GOF) book [amazon.com] are about class hierarchies, not their implementation in any particular language. However, they have provided implementations of these patterns in Smalltalk and C++. Later books have converted these implementations to Java, COBOL, and several other languages. It's fair enough that Perl programmers get a look in!
Again, although the patterns in GOF are fairly non-specific as to target language, later publications have emphasized language-dependent patterns [amazon.com]. I'm sure that many of these patterns may prove to be directly transferable to mod_perl, but some will not. Likewise, I'm sure that some patterns will be found that are suitable for Perl but which are not transferable to Java.
Re:Design Patterns don't live in a language (Score:1)
Re:Design Patterns don't live in a language (Score:1)
(jfb)
Perls Idiom NOT Perl Specific Pattern (Score:3, Insightful)
I would call that a "Perl Idiom"
It is not a pattern.
Patterns are CONCEPTS not IMPLEMENTATIONS
Re:Design Patterns in Perl (Score:1)
Take singletons for instance. It is an admittedly non-trivial task to get the memory management right in traditional non-garbage-collecting languages, and the only thing you gain for that complexity is not having to store your global data in a global namespace. But the singleton class has to be in a global namespace in order to be globally accessible, so maybe you don't gain anything at all.
I really think that people advocating design patterns need to include the old-fashioned, simple patterns in their list, such as global variables, subclassing, etc. Less experienced programmers learning about design patterns get the impression that they should use these complex, advanced patterns for _every_ problem, instead of using simple solutions for simple problems.
Re:Design Patterns in Perl (Score:2)
An lesson in why Perl is bad for teams.... (Score:4, Interesting)
I read the article with an ever increasing sense of disbelief. Perl is definately a lanaguage for the individual rather than for groups or projects. One person on their own okay, but in a project....
Perl lets me to program in a style that suits me, rather than enforcing a style that some language designer thought would be best for me.
Now that is a quick way to bugger a project, everyone with their "own" style.
Perl is multi-paradigm: I can write code that's procedural, or object-oriented, or functional, or declarative; whatever solves my problem best. I can even mix styles when the optimal solution calls for that.
Leaving asside discussions on whether Perl is "mutli-paradigm" or indeed any language can be. This is another case of great for me, sucks on a project. You would never want to take this approach on a large project, it increases maintainance costs and learning costs for new people.
And then of course the piece de la Resistance... the most important skill is...
programming itself
Let me get this straight, its CODING ? Not Design, not Engineering, requirements, risk analysis or whatever but banging the code out.
I know this will probably get moded as "Flamebait" or whatever, but the reality is this is exactly the sort of language and approach that holds back software development and keeps us in the Dark Ages. Languages like Ada demonstrated clear advantages and had lower development and maintainance costs than C, so all new languages have their syntax based on.... C. Scripting languages have a history of producing huge amounts of unreadable and unmaintainable code.
Why can't we just grow up and realise that this is an Engineering discipline that deserves the same respect and approach as structural, mechanical or whatever engineering. If someone said "well I like using bamboo to build bridges, I'm going to build a 6 lane highway with it" we'd laugh. This guy is talking about the same sorts of things and promoting a language that has none of the advantages of bamboo for bridge building.
At least with people and languages like this, I'll never be unemployed, as there will always be buggered systems to fix or replace.
Newton stood on the shoulders of giants, we fail even to build on the work of pygmies.
Not a troll (Score:1, Troll)
The fact of the matter is that anyone who is involved in professional web site development will know that Perl is becoming less and less important as a scripting language, I believe precisely because of its design and philosophy.
Unfortuately, "Perl gurus" like to write programs which are as short and "clever" as possible. That type of programming is not compatible with large, professional software development projects.
Of course this opinion will probably be modded as a troll as well by those very same "perl gurus".
Re:Not a troll (Score:1)
Also, what do you mean they like to write short and clever programs? Doesn't everyone? Cut down on the lines of code, up the efficiency, its every programmers dream. Many large professional programs have been written in Perl. If you've ever read the Oreily DBI Perl book, the first few pages have several Perl programmers talking about how Perl and the DBI have worked with databases for companies like AT&T.
Perl can very much be used for large projects.
And thus, I leave you with:
"A well written Perl program will run faster than a horribly written C program." (I think Christiansen said that one, but I'm not sure
-Vic
Re:Not a troll (Score:1, Offtopic)
On a personal level, anyone who enjoys computer programming enjoys 'short and clever' programs.
On a personal level I appreciate that this is short and clever:
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^
close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];sleep rand(2)if/\S/;print
However, I think you will understand that no serious professional programmer would use this type of programming in a professional context.
Of course, the above example is extreme, but it has to be said that many "perl gurus" enjoy this type of cleverness and cannot stop themselves even in situations where it is inappropriate.
Most professional programmers understand that "short and clever" is very often bad in a large software project. Read, for instance, Code complete by McConnel.
Re:Not a troll (Score:1)
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{ @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2
Why do people love perl? Maybe I'm a fool but I can't unterstand it. I've uses many languages and IMHO the way C does it (syntax) is still one of the easiest (if you mean programming - not Vbasic things
IMHO php is the best programming language, if you follow some rules.
b4n
Re:Not a troll (Score:2, Insightful)
Well if you follow some rules it shouldn't matter what language you use
1) lack of commenting (duh!)
2) being unfamiliar with a language
3) lack of organization (formatting code blocks)
Perl programmers tend to be bad on the third point, but it's not the fault of the language. Personally I find it easier to read a program where my variables are easily marked with a $ in front, but that's probably a sign I've done Perl to long.
Re:Not a troll (Score:3, Informative)
Well if you follow some rules it shouldn't matter what language you use :) Really though, difficulty reading a language is usually due to
1) lack of commenting (duh!)
2) being unfamiliar with a language
3) lack of organization (formatting code blocks)
I'd add a 4th, though it's related to the first:
4) Meaningless variable names.
I rue the times that I've maintained other people's code that was load with code like this:
temp = foo;
if (temp > = g) {
for (int x = 1; x > rst.length; x++ )
{
if (rst[x] < noid) temp -=
}
}
What the????? What is temp? Clearly not the temperature, since this is a financial application. Is it really that freakin' much harder to write something like:
newInterestRate = STANDARD_RATE;
if (interestRate > = cutoffRate) {
for (int x = 1; x < possibleRates.length; x++ )
{
if (possibleRates[x] < THRESHHOLD) newInterestRate -=
}
}
BTW, sorry for using pseudo-java as a ferinstance.
great point (Score:3, Informative)
My guess is that many programmers haven't had enough painful experience maintaining crappily-written code. Maybe the first thing that should be taught in CS 101 is not how to write "hello, world", but how to take a poorly documented and convoluted program written by somebody else and fix the bugs. (No flames about how CS is about computer science not programming; you know what I mean here.)
For me personally, the incentive to write more self-documenting code was having to maintain stuff I'd written and deployed in commercial environments for a period of years. I don't care how well you knew the code when you wrote it, when your customer unearths some obscure bug in five years' time you're not going to remember a damn thing. And that is a miserable experience. It taught me to take the time up front to save myself the agony down the line.
Re:Not a troll (Score:1)
Re:Not a troll (Score:1)
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^
close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];sleep rand(2)if/\S/;print
[bpoi@beast]$
Reversed
syntax error at
Execution of
Nice try, but it doesn't work.
Re:Not a troll (Score:2)
Nice try, but it doesn't work.
But isn't it obvious why it doesn't work? No?
Know you know what it feels like trying to edit a "Perl Guru's" code.
Re:Not a troll (Score:1)
Know you know what it feels like trying to edit a "Perl Guru's" code.
You have three options:
1) Learn Perl better
2) Write the same thing in another language that you like better
3) Do not program
All of the above include implicitly the requirement to quit bitching that you can't understand it. You think that'll get you anywhere with intelligent people?
Re:Not a troll (Score:4, Interesting)
yes - obvious as soon as I tried running it - lets see
perl -e '@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";
sub p{@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*
map{$P=$P[$f^ord($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;
map{$p{$_}=~/^[ P.]/&& close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];
sleep rand(2)if/\S/;print '
syntax error at -e line 4, near "&&}"
Line 4 , near "&&}"
perl -e '@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";
sub p{@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*
map{$P=$P[$f^ord($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;
map{$p{$_}=~/^[ P.]/&& close$_}%p;wait until$?;map{/^r/}%p;$_=$d[$q];
sleep rand(2)if/\S/;print '
tl hnU ei hPkaecJua/ sterrnoxr
Ok - I get it its a JAPH [cpan.org] - and this guy has obviously cut and pasted
it from somewhere and something has munged his code - presumably the
slashdot form - hmmm -if he's posting HTML and there was to be a line
input operator pair there < > then they wouldn't display
properly in the browser. Wonder what the filehandle name could be - well
the only thing in scope inside that map { } block is the implicit $_
coming from the %p elements on the RHS of the map statement - lets try
that
perl -e '@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";
sub p{@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*
map{$P=$P[$f^ord($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;
map{$p{$_}=~/^[ P.]/&& close$_}%p;wait until$?;map{/^r/&& <$_>}%p;$_=$d[$q];
sleep rand(2)if/\S/;print '
Just another Perl / Unix hacker
Each letter appearing after a certain delay - hey , thats quite cute !
This took me lest than a minute to run debug and fix - without even
analysing the core algorithm there - just responding to the helpful
diagnostic messages emitted by the perl interpreter and fixing the
obvious syntax error ( with a little lateral guesswork ). Bear in mind
that (i)I am no perl guru , by any means and (ii) this
is a JAPH - its supposed to be a cute obfuscated bit of code
for people to have fun decoding and figuring out. So no, I don't
accept your point at all - would you judge the quality of the C
programming language based on the entries from the annual Obfuscated C
contest. No ? I'd also wager it would take you (or me) a damn sight
longer than two minutes to debug one of those [ioccc.org] beauties based
on someone elses poor transcription.
Re:Not a troll (Score:1)
I just have to comment on this.
I disagree. I program for a living and for fun, but I think "clever and understandable" beats "short and clever" every time. Plus, "short and understandable" beats "short and clever" fairly often. Yikes! I know some people think obfuscated code is clever. I'm not one of them. If that's clever then Earnest was right - cleverness is overrated.while I agree... (Score:2)
All in all, I don't really care about lines of code and efficiency (of execution). CPU time is absurdly cheap. Human time is extremely expensive. So I care about time to develop and maintain -- if that means a slightly longer, less clever, and easier-to-read approach to solving a problem, that's likely the one I'll choose.
Re:An lesson in why Perl is bad for teams.... (Score:1)
MosesJones makes a damn good point (upto the last couple of paragraphs, theyre just flamebait). Perl is a scripting language - remember? Its great for knocking up odd bits of code to do simple (or even not-so-simple) tasks but anything greater than 100 lines rapidly becomes a headache to maintain. I don't even want to think about a team-based project writing in perl.
Re:An lesson in why Perl is bad for teams.... (Score:1)
Re:An lesson in why Perl is bad for teams.... (Score:1, Insightful)
Like any other language, you modularise when things start to get out of hand - too many of folks here have clearly never used perl in big projects and just assume we're all writing vast clones of bash scripts - that's just plain wrong. You also clearly define a house coding style at the outset of a project, and review regularly to ensure that style is enforced - perl can be as clean as you want it to be IMHO.
At my last company we used the usual suspects of apache, mod_perl, emb_perl with an Oracle backend to drive a big UK financial web site. We made heavy use of HTML components and modules, would use CPAN for existing solutions to problems, or write our own re-usable, modular code just like anyone would do in any other language. There is NO inherent limitation in perl preventing folks from doing that.
It was also interesting that we had the usual suspects complaining about site performance and how everything would be better with IIS/ASP or JSP - in virtually every case I was involved in we profiled the code and found it was caused by sub optimal database queries or database/network performance limitations, not perl itself.
Us poor misguided fools using perl on big projects are fully aware of how much perl can really do - equally we're aware of its few but definite limitations - OO is currently not a strength - but perl 6 should overcome this, and there is an impressive number of talented programmers out there working to deliver it.
Why not rejoice in the fact that we have such a wonderful variety of excellent programming languages - or would you all really prefer to be coding in C++?
Discipline in art is independant of the medium (Score:5, Insightful)
Next, 'programming' is not the same as 'coding'. Programming has come to mean all the terms the author of the above post used: Design, Engineering, Requirements, Documentation.
The author of this post is half-right, but missing the big picture. There are folks who develop with maturity and discipline with Perl, and there are folks who write garbage in every language. The freedom to screw ourselves over is necessary for us to learn how not to screw ourselves over.
So no, Perl isn't bad for teams, self-centered programers are bad for teams. I should know, I've been that programmer.
(If I felt like invoking flame-mode, I'd suggest that perhaps the poster is coming from an academic or corporate background where individualism is bad for the hierarchy...
Re:Discipline in art is independant of the medium (Score:2, Interesting)
People can write obfuscated C yet you don't see (as many) people running around crying murder, mayhem, and the end of the world at C. It is just annoying to see people trash a language like that, for any reason.
I can write code that is completely unlike anyone else in my project in *ANY* language you can give me. It is the job of a good project manager to ensure that peer reviews are conducted in an orderly and sufficient manner. It is a good project managers job to come up with the programming standards for a project.
With standards on the style of how a language should be used and a disciplined team, your code is coherent. With an team that has less discipline you will see things are a bit more chaotic.
Notice, the language simply does not matter. Perl infact should be better in MORE projects if you can change the style and form of the code and the way you write it, simply because it suits more needs and projects that way.
All of this said, I don't use Perl as a personal choice. I never buy the argument Perl is hard to read or write just because it is Perl, I just don't use it.
Re:An lesson in why Perl is bad for teams.... (Score:1)
Just because a language (in this case Perl) allows the programmer to program which ever way they like, it doesn't mean that they should.
Ideally any large project, or better still any program should be planned and specified before one single line of code gets written.
Standards and specifications are exactly what forces programmers to code in a manner that can be understood by the rest of the team, and in many cases will make life easier for the said programmer.
In theory it should end up in a better final product - if the initial specification phase is done properly, then most problems should have already been thought of - all you've got to worry about now is the customer changing the goal posts for the third time this week :-)
Re:An lesson in why Perl is bad for teams.... (Score:1)
You obviously misunderstood the article. After Conway says that programming itself is the most important skill, he goes on to say,
He obviously includes design and a deep understanding of how software works as part of the discipline of programming. He is not talking about just "banging out code."Re:An lesson in why Perl is bad for teams.... (Score:1)
Not to mention that all languages have features which yeild hard to understand code IF over used, i.e. templates+overloading in C++, automagical variables in perl, lambda notation in a functional language(Haskell), pointers in C, etc. I'd pick one from Java but I haven't programed in it enough to know, but I refuse to believe it is impossible to write obfuscated code in any language.
If only more would see . . . (Score:1)
After all, I'm not hiring them to replace my domain expertise; I'm hiring them to get a job done -- a programming job. So I'm going to hire someone I can explain my problems to quickly (that's where the "minimal understanding" comes in handy), and then unleash them to develop a solution that's correct, efficient, robust, maintainable, under-budget, and on-time.
That's a great piece of insight that a lot of managers/employers/HR people need to keep in their hip pocket. It seems too many can be dazzled by the knowledge, but miss the lack of ability to perform their intended task quickly and efficiently!
Method redispatch (Score:1)
This project would also require
1) a mechanism to redefine class representations and instances on the fly - similar to
(defmethod update-instance-for-redefined class
2) a mechanism to "save core" under Perl (does this one exist yet?)
Ach du Lieber (Score:1, Troll)
None of these are good reasons to use Perl. None! These are all reasons that Perl is a maintenance nightmare, and not at all suitable for programs in excess of five hundred lines, or programs that will ever have to be modified.
Even good Perl is some of the worst code I've ever seen.
Just say no.
I disagree. (Score:3, Insightful)
We have a large number of very large and complicated projects done in Perl, plus literally thousands of minor, single-use programs. There have been no maintainence issues to speak of.
Perl, like any other language, can be written in such a way as to only be comprehensible by the authour. But if you optimise the code for *LEGIBILITY* - ie, no use of "$_" or the "implied $_" then Perl has spectacular legibility. Much better than C, C++, or (especially) Java.
In fact, the projects that meet or beat deadlines are usually written in Perl. Those that miss deadlines, drag on for ages, and prove impossible to maintain once complete are written in Java.
That's the real beauty of Perl, from a large-project-maintainence point of view. Perl's "there's more than one way to do it" idiom means you can write code such that it is much easier to maintain than a "bondage and discipline" language that only has One True Way to code in. Java's syntax is optimised for the language designer's preferences and tastes, where Perl allows you to optimise for the needs of the project.
Y'know, the anti-Perl sentiment that runs through a sub-population of Slashdot reminds me very much of Medival England, back when French was the language of the Royal Court. French was considered the language of nobility, and English was the language of commoners. English was gauche, ugly, and messy.
But (and I'm a fluent French speaker, so I know whereof I speak here) English is a far more flexible and adaptable language than French is. You can write some really horrible, incomprehensible stuff in English, if you want to. But you can also write Shakespere. French - even the French of Voltaire and Hugo - is still pretty much French.
In the Darwinism of languages, French (once the lingua franca of the world - note the irony in the term?) has been relegated to second-fiddle status and is on the decline, where English is now the closest thing to a global language we've got, and is on the incline.
So too is Perl.
Re:I disagree. (Score:2)
People seem to think that if they use Perl, they can ignore solid software engineering principles like code reviews, documentation, etc.
Poorly written code with too much use of $_ shouldn't pass a code review -- it should be rewritten to follow the organization's standards.
Perl is a fantastic tool, but it's not a panacea. You still have to back it up with a strong foundtion of software engineering.
Re:I disagree. (Score:1)
Of course it also give the prgrammer the ability to write in klingon, which can be harder to understand for some people.
Re:I disagree. (Score:2)
> I work for a Major Automotive Manufacturer's ITM department, and Perl has saved our lives.
Yes, Perl is a usefull tool, but it isn't the only one..
Why couldn't have you used Python instead?
Being more readable than C/C++ is not an impresive feat!
I hate Java myself: too much bugs in the standard library, the design of Swing is nice but its implementation is buggy and slow.
> s. You can write some really horrible, incomprehensible stuff in English, if you want to. But you can also write Shakespere. French - even the French of Voltaire and Hugo - is still pretty much French.
Mmm, the French slang (l'argot) can be quite hard to understand too and I'm French!
But frankly the fact that now English rules and that French is less and less spoken has NOTHING to do about which language is the more flexible!
It is a consequence of the economic domination of the USA..
If in the future China rule the world (economicaly speaking) then people would more and more use Chinese..
Re:Ach du Lieber (Score:2)
what skills a Perl programmer needs (Score:1)
I really don't get it (Score:5, Insightful)
I do not understand why a majority of people on
Try it before you knock it. Give it a chance. If you don't like it then use the tool you like but don't keep spreading flames and lies about it. Saying its only good for 500 line programs or that its always unmaintainable or it can't be used by teams simply isn't true. And ANY language can have all of those attributes.
Perl also has a great community that I've not seen in other languages. Don't know how to do something, ask Perlmonks. Those guys are even one of the few places where newbies can come. Very rarely do I even see someone screaming RTFM at them. Most of the time you just get your question answered and answered fast. There are other places that aren't so kind.
Perl is great. Long live Perl
Because Perl can be tough for teams (Score:3, Insightful)
However, Perl is really a language that I find more suited to "glue" than use on a continuing basis by teams of programmers. The vast majority of Perl (and a LOT of C++ for that matter) code I have seen used by teams was phased out MUCH faster than the equivalent PHP+C, Java, or Python code. Now with Inline.pm perhaps the horrible problems of using XS or Swig for wrapping "real" code are gone, but the fact remains, without a LOT of discipline and some bitter years of experience, Perl offers more chances for a programmer to take shortcuts. Again, great for quick glue jobs, but bad for long-lived projects. For what it's worth, the C++ code that got shitcanned was big on templates, gratuitous operator overloading, and all the other Perl-like shit that I hate in C++... if there's one good thing I can say about Java it's that it isn't C++.
But I *hate* the current Java platform with a seething passion. I don't really like C, and I can't hire a bunch of Common Lisp or Python programmers off the street. Ada? Probably, but who wants to deal with DoD curmudgeons? So every approach that I can see is a compromise in some respect or another. All the "good" ways to write code have their problems. Perl's problem is that it offers lazy programmers (oops, that was redundant) many, many ways to churn out spaghetti that "works"... for a while.
As un-fond as I am of fuddy-duddy computer scientists, their focus on formal correctness, proofs, and mathematical solutions to problems is really where it's at when you are solving a problem that hasn't been attacked before. If you're just re-inventing the wheel, Perl (or any other language) is fine, but if you need to parallelize development of some fast, bug-free innards code, it isn't what you want to release in.
I use Perl on a daily basis for configuration, scripts, etc. because it's the best tool for those jobs. Right now I am the only programmer on my team. When that changes again, I'm going to have to go back to a more easily maintained solution, which looks like it'll be PHP+C for most of my tasks. (did I mention that I hate Java with a seething passion? Too much work for too little payoff) This isn't too tough since PHP and Perl have equivalent means of using extension classes, etc. and PHP is actually easier than Perl to integrate directly with C (across-the-board, not just using Inline.pm, which I admit rules). Work with a large team doing development with some custom extension code, etc. and I'll bet dollars to donuts that you, too, will one day shrug your shoulders and admit that Perl is not right for all types of work. It's also a bit baroque and the syntax can be frustrating for people who aren't from a Unix background. I started out sharing your perspective years ago because Perl is SO very wonderful when you're working all by yourself. But it isn't so great when you're with a team. Especially if you are working on code that is inter-dependent with other programmers, it's important to be using the same or similar approaches to solving problems, and this is anathema to the TMTOWTDI credo at the heart of Perl. I'm not going to hedge on this claim -- I, too, make a LOT of money writing Perl and other code, I've done so for years, I appreciate the CPAN and Perl community, and I try to give back -- but I refuse to be a simp and just crow about how great Perl is for EVERY situation, when I have seen so much evidence to the contrary.
(It is still the greatest string manipulation and glue language known to mankind, though. And many of the one-offs I wrote in Perl have made my company tens of thousands of dollars. So the fundamental truth, "Use the right tool for the job" still holds!)
Re:Because Perl can be tough for teams (Score:5, Funny)
I agree Perl provides a lot of freedom to solve problems in the way most suitable to you. However, to use Perl successfully, you still need to set standards for acceptable algorithms, approaches, and documentation. This is exactly what you would do in Java, and exactly what you would do in C++ (i.e., by saying no templates/operator overloading).
I'd argue that such standards are necessary for any significant development effort - its just the nature of the beast, when trying to get multiple people to work together to tackle a problem.
So how do you use Perl effectively in a structured environment with teams of programmers working together? Here's a few ideas:
1) Code reviews. All code written for a team msut be reviewed by the team. This is absolutely essential to keeping the system functioning. If the team rejects it, the code must be fixed.
2) Documentation. Perl provides POD, a simple and standardized way to document the code you write. Enforce a standard that code without *meaningful* POD is not acceptable.
Note that documentation also means you need to document more than the code - you need to document the design decisions, the requirements the code tries to satisfy, and the assumptions made for the system as a whole. Without proper system/process documentation, a development project will fail.
3) Create standards for acceptable approaches to solve the problem. For example, Perl provides eval for exception handling - you could mandate that all external error handling code make use of eval to keep error detection orthogonal to error handling. You could (and should) require team members encapsulate code in modules, and provide documented interfaces to those modules. Code not encapsulated in a module will not be accepted into the tree.
There are only a few examples to illustrate ways to make development in Perl successful for your organization. These are the same problems you tackle in developing a sizeable project in any language with a team of programmers - Perl is no different, and is not a panacea for those problems. However, if standard management and structured development techniques are applied, developing in Perl can (and will) work for large organizations.
Perl is no different from any other technology in this regard. that for a large project, it is essential to set standards
Re:Because Perl can be tough for teams (Score:2)
Yes on 2, no on 1. What you said earlier:
is true, and it it more true about Perl than it is about many other languages. I have often asked myself, "Why do I love Perl so much? Why is it that every time I come back to this language it's like falling in love again?". And a big part of the answer is that it is so expressive (Larry designed it this way, being a lover of spoken language). I don't feel forced into coding things in a particular way. Also, as I grow in my understanding of the language I find that I can express myself more efficiently and concisely.
I really love Perl. But as an honest observer I have to admit that there are consequences to this freedom, which, again, I think undeniably exceeds that of other languages. If you need to iterate over every line of an array, for example, how are you going to do it? In many languages there is only one way that the average person would think of coding it.
In Perl, you might do a for (or foreach), with a named dummy variable (or you could take advantage of the fact that $_ is automatically assigned), followed by a brace-delimited block. Or, maybe you will be able to do the guts of the block in one line and you can just tack the "for" on the end as a statement modifier. Maybe you think "map" is the way to go. Maybe you're trying to learn about map and want to see if it works in this situation.
I love Perl precisely because it allows all of this--freedom, in my opinion, is a wonderful thing. But the existence of freedom and the extent of that freedom guarantee that there is going to be more variability in the way things are coded.
I'm not saying that you can't use it in groups or anything like that, but I think it is incorrect to say that it is no different from any other language in that respect. When people are free, they are going to wander further from each other than they would if they were not free to. I still think freedom is good. And I think that we should be responsible with our freedom. But that doesn't change the fact that Perl gives you more freedom, and that this fact has implications.
Re:I really don't get it (Score:1)
Perhaps part of the reason why you don't agree with other people's assessment of Perl is that you aren't very experienced in the alternatives.
I think Perl is a fine replacement for /bin/sh scripts.
But, I have seen people write applications in Perl, and it wasn't
pretty.
Re:I really don't get it (Score:2)
Of course any program in any language can have those attributes. But are you seriously arguing that all programming languages are equally maintainable or equally usable by teams? Are False [fov120.com] or Intercal [muppetlabs.com] really just as easy to maintain as Perl or Python? Is csh just as easy to write a 500,000 line program in as C++?
Obviously anyone saying that you can't write a maintainable or large program in perl is overstating the case. What more reasonable people are saying is that perl makes it easy to hang yourself, probably too easy. We can all sit around and say only other programmers make mistakes and thus we don't need a bondage and discipline language but when you look at the state of the average code base that argument is hard to take seriously.
Re:I really don't get it (Score:2)
I think that you are making a big assumption here. I suspect that a lot of people who dislike perl are those who have to use it. I'm writing in perl at the moment because I need some libraries written in it. It would take too long to recode these in a language that I like, so I am using perl.
"Try it before you knock it. "
Same assumption here I think. Many who knock perl have already tried it.
I'm not particularly religous about perl. I would just rather avoid when I can. Every computing langauge is of course a compromise, but for me many of the compromises that perl makes are in the wrong place. In particular I would say the syntax is horrible, or at least very complex. The "more than one way" philosphopy I find annoying. My experience is that perl code from different authors tends to be highly idiomatic. Its object orientation appears to me to be rather poor. You can't for instance define a interface contract (I'm sorry but "read the documentation" just doesn't cut the mustard for me). And finally its poorly typed. So its not openly declared what types a method or function takes, nor what types they return. At least not without reading either the documentation (if that exists, and its correct), or the implementation (which is not reliable if you are trying to address a common interface.
Now of course perl has its strengths. Its text processing is powerful (I've done a lot of text processing in Java for instance. Bad trip). It can be very quick to write (although I find this becomes less true as code gets more complex). CPAN is a fantastic resource (and a curse! Its why I writing perl at the moment).
Personally I wouldn't get attached too much to any language. You can write long programs in it, you can maintain it, and you can use it in teams. But to my mind this is indeed where perl is weak.
You will note that this is not a flame...
Phil
Re:I really don't get it (Score:2)
Well I'm a self taught programmer as well, even though I work in a CS dept!
Its one of the reasons that I don't like Perl. I haven't grown up being to remember all the obscure syntatic elements, and whether I am using an array, or a scalar reference to an array, or whatever. I like the compiler to know this stuff, and check that I have it right!
Call me a wimp if you like!
Phil
Re:I really don't get it (Score:3, Funny)
CmdrTaco? Is that you?
Steven
You don't have to be limited: CPAN (Score:3, Interesting)
But of course, you need to use perl.
Netlib [netlib.org] may be the closest thing I know of for numerical analysis. While CPAN doesn't have the depth of numerical analysis the netlib does, it has much more breadth. I can usually find something that makes a new project much more quickly than I can code it up myself. CPAN is one of the big reasons I use perl
Keep you credit card in your wallet, leave the purchase requisitions in the file folder; keep your money and your sanity. Just check out CPAN!
Baroque?? (Score:1)
I used to do a huge amount of C++ programming too, and enjoyed it. But that was back before the committees got hold of it and turned it into a baroque monstrosity.
And there I was thinking Perl was pure baroque with all that weird syntax. The clarity of C on the other hand is Enlightenment. Which makes Pascal Renaissance.
So what would Leonardo da Vinci programmed in?
Oh, dear, there does the little karma I had
Identification is not necessarily exclusionary. (Score:1)
check out Playing both against neither [objectmentor.com] (pdf format) which gets into the fallacy of the "exclusive or" mentality which seems to be apparent in many of the messages post here (so far).
The world is much too interesting, even the parts, like programming languages, which we've created, to be so easily pigeoned into such small compartments.
Perl vrs. Python (Score:3, Offtopic)
# print the whole thing one at a time
for $i ( 0
for $role ( keys %{ $LoH[$i] } ) {
print "$i: $role is $LoH[$i]{$role}\n";
}
}
in Python:
for i in range(len(list)):
for key in list[i].keys():
print i, ": " + key + " is " + list[i][key]
Consider line 2 of both examples. Perl's contains 11 non-alphanumeric typographical symbols. Python's contains 6. On a purely visual level alone, I can't imagine anyone preferring to maintain the former over the latter. Furthermore, Perl requires the explicit "% { }" foo so that it knows it's dealing with a hash, an issue Python doesn't face. (Orthogonality... now _there's_ a concept!)
Now take the above Perl example and imagine if you're using a _reference_ to an array of hashes, as in:
foo = \@LoH;
for $i ( 0
for $role ( keys %{ $$foo[$i] } ) {
print "$i: $role is $$foo[$i]{$role} \n";
}
}
Sweet Jesus, my eyes are hurting! I started using Python 6 months ago and for general purpose scripting, I swear I'll never go back to Perl if I'm not forced to.
Re:Perl vrs. Python (Score:1)
What I dislike about Perl... (Score:1)
I understand the sentiment of some when they equate Perl with "line noise" - we have all seen the lovely "one-line" Perl scripts which seem to "be all that and a bag of chips" - scripts that seem to do the impossible, sometimes.
I am sure we have all seen instances of this same type of coding within larger Perl systems, as well. I know I have looked inside some modules I have download, some code I have picked up in places, and nearly gagged at some of the stuff I have seen...!
Sure, it worked great - but unless you are a master regex wizard (regex is something I am still trying to grasp the complexities of - whoever came up with the system should be beat - I mean, if you want to do something complex, that is what coding is for - not everything should be done on the command line!) you can't understand it. Regex, unfortunately, seems like a "must-to-know" to do certain things in Perl, it seems. I don't want to really come across as knocking regex too much - I attribute that more to my lack of understanding. I am sure one day I will come to "love it".
I think what upsets me the most is that many of these "wizards" assume that because they wrote the regex code for a certain function, that others can easily read it. However, it is apparent by the number of people who refer to Perl as "line noise" that others find those expressions hard to read!
I think it would be better if those expressions were broken out/down into seperate lines, with comments explaining what each section is doing (why is commenting so hard for most programmers to do? You want fun? Wade through the Descent I code - this from a pro game house - hahahaha! - non-commented C code at its finest - but I digress). If they must, because of performance reasons (I don't honestly know for sure), provide the single line version as well, and put the multi-line version in comments or something.
Nothing makes me loath Perl more than trying to figure out the bits (that should be "huge bits") of regex almost invariably scattered throughout...
Regular Expressions (Score:3, Informative)
A finite state machine is essentially a set of rules that operates on a string. Given the current state and the input one travels to a new current state. The theory of finite state machines is integral to the development of computer science and has a very strong mathematical foundation. A computer language that can be represented by a finite state machine is called a regular language.
This is where regular expressions come in. They are essentially user constructed finite state machines. The input is the text, and the state is the curent symbol (or symbol set). If you match the current symbol, you move to the next. If you don't you go back to the beginning. If you reach the end of the symbol set, you have a match.
Regular expressions weren't made up to confound you, they were the implementation of a sound mathematical method that is very useful for text processing. However, regular expressions by themselves are not enough to form a Turing Machine, or even an approximation of a Turing Maching (which is what the computer sitting on your desk is).
Moving to more practical matters; regular expressions are not easy to read. You're working on raw characters, and you have to have lots of escaped to handle everything. They become easier with practice, and are very useful. The biggest problem with them is that every application (Perl, vi, emacs, grep, etc) use their own syntax for them, which means you have to shift gears every time you try to use them in a different application. But that is a problem with the implementation, and not the tool itself.