Quality of perl implementations (Was: Re: if file already exists then remove...) 
Author Message
 Quality of perl implementations (Was: Re: if file already exists then remove...)

[A complimentary Cc of this posting was sent to Larry Rosler


Quote:
> I am troubled by your philosophy of abstention from directing the
> attention of Perl implementors toward reliability as opposed to new
> features.  

I was puzzled by this attitude of Perl users for a long time.  Until I
lost any faith in that Tom knows what he writes about.

Let me reiterate my current opinion on the topic: the reason for my
puzzlement (and your trouble) is the difference between Perl as a
scripting language and Perl as a programming language.  Perl is
absolutely fine as a scripting language.  Perl is pretty unusable as a
programming language.

Thus people who use Perl "in scripting mode" do not care about bugs,
ambiguities and undoc behaviour: they just experiment with their
scripts until they think the scripts do what they want.  The design of
Perl makes such experiments a kind of fun in itself, and the
understanding that this is not how things are supposed to be
programmed is drowned in all this fun.

And the ubiquitous false adverti{*filter*}ts that Perl is a "programming
language" creates a warm fuzzy feeling that all this fun of
experimenting *is* programming.  Hence that

  Programming Perl is fun!

slogan.  Additionally, for a lot of tasks the "scripting mode" is
quite justifiable: the result may be easily controllable/undone, so
that if things go wrong, you just try again.  Or the problem to solve
is so simple, that your experiments (plentiful because it is so hard
to write correct Perl on the first try) have a good chance to cover
most of the cases your script is going to be used in.

Summary: now I'm not so puzzled as before.  ;-)

Ilya



Thu, 24 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

Quote:
> Perl is absolutely fine as a scripting language.  Perl is pretty unusable as
> a programming language.

I will labor along under my delusions, if you don't mind. I have been
using Perl for my non-programming for quite some time. I know that
other pronouncements are often made:

        1. You shouldn't use Perl for large applications.

        I have managed to produce a program that is fairly large, is in
        fairly wide use, and is entirely (or almost) in Perl.

        2. You can't use signals in Perl.

        On BSD and derivatives, I agree. On Solaris and Linux and other
        SYS5-ish OS, Perl seems to do pretty well. Failure rates
        on busy systems that are not that much different than the rate
        of parity errors in RAM of a few years ago. (Do parity errors
        still happen? Do we have cosmic ray shields now? 8-)

        3. You can't program a long-running daemon in Perl.

        My daemon routinely runs for months at a time. It does
        have the luxury of forking for most of its real work, but
        it accumulates hours of used CPU with no memory leaks.

Had I listened to the unoffical information, I might not have
done it.  And it works just fine in the real world.

Regards,
Mike Heins
--
Internet Robotics, 131 Willow Lane, Floor 2, Oxford, OH  45056

Function in chaos, finish in style. -- Unknown



Fri, 25 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

Quote:


>> Perl is absolutely fine as a scripting language.  Perl is pretty unusable as
>> a programming language.

> I will labor along under my delusions, if you don't mind. I have been
> using Perl for my non-programming for quite some time. I know that
> other pronouncements are often made:

> 1. You shouldn't use Perl for large applications.

> I have managed to produce a program that is fairly large, is in
> fairly wide use, and is entirely (or almost) in Perl.

I have to agree.  When I first started using Perl Dec'96/Jan'97 I wrote an
H/R Job Postings script which was 2,000 lines long.  About 1,200 of those
were documentation so I would/could remember what I wrote and why.

Today, that same program was rewritten into 700 lines (300 less
documentation.)  Why?  I actually 'feel' like I know what I am doing. :)

PS - it's not a CGI (the front-end is, however.)  The program is memory
resident (a server) waiting to handle job posting applications and then
makes ftp calls a SuSE LinuxPPC server which makes PDFs on the fly (the code
is also written in Perl.)

So, I would hazard to say  --  "How big is a BIG application in Perl?"

Quote:
> Had I listened to the unoffical information, I might not have
> done it.  And it works just fine in the real world.

No, I don't listen :)  (Having just read Lincoln Stein's musings in
WebTechniques - I don't believe he does either.)

What I will say is that people today are pretty unstable as programmers.
(Now, I'm waiting for the fall-out on that one...  ;)

my $cents = 2;  # No, I'm prolly not a programmer either :D
-Sneex-  :]
- FCCJ * 501 W State St * Jacksonville, Fl 32202 * 904/632-3089 -



Fri, 25 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

Quote:

> When I first started using Perl Dec'96/Jan'97 I wrote an H/R Job
> Postings script which was 2,000 lines long.  About 1,200 of those
> were documentation so I would/could remember what I wrote and why.

> Today, that same program was rewritten into 700 lines (300 less
> documentation.)  Why?  I actually 'feel' like I know what I am doing.

> So, I would hazard to say  --  "How big is a BIG application in Perl?"

My record is an app which is about 10k lines, including comments and
whitespace. The "meat" of the program is about 6200 lines. I'm not sure
whether Ilya would consider it a program or a script, despite it's bulk.
It's not something that you have up and running for a sustained amount
of time. It's basically a glorified (and hideously complex) text
processor. Still, it shows that large Perl apps are feasible.

