Why did Quora choose Python for its development?

[Octavian Rasnita]

From: "Daniel Kluev" <dan.kluev at gmail.com>

> On Sun, May 22, 2011 at 6:44 PM, Octavian Rasnita <orasnita at gmail.com> wrote:
>> Because of its flexibility, Perl offers more advanced modules and libraries which are not available for Python.
> 
> 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.
... 
# routes setup 
config.add_route('list', '/') 
config.add_route('new', '/new') 
config.add_route('close', '/close/{id}') 
"
...

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 = $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