[Novalug] Why Python

James Ewing Cottrell III JECottrell3@Comcast.NET
Sun Jul 21 15:41:08 EDT 2013


On 7/21/2013 8:54 AM, shawn wilson wrote:

> But hell, lets go with the idea that "Perl sucks". OK, prove it. Code,
> use cases, or studies (I prefer debating code - code doesn't lie).

We could do that, but when one language lacks a feature, or default to 
not using it, you are comparing Apples to Oranges.

For exacmple, once convinced that, say, Exceptions are Superior, it's 
hard to go back to Error Return Codes.

The only questions left are "How Important Is This" and "In What 
Environment?". For Small Jobs, it almost doesn't matter what you do.

The other question is what concepts you latch onto, or even Invent In 
Your Own Mind. I would state my own as something like "Current Thinking 
in Language Design is that Everything Is An Object, Variables Are 
Untyped, Objects Are Strongly Typed, Variables Hold Object References, 
and Exceptions Are The Rule".

This statement is True of Python and Ruby, Mostly True of Java (but true 
of some of its derivatives). I'm probably Simplifying, but then again, I 
Always Do.

I'd rather debate Principles rather than Details.

JIM

> On Sun, Jul 21, 2013 at 2:23 AM, James Ewing Cottrell III
> <JECottrell3@comcast.net> wrote:
>> On 7/20/2013 11:49 AM, William Sutton wrote:
>>> OK, replying here to a number of different threads/people about Perl
>>> misconceptions:
>>>
>>> 1. Perl has TK and GTK integration for GUIs
>>
>> As does Python and probably Ruby.
>>
>>> 2. Perl is very C-like, other than the weak typing, because Perl was
>>> written in C and consciously designed to be C-like.
>>
>> True. Of course, almost everything is written in C.
>>
>> Perl was designed as a mishmosh of C, sh, awk, with a few sed and tr
>> features.
>>
>>> 3. Perl has support for RoR- and Java MVC-style applications.  Originally,
>>> there were things like HTML::Mason (which allows PHP-style inline Perl
>>> code in HTML) and Template::Toolkit (which provided variable replacement
>>> and looping for basic template generation).  Now there is Catalyst, which
>>> is a Perl MVC framework.
>>
>> OK.
>>
>>> 4. Perl provides OO capabilities.  True, they were implemented somewhat as
>>> an afterthought, but Class::MethodMaker and Moose have significantly
>>> improved that.
>>
>> I consider this a Fatal Flaw. Perl 5 should have been a Separate
>> Language, just like C++ should have.
>>
>> Both of these suffer (as does C)from the fact that there are two kinds
>> of assignment (a=b vs a=&b) and two kinds of dereference (p.q and p->q).
>> C++ went even one better (read: worse) by inventing References, which
>> are really Call By Name Arguments.
>>
>> Java, Python, and Ruby all Got This Right: there is exactly one kind of
>> Assignment (always an Object Reference to a Variable), and one kind of
>> Dereference, the "." operator. And Java blew it by exposing the
>> Primitive Types as Non-Objects.
>>
>> Actually, Pardon Me for confusing the issues of Dereference and
>> Attribute Selection. The real point if that by forcing everything to be
>> an Object Reference (at least Conceptually), the Syntax Simplifies.
>>
>>> 5. Perl runs on Windows as well as *NIX.  It was the first scripting
>>> language available on Windows, which is why Microsoft financed some of the
>>> ActiveState development work.
>>
>> Everything Runs Everywhere.
>>
>>> 6. You can package standalone Perl applications, using such tools as
>>> perl2exe and par.  It won't obfuscate your source (much), but it will
>>> allow for a single distributable file.
>>
>> Presumably you could cat all your sources all together as well.
>>
>>> 7. You can write fairly large applications in Perl.
>>>     - At one of my prior employers, we had a several-thousand-line
>>> Perl+Mason+Postgres in-house content management system for building
>>> multiple news sites.  On 9/11/2001, it survived a double-OC3 onslaught of
>>> news-hungry people, and didn't even flinch.
>>> - At another employer, I wrote about a 5 thousand line systems monitoring
>>> tool that ran on Windows, various flavors of Linux, Solaris, HP-UX, and a
>>> couple of versions of AIX, checking a couple of thousand servers every
>>> day.
>>
>> Probably true of Python and Ruby as well, altho Perl has been around
>> much longer and has had more time to tun their compiler and RTE.
>>
>>> - At yet another employer, I wrote a Perl+Template::Toolkit+mySQL+AJAX
>>> application that created an in-memory JavaScript sandbox for manipulating
>>> data and either posting the changes back or reloading the original data.
>>> 6 years later, they've found 2 bugs and implemented 2 feature requests.
>>> - At my current employer, I have approximately 20-30k lines of Perl that
>>> automate data loading and file storage checking (e.g., are the files still
>>> where we think they are?).
>>
>> Good to know.
>>
>>> 8. Perl is not unreadable.  It can be unreadable, just as any other
>>> language can be unreadable.  It depends on the programmer.  I tend to
>>> comment liberally, leave plenty of vertical whitespace, group related
>>> blocks of code, etc.
>>
>> Agreed. However, the language is "Too Slippery". After all this time (I
>> was an Early Adopter, since the late 80s) I still can't remember all the
>> ways that Open and Split can be used, or when exactly the $1 .. $9
>> variables are set. The language is Context Dependent, for goodness sake!
>>
>> You see, Perl is a Bad Language because Larry has the Wrong Idea. He is
>> a Linguist, and his Theory is that you should be able to say Whatever
>> Sounds Reasonable and have the Language Figure It Out.
>>
>> Of course, Larry is just Clever Enough and has enough Genius to make
>> something Incredibly Useful, despite its flaws.
>>
>>> 9. Perl is not slow, despite being interpreted.  Several years ago that
>>> may have been true, but of late, the speed of the CPUs and memory mean
>>> that interpreted languages, once compiled to bytecode, run at near-native
>>> speed (this is not just Perl).
>>
>> True, but everything besides C and C++ need to Garbage Collect.
>>
>>> Now, some other comments:
>>> 1. I tried RoR.  I was intrigued by the idea of removing the database
>>> lookups from my code.  What I discovered was that RoR expects you to
>>> design your database in a particular way, and that if you ever want (or
>>> need) to do a complex query...it makes it difficult or impossible to do.
>>
>> Rails makes the Simple Things Easy, and the Hard Things Possible. Perl's
>> Motto!
>>
>>> 2. I haven't tried Python.  I never really saw the need.
>>
>> Me neither. Rather than learn Python, I kept banging out Perl programs
>> and scripts until I got into a DSW with a Jerk who knew Python and
>> finally learned it, 20 years later. I wish I hadn't waited that long.
>>
>>> I never much
>>> liked the C makefile "indenting of a particular depth and type is
>>> required" paradigm, so I don't think I'd be too thrilled with it in
>>
>> Trust Me, you will get used to it!
>>
>>> Python.  Moreover, as I previously noted, Python users do tend to be quite
>>> vocal about how great Python is and about why Perl sucks (but also about
>>> why they wish they had XYZ feature that Perl has).
>>
>> Perl Sucks because It's a Bad Language. It's also Incredibly Easy to
>> Use, but it gets you into Bad Habits. I'd like living on Doughnuts and
>> Hot Dogs.
>>
>>> 3. I tried Java a few times.  It was maddening to have to import half a
>>> dozen modules and create an entire object, just to write "hello world."
>>> The nounification of all objects is just one more annoyance.  Why do I
>>> have to make something an "ObjectFactory"?
>>
>> Um, aren't Objects naturally Nouns? And while you can easily get bogged
>> down in Libraies, Modules, and Frameworks in any language, You need a
>> better example than "Hello World". But yeah, it's Wordy, not the least
>> of which is because of Type Declarations.
>>
>> Then again, if you use 'use strict', you end up with 'my' and 'our'
>> declarations too.
>>
>>> 4. Sometimes bash really is better than Perl/python/whatever.  If I want
>>> to rename 5000 files quickly, I probably don't want to go through the
>>> trouble of writing a program to do it.
>>
>> Bash is Terrible at Arrays. Nuff Said.
>>
>>> Perl has a great many more abilities than it's getting credit for in this
>>> thread.
>>
>> It's also missing Exceptions! Checking Error Return Codes is Error
>> Prone. I won't even mention the stupid Sigils. Do you really need a
>> Scalar, Array, Hash, and Subroutine all with the same name?
>>
>>> That said, I'm a firm believer in the pragmatic and the practical.  Use
>>> what you know, and what you have available.  If you find something
>>> lacking, learn something else that puts a new tool in your toolbox.  In
>>> the last few years, I've picked up bash scripting and PL/SQL.
>>
>> I agree. But it can keep you Stuck In A Rut. Perl was Easy, so I used it
>> because I never seemed to have enough time to learn Python.
>>
>>> When asked to provide an analysis of something, it has been quite common
>>> for me to build a list in the database using SQL, export it to a text
>>> file, write a bash script to generate another text file, sort the two
>>> files, and then do a gvimdiff to see the results.  The result feels a bit
>>> like performing magic on a stage, and leaves bystanders blinking, trying
>>> to figure out what just happened.
>>
>> Now You're Just Showing Off :)
>>
>>> William Sutton
>>
>> JIM
>>
>> _______________________________________________
>> Novalug mailing list
>> Novalug@calypso.tux.org
>> http://calypso.tux.org/mailman/listinfo/novalug
>




More information about the Novalug mailing list