[Novalug] Why Python

William Sutton william@trilug.org
Sat Jul 20 11:49:38 EDT 2013


OK, replying here to a number of different threads/people about Perl 
misconceptions:

1. Perl has TK and GTK integration for GUIs
2. Perl is very C-like, other than the weak typing, because Perl was 
written in C and consciously designed to be C-like.
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.
4. Perl provides OO capabilities.  True, they were implemented somewhat as 
an afterthought, but Class::MethodMaker and Moose have significantly 
improved that.
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.
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.
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.
- 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?).
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.
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).

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.
2. I haven't tried Python.  I never really saw the need.  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 
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).
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"?
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.

Perl has a great many more abilities than it's getting credit for in this 
thread.

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.

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.

William Sutton

On Sat, 20 Jul 2013, Clif Flynt wrote:

> On Sat, Jul 20, 2013 at 08:48:02AM -0400, Varol Okan wrote:
>> ...
>> I think scripting has its benefits ... Clearly.
>>
>> Though as a hard-core developer I sometimes wonder why you would want to
>> jump through hoops and loops to fit a square peg into a round hole.
>> There are clearly limits with any development tools. It just seems that
>> sometimes things are being actively developed which should be taken out
>> and shot at first sight.
>>
>
>  This is where hybrid architectures come in.  This was what Tcl first
> brought to the table, and why Ousterhout got the ACM award for the idea.
>
>  Perl, python and the others support this concept as well.
>
>  The idea is that 80% of your code uses 20% of your development time,
> and 20% of your run time.
>
>  So, an real application (not a quick hack to scan a log file or
> provide a GUI for a config files) written in pure python, tcl or perl
> is probably a dog.  There will be some 10-20% of the code doing nasty
> math in a slow interpreted loop.  (Think doing an SSL encryption in an
> interpreted language).
>
>  So, you link your scripting language to the openSSL libraries, and
> now your script is fast.
>
>  For a real app, you've probably got a bunch of calculations or string
> tweaking that's not in a pre-built library.  If you write those
> calculations in the scripting language, you can time your app with a
> calendar.
>
>  So, you write that 20% of the app in C or C++ and link that to your
> interpreted scripting language code.
>
>  Now you've used the power of the scripting language to develop an
> application in about 1/5 the time you'd have taken to write it in C or
> C++, and it's running in about 1.2% of the time that it would run if it
> were pure compiled code.
>
>  Win-Win.
>
>  The architecture for Tux Racer is a good example of this - the GUI
> screens and the definitions of the courses are all done in Tcl.  When a
> user selects a course, it's read into the C data structures, and when
> you run it, the optimized C code handles the real-time graphics.
>
>  Using Tcl made it fast to develop the GUI screens, and provided a
> fully functional language for defining the courses, saving a bunch of
> reworks as folks realized that the configuration language lacked some
> feature or other. (Been through *that* loop too many times.)
>
>  As was commented - as a developer you should have a bunch of tools on
> their belt and use the best one for the task.  C/C++ for compiled code
> speed. Scripting language for development speed.
>
>  Clif
> -- 
> ... Clif Flynt ... http://www.cwflynt.com ... clif@cflynt.com ...
> .. Tcl/Tk: A Developer's Guide (3'd edition) - Morgan Kauffman ..
> .20'th Annual Tcl/Tk Conference:  Sep 23-27 New Orleans, LA, USA.
> .............  http://www.tcl.tk/community/tcl2013/  ............
>
>
>
>
>
> _______________________________________________
> Novalug mailing list
> Novalug@calypso.tux.org
> http://calypso.tux.org/mailman/listinfo/novalug
>



More information about the Novalug mailing list