Learning perl - for experienced programmers

[John Bokma]

etc., enforce a strictness that Perl doesn't.

A good programmer has enough discipline to "enforce" this
himself/herself. It has been often said, by me and by others, that
crappy code comes from a crappy programmer, not because of the language
allows for crappy code.

Moreover, I have seen often enough people doing their very best to work
around the strictness of a language.

I prefer to stick to the following rule: use the *best* solution where
possible. The lack of protection in Perl IMNSHO helps me here.

Additionally, Java
compiles to bytecode, and I've not had a problem running class files
on different systems. With Perl, I've found that I need to code for
the target system. Programs written for Windows will run on Linux, but
some programs written on Linux will not, repeat, not, run on Windows.

This says a lot about your Perl skills, and (surprise) about your Java
skills. I have used both languages side by side for some time, and I
*had to* keep in mind while using both that it wasn't running on a
single platform. Also, I had to test my code on every platform for both
languages. Mostly just to be sure.

I made an analogy earilier, Java is like a deuce and a half, while
Perl is like a sports car.

I see often software compared to cars, and never seen a comparision that
made sense.

[ Perl OO rant ]

he set some class variables. Blame the programmer (you would be
justified in doing so), but share a small part of the blame with the
language.

Instead of making yourself sound the whole time like someone with
skills, show "us" your skills by giving a good argument or a clear
example how Perl is bad at OO. I can make a list of what I would like to
see changed, and what's "wrong" IMO.

Can you?

I keep an eye on dice.com. If you search for Perl, you see admin and
web jobs, but few for Perl developers in general. Search for Java, and
you get plenty of general programming results. Java jobs: 14217; Perl
jobs: 4780 - a 3 to 1 ratio.

does this prove that there are enough perl programmers?
does this prove that there is no increase?

 

[John Bokma]

How useful is the API of a code library?

Without clear documentation? As useful as grepping *.pl and *.pm
for use, sub, @ISA IMNSHO.

 

[addinall]

There is a lot wrong with PHP

OT: Apologies.

What for instance? I program in Perl, PHP, C
and PL/SQL on a daily basis and see the
use for all of these tools.

Mark Addinall.

 

[cartercc]

A good programmer has enough discipline to "enforce" this
himself/herself. It has been often said, by me and by others, that
crappy code comes from a crappy programmer, not because of the language
allows for crappy code.

Did you read what I wrote? Apparently not.

This says a lot about your Perl skills, and (surprise) about your Java
skills. I have used both languages side by side for some time, and I
*had to* keep in mind while using both that it wasn't running on a
single platform. Also, I had to test my code on every platform for both
languages. Mostly just to be sure.

No. It says a lot about my local network and the network engineers. I
don't control my machines or what runs on them, and I don't have
administrative privileges. In fact, I have to scream like hell just to
get a user account on the systems I'm supposed to be supporting.
Politics is hell, and right now, I'm in it.

I'll tell you a little story -- a true story. We (me and the 'other'
developer) were demonstrating a Java app to my boss, the IT Director.
This is an app that connects over a network to a remote database
server, runs queries, downloads the data, and puts it into a local
database. This runs several times a day, and downloads around 20K or
30K records at a time. I was demonstrating the unit tests by saying
something like this: "Here is the VPN class test. Here is the
configuration class test. Here is the query class test. Here is the FTP
class test." He said to me, and I quote, "When do you plan on taking
these classes?"

This guy is a smart guy, with a degree from an engineering school with
an international reputation, who has had a successful career in
industry managing large engineering projects, but he's a hardware guy
and as far as I know has never studied a programming language. In fact,
his attitude toward coding is, "You build it once, and you're finished.
If you have to revise it, it means you built it wrong." This is almost
word-for-word what he tells me. He thinks iterative development is the
most screwed up idea in the world. (He doesn't build bridges and roads
iteratively.)

Instead of making yourself sound the whole time like someone with
skills, show "us" your skills by giving a good argument or a clear
example how Perl is bad at OO. I can make a list of what I would like to
see changed, and what's "wrong" IMO.

Can you?

You've got to be kidding! I'm not a programmer, but I have three
advanced degrees, one a doctorate, and two of them in SW and CS. I have
made my living as a database, web, and system admin. I'm pretty good at
what I do, which (mostly) isn't writing code. Even though I've taught
programming (Java, C, JavaScript, and believe it or not, Perl), I've
never been employed as a programmer per se. I'm good enough to do my
job, but that's all. As to how Perl is bad at OO, I do not write OO
Perl. Except for the DBIs and DBDs I use. I wouldn't be qualified to
critique Perl as to OO.

does this prove that there are enough perl programmers?
does this prove that there is no increase?

The only thing this proves is that there are 14K Java jobs and 4K Perl
jobs on dice. This speaks for itself.

Doing a cursory search turns this up:
..NET 7241
c 6016
c++ 5913
c# 4881
vb 2442
cobol 1385
ada 191

