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.
By which of course he means good, gooder or goodest. Damn intellectuals.
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.
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...
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
The problem I see with Perl is a management problem. Everyone complains that Perl produces bad code, but in reality, programmers produce bad code. By our very nature as human beings, we all think differently.
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
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