lerning perl

[Bill Cunningham]

Is the best way to learn perl to start with perlintro and then move in a
sequence through the tutorials? Where can I get the meanings of the
functions? man open works with the unix API and man fopen with C, but what
about perl functions?

B
man key for example doesn't work.

 

[Jürgen Exner]

Is the best way to learn perl to start with perlintro and then move in a
sequence through the tutorials?

Get yourself a book. If you are an experienced programmer in some other
language then "Programming Perl" is a very good start. If you are new to
programming itself then 'Learning Perl" is often highly recommended.

Where can I get the meanings of the
functions? man open works with the unix API and man fopen with C, but what
about perl functions? man key for example doesn't work.

Use perldoc:
perldoc -f open
perldoc -f keys

To learn more about perldoc use perldoc
perldoc perldoc

And for frequently asked question, e.g. about what books there are use
perldoc -q books

jue

 

[Jens Thoms Toerring]

Get yourself a book. If you are an experienced programmer in some other
language then "Programming Perl" is a very good start. If you are new to
programming itself then 'Learning Perl" is often highly recommended.

Before you start spending lots of time trying to "help" this
Bill Cunningham character I'd recommend that you all spend a
short bit of time on checking his posting history over the
years in other newsgroups (like, for example, comp.lang.c or
comp.unix.programmer) and see for yourself if you can detect
a certain pattern. I think I can predict with high certainty
that he will never master the most basic elements of Perl -
same as he never seems to manage to write a working C pro-
gram after years of coaching - it looks as if he actually
gets worse at it over the years...

Regards, Jens

 

[Bill Cunningham]

Done, thank you; forewarned. Now let's see; who knows, things might
be different.

I've had a lot of trouble with C over the years but I am still trying to
master it. I'm not a professional programmer but I've read about perl and
I'm still checking things out. I have invested so much time in C I'm not
going to leave it. Even knowing how to program things in C I don't know
algorithms and that's needed for proper programing. I do some programming in
the unix api. Like I am studying sockets. Python has been suggested to me by
others over the years and I looked at it and perl just seemed better. What
can I say I try.

Bill

 

[Bill Cunningham]

Get yourself a book. If you are an experienced programmer in some
other language then "Programming Perl" is a very good start. If you
are new to programming itself then 'Learning Perl" is often highly
recommended.


Use perldoc:
perldoc -f open
perldoc -f keys

Ok my linux implementation has perldoc in it's own package. I have it
installed now.

 

[Jürgen Exner]

[...] Even knowing how to program things in C I don't know
algorithms and that's needed for proper programing.

In other words: you are and have been putting the cart before the horse.
Maybe you should look into learning programming first. Once you
understand that then switching to a different programming language is
usually the easy part (yes, there are exceptions).

jue

 

[Justin C]

[...] Even knowing how to program things in C I don't know
algorithms and that's needed for proper programing.

In other words: you are and have been putting the cart before the horse.
Maybe you should look into learning programming first. Once you
understand that then switching to a different programming language is
usually the easy part (yes, there are exceptions).

jue

I feel a certain affinity with the OP. My first
programming was punched cards (at school), after that
I taught myself BASIC on a ZX Spectrum. I went on an
'Introduction to C course' intending to take the
follow-on course but the college dropped it saying
there was no demand. And there my education stopped
until I bought Learning Perl.

I've only ever learnt programming as part of learning
a programming language. I'd never considered it
possible to learn programming without a language
being associated. Could you point me (and the OP if
he's interested) in the direction of suitable /
relevant material?


Justin.

 

[Peter J. Holzer]

[...] Even knowing how to program things in C I don't know
algorithms and that's needed for proper programing.

In other words: you are and have been putting the cart before the horse.
Maybe you should look into learning programming first. Once you
understand that then switching to a different programming language is
usually the easy part (yes, there are exceptions).

I feel a certain affinity with the OP. My first
programming was punched cards (at school), after that
I taught myself BASIC on a ZX Spectrum. I went on an
'Introduction to C course' intending to take the
follow-on course but the college dropped it saying
there was no demand. And there my education stopped
until I bought Learning Perl.

I've only ever learnt programming as part of learning
a programming language. I'd never considered it
possible to learn programming without a language
being associated.

I don't think you can learn programming without a language (that would
be like learning to write novels without a language).

But you can't learn programming without algorithms either.

Programming is the art of finding algorithms and expressing them in a
formal language.

If you only learn what the elements of a programming language mean but
not how to put them together, you will never be able to program. If you
aren't able to analyse a problem, to find a repeatable way to solve the
problem (= an algorithm), you won't be able to program.

Actually writing down the algorithm in a specific language is easiest
part (although the devil can certainly be in the details), and it is
also mostly interchangable. If you understand a problem and its solution
and you can write it down in one language, you can also write it in any
other language with a little effort. (This is also apparent in the
existence of compilers: Compilers are programs which translate from one
programming language to another: They have existed for a long time, so
that's obviously a simple problem. But there are no programs which can
really program. So that's a hard problem which needs human creativity)

(I'm not even sure if everybody can learn to program: Some people just
don't seem to have the knack)

hp

 

[Bill Cunningham]

In other words: you are and have been putting the cart before the
horse. Maybe you should look into learning programming first. Once you
understand that then switching to a different programming language is
usually the easy part (yes, there are exceptions).

I can see right now that perl is going to be easier and higher level
than C. Now if I can do it. It C to check arrays you have to iterate through
the array elements by writing a program. It seems to be a lot easier in
perl. And I've got about as far as perlintro and I have to re-read it to se
what => is and "<" and ">" in the open function.

Bill

 

[Peter J. Holzer]

Turing, Church and so on did; but most of us aren't in that category.

I would say they just invented their languages as they went along.

hp

 

[ccc31807]

Is the best way to learn perl to start with perlintro and then move in a

Let me make a suggestion that's probably fundamental to learning any language, whether a programming language or any other kind of language: have a real need to learn the language.

The only way (repeat, ONLY) to really learn a language is to use it every day for real work. In many cases, Real Work means having to meet the demandsof a manager, customer, or some other person in authority.

My first exposure to Perl was academic, but then I used it for web applications, then got a job as a database manager and starting using it for database applications. I can't say I have a broad knowledge of Perl, but I certainly have a very deep understanding of those aspects of Perl that relate to the size of my paycheck!

You don't learn Perl by reading a book, even the Good Book which is the Perl documentation. You learn Perl the same way you learn to cook or to play amusical instrument or anything else --- practice, practice practice. Everyday for hours on end. If you don't do this, you will never learn Perl, or anyother language for that matter.

Books are very important, and I have over the years accumulated a shelf of books on Perl. I've managed to read most of them, and some of them I have read multiple times. I have the documentation on my hard drive and many times I have it open in a web browser when I'm writing Perl, it's that important. But as important as all of these things are, nothing is more important than engaging in the practice of writing Perl.

CC.

 

[ccc31807]

No. It's just like being a musician, or an artist: some people can do
it, some can't, and if you can't you might be able (with a lot of work)
to learn enough of the basics to bang out something approximately
reasonable, but you'll never do it well.

I'm not sure that I agree. With some things, you just have to learn basic stuff to do well. If you can fry potatoes and grill hamburgers you can cook,even though you will never be a chef. If you can learn to play hymns from a hymnbook you can be a church pianist, even though you might not be a concert master.

I've got a buddy who works for a defense contractor and bangs out user applications in VB for a living. He's written a ton of code over the years and does well financially. He's the only one in his unit who does what he does,and he performs an essential function for his unit. He's not a programmer,and doesn't know VB real well, but he's mastered the art of slinging code to perform useful functions.

In many cases, it's not what you've got, but how you use what you've got. Idon't disagree that some people have natural talent that the rest of us can't match, but that doesn't mean that thos of us without the talent can't make a contribution.

CC.

 

[Peter J. Holzer]

I've got a buddy who works for a defense contractor and bangs out user
applications in VB for a living. He's written a ton of code over the
years and does well financially. He's the only one in his unit who
does what he does, and he performs an essential function for his unit.
He's not a programmer,

This is a contradiction. If he "bangs out user applications" and has
"written a ton of code", he is a programmer. He may be a bad programmer
(I don't know him and haven't seen his code, so I couldn't say), but he
definitely is a programmer.

I don't disagree that some people have natural talent that the rest of
us can't match, but that doesn't mean that thos of us without the
talent can't make a contribution.

I guess you haven't met the people I meant when I wrote that "some
people don't have the knack".

There are people who couldn't "bangs out applications" even if their
live depended on it. They can't get from a problem to an algorithm to
code. They can learn the elements of a programming language by heart but
they never see how to apply them (I've met people like that when I was
an instructor at the university: They failed the same course (with only
minutely varying assignments) semester after semester).

Then there's those who could do it (at least for simple problems) but
don't have what I would call a programmer's mind: They just prefer to do
the same routine job by hand every time instead of writing a simple
script.

These people don't become programmers.

Of course there are (huge) differences in talent among programmers, too:

There are really bad programmers, you can write code, but it's buggy and
clumsy and they take a long time to solve even simple problems.

And there's the geniuses who whip out complex, non-trivial software
systems over the weekend, with few bugs and elegant solutions.

Most of us are between those extremes, I think.

hp

 

[ccc31807]

I'm sure you won't like me saying this, and it is certainly *not*
directed at anyone in particular, but there are far too many bad
programmers in the world and they do far more damage than they realise.
The entire PHP ecosystem (language, interpreter, libraries, the lot) is
a scary example of the way code written by people who really had no
business writing code can end up being used for important and security-
sensitive applications. (Many of the CGI scripts written in Perl and
copied from one site to another before PHP came along were an earlier
example.)

I don't object to this at all, and would subscribe to it. My point
was, to use an analogy, that while there might be a huge difference
between a master stone mason and a bricklayer in making a work of art,
you don't need a master mason to build a brick wall -- a bricklayer
will do just as good a job and maybe a better job BECAUSE he might
have a strong back but a weak mind.

To put it another way, 'People' and 'Cosmopolitan' and 'Playboy' sell
a lot more product than ACM or IEEE SIGS, even though you can call
contributors to both kinds 'writers.' You don't need advanced literary
skill or heightened aesthetic to write for 'People' et al, but that
doesn't mean that you don't serve a useful function in the writing
ecosystem.

Your point is that those with limited abilities should not do language
design, but that's a different issue. I fully agree with you here.

CC.

 

[ccc31807]

There are really bad programmers, you can write code, but it's buggy and
clumsy and they take a long time to solve even simple problems.

Maybe one of the things I had in the back of my mind was the
difference between professionals and amateurs. The word 'amateur' is
Latin, and refers to someone who does something out of love for it. A
professional is a mercenary who does something simply for the money.
There are plenty of bad musicians, or golfers, who make music or play
golf because they love to do it -- and there are also professional
musicians and golfers.

Unfortunately, we all know the difference between bad musicians and
golfers who do it out of love, and those that are really good.
Customers and employers don't (or can't) make the same distinction
with programmers.

And there's the geniuses who whip out complex, non-trivial software
systems over the weekend, with few bugs and elegant solutions.

Absolutely! And this is another critical problem. We as a
technological/managerial culture have a decided preference for ten
code monkeys over one brilliant genius, even though one brilliant
genius might produce more than a hundred code monkeys.

CC.