Languages as a moving target (was: Re: Perl question)

[Jay R. Ashworth]

On Fri, Jun 18, 2004 at 09:05:52PM -0400, Fairlight wrote:
> At Fri, Jun 18, 2004 at 11:39:17AM -0700 or thereabouts, 
> suspect Bill Campbell was observed uttering:
> > On Fri, Jun 18, 2004, Jay R. Ashworth wrote:
> > >On Thu, Jun 17, 2004 at 05:37:13PM -0400, Fairlight wrote:
> > >> PHP is eeeeeevilllllllll!  And people say -perl- is a moving target?  :)
> > >
> > >You make an interesting point here, Mark; one which punches one of my
> > >larger buttons.  And no, this is actually *not* a filePro sucks screed,
> > >folks.  :-)
> > >
> > >Is it my imagination, or do programming langues rev faster (higher? :-)
> > >than they they did When I Was A Kid?
> > >
> > >It seems to me that COBOL, Fortran, C, Pascal, and all the
> > >"traditional" programming languages have a much longer revision cycle,
> > >and much smaller changes than most of the more recently designed
> > >languages (with the possible exception of Perl). 
> 
> And how many versions of gcc have been out in the last few years?  Geez.
> I'm not even sure what they're adding.  :)

Fine.  But has the *language* changed?  I don't think so.

> > >PHP, Python, and things which are more 'environments' than languages,
> > >like Zop, all seem to rev so fast that I can't even get my programming
> > >knowledge stable in them before There's A Better Way To Do It.
> 
> Fortunately, perl seems to -rarely- break backwards compatablity.  The only
> thing I can think of is the case where they started requiring @ to be
> escaped inside interpolated strings, and that was -ages- ago between v4 and
> v5.  Better ways of doing things come out, but they rarely break the old
> ways.  I hear it's not so in the PHP world, where one minor release to the
> next can rip a function right out from under you.

Perl is indeed better than some.

> > >Is this just me?  Or are language designers just antsy-pants these days
> > >compared to, oh, Fortran 77 and Fortran *90*?
> 
> A bit.  :)

:-)

> > >Lots of people like Python a lot.  I can currently read it, and modify
> > >it a little, but not write it.  A debugger that would show current
> > >execution context, stackframing and the like in realtime would help a
> > >lot, but while there probably is one, I ain't found it yet.
> > 
> > I haven't tried it with python, but ``ddd'' supports python.  I've used
> > that extensively with perl, and find it very helpful.
> 
> I recently tried perl -d.  *cough*  Uhm, I have better luck using gdb with
> C code, to be honest.  I can -use- that.  Granted, I only tried this for
> like 30min, but debuggers have never been particularly easy for me to use.
> I prefer to rely on an old maxim my C mentor impressed upon me, which can
> be applied/extrapolated to any language:  "Remember, printf() is your
> friend!"

As long as you're not chasing a Heisenbug.

> I've rarely found something that couldn't be narrowed down with a little
> debugging output, if I have the source.

GUI programs, my son.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

                2004 Stanley Cup Champion Tampa Bay Lightning