Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeder.news-service.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=H/csRX/hUGmUjMSgjxIPitBSjpgmhNMgb7PX48gMApQZrvggHdZ9alfvfE1w82gm+I jcdYzPjuvsrhChwOb0qFkOB8shABq+eTenlX3HJPyXmS/AxD480yTtnmBX3/3iWZTy1S wrhLM8DnCG52XfeOzKF/K2E9mXK2sLnkTCmbA=
From: "Octavian Rasnita" <orasnita@gmail.com>
To: <python-list@python.org>
References: <80d59383-36a3-4744-85c4-1a0577f1d3a6@dr5g2000vbb.googlegroups.com><BANLkTinviKm4A232=niyBCsqpKeazyWm=g@mail.gmail.com><BANLkTik+iBBgGBfZruE4BLoq0pz01sj9BQ@mail.gmail.com><BANLkTi=dyW-ZW=bEfSZmsHDjzo34+3rHrA@mail.gmail.com><BANLkTim0JVK-4yMxbjV+MC6TSh3k8tYPhg@mail.gmail.com><9CDC4B2CD1F445E994119A50F65155DF@teddy> <BANLkTi=5RytpHpP1ausX9n064vkhDHz+FA@mail.gmail.com>
Subject: Re: Why did Quora choose Python for its development?
Date: Sun, 22 May 2011 15:47:33 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1913.1306068468.9059.python-list@python.org>
Lines: 111
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:5972

From: "Daniel Kluev" <dan.kluev@gmail.com>

> On Sun, May 22, 2011 at 6:44 PM, Octavian Rasnita <orasnita@gmail.com> =
wrote:
>> Because of its flexibility, Perl offers more advanced modules and =
libraries which are not available for Python.
>=20
> What 'flexibility' are you talking about? This seem to be very biased
> statement, based on lack of according python experience.

I am talking about that flexibility which was criticized in the previous =
messages telling that this flexibility allows any programmer to use his =
own way.
Perl doesn't force anyone to indent the code, don't force the programmer =
to define a hash element before using it, allow the programmer to =
interpret the variables in strings directly. These things should be not =
used always, but if in some cases if the programmer wants to use them, =
he can use them with no problems. And this means flexibility.

> There are many python web frameworks which allow you to use w/e
> interfaces, template languages and ORMs you want - Pyramid/Pylons is
> good example.
> 'Very powerful' and 'great' are 'very useless' descriptions of these
> modules. Please, show us what exactly is so 'advanced' about them
> which cannot be done in python.


Every language can do almost anything, so this is not important, because =
the Python programmers didn't chose Python because it can do what other =
languages cannot do.

It is important how easy is to create an app with it, and while Python =
offers helpful features for creating desktop apps, for creating web apps =
Perl is better.

Here is a text from the documentation of Pyramid/Pylons:

"We finally need to add some routing elements to our application =
configuration if we want our view functions to be matched to application =
URLs.
...=20
# routes setup=20
config.add_route('list', '/')=20
config.add_route('new', '/new')=20
config.add_route('close', '/close/{id}')=20
"
...

First, this is a bad style of mapping urls, because this list must be =
maintained every time the programmer changes something in a controller =
that makes the app need to use other urls.
Catalyst don't need this overhead and don't need to specify the url =
mapping in a separate module. If the controllers change, then the url =
dispatching also changes.

Second, this way of url dispatching is not so flexible, because it =
doesn't allow as many types of url mappings.
Catalyst allows to dispatch the urls to actions based on controllers and =
subroutines names, globally or locally (based on the current =
controller), it allows dispatching based on regular expressions, it =
allows a chained dispatch where more actions are executed in a certain =
order on a single request, and all these without typing code outside of =
the subroutines that do the actions.

The module DBIx::Class which is used usually as an ORM can create the =
class files for all the tables from a database (MySQL, Oracle, =
PostgreSQL, SQLite, MS SQL, etc), and it can be used to search using =
unions, sub-selects, can define views at ORM level, can accept to insert =
different types of objects like DateTime objects and can also return =
those type of objects, and many other things, and most of the things it =
can do can be done without using SQL code at all, but only standard Perl =
code and Perl data structures.

HTML::FormFu form processor is one of the most used form processors in =
Catalyst applications and it can generate and parse forms created =
directly in the code of the application, or as external configuration =
files defined using JSON, or YAML, or Apache configuration style, or =
Perl data structures, or XML...
The forms defined are very easy to create and the elements from those =
forms, for example the list of elements in a combo box can be taken =
directly from a database by specifying just a few configuration =
elements. The results of a form submit can be also inserted in a =
database using a connector with DBIx::Class without specifying any =
database table column name in the programming code, and for doing this =
are required just a few lines of code that checks if the =
$form->submitted_and_valid() and that does the redirection after the =
submit, the insertion in the database requiring just:

$form->model->create;
or
$form->model->update( $db_record );

...after that record was defined using just something like:

my $db_record =3D $c->model( 'DB::TableName' )->find( $record_id );

And HTML::FormFu can do filtering based on many conditions, impose the =
specified constraints, specify different inflators/deflators from the =
inserted strings to their corresponding object types, do a validation =
eventualy based on a database query that checks for duplicates or other =
things, transform the data automaticly after the form was processed, can =
use I18N for displaying the field labels or values translated in the =
active language, have its own rendering engine or can render custom form =
fields made using Template-Toolkit, etc.

Yes, for web apps I have seen more things which can be done much better =
in Perl, much easier and clear, with less code, and not because the =
programmer needs to do not-recommended tricks for shortening the code, =
but because there are very many modules on CPAN that do the hard work.
Octavian