Re: Extract number from character field(Perl syntax) (wayyofftopic)

Jim wrote:
>Yes, I can use Perl if I HAVE to.  I went through a few tutorials
>on the internet to learn it, and I did not find it intuitive at all.  I
was also
>helping a Perl programmer debug their Perl scripts.  This was someone
>who was using Perl for quite a while and couldn't find the bug.  Here I
>had been using Perl for less than a few weeks and found their bug.
>It's not a matter of not being able to decipher it, but the fact that it
does
>have to be deciphered to be figured out.

Do you use "-w" and "use Strict;" in Perl?  The former option
give you more warnings, the latter restricts some of the more
dangerous features of the language.  In the Perl newsgroups,
when someone asks why their program isn't working, this is
often the first question asked.

Perl may take longer to learn than other languages, but then,
why should everything be easy to learn?


>I don't' feel I need to learn something such as "regular expressions" if
>it's only going to be used in one or two langauges/platforms.  On the
>other hand, learning pointers, functions, subroutines, etc... can be used
>in almost all languages, one way or another.

Generally, those who are familiar with regular expressions in
Unix-style systems, really miss them when forced to use other
systems.


>OO is fine, because it can be used in quite a number of languages.  In
fact,
>I've used OO in Delphi, VB, some VC++

On the other hand, there are differences in most OO languages.
Some support multiple inheritance, others only single.  Some
are "typeless" and resolve things at run-time, others complain
about type mismatches at compile-time.  Add to that different
class libraries you have to learn.  Java, the language, is easy.
The hard part of Java is learning the class libraries.

To me, it seems that when doing OO in a language with strong
type checking, you spend most of your time trying to fit an OO
design around the limitations of the language.  For example,
casting objects to the correct type is almost unavoidable in
languages like C++ and Java.


>Java MAY become big, if someone
>makes a GOOD compiler for it, which will bring it up a generation or two.

I suspect your beef is not with the compiler, but rather with
the JVM.  Java on the AS/400 has one of the best JVMs around.


>I think this has to do with the mentality of the Linux world.  I have a
>Linux system at home I installed, and I had complained to someone
>that every time I tried to install a package it complained about missing
>dependencies.  His reply was that's what made it so fun.  So after
>downloading the program I wanted, downloading one dependency
>then finding out IT had a dependency, I downloaded THAT dependency
>installed it, installed the previous dependency then the original program
>I wanted.  This was a XWindows IRC client.  Took me about 4 hours.
>When I wanted one for Windows I download mIRC and installed it.
>
>Spending 4 hours to do something that can be done in 1/2 hour is not
>my idea of "fun".

Nor is that my idea of fun.  In Windows, haven't you ever
installed some app that updated DLL's causing other apps
to fail?  (I've read that that's a common problem in the
Windows world.)  A different angle to a similar problem.

One way to deal with dependencies is to spend a buck or
two now and then for the latest CD of some distro like
Redhat or SuSe.  That will give you current versions of
the more common packages.

But comparing that to learning Perl is not the same.
People use Perl because they can solve problems quickly,
not because they want to waste their time solving cryptic
bugs.  A good understanding of Perl is necessary to avoid
falling into the traps.  "-w" and "use Strict;" are
essential to avoiding the most common pitfalls.


>> You've read the story about the UCLA programming
>> contest where the winner decidedly trounced all others
>> by using Perl?  The organizers of the contest banned
>> Perl from subsequent contests!  (The winner said he
>> didn't know what to do with his prize - a copy of MS
>> Visual C++!)
>
>Why not program in Assembly?  Isn't it the most powerful there is?
>But there are very few Assembly programmers out there.

The purpose of the contest was to solve as many problems
as possible in three hours.  The winner, a single programmer
using Perl, solved five.  The second place _team_, solved
three.  I know from personal experience that writing a
program in assembler language can take at least double the
amount of time than by using a high-level language like C.
And even that includes using macros that simulate features
of high-level languages.  (But then, it's been years since I
did any assembler programming - faster processor speeds and
optimizing compilers have made assembler obsolete.)

The lesson is that you can often get a program up and
running faster using something like Perl.


>> Someone once told me:  "There are two type of people:
>> those who like APL and those who haven't been properly
>> introduced to it."  I think the same could apply to
>> Perl.
>
>How many APL programmers do you know around today?  In fact,
>I went looking for an APL compiler for my Windows box a few years
>back.  Didn't come up with anything.

I wasn't defending APL. (I was never properly introduced to
it myself!)  My point is that you often need the proper
education, especially for something that appears at first
glance difficult.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---