[25524] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 7768 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 10 18:10:30 2005

Date: Thu, 10 Feb 2005 15:10:22 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Thu, 10 Feb 2005     Volume: 10 Number: 7768

Today's topics:
    Re: The Problem with Perl (Richard Williams)
    Re: The Problem with Perl <ebohlman@omsdev.com>
    Re: The Problem with Perl <nospam-abuse@ilyaz.org>
    Re: The Problem with Perl <cwilbur@mithril.chromatico.net>
    Re: The Problem with Perl <abigail@abigail.nl>
    Re: The Problem with Perl <abigail@abigail.nl>
        What's (not) up with www.perldoc.com? <ceo@nospam.on.cox.net>
    Re: What's (not) up with www.perldoc.com? ioneabu@yahoo.com
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Thu, 10 Feb 2005 19:43:48 +0000 (UTC)
From: rdwillia@hgmp.mrc.ac.uk (Richard Williams)
Subject: Re: The Problem with Perl
Message-Id: <cugdhk$dl0$1@helium.hgmp.mrc.ac.uk>

In article <m3d5vauipd.fsf@goedsole.com>,
William Goedicke  <goedicke@brandeis.edu> wrote:

>I've got some friends whose programming activity is not at all like
>the sporadic hacks that I engage in.  They're extremely expert
>programmers with advanced programming degrees from MIT who are
>developing things like tank simulations for the DoD in lisp and other
>more arcane languages.  With the one caveat that it may be OK for a
>piker like me who doesn't need to code anything major, they speak of
>perl with utter contempt.

There are, of course, plenty of counterexamples of programmers with this 
sort of 'advanced CS' background who have a rather different opinion of 
Perl. Some of them have even expanded on it at book length:

http://www.macavon.co.uk/books/Perl/PerlTPC.html

You might enjoy the 'coffee shop epilogue'.

Richard.


------------------------------

Date: 10 Feb 2005 20:08:33 GMT
From: Eric Bohlman <ebohlman@omsdev.com>
Subject: Re: The Problem with Perl
Message-Id: <Xns95F99127C3A2Bebohlmanomsdevcom@130.133.1.4>

Charlton Wilbur <cwilbur@mithril.chromatico.net> wrote in 
news:87ekfoxpl7.fsf@mithril.chromatico.net:

> And that difficulty -- to return to the original point of the thread
> -- is why stricter languages than Perl are so popular.  They
> substantially reduce the risk of project failure due to technical
> issues with the coding, and they reduce the business's dependence on
> finding brilliant talent.

That's the sort of statement that really needs to be backed up with 
empirical evidence rather than anecdotes or "it seems to make sense."  
It's certainly a popular *perception* that's driven a lot of language 
design, but then the world of business (and, for that matter, everything 
else) is full of unexamined assumptions that seem to make sense but that 
often, on closer examination, don't.

In the case at point, I think the essential quality of programmers that 
you're looking for isn't "brilliance" but rather just a modicum of self-
discipline; the ability to realize, to steal a line from a J.K. Rowling 
character, that there can be a difference between doing what's right and 
doing what's easy.  And I think that, in programming, the determinants of 
that are more cultural than personal; people will do what's seen to be 
valued in their environment.  If "great hacks" and tricky code are seen 
as something to be proud of, that's what you'll get.  It's not so much a 
matter of ability as it is of attitude.  Read Gerald Weinberg's _The 
Psychology of Computer Programming_; he discusses at great length both 
the organizational/social and personal factors associated with good vs. 
bad programming.

And in any case, my understanding is that the typical failure modes of 
any large programming project seldom involve low-level issues of the sort 
that could be handled by tool-enforced discipline (e.g. passing strings 
to functions expecting integers); those should be nipped in the bud by 
unit testing and similar practices.  Rather they involve macroscopic 
things; the individual pieces work by themselves, but not together, 
typically due to different people working off assumptions that are 
almost, but not quite, identical.  Focussing on specific characteristics 
of the language is really a form of micro-optimization.


------------------------------

Date: Thu, 10 Feb 2005 21:06:53 +0000 (UTC)
From:  Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: The Problem with Perl
Message-Id: <cugidd$ti5$1@agate.berkeley.edu>

[A complimentary Cc of this posting was sent to
Anno Siegel
<anno4000@lublin.zrz.tu-berlin.de>], who wrote in article <cue5go$95a$1@mamenchi.zrz.TU-Berlin.DE>:
> > This is a really important point.  Perl shouldn't be thought of as an 
> > "undisciplined language"; it should be thought of as a "bring your own 
> > discipline (BYOD) language."