-mjc



Fri, 25 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

Quote:



>>> Perl is absolutely fine as a scripting language.  Perl is pretty unusable as
>>> a programming language.

>> I will labor along under my delusions, if you don't mind. I have been
>> using Perl for my non-programming for quite some time. I know that
>> other pronouncements are often made:

  <SNIP>

Quote:
>So, I would hazard to say  --  "How big is a BIG application in Perl?"

I'm currently working on an automated test system for telecom/datacom
systems that's written almost entirely in Perl and runs under FreeBSD.  
There are three primary processes, and several secondary processes, all
of which communicate via TCP sockets.

It currently tips the scales at just over 50,000 lines, not including the
CGI interface.  That includes copious POD for the API functions, as well
as a reasonable amount of commenting in the code itself.

--



Fri, 25 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)
:>
:> So, I would hazard to say  --  "How big is a BIG application in Perl?"

: My record is an app which is about 10k lines, including comments and
: whitespace. The "meat" of the program is about 6200 lines. I'm not sure
: whether Ilya would consider it a program or a script, despite it's bulk.
: It's not something that you have up and running for a sustained amount
: of time. It's basically a glorified (and hideously complex) text
: processor. Still, it shows that large Perl apps are feasible.

Certainly large projects are feasible in Perl. My internal code
development libraries are pushing 40 Klines (including whitespace
and comments) of Perl. That doesn't count the additional 5-7 Klines
of stuff in my public development libs on CPAN. My largest recent Perl
project was around 45 Klines of purpose specific code.

--
Benjamin Franz



Fri, 25 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

Quote:

> Sent: Monday, May 08, 2000 15:37

> Subject: Re: Quality of perl implementations



> :>
> :> So, I would hazard to say  --  "How big is a BIG application in
Perl?"

> : My record is an app which is about 10k lines, including comments and
> : whitespace. The "meat" of the program is about 6200 lines. I'm not
sure
> : whether Ilya would consider it a program or a script, despite it's
bulk.
> : It's not something that you have up and running for a sustained
amount
> : of time. It's basically a glorified (and hideously complex) text
> : processor. Still, it shows that large Perl apps are feasible.

> Certainly large projects are feasible in Perl. My internal code
> development libraries are pushing 40 Klines (including whitespace
> and comments) of Perl. That doesn't count the additional 5-7 Klines
> of stuff in my public development libs on CPAN. My largest recent Perl
> project was around 45 Klines of purpose specific code.

So far, all the projects reported have been single-individual efforts.
Has anyone had experience with Perl in team projects?  That might be a
more significant criterion relative to the usefulness of Perl for
'Programming in the Large'.

--
Larry Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/



Fri, 25 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

: > Sent: Monday, May 08, 2000 15:37

: > Subject: Re: Quality of perl implementations
: >
: >


: > :>
: > :> So, I would hazard to say  --  "How big is a BIG application in
: Perl?"
: >

: So far, all the projects reported have been single-individual efforts.
: Has anyone had experience with Perl in team projects?  That might be a
: more significant criterion relative to the usefulness of Perl for
: 'Programming in the Large'.

Check out www.dir.gov.bc.ca .

I am not working there anymore (I'm just a contractor and I've been doing
other things) so I don't have lines of code counts, and etc.  You will
have to guess those sort of numbers from the number of screens, and the
type of data. Many screens can be used for update if you were a local user
with admin privileges.  In any case its not trivial.

I do know the project is a coordinated effort of about 6 people, off and
on, and is written in Perl and MySql, with CGI used for both data display
and standard user data updates.  The key issue, as on any multi user
project, is good modularity.  That doesn't mean Perl "modules", that means
units of code that individual people can work with, with simple, clear,
well defined interfaces between the work units, and that can be developed
and tested very much as independent units.

Perhaps it's because a CGI based application is easy to modularize, but
this project was at least as easy to work on as any other multi person
project I've been involved with.

A highly paid friend who works for IBM once told me "perl is just for
throw away programs".  He was right, but not the way he meant.  On an IBM
main frame, programmers will have entire libraries of JCL simply so they
can easyily run programs with the correct parameters.  On Unix you would
simply type in the commands as you need them.  In other languages I have
written (and carefully saved and documented), numerious utilities or small
applications.  With Perl I just type in the code as I need it.  All the
old utilities are gone.

Yes its throw away, but that's because its so easy to use Perl to solve
problems.  I bet many of those "single-individual efforts" wouldn't be
that way if they were written in another language.

What would you rather have?  Three of four happy programmers scripting
your application, or a hard working team of twenty "software engineers"?



Fri, 25 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

Quote:

>> Certainly large projects are feasible in Perl. My internal code
>> development libraries are pushing 40 Klines (including whitespace
>> and comments) of Perl. That doesn't count the additional 5-7 Klines
>> of stuff in my public development libs on CPAN. My largest recent Perl
>> project was around 45 Klines of purpose specific code.
>So far, all the projects reported have been single-individual efforts.
>Has anyone had experience with Perl in team projects?  That might be a
>more significant criterion relative to the usefulness of Perl for
>'Programming in the Large'.

Sure. We wrote ~40K Perl code for an information system in a team with four
members. We're using the OO features quite heavily in some places.

The only negative side of using Perl is that uncommented and complex REs are
very hard to understand for people that didn't write them. But OTOH I do not
like to know, how the pattern matching code would look like, if it would have
been written in Java.

Erich
--

                                 http://www4.informatik.uni-erlangen.de/~meier/
          "There has been much talk about component architectures
           but only one true success: Unix pipes."  (R. Pike)



Sat, 26 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)


:>> Perl is absolutely fine as a scripting language.  Perl is pretty unusable as
:>> a programming language.
:>
:> I will labor along under my delusions, if you don't mind. I have been
:> using Perl for my non-programming for quite some time. I know that
:> other pronouncements are often made:
:>
:> 1. You shouldn't use Perl for large applications.
:>
:> I have managed to produce a program that is fairly large, is in
:> fairly wide use, and is entirely (or almost) in Perl.

[snip]

: So, I would hazard to say  --  "How big is a BIG application in Perl?"

About 35,000 lines, most of which are code. It uses about 20 custom
modules, supports about a dozen more Perl modules for adding various
levels of functionality (DBI, MD5, LWP, SQL::Statement, etc.)  and has
a few thousand lines of support "programs". I think it is one of the
larger Perl applications out there, and AFAIK is the largest one with
a "perl Makefile.PL" installation.

--
Internet Robotics, 131 Willow Lane, Floor 2, Oxford, OH  45056

Fast, reliable, cheap.  Pick two and we'll talk.  -- unknown



Sat, 26 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

Quote:

>So far, all the projects reported have been single-individual efforts.
>Has anyone had experience with Perl in team projects?  That might be a
>more significant criterion relative to the usefulness of Perl for
>'Programming in the Large'.

I am currently working on a 50K-100K line perl project, with maybe 50
developers in and out of it at various times.

There have been some Perl related problems, but I don't how much of it
is endemic to Perl, an how much is because so few developers have
experience with Perl on this scale.

-T



Sat, 26 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)
[A complimentary Cc of this posting was sent to Mike Heins


Quote:
> I will labor along under my delusions, if you don't mind.

No, I do not.  I would not even mind people writing applications in
TCL, DOS batch files etc.

Quote:
>    I have managed to produce a program that is fairly large, is in
>    fairly wide use, and is entirely (or almost) in Perl.

Which still does not make Perl a programming language.

Quote:
>    2. You can't use signals in Perl.

>    On BSD and derivatives, I agree. On Solaris and Linux and other
>    SYS5-ish OS, Perl seems to do pretty well. Failure rates
>    on busy systems that are not that much different than the rate
>    of parity errors in RAM of a few years ago.

In my experiments every 30th signal corrupts perl process (so that the
corruption is easily detectable, actual corruption can happen more
often).  But still feel free to "labor along under your delusions".

Quote:
> Had I listened to the unoffical information, I might not have
> done it.  And it works just fine in the real world.

The criterion "works just fine in the real world" is the latmus test
for scripting.

Ilya



Sun, 27 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

: The criterion "works just fine in the real world" is the latmus test
: for scripting.

I don't agree. "works just fine in the real world on one system" would
be a good litmus test for scripting. When it reaches "works just fine
in the real world on thousands of diverse systems" then I maintain it
is a program.

--
Internet Robotics, 131 Willow Lane, Floor 2, Oxford, OH  45056

Any man who is under 30, and is not liberal, has not heart; and any man
who is over 30, and is not a conservative, has not brains.
 -- Winston Churchill



Sun, 27 Oct 2002 03:00:00 GMT  
 Quality of perl implementations (Was: Re: if file already exists then remove...)

Quote:
>>        I have managed to produce a program that is fairly large, is in
>>        fairly wide use, and is entirely (or almost) in Perl.
> Which still does not make Perl a programming language.

Hmmm. People have written programs. They've used Perl to write said
programs. Yeah, that makes it a programming language. Unless your
definition of "programming language" does not include "a language used to
program a computer". Don't people get tired of the programming language
v. scripting language argument?

Alas, I just started another game of chess. Gotta run.

-- Sean...

#!/usr/bin/perl
$j=\$j;{$_=unpack(P24,pack(L,$j));/Just Another Perl Hacker/?print:$j++&&redo}



Sun, 27 Oct 2002 03:00:00 GMT  
 
 [ 120 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9]

 Relevant Pages 

1. DBGRID : Colour Individual Cells

2. if file already exists then remove...

3. Problems writing to a file that already exists!

4. Editing a file if line doesn't exist already

5. Atomic file create or fail if already existing

6. TMemoField: DataSize and GetData

7. ANSI/ISO Pascal FAQ

8. Anybody against using Data::Type while Data::Types already exists on CPAN

9. English parsing module - does one exist already?

10. I am searching for an existing C parser...

11. Win32::FileSecurity removes some existing rights

12. Info on device driver development

 

 
Powered by phpBB® Forum Software