SPUG: Does Perl Scale? (Was: Evolution of Perl)

Brian Aker brian at tangent.org
Mon Aug 13 12:37:05 CDT 2001


Ken McGlothlen wrote:
> | Much as I like Perl, weakly-typed, free-form languages like Perl are not as
> | appropriate for large projects as C++ and Java are.  Since Perl doesn't have
> | any way of enforcing compliance with subroutine interfaces for OO calls, it
> | can be difficult to track down bugs in large systems.  It's easy to say that
> | programmers shouldn't create bugs, but using a strongly-typed language can
> | produce a better product.
Its funny to read this sort of thing because its the same thing that was
said about Java when it first came out (more about its memory management
though).
Fact is, you can build very large applications in high level languages
normally
with less code and in less time.

Speed (unless you use very poorly written algorithms, (which are
normally the
heart of all optimization issues)) is a minor issue that can be worked
out
with hardware. Hardware is cheaper then developer's time. 

A good design can always be broken down into smaller pieces. Through
smaller 
pieces you can normally track down your problems. The most important
thing
to do while programming is build tests for each of your modules (and
keep
them up to date!). This will simplify many of your problems.
If you use h2xs to setup your module tree, perl makes it very easy to
test
large projects.

BTW with weakly type languages that have garbage collection (I would
have been
a bigger fan of Java if it had been weakly typed) you have a benefit
over
C++ or C in that you aren't having to constantly look for buffer
overflows.
This takes out a lot of your development time. 
Big projects like Apache, normally have to develop their own garbage
collection
systems (look at how "pools" work in Apache for an example).

> | More importantly, C++ and Java programmers tend to be more rigorous than
> | Perl programmers.  Damian's talk is a good illustration of some of the
> | warped programming styles that Perl can seduce programmers into.
I have seen a calendar widget in Java that was made up of 60 classes! I
have
seen some code that was done to produce Applets that was impossible to
follow (the guy cut every corner possible to make the thing fast enough
to run on the average browser, and to be small enough to download).

Any language can be butchered, and to be honest there is no "right" way
of programming. You can pick standards (which is a good idea for any
group of programmers working together) but that is about it.
When I see unless(x) it takes my brain to parse this a bit longer
then if(!x). Why? Because perl is far from my first language and I
am just not accustom to it (and unless(!x) just sends me for a loop.
I have been using Perl for around 10 years at this point, but I have
been using languages like C for a bit longer.

Not everyone speaks english the same way and not everyone's brains
are wired to write code exactly the same way.  

> Back when I was a Pascal fan (1981-6), I used to say the same sort of thing
> about C programmers.  Pascal was a nice, high-level, strongly typed language,
> whereas C (at the time, K&R C---ANSI C was on the far horizon) allowed you to
> break typing, screw with function calls, etc., etc., etc.  Moreover, most of
> the C code I'd seen to date was obscure---I would even say "badly written" from
> a maintenance viewpoint, whereas my Pascal programs were graceful, well written
> and comprehensible.
No way to cast either so writing device drivers was a real pain in the
ass :)

For historical reference:
http://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html

> I mentioned this to my teacher one day, and he said, "It's time to let you in
> on an old adage:  `You can write FORTRAN in any language.'"
I really miss arithmetic ifs. Its the one thing that languages just
never
picked up on after Fortran.

> Once I did get hold of my own Unix account, though, and got past the
> obscureness of the commands (RENAME became mv, COPY became cp, HELP became man,
That is funny, since I wrote an entire Borne shell replacement in
assembly
because I hated VMS so much.

> Now Perl is object-oriented.  That's a tough thing to bolt onto a procedural
> language.  The only *native* object-oriented language I've seen that did it
> disturbingly low-level.  But I wouldn't use C++ for those, either.  The one
How close is gtk to being exactly this? I have used Glade under Linux to
create
front ends quickly. I am told that gtk works fine under Windows. 
Anyone have any experience with windows and gtk?


> thing I really wish Perl had going for it is a really good cross-platform GUI
> I dunno.  VB has become sort of the modern-day COBOL.  :)
I would disagree. Java is modern day COBOL. Very easy language that you
can
take bad programmers and throw them at it. Applets were a failure,
servlets
have sort of taken off(even though I am not to sure of this, I have yet
to find a big shop that uses them (well there was HomeGrocier)... but
where I 
have seen it most frequently used in the work place is a a replacement
for 
doing COBOL in mainframe environments. Right there Java has pretty much
taken the scene from COBOL.
The moment I realized this I also lost all interest in Java :)

And for large projects I have done over 70K line applications in 
perl, with no problems(with groups of developers!). The real chore was
to get 
an agreement from developers on coding practices, get it written down,
and 
spanking folks that don't follow it.

	-Brian
--
_______________________________________________________
Brian Aker, brian at tangent.org 
Slashdot Senior Developer
Seattle, Washington
http://tangent.org/~brian/
http://slashdot.org/
_______________________________________________________
You can't grep a dead tree.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/





More information about the spug-list mailing list