Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Re: Perl's warts

by mothra (Hermit)
on Mar 21, 2001 at 19:38 UTC ( #66041=note: print w/replies, xml ) Need Help??


in reply to Re: Perl's warts
in thread Perl's warts

because I didn't come from a UNIX background. ("ls" and "chmod" were about the only UNIX commands I knew.) Everytime the book said "Perl function x works just like y in UNIX" I had to go spend (sometimes hours) trying to figure out what the heck that meant. It was very frustrating.

This statement reflects something I've said many many times before and I'll say yet again, Perl needs to be more OS agnostic. The fact that it's severly Unix biased is not A Good Thing(TM). Perl has so much to offer for developers of all platforms (and speaking from my perspective, most certainly Win32 and Unix), but there's noone that can convince me that it really "feels" like a Win32 language in any way as much as it does a Unix one. (I happen to use both OS's).

Perl is NOT designed for creating one-size-fits-all solutions, which means that there are very few pre-packaged, ready-to-go out-of-the-box, for-pay Perl programs. That's not a bug, it's a feature. Perl isn't designed to solve everyone's problems, it's designed to solve your problem.

Interesting way of putting it. Though I can't say I totally agree that it's not for "ready-to-go out-of-the-box" stuff. Visual Basic + DLL Hell isn't a much more exciting prospect to look forward to. I speak from experience at my last job, where we simply could not get our internal report generation program to run on any but one of the computers in the office (because of missing DLL's and other odd errors).

And just one more thing I can't help but comment on...use Python for large projects? eek...I started testing Python out by doing (or starting to do) a new client of mine's site with Python. I got severely turned off by the syntactic whitespace when a.) I indented one line with a tab and the next line with spaces and the compiler complained (a completely invisible error), and b.) I downloaded what I thought would be a reusable form mailer Python program, only to find out when I got it that the indentation was all messed up, rendering the code useless. I can't imagine how much my paranoia would increase if I was dealing with a 20,000 - 50,000 line Python code base.

Needless to say, I'm doing the site in Perl now. :)

Replies are listed 'Best First'.
Re: Re: Re: Perl's warts
by merlyn (Sage) on Mar 21, 2001 at 19:51 UTC
    This statement reflects something I've said many many times before and I'll say yet again, Perl needs to be more OS agnostic. The fact that it's severly Unix biased is not A Good Thing(TM). Perl has so much to offer for developers of all platforms (and speaking from my perspective, most certainly Win32 and Unix), but there's noone that can convince me that it really "feels" like a Win32 language in any way as much as it does a Unix one. (I happen to use both OS's).
    And I'll disagree with that. Perl's target market is Unix hackers. It's a toolbox for Unix. The fact that it also tries to be cross-platform is secondary in goal. I would not want any decisions made to increase portability at the expense of how well it hacks on Unix any more than I'd want Perl to be easier for beginners at the expense of experts.

    Certainly, if you can add or modify a feature to make it more portable without damaging the Unix interface, I'm for that.

    But let's take a common complaint: the unlink operator. Everyone not familiar with hacking C on Unix wants to rename that to something like the delete operator. No. I say no. The prime market for Perl is still the Unix hackers who are moving cross-languages, not "scripting hackers" (whatever that is) moving cross-platforms. The word unlink has a very specific meaning to Unix hackers, and helps us get the job done faster.

    Perl fills the niche as well as it does because it did stay focussed on what was important for Unix hackers.

    If you want vendor-neutral, equally inefficient code on all platforms, you know where to find Java.

    -- Randal L. Schwartz, Perl hacker

      If you want vendor-neutral, equally inefficient code on all platforms, you know where to find Java.
      Let's not inadvertently sell Perl short. Perl is an example of a vendor neutral language, and ActiveState's port of the language to Windows seems full-featured to me.

      On the other hand, Java can't be vendor-neutral, because it is owned by Sun Microsystems and Sun is one of the largest hardware/software vendors in the world. Even if Sun were to say that it does not use its ownership of Java to promote their own products I would not believe them.

        You are absolutely right that Sun uses its ownership of Java to promote its own products. Let me just give 3 examples.

        Java is designed so that you are forced to use threading everywhere. At the time it was written, exactly one flavour of Unix was designed to work well with heavy multi-threading, and that was Solaris. Competitors such as HP-UX used kernel threads and if you tried to open too many the box would slow to a crawl.

        Sun has a long history of using its ability to control of Java certification as a bargaining chip in negotiations with vendors.

        To get around the performance problems of Java, Sun has defined various extensions with efficient platform-specific external implementations. This includes things like vector math packages. In case the optimized implementation is not available for your platform, there is a fallback native Java implementation of the API which is much, much slower. Solaris has fast implementations of all of these standards. But other platforms, like Linux, have had trouble getting supprot even when companies existed that were ready, willing and able to pay necessary license fees and develop the package.

        The result is that Java applications developed on Solaris that run fine on Windows will crawl to a halt on Linux.

        Yes, Java may be write once, run everywhere. But not all platforms you run on are created equals...

Re: Re: Re: Perl's warts
by mrmick (Curate) on Mar 21, 2001 at 21:23 UTC
    Just my $.02 .........

    While Perl's target market had traditionally been rather UNIX-centric, I think that this is no longer the case. More and more people are using Perl on WIN32 and Mac. In fact, most desktops are indeed WIN32 (I don't like it either).

    With that said, I think that the misconceptions about Perl are largely based on most people thinking that it is strictly a web scripting language. People don't realize that this wonderful language has been used to develop enterprise-type solutions for large corporations.

    In fact, many hardware design tools/suites (on UNIX and WIN32) use Perl as part of their API because of its flexibility and power. We also use Perl as part of our software distribution system here at work (on UNIX and WIN32).

    I would not want to take the UNIX flavour away from Perl because I think therein lies its power. If someone does not know UNIX commands and the like, then it's about time they learned them. After all, if someone's not willing to learn a little, why do they even bother programming or doing anything for that matter?

    Try not to think of Perl's unique features as warts but rather as beauty marks.

    Mick
Re: Re: Re: Perl's warts
by Trimbach (Curate) on Mar 21, 2001 at 20:15 UTC
    Interesting way of putting it. Though I can't say I totally agree that it's not for "ready-to-go out-of-the-box" stuff. Visual Basic + DLL Hell isn't a much more exciting prospect to look forward to. I speak from experience at my last job, where we simply could not get our internal report generation program to run on any but one of the computers in the office (because of missing DLL's and other odd errors).

    I would argue that Visual Basic + DLL Hell isn't designed to provide any solution for anyone :-D but when I said "ready-to-go out-of-the-box" I was referring to pre-compiled binaries... probably written in C or C++ or something like that. Any such generic solutions have inherent limitations because they're generic... the binary can't take into account all the little in's and out's of my particular system, and because they're precompiled they can't take into account all the intricacies of my problem at hand. A generic binary can often be a good solution to a problem, but a custom-made solution can be made perfect.

    That's where I think Perl is the bomb... it gives you a relatively easy tool to provide a perfect, customized solution. (Sure, you could write your own binary in C, but why when it's so much more fun to do it in Perl. :-D)

    Gary Blackburn
    Trained Killer

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://66041]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (5)
As of 2019-10-19 22:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?