Re: Python?

  • From: Octavian Râsnita <orasnita@xxxxxxxxx>
  • To: <programmingblind@xxxxxxxxxxxxx>
  • Date: Sat, 14 Feb 2009 01:02:40 +0200

Yes I know that there are web frameworks for python also, but as I read from their description, they are not as powerful as Catalyst for perl or Ruby on Rails for Ruby. And I am not talking only about what the frameworks can do, because they do similar things, but the perl ORMS are better developed, and at least Catalyst framework is not limited, so the developer can choose to use any templating system for perl he wants, any ORM, any form manager, a pretty good variety of database types, but I think what I liked the most is the way Catalyst does the dispatching of URLS to the action subroutines. While in many frameworks the programmer needs to manually specify the dispatching for each URL type in a special file, Catalyst doesn't need to do that. Any new module which is created would know its place in the application, and any subroutine will know the URL that will execute it, so if someone decides that he wants to delete a subroutine or a whole perl module, the programmer doesn't need to specify somewhere that that URL can't be accessed anymore and remove that mapping.


But this might sound simple and limited to a single way of dispatch type like most other web frameworks can do, however more dispatch types are available.

For example if the module is named
MyApp::Controller::Foo
and a subroutine from this module is defined as:

sub bar : Local {...}

then it will be accessed with the URL /foo/bar.