> Yeah, but people don't.  Matt, of script archive fame didn't.  Many of
> the folks whose code we get to see on clpm obviously don't.  Programming
> discipline?  What's that, it works!

> > Larry's philosophy is that programming 
> > discipline is a human issue, not a technical one, and therefore needs to be 
> > enforced by human (social) means, not through technical characteristics of 
> > tools.

> A decision that has a price.  There's code out there the community has
> to deal with -- Matt's archives have cost a tremendous effort and still
> do.

Slightly paraphrasing what Alan Kay said in his recent interview,
programming environment is a way to translate your intelligence (or
combined intelligence of your team) into a final product.  I can
imagine many situations when B&D environment provides much better
translation...

Ilya


------------------------------

Date: Thu, 10 Feb 2005 21:29:24 GMT
From: Charlton Wilbur <cwilbur@mithril.chromatico.net>
Subject: Re: The Problem with Perl
Message-Id: <87acqcxg0g.fsf@mithril.chromatico.net>

>>>>> "EB" == Eric Bohlman <ebohlman@omsdev.com> writes:

    EB> In the case at point, I think the essential quality of
    EB> programmers that you're looking for isn't "brilliance" but
    EB> rather just a modicum of self- discipline; the ability to
    EB> realize, to steal a line from a J.K. Rowling character, that
    EB> there can be a difference between doing what's right and doing
    EB> what's easy.  And I think that, in programming, the
    EB> determinants of that are more cultural than personal; people
    EB> will do what's seen to be valued in their environment. 

Well, there are two factors here.  The productivity difference between
*good* programmers and *great* programmers can be substantial, but
both will have self-discipline.

    EB>  If "great hacks" and tricky code are seen as something to be
    EB> proud of, that's what you'll get.  It's not so much a matter
    EB> of ability as it is of attitude.  

I think it's a matter of both: great programmers often have the
ability to change attitudes by demonstrating that there's a better way
and by being a bellwether for local attitudes.

But looking at this with managers' eyes: it's *much* easier to mandate
"This code will be in Java," with what language-imposed discipline
that entails, than it is to mandate "Programmers will be
self-disciplined enough to write readable, maintainable code."  This
is especially true when the manager's decisions are subject to review
by higher, non-technical authorities.

I've watched a good development team at work, and I know the two
people largely responsible for making it into a good development team.
The way they got it to be good was by having objective criteria that
could be clearly supported even to non-technical managers: Java as the
language of choice, test suites written in conjunction with the code,
strict source code control procedures (including not allowing change
commits unless the class passed the test suite), nightly builds.  And
even then the only reason it succeeded is because their manager was
wise enough to figure out who was an obstacle in the way of progress
and get them transferred off the team.

I don't think it would have been possible to accomplish the same ends
had they chosen Perl instead of Java, because they would also have had
to impose much more subjective style rules, and that would have made
it much more difficult for the manager to get rid of the problem
people on the team.

    EB> And in any case, my understanding is that the typical failure
    EB> modes of any large programming project seldom involve
    EB> low-level issues of the sort that could be handled by
    EB> tool-enforced discipline (e.g. passing strings to functions
    EB> expecting integers); those should be nipped in the bud by unit
    EB> testing and similar practices.  Rather they involve
    EB> macroscopic things; the individual pieces work by themselves,
    EB> but not together, typically due to different people working
    EB> off assumptions that are almost, but not quite, identical.
    EB> Focussing on specific characteristics of the language is
    EB> really a form of micro-optimization.

I suspect that that's because the only people trying large programming
projects in less restrictive programming languages have already
mastered the smaller-scale issues that go along with that programming
language or have the same sort of discipline imposed in different
ways.  I don't think there's a qualitative difference between Java OO
with one standard way of doing things and Perl OO with a manager- or
team-specified way of doing things; in that case, though, you lose
most of the programmer-visible benefits of Perl.  There's little
difference, after all, between having only one way to do a thing in
the language and having many ways but being restricted to only one.

Charlton


-- 
cwilbur at chromatico dot net
cwilbur at mac dot com


------------------------------

Date: 10 Feb 2005 22:38:33 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: The Problem with Perl
Message-Id: <slrnd0noj9.g2.abigail@alexandra.abigail.nl>