I'll let you draw your own conclusions, since you seem to be an expert
conclusion drawer.

CC

 

[John Bokma]

OT: Apologies.

What for instance?

- inconsistent function naming
- huge number of functions in the default name space.

The latter is something Perl suffers from as well IMO, but not as bad as
with PHP. At least the names are not a mess like with PHP.

 

[John Bokma]

Did you read what I wrote? Apparently not.

Because you disagree? You say Java is better for large projects because
it enforces a strictness [1]. I call this bull shit.

[1] which according to you Perl programmers don't like, a generalization
that IMO is false

No. It says a lot about my local network and the network engineers. I
don't control my machines or what runs on them, and I don't have
administrative privileges. In fact, I have to scream like hell just to
get a user account on the systems I'm supposed to be supporting.
Politics is hell, and right now, I'm in it.

[ snip story ]

Your point is?

You've got to be kidding! I'm not a programmer, but I have three
advanced degrees, one a doctorate, and two of them in SW and CS. I
have made my living as a database, web, and system admin. I'm pretty
good at what I do, which (mostly) isn't writing code. Even though I've
taught programming (Java, C, JavaScript, and believe it or not, Perl),
I've never been employed as a programmer per se. I'm good enough to do
my job, but that's all. As to how Perl is bad at OO, I do not write OO
Perl. Except for the DBIs and DBDs I use. I wouldn't be qualified to
critique Perl as to OO.

Ok, IRMC, since
"Perl's object model, by contrast, is a mess"
<[email protected]>


I guess your random statement had a lot to do with
"Tom was beginning to use OO Perl for the last two or three years"

He probably never got beyond the first 3 pages because of the mess he
programmed.

The only thing this proves is that there are 14K Java jobs and 4K Perl
jobs on dice. This speaks for itself.

How does 14k appels compared to 4k pears speak about:

if there are enough pears?
there is no increase of the number of pears compared to previous years?

Doing a cursory search turns this up:
.NET 7241
c 6016
c++ 5913
c# 4881
vb 2442
cobol 1385
ada 191

I'll let you draw your own conclusions, since you seem to be an expert
conclusion drawer.

At least I don't pull them out of my ass :-D.

 

[John W. Kennedy]

Okay, the lack of records (what is record I/O?)

In C, fread/fwrite. FORTRAN binary I/O, the nearest equivalent, is
scatter/gather.

is serious. Other
features could be supported by library routines.

At a completely unacceptable overhead for most of them, replacing, in
most cases, sequences of three to five instructions with hundreds or
thousands.

 

[addinall]

In C, fread/fwrite. FORTRAN binary I/O, the nearest equivalent, is
scatter/gather.

Eh?

What is wrong with

OPEN
READ
WRITE
CLOSE

???

Mark Addinall.

 

[addinall]

No, it wouldn't have, lacking, as it did (just off the top of my head):
decorated numeric output,

F14.2

Fourteen digit places, reserve two for decimal.

record I/O,

OPEN
READ
WRITE
CLOSE

Could all access record I/O

fixed-point arithmetic, and

FORTRAN had support for fixed point arithmatic since the IBM
360/44.

even the most primitive string manipulation.

Eh?

CHAR
ICHAR
TRIM
INDEX
LEN
STRING // STRING2 // STRING3


Hope that helps!

Mark Addinall.

 

[addinall]

- inconsistent function naming
- huge number of functions in the default name space.

The latter is something Perl suffers from as well IMO, but not as bad as
with PHP. At least the names are not a mess like with PHP.

You just took someone to task for saying that the Perl
object model was a 'mess' compared to Java! Shame
on you for using the same argument!

Personally, I think Java sucks for almost anything,
and would much rather code an application in Perl.
However, PHP does screens and forms nice and fast,
and while the object model is not exceptionally powerful,
I find it intuitive and easy to use. Shrug.

Mark Addinall.

 

[John Bokma]

You just took someone to task for saying that the Perl
object model was a 'mess' compared to Java!

Because he had no idea what he was talking about? I recall he wrote
somewhat in the end "I am not a programmer".

Shame on you for using the same argument!

Same argument? I gave two very clear examples instead of just "Yeah,
well, Tom never really got it" (or something along those lines).

Maybe read:
http://tnx.nl/php

(please do not quote signatures)

 

[anno4000]

In C, fread/fwrite. FORTRAN binary I/O, the nearest equivalent, is
scatter/gather.


At a completely unacceptable overhead for most of them, replacing, in
most cases, sequences of three to five instructions with hundreds or
thousands.

I don't understand. If a compiler can realize an operation in a handful
of instructions, why should a library take hundreds or thousands?

Anno

 

[John W. Kennedy]

Eh?

What is wrong with

OPEN
READ
WRITE
CLOSE

In the first place, there were no OPEN or CLOSE statements in FORTRAN in
the time period under discussion. OPEN was achieved implicitly; CLOSE
was implied, as needed, by the END FILE and REWIND statements.

