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

boldt@ca.ibm.com wrote:

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

Actually, the bug in the program was a logic bug.  Which was what
made it so difficult for them to figure out.  Program ran fine, never
gave an error, just didn't' do what it was designed to do.

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

Why shouldn't everything be easy to learn?

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

But the fact remains, they aren't in other systems.

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

True.  There are syntactical differences in all languages.  If there weren't
they would be the same language anyway.

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

True.

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

*shrug* <g>

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

Actually, that has very seldom happened to me.  Although, to be
honest, it is a real pain in the neck to determine all the DLLS you
need to send with a package you write.  I am helping someone
learn to program (poor sap, me as a teacher) and he is using Visual
Basic.  He still has trouble trying to get RICHTX32.OCX or DLL
to work.

But then, he's the developer, not a end user.

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

I bought RedHat 5.2 not 2 months ago.  Soon as I get it installed
I'm told that 6.0 or 6.1 is the latest and greatest now.  I just don't
feel like spending forever trying to figure out what packages and
files and everything else I have to download to upgrade.

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

Never ran into that problem myself, but then, I haven't used Perl that much
either.

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

How fast something is programmed doesn't' necessarily make it
the best program.  Although I will agree, being able to program quickly
is a definite asset.  It's just a problem if no one else can figure out how
to fix it, maintain it etc...

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

I know that on my Linux box there are just some things I'm going to have
to use Perl for instead of anything else, just because that's how everyone
else does it.

But, just like APL, where you could write a program very quickly in a very
short amount of space, maintainability becomes very very difficult.

As you can probably tell, I am one for making almost all languages do 
everything,

and making them do it very similar.  Years ago, 10+, this was unheard of,
but is becoming a reality.  I'm sure, though, that as we approach that ideal,
I'll be retired anyway.  But, heck, maybe by then my PCs will never give
me a BSOD.

Regards,

Jim Langston

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