William Goedicke (goedicke@brandeis.edu) wrote on MMMMCLXXXI September
MCMXCIII in <URL:news:m3sm45kv4o.fsf@goedsole.com>:
][  Dear Abigail - 
][  
][  You wrote:
][  
][      Abigail> People like [...] should never have programmed in
][      Abigail> Perl. Perl didn't force itself upon them. They should
][      Abigail> have coded in Java, Python, or another "I'll hold your
][      Abigail> hand" language.
][  
][  That's an eloquent (though still lacking in preciseness) statement of
][  a persistant point in the thread.  There are two important messages
][  here.  Perl provides enormous flexibility which people can shoot
][  themselves in the foot with.  Second, there are bad programmers and,
][  no matter the language a bad programmer can write incomprehensible
][  code.

I did not say anything about bad programmers. I wasn't talking about
bad programmers. You can be a good coder, but Perl just isn't your kind
of language. Just like you can be a good soccer player, but playing the
position of goalkeeper doesn't bring out your good points.

][  Do "Java, Python"... really "hold your hand" to an extent that bad
][  programming is diminished.  If so, that's a good thing.  I would still
][  like to know what qualities those languages have that differentiates
][  them such that they can accomplish this.  Maybe the best answer to my
][  original question is use perldoc

It's still possible to program badly in Java, Python, or another language,
and it doesn't take much effort. One can get lost in any city. But more
people will find it easier to navigate in Manhattan than Rome. But some
people will find Rome more attractive than Manhattan.

][                                    Perl's function prototyping
][  mechanisms... to diminish obfuscation (except when that's the goal ;)

Perl's function prototype mechanism isn't very great, and many people
agree it was a failed experiment. 

][  What are the other similar mechanisms people use effectively to make
][  their Perl code more comprehensible and maintainable?

More comprehensible and maintainable than what?


Abigail
-- 
srand 123456;$-=rand$_--=>@[[$-,$_]=@[[$_,$-]for(reverse+1..(@[=split
//=>"IGrACVGQ\x02GJCWVhP\x02PL\x02jNMP"));print+(map{$_^q^"^}@[),"\n"


------------------------------

Date: 10 Feb 2005 22:39:14 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: The Problem with Perl
Message-Id: <slrnd0noki.g2.abigail@alexandra.abigail.nl>

William Goedicke (goedicke@brandeis.edu) wrote on MMMMCLXXXI September
MCMXCIII in <URL:news:m34qglmg1r.fsf@goedsole.com>:
&&  Dear Abigail et al - 
&&  
&& >>>>> "abigail" == abigail  <abigail@abigail.nl> writes:
&&  
&&     abigail> A reaction, in the hope your posting isn't a troll.
&&  
&&  It's not I genuinely think it a valid question and discussion.
&&  
&&     abigail> I think that for the majority of the people [...] Perl is
&&     abigail> the wrong choice.
&&  
&&  But, why?


Because it gives them too much rope.



Abigail
-- 
#!/opt/perl/bin/perl -w
$\ = $"; $; = $$; END {$: and print $:} $SIG {TERM} = sub {$ := $_}; kill 15 =>
fork and ($; == getppid and exit or wait) foreach qw /Just another Perl Hacker/


------------------------------

Date: Thu, 10 Feb 2005 20:29:20 GMT
From: Chris <ceo@nospam.on.cox.net>
Subject: What's (not) up with www.perldoc.com?
Message-Id: <AuPOd.5506$hU7.3472@newssvr33.news.prodigy.com>

Anyone know what's (not) up with http://www.perldoc.com?  Haven't been 
able to get to it for a couple of days now.  I haven't used it in a 
while, so I went looking for what I thought would surely be other 
mesages on this, but didn't find anything in the last month.  Surely it 
hasn't been down longer than this...?

-ceo


------------------------------

Date: 10 Feb 2005 14:38:16 -0800
From: ioneabu@yahoo.com
Subject: Re: What's (not) up with www.perldoc.com?
Message-Id: <1108075096.587676.14970@g14g2000cwa.googlegroups.com>


Chris wrote:
> Anyone know what's (not) up with http://www.perldoc.com?  Haven't
been
> able to get to it for a couple of days now.  I haven't used it in a
> while, so I went looking for what I thought would surely be other
> mesages on this, but didn't find anything in the last month.  Surely
it
> hasn't been down longer than this...?
>
> -ceo

http://perldoc.perldrunks.org/

you can download all in .html and .pdf for yourself.

Then to get rid of the pesky .pdf's:


#!/usr/bin/perl
use strict;
use warnings;

use File::Find;
find(\&wanted, $ARGV[0]);
sub wanted { unlink if /\.pdf$/ }


wana



------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc.  For subscription or unsubscription requests, send
#the single line:
#
#	subscribe perl-users
#or:
#	unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.  

NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice. 

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V10 Issue 7768
***************************************


home help back first fref pref prev next nref lref last post