In the second place, as I said, FORTRAN binary I/O is scatter-gather,
and thus imposed an unacceptable overhead.

 

[John W. Kennedy]

I don't understand. If a compiler can realize an operation in a handful
of instructions, why should a library take hundreds or thousands?

Because a compiler is aware of compile-time constants.

 

[John W. Kennedy]

F14.2

And what about thousand commas, "CR" and "DB", and floating currency signs?

Fourteen digit places, reserve two for decimal.

No, fourteen characters, reserving three for decimal point and two
decimal digits.

OPEN
READ
WRITE
CLOSE

No, as I have already explained.

Could all access record I/O


FORTRAN had support for fixed point arithmatic since the IBM
360/44.

No it did not. In the first place, 44PS FORTRAN supported exactly the
same language as FORTRAN G and H (it even used the same manual). In the
second place, FORTRAN has /never/ supported fixed-point arithmetic.
(Except to the extent that integer arithmetic is a subset.)

Eh?

CHAR
ICHAR
TRIM
INDEX
LEN
STRING // STRING2 // STRING3

None of which existed in the period in question.

 

[axel]

Okay, the lack of records (what is record I/O?) is serious. Other

Record I/O is basically conducting I/O by reading and writing files
based on 'records'... i.e. you can't just print a line to a file, you
need to write a whole record in a fixed format of some type.

I am probably wrong, but I believe even today COBOL programmers think
solely in terms of records and find it difficult to imagine free form
data.

I certainly remember many years ago when I first used a computer
at school (translation for Americans... that is the thing before
university after delving beyond BASIC, I went further and
experimented with COBOL and Algol 60... as a consequence I found
that the OS I was using (ICL 1900 series, probably unknown outside
the UK) had very specific means of reading and writing to files.

There were things like TR and TP (Tape Reader and Printer), CR and
CP (ditto for 80 character width punched cards) and so on... even
when reading and writing to files, these had to be to be used (rather
like peripheral drivers today). There was also some disc stuff...
and funnily enough even specific writers for Magnetic Drums. I
really wish I had kept the manuals from that time that I acquired
as they really are museum pieces now... especially the pages regarding
how to programme using proper money such as pounds, shillings, and
pence.

Axel

 

[axel]

John Bokma wrote:

You just took someone to task for saying that the Perl
object model was a 'mess' compared to Java! Shame
on you for using the same argument!

It's not quite the same. From what I remember of the last time of
seeting up PHP, it was a case of having to decide what was wanted then
and there (as in access to whatever DBS/LDAP/&c) rather than being able
add on modules as needed. Hence stuff got there and if it was wanted
later, basically you are buggered.

Personally, I think Java sucks for almost anything,
and would much rather code an application in Perl.

Makes sense. For many, many applications. If I were greedy and
wanted to spin out a contract, it would be lovely to code in Java
as it takes a lot longer to do some very simple things... not in
the conception or the algorithm... just actually coding it all.
But I am not greedy and more importantly I am easily bored.

However, PHP does screens and forms nice and fast,

Yes... for reading stuff from a DBS. Writing to one is a nightmare
as one never actually knows how a system is set up so it virtually
becomes impossible to write generic secure code. So I don't.

Unless offered a fistful of dollars to choose between the good,
the bad and the ugly.

Axel

 

[John W. Kennedy]

Record I/O is basically conducting I/O by reading and writing files
based on 'records'... i.e. you can't just print a line to a file, you
need to write a whole record in a fixed format of some type.

I am probably wrong, but I believe even today COBOL programmers think
solely in terms of records and find it difficult to imagine free form
data.

In actual COBOL, it is the only form of I/O.

But in the 60's, this was a major performance point. By doing the I/O in
raw binary, record form, both memory and processing were saved. (The
normal COBOL READ and WRITE statements are designed to give the
programmer pointers to the records in the actual buffers -- the disk
cache, if you will -- though modern operating systems generally don't
permit this, so that COBOL has to create a dummy buffer, instead.)
FORTRAN binary I/O required a separate buffer, and then variables had to
be copied to and from the buffer, one at a time. On a 14xx or 7080, or
on the smaller 360's, this could make a huge performance difference,
especially when using I/O devices with timing thresholds. (For example,
if the system driving a base-model 1402 card reader couldn't keep up its
rated speed of 800 cards per minute, it slowed to 400.)

 

[Charlton Wilbur]

...could you? It's possible to write good or bad code in just about
any language, but some languages definitely make it easier to write bad
code and other languages definitely make it easier to write good code.

More to the point, some languages abstract away some things, and
others don't. When I write SQL, I'm not worrying about how the data
is represented in the filesystem and when and how it gets cached.
When I write Perl, I'm not worrying about how many bytes of memory are
being allocated and whether that memory will be freed in the end.
When I write C, I'm often doing both.

Charlton