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]

"Bill Cunningham" <nos...@nspam.invalid> wrote:
> 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]

Jürgen Exner <jurg...@hotmail.com> wrote:
> "Bill Cunningham" <nos...@nspam.invalid> wrote:
> > 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.

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
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de

[Henry Law]

On 30/10/12 10:47, Jens Thoms Toerring wrote:

> 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

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

--

Henry Law Manchester, England

[Bill Cunningham]

Henry Law wrote:

> 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]

Jürgen Exner wrote:

> 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

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

[Jürgen Exner]

"Bill Cunningham" <nos...@nspam.invalid> wrote:
>[...] 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]

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.

--
Justin C, by the sea.

[Peter J. Holzer]

On 2012-10-31 15:10, Justin C <justi...@purestblue.com> wrote:
> On 2012-10-30, Jürgen Exner <jurg...@hotmail.com> wrote:
>> "Bill Cunningham" <nos...@nspam.invalid> wrote:
>>>[...] 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


--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[Bill Cunningham]

Jürgen Exner wrote:

> 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

[Ben Morrow]

Quoth "Peter J. Holzer" <hjp-u...@hjp.at>:

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

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

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

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.

Ben

[Peter J. Holzer]

On 2012-11-05 20:34, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-u...@hjp.at>:
>> I don't think you can learn programming without a language (that would
>> be like learning to write novels without a language).
>
> 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


--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr

__/ | http://www.hjp.at/ | zusammenpa�t. -- Ralph Babel

[Graham]

"Ben Morrow" <b...@morrow.me.uk> wrote in message
news:7gklm9-...@anubis.morrow.me.uk...

Interesting. By profession and training, I'm a construction industry
surveyor/estimator and I was trained to think logically (and I probably do
naturally anyway). It's only a short jump from that to programming. I've
played with Perl for the best part of 15 years now and, with a bit of help
from people here have actually got half decent - see recent results at
http://guitartabs2notes.cleverpages.co.uk (and particular thanks to Ben for
his help with that).

Graham

[ccc31807]

On Monday, October 29, 2012 9:19:38 PM UTC-4, Bill Cunningham wrote:
> 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 demands of 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 a musical instrument or anything else --- practice, practice practice. Every day 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]

On Monday, November 5, 2012 3:48:05 PM UTC-5, Ben Morrow wrote:
> 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. 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.

CC.

[Mladen Gogala]

On Fri, 09 Nov 2012 14:34:12 -0800, ccc31807 wrote:

> 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 demands of a manager, customer, or some other person in authority.

Commonly known as "PHB".



--
Mladen Gogala
The Oracle Whisperer
http://mgogala.byethost5.com

[Ben Morrow]

Quoth ccc31807 <cart...@gmail.com>:

> On Monday, November 5, 2012 3:48:05 PM UTC-5, Ben Morrow wrote:
> > 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 didn't mean 'doing well' in the sense of making money, or making a
useful contribution to society, but in the sense of doing whatever it is
you are doing, considered as an end in itself, as well as it can be
done. There is certainly a place for mediocre cooks and mediocre
musicians, and the fact they are mediocre doesn't necessarily diminish
the usefulness of what they are doing. It simply means that a good cook
or a good musician doing that job, if you could get one to do it, would
do it a whole lot better.

(Cooking might be a bad example. I'm not convinced that cooking at any
level below high-class restaurant food requires anything more than
application and experience to do well.)

> 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.

Right, there are plenty of jobs for bad programmers. It doesn't stop
them from being bad programmers, though, and it doesn't change the fact
that for many (probably most) people no matter how hard they work they
will never be good programmers. If your only interest is in earning
money that may not matter, but I don't consider that particularly
important (necessary, yes, but neither interesting nor valuable in the
general sense).

> In many cases, it's not what you've got, but how you use what you've
> got. 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'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.)

Ben

[Peter J. Holzer]

On 2012-11-09 22:43, ccc31807 <cart...@gmail.com> wrote:
> 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.

[ccc31807]

On Nov 9, 11:18 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> 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]

On Nov 11, 7:39 am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> 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.