Slashdot Mirror
Damian Conway On Programming, Perl And More
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.
Although slashdot loves to post Damian Conway stories, those who still haven't had their fill can follow his online diary at yetanother.org.
Current projects:
Good God, vi?!
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...
I've got a bad attitude and karma to burn. Go ahead. Mod me down.
By which of course he means good, gooder or goodest. Damn intellectuals.
Free Java games for your phone: Tontie, Sokoban
i found his choice of programming languages very interesting myself. he really seems to be a big fan of elegance. personally i've always found the idea of thinking of code as art to be rather offensive. i mean: i code and i appreciate art. i think to suggest that there is a crossover demeans both. not to mention that he praises the hypercard scripting language and i have something of a vendetta against it having spent several months once trying to update a massive piece of edu-software written entirely in uncommented hypercard script. blech.
lysergically yours
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.
Free Java games for your phone: Tontie, Sokoban
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 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.
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.
An Eye for an Eye will make the whole world blind - Gandhi
> 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 think its a result of hackishness: a common trait amongst perl programmers is to want to solve a problem in the fastest, simplest way possible and most are mature enough to admit their favourite language isn't always the right tool for the job.
You can be artistic or even create artworks with anything.. although I once found visual basic to be a big impediment.
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.
No coding is a craft or maybe engineering, not an art. An artist's objective is to produce something that has an aesthetic quality. An engineer's or craftsman's objective is to produce something that performs a function. "Aesthetically pleasing" is secondary. e.g. the function of a bridge is to get people or things across a river without them getting their feet wet
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.
autopr0n is like, down and stuff.
"Parse::Perl. Just as the name says, its goal will be to provide a pure Perl parser that parses Perl itself."
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...
autopr0n is like, down and stuff.
It's true that individualistic programing styles can slow down a project, and it's true that perl allows almost infinite programming style, or lack of same. However, the two issues are orthogonal, and Perl itself is not bad for cooperation. Just ask the CPAN developers.
:)
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...
"Perl Specific Patterns"
I would call that a "Perl Idiom"
It is not a pattern.
Patterns are CONCEPTS not IMPLEMENTATIONS
Execution of ./shit.pl aborted due to compilation errors.
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.
I make my living as a perl programmer
/. are so quick to flame Perl. If you don't like it don't use it but don't flame people who do. I love Perl. As far is being hard to read or understand well I think that's people who have never tried. When I started coding Perl I was a complete newbie. I'd done a little C and a bit of Basic and I wanted to learn how to right CGI scripts. Someone showed me Perl and inside a week I was writting (badly but still writting) a message board. It took me weeks, it was horrid but it worked. I know very few people who can do that in any other language. In fact it was Perl that got me to move away from the darkside of Windows (this was before ActiveState made Perl on Windows a more manageable beast).
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
The Anti-Blog
"if you follow some rules. "
:) Really though, difficulty reading a language is usually due to
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.
I work for a Major Automotive Manufacturer's ITM department, and Perl has saved our lives.
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.
You don't have to be limited to what your compiler vendor supplies, or the extra libraries you (or your company) can afford. CPAN provides an enormous repository of useful (and usually well-written and well-tested) tools that no other language approaches.
But of course, you need to use perl.
Netlib 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!
I write Perl too. I write Perl professionally and I do a professional job of it -- my code is organized into object-oriented modules that could pass for Java if it wasn't for the pointies and easier string manipulation. The documentation is Javadoc-style POD and it's kept up to date. Same thing goes for my PHP code, my C code, etc... I don't write Java code professionally anymore but that's where I picked up some of my documentation and OO habits, since I learned C++ as a scientific (computational) language. Anyways, discipline will see you through if you want it to. It's always more productive to just design and write the damn code than to hold meetings over which language to do it in.
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!)
Remember that what's inside of you doesn't matter because nobody can see it.
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 - 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 beauties based
on someone elses poor transcription.
-- Oh Well
Printing an array of hashes in Perl (lifted from O'Reilly book):
.. $#LoH ) {
.. $#$foo ) {
# 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.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
The middle mind speaks!
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.
The only thing that we learn from history is that nobody learns anything from history.
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.
"Biped! Good cranial development. Evidently considerable human ancestry."
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.
"Biped! Good cranial development. Evidently considerable human ancestry."
any not only that, but if you do in in Perl you have a much better chance of being done in less than 500. Many have been the pages of C code I've seen go by that could be replaced wtih a few lines of Perl.
Liberty uber alles.