[aklug] Re: Perl 5 OOP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arthur Corliss wrote:
> On Thu, 7 Jan 2010, Christopher Howard wrote:
>
>> All right -- language war!
>
> :-) Not trying to start that. Just saying apples to orange comparison when
> you look at what those languages are trying to accomplish.
>
>> Err, oops... mature response: Doubtless, Perl is a powerful and
>> convenient language, or it wouldn't have had such an integrated,
>> gripping influence in the Unix world. Is it even possible to run even a
>> minimalistic Linux system without Perl, with all the utilities we have
>> come to depend on?
>
> Technically, yes, but you will be rewriting many of the helper scripts and
> some of the cron'd maintenance scripts. By default, it is far simpler to
> just have it there.
>
>> Perl was actually my first language, and C was my second language. I
>> have actually been a rather firm Perl supporter in the past, and there
>> are a number of things that I do really like about Perl.
>
> Find me *any* language that does regular expressions better than Perl. :-)
>
>> Having said that, I have come to realize that Perl does not provide a
>> very comfortable environment for developing structured code bases that
>> grow and bend well to fit the needs of the project. As others have
>> mentioned often (here and elsewhere) much of syntax and capabilities
>> that modern programmers have come to love and depend on were sort of
>> tacked on to Perl 5 as an afterthought in the form of modules. And
>> sometimes these additions never quite reach the same level of natural
>> comfort as in most other languages, OOP being probably the most sore
>> example.
>
> I would object to the concept that you can't have structured code bases
> (and
> scalable ones at that) under Perl. In fact, I personally know Google would
> disagree with you as well. In addition, I'm not sure about the
> assertion of
> "tacked on". Most of the modules on CPAN are written in a very Perl'ish
> manner. Sometimes you have to deal with the predilections of the author
> (do
> they prefer functional interfaces, OO, etc.), but it's all very much
> Perl'ish in any manner.
>
> That said, I will grant you OOP will not be quite as easy as in other
> languages (and never mind the fact that many programmers use OOP far more
> than they should -- being a purist and doing *everything* in OOP is
> imbecilic), but give me another example? For everything I've had to deal
> with, I haven't felt the "tacked-on" nature of things that you have (at
> least not as endemic as you paint it here). Quite frankly, even in
> C/C++ you have various different conventions you have to abide by when
> dealing with disparate third-party libraries. That's a problem with all
> languages.
>
>> Your argument about allowing low-level manipulation has merit, although
>> it is something of a double-edged argument in the case of Perl. For
>> while you have the option to do low-level coding, do you really have the
>> option to do high-level coding? That is, if it takes twice as much
>> thought and code to do high-level programming, is it really high level?
>
> In OOP, definitely not on par with the true OOP languages. As I mentioned,
> this really doesn't bother me. If you look at the computer language
> shootout, I think you'll see that for many tasks Perl is on par with many
> high-level languages when comparing lines of code per function. And where
> it fails, <G>, write a module and never write it again. All future code
> now
> gets the same benefits (though I doubt you'll find *any* high level
> language
> with a publically accessible library of code on the scale of CPAN).
>
> In short, it sounds to me like your objection really has nothing to do with
> the language but your personal programming philosophy. It sounds like you
> want to do nothing but high-level programming. Certainly, Perl may not be
> your cup of tea, then. And for general tasks you can get away with it.
> But
> I think the reality is that once you have to deploy scalable code on
> limited
> resources you're going to wish you could get closer to the bare metal
> and do
> some low-level refinements. Quite frankly, most "high level" languages
> cheat the system by just providing wrapper APIs to C libraries.
>
> <G> When in need of performance, what do we all do? Turn to a library
> built
> in a low-level language....
>
>> Java is probably not the best comparison as it is supposed to be
>> strictly high-level. Most notably, no pointer arithmetic allowed. A
>> better comparison would probably be C++. C++ gives you natural OOP,
>> concise syntax, comfortable exception handling, and so forth. But it
>> also always you to drop down into C style constructs and mess with
>> pointers, manipulate structures, and heck, even execute assembly code if
>> you want to!
>
> It also is incredibly non-portable, very much sensitive to the differences
> between compilers (hell, even versions of the same compilers) for STL
> support and so on. :-) At which point you're best left going back to ANSI
> C or, heh, Perl.
>
>> In all fairness, though, every language has changed an adapted over
>> time. Perl 6 was supposed to give us everything we wanted. But what is
>> the state of Perl 6? When does it become something that we can expect to
>> find readily available in most major distributions?
>
> :-) I'm a dinosaur, so I really don't know, and don't care. Perl 6 is a
> major inconvenience to me (when it comes) because it's a radical enough
> evolution of the language that I'm going to have to port all of my existing
> Perl 5 code just to make it work correctly with Perl 6 code. I'm not
> looking forward to that. Most of the CPAN developers aren't looking
> forward
> to that.
>
> Rewriting code bases in new languages is a young man's game. As you get
> older and your core libraries get large enough you'll see that you're going
> to be less eager to reimplement the same software in a new language, less
> interested in resolving the same problems you've already solved.
>
> --Arthur Corliss
> Live Free or Die

I'll think I'll let this debate rest for now. One more point of
curiosity, though: I was surprised by what you mentioned about porting
to Perl 6. I had just assumed that Perl 6 was going to be backward
compatible. But I checked online, and apparently it isn't.

Kind of odd decision... you would think they would have found some way
to make use of all those specialized Perl 5 modules. I remember reading
online that it is possible to embed Perl 6 code in a Perl 5 script by
way of a module... seems strange that they don't have some way of
translating Perl 5 code (or at least function calls and exports) into
Perl 6 before run-time.

- --
Christopher Howard
http://indicium.us
http://theologia.indicium.us
http://robots.arsc.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktH0tAACgkQQ5FLNdi0BcUlbwCeOCcCtkiMjoL7aD4hriB88LmJ
C9EAn0Oc9SF+VVUmCvvwbRLJmaEyT6n8
=fXlx
-----END PGP SIGNATURE-----
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Fri Jan 8 15:52:26 2010