On scripting languages - Jay Maynard

> Recent entries
> Calendar view
> Friends page
> User info
> Jay's web page

Monday, 10 October 2005


Previous Entry Share Next Entry
0932 - On scripting languages

kinkyturtle dropped a minor bombshell last night when he mentioned that he was looking to learn Perl. I don't normally think of KT as a programmer (as, I suspect, most folks don't), but occasionally I do have to remind myself that he did do Scheme while he was at Rice. (Typical Rice thing, not too connected to the real world.) For KT's purposes, it will probably serve just fine, and Randal Schwartz's book Learning Perl is as good an introduction to a programming language as any I've seen anywhere, even if the companion reference Programming Perl tends to be moderately disorganized. KT won't have to deal with that for his uses, though.

Personally, while I'm comfortable in Perl and have a fair amount of experience with it, it's not the first tool I grab out of the toolbox any more. That honor goes to Python. I find it a lot more readable and maintainable, and I think it'll be easier to learn than Perl - and won't have a major redefinition to deal with in the future, unlike Perl (Perl 6 will, supposedly, be quite different from Perl 5).

There's also another reason that affects me, but that KT won't probably have to deal with: I find CPAN (the Perl module library) to be the Linux version of Windows' DLL hell problem. CPAN modules are updated frequently, with lots of version dependencies. This wouldn't be a problem except that the maintainers break backwards compatibility fairly frequently, and so if your program depends on a module, you might find yourself having to struggle to keep up, especially if you install another program that depends on a new version of a CPAN module which, in turn, drags in a newer version of the module that you'd been depending on, often six or ten layers of dependency deep. This completely sank one project I worked on.

Python has its detractors, mostly based on the unusual block syntax it uses. In Python, block structure is expressed by indentation. Most hackers, perhaps based on a genetic dislike of FORTRAN, JCL, and other old technologies where you had to put stuff in specific columns, have a dislike for having whitespace be significant syntactically. Those same hackers, however, will indent block structure anyway as a matter of good programming practice, and all Python does is use that same mechanism as the language's actual block structuring facility. I got used to it in a hurry.

Python avoids the CPAN hell problem by including the commonly used stuff with the standard language distribution. This means that upgrading Python, or its modules, is much less of a hassle, and much less likely to break your programs.

There are still some strengths Perl has over other languages. In particular, its pattern matching and related capabilities are still unsurpassed. Even so, I'll hack around the comparative weakness in Python to get the rest of the capabilities and maintainability. To me, it's that much better overall.

current mood: [mood icon] geeky
current music: The Doobie Brothers - It Keeps You Running

(6 comments | Leave a comment)

Comments:


[User Picture]
From:unspeakablevorn
Date: - 0000
(Link)
My main problem with Python (mind, this is with it being The Language I Do Things In) is that it is dynamically typed. Sometimes I want to be able to make absolutely sure that I'm passing in the right kind of thing. Also, dynamically typed languages don't have the ability to do function overloading, which I like to use to improve readability.

For that, I use C++.

Vorn
[User Picture]
From:jmaynard
Date: - 0000
(Link)
I can see your point on function overloading, but I'm not sure that's that big a cost in readability. However, in a dynamically typed language, the concept of "passing in the right kind of thing" doesn't mean much to begin with, does it? In that case, it's the interpreter's job to get the interpretation of the function argument correct, not the programmer's, and to do any necessary conversions.
[User Picture]
From:unspeakablevorn
Date: - 0000
(Link)
"any necessary conversions" may not, and usually do not, exist. Make a number out of a dictionary, go ahead, I dare you. :)

The problem with dynamically typed languages is that I don't know, just from a glance at the declaration line of a function, what I'm supposed to be giving to it, and I don't find out until that code path is followed by the interpreter. While the object I pass can technically be anything that has all the methods and instance variables asked of it by the function, I actually have to read the function all the way through to get that. Statically typed languages avoid this by binding method and instance variable names to class names, so that one word says all you need to know about an argument to a function.

Of these two, which is easier to figure out what's being talked about?
Map
[Error: Irreparable invalid markup ('<string,>') in entry. Owner must fix manually. Raw contents below.]

"any necessary conversions" may not, and usually do not, exist. Make a number out of a dictionary, go ahead, I dare you. :)

The problem with dynamically typed languages is that I don't know, just from a glance at the declaration line of a function, what I'm supposed to be giving to it, and I don't find out until that code path is followed by the interpreter. While the object I pass can technically be anything that has all the methods and instance variables asked of it by the function, I actually have to read the function all the way through to get that. Statically typed languages avoid this by binding method and instance variable names to class names, so that one word says all you need to know about an argument to a function.

Of these two, which is easier to figure out what's being talked about?
Map<String, double>
An object that can index on a string, and things it pulls out via indexing are being multiplied by floating point numbers.

The argument for statically typed languages is that the former is much easier to deal with, simply because we know /exactly/ what kind of things we need to implement to get it to work, and we don't have to go looking at the (maybe impossible to read) implementation.

Vorn
[User Picture]
From:livemerlyn
Date: - 0000

Learning Perl is not an intro to *programming*

(Link)
I had to read this a couple of times to ensure that "KT" is already a programmer. Thanks for the compliment on (and mention of) the book. Also check out "Learning Perl Objects References and Modules", in the same spirit and form as the llama.
[User Picture]
From:jmaynard
Date: - 0000

Re: Learning Perl is not an intro to *programming*

(Link)
You're right about Learning Perl not being an introduction to programming...then again, I'm not at all sure I'd inflict Perl on the beginning programmer, as the flexibility would get in the way of teaching the basics of breaking down a problem and solving it one step at a time.

I'll have to look for the other book you mention.
[User Picture]
From:sideband
Date: - 0000
(Link)
I would rather code CGI in assembly, without the assembler, with binary input only, than to write ANYTHING in Perl..

But that's just me.

> go to top
LiveJournal.com