But the subroutine can be defined with other attributes like
sub bar : Global {
sub bar : Path {
sub bar : Path('/lala/') {
sub bar : Index {
sub bar : Regexp('^lala\d') {
sub bar : default {

or the most interesting and sometimes very helpful
sub bar : Chained {

then the URL that access the current subroutine can be a different one.

And if the programmer wants to redefine the structure of the site, then very few changes need to be made and the most important is that those changes are very closed to the programming code, so the programmer won't forget to do something and break the app.

But of course, as I said, I agree with you that it is not nice at all to fight to find the best module for what you need.

Those who want to start don't even know what way to take, because there are other web frameworks for perl, and those who like CGI::Application for example, use to like other templating systems like HTML::Template and not Template-Toolkit, and they might also like another ORM than DBIx::Class which is the default for Catalyst, and another frame manager than HTML::FormFu which starts to be much and much used by Catalyst users, and those who like to use Mason as a templating system also like to use its features as a framework not only as a templating system, and then there are many other frameworks that combine all these preferences with many others.

The beginner always wants to know which is the best and recommended way, but if he would ask 20 perl programmers, he would find 4 or 5 different answers, and as it is very much to learn in these tools before beeing able to use them all, I can say that it is pretty impossible for a beginner to try them all and decide what he likes.

Core perl is a very low level language, but perl +CPAN modules it is really the highest level language, but the problem of that high level language is that there isn't a single language but much more.

Some programmers say that programming with Catalyst is not perl programming, because this framework offers so many high level functions that a programmer never needs to use functions like open(), print(), or SQL commands, or functional style modules, so it is very different than a classic CGI program, because very many things are done automaticly, very many methods and variables can be taken from the $c context variable which can be used in every controller subroutine, and so on. Well, the other perl frameworks, even if they are not so well developed or fast developing, also use to define their own syntax and way of doing things, so a beginner that only knows to create CGI programs won't understand anything by just looking at the code.

And it is very hard to create a good perl book that could help a beginner to learn to use the best tool, because that book should have thousands of pages. This is because a framework like Catalyst usually don't do very many things by its own code, but it uses other perl modules, that already do those things better, but those other perl modules have their own syntax that should be learned, so by just learning the perl core functions, the programmer doesn't know anything.

For example, when using the DBIx::Class ORM in Catalyst, it also does pagination by using the module Data::Page, so the pager object is taken with a simple

my $pager = $resultset->pager;

and this object contains the total number of items, the number of pages, the number of the first and last item on the current page, the number of the previous and next page, and other things that can be helpful for printing links to the next and previous page, or to display things like "elements 20 - 30 from 100" without needing to make any calculation.

And as I have previously told in another message, one of the biggest benefit is the ORM DBIx::Class that automaticly can create relations between database tables, so after searching in a single table of clients for example, the programmer can get the related rows from other tables from the database, without needing to define any SQL query, and without needing to define the DBIx::Class relation.

For example, if the object $companies contains the list of companies selected based on a certain criteria, we can get the employees of those companies from the "employees" table, and then get the data for those employees, and even get the credit card numbers for the selected employee, with a simple code like:

foreach my $company(@companies) {
foreach my $employee(@{$company->employees}) {
print $employee->name;

foreach my $card(@{$employee->card}) {
print $card->number;
}
}
}

But of course, this can be done in the template directly with an even simpler code like:

[% FOREACH company IN companies %]
[% FOREACH employee IN company.employees %]
[% employee.name %]<br>
[% FOREACH card IN employee.cards %]
[% card.number %]<br>
[% END %]
[% END %]
[% END %]

But these are offered by DBIx::Class because it is also based on other modules like SQL::Abstract, which might be based on other modules, and some of the methods that will be used by the programmer are offered by those base modules which are very many and not always hard to learn, but very much to learn.

Of course, after learning them, as you have seen, it is very simple to create very complex apps, with very little code which would be very easy to maintain, but the real powerful things can't even be explained to the beginners because what I told here are only simple things like searching in a single table only and then using the data that has relations to that table, because the advanced things are much harder to understand.

You can combine this with the fact that the framework offers features like the possibility of using a model not a database but a public web service that offers information, or that it can use not only a user/passowrd stored in the database for authentication but offer access to other known sites that can provide the authentication, or the fact that other tools like HTML::FormFu let you add a Captcha in your form by just adding 5 or 6 lines in a configuration file, or tens of plugins that allow creating a form upload with a progress meter that shows a lot of information, or help to add some Scriptaculous AJAX-based widgets by just placing a short piece of text in the templates, and other things like these.

Many frameworks offer some of those features, but when I read the presentation of many of them, I found very many missing advantages, and I thought that I wouldn't like to need to do them myself instead of just writing a few lines of code for using other already made modules.

Octavian

----- Original Message ----- From: "Jamal Mazrui" <empower@xxxxxxxxx>
To: <programmingblind@xxxxxxxxxxxxx>
Sent: Friday, February 13, 2009 11:24 PM
Subject: Re: Python?


Yes, the range of CPAN packages is remarkable, and the ActiveState
package manager is better then Python's or Ruby's.  In terms of the lead
developers of Perl, however, their performance is disappointing and
makes one lose confidence in the longterm viability of the product.
Compare perl.org to python.org, for example -- much more current stuff
is happening with Python.

I prefer the Python philosophy of there's probably a best way to do it,
so one can learn best techniques that have evolved and then use them as
building blocks for larger things, rather than trying to figure out what
technique to use and which is better all the time.

I know that Perl has much to offer in web development, but I'm surprised
to hear of the differences you describe with Python.  There are several
web frameworks that seem to be used a lot, including dJango, Turbogears,
Twisted, and Plone.

Jamal

On Fri, 13 Feb 2009, Octavian Râsnita wrote:

Date: Fri, 13 Feb 2009 22:40:56 +0200
From: Octavian Râsnita <orasnita@xxxxxxxxx>
Reply-To: programmingblind@xxxxxxxxxxxxx
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: Python?

This is because maybe you are not familiar with the perl community.

There are hundreads of perl related mailing lists, for beginners, for CGI
developers, for each web framework that can be done in perl, for each module
that's some more popular and well developed, for each library for creating
desktop GUIS, IRC channels for most of them, hundreads of CPAN mirrors all
over the globe, more perl distributions, more ppm repositories, and so on.

It is not so important that perl 6 is not ready yet, even though it would be very good to have all its features, because the CPAN modules can be used to
get those features that should be offered by next versions of Perl.

For example, I know that most perl books (maybe all of them) teach about how
to create OOP programs in perl, but in the old style.
But if you want to use the way that will be used in Perl 6, you could use
the modules Moose, or Mouse which offer more features, making the OOP
development much easier. For example you don't need to define the
constructors if you don't want, you can define the type of variables and
specify if they are read/write or readonly and other things like these.

You can also use the modules IO::*, File::*, List::*, Scalar::* and others
that lets you create OOP programs without needing to use the perl built in
functions, and use less code.

The real problem of all these is the same thing which is considered the
biggest advantage of perl: the fact that there are more ways to do it.
I truly think that this advantage is no more an advantage these days.

I don't really like the Python's "there is only one way to do it" style, but what is too much is too much, and there are far too many CPAN modules, very
many of them do similar things, but some of them are very good and some of
them very bad. Well, a beginner doesn't know which are the good ones, and
which are the bad ones, and he doesn't know what to choose, and finally he
might choose PHP or Python.

And this is not a problem for the beginners only. I have a lot of experience in perl, but if I need to do something in a program, I am sure I will find a
module on CPAN that can help me, however I am also sure that I will surely
find very many modules, and I would need to start testing them. Some of them
would work only if I would use ANSI code and no UTF-8 because the creator
cares only about the english-speakers only. Others can't be used with
Right-To-Left languages so I know I won't be able to use them for those
languages, others create GUIS that are not accessible for the blind, others
are too low level, others have bugs, some of them are too slow, or some of
them are very good  and fast developing, but lack documentation, some of
them are not thread-safe, some of them are not working under Windows and so
on.
And the perl developers are usually much less interested about Windows than
python developers, which is something I don't like, because even though I
put the programs to run under Linux, I make them under Windows.

But I also know that every language has libraries which are not thread-safe,
or which are badly made, or have errors, or are deprecated. At least for
perl I can install them from CPAN.

It doesn't matter that it appeared the version 3 for python, but perl is
still on version 5, while I can't find libraries for python which are as
advanced as those for perl in the fields I need.
I am sure python is better than perl for creating desktop apps and
especially under Windows, because there are very very few good perl
developers that care about Windows related things like OLE, Win32 API, or
creating Windows threads and managing Windows processes.
But I am nostly interested for web development, for working with databases, templating systems, libraries for internationalization and other things like
these.

And I also use modules that get financial data from different web sites,
create graphs and other things like these, so it depends on what we need to
do in our jobs.

Octavian

----- Original Message -----
From: "Jamal Mazrui" <empower@xxxxxxxxx>
To: <programmingblind@xxxxxxxxxxxxx>
Sent: Friday, February 13, 2009 8:33 PM
Subject: Re: Python?


> One other disadvantage I have encountered using Python with speech > relates
> to the number of syllables one has to hear.  Recommended style is to
> delimit strings with a single rather than double quote (though either > may
> be used).  By my count, apostrophe is four syllables compared to one for
> quote.  A similar issue is with the special object properties that begin
> and end with double underscore sequences, e.g., __init__ -- that's six
> syllables before the word and six after!  This can be annoyingly verbose
> at times, e.g., when querying the attributes of an object in the
> interactive environment. Of course, this is a relatively minor issue, > but > I am mentioning it too in the spirit of listing all screen-reader > factors
> that come to mind.
>
> What impresses me about Python, perhaps more than anything else, is how
> organized, dedicated, and sophisticated the community is.  There are
> numerous, well-known Python experts besides the lead author.  There are
> more Python conferences than for any other scripting language.  Python 3
> is out, but Perl 6 is not even close.  Ruby 1.9.1 was finally released
> officially, but without a usable version for Windows, and based on the > web
> site and my inquiries to a WxRuby list, a solid Windows version will not
> be coming any time soon!
>
> Jamal
>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>

__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind

__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind

__________
View the list's information and change your settings at //www.freelists.org/list/programmingblind

Other related posts: