Why did Quora choose Python for its development?

[Daniel Kluev]

On Sun, May 22, 2011 at 11:47 PM, Octavian Rasnita <orasnita at gmail.com> wrote:
> From: "Daniel Kluev" <dan.kluev at gmail.com>
> 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.

This is syntax-level flexibility, which, IMHO, does not affect
'advanceness' of modules at all. At language level, python is far more
flexible than perl with its magic methods and hooks, allowing to
overload any underlying language principles and protocols.

> 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.

Explicit is better than implicit. One of reasons why I chose
Pylons/Pyramid as my standard toolkit is that it allowed me to define
mappers in any way I needed them to.
If you want automatically defined mappers, there are lots of other
python frameworks and modules which do exactly that. Moreover, even
Routes itself (module, which does url mapping in Pylons) allows you to
use automated mappers, via :controller/:action tokens. It allows
pretty much everything you listed as 'features' of catalyst mappings.
If you prefer to stuff routing logic into controllers and have default
routing based on controllers and method names, you can use TurboGears
framework, which has exactly that mindset, or you can use its mapping
modules in Pyramid application.

> 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.

There are lots of Python modules which do exactly this and much more.
SQLAlchemy, SQLObject, Web2Py's DAL, and so on. They are integrated
into frameworks by default.

> 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:

Once again, there are dozens of such modules in python. FormAlchemy
integrates directly with SQLAlchemy, for example, and does all form
generation, parsing, validation, and instance updating/inserting for
you.

> 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.

I doubt you had enough experience with python frameworks like
Pyramid/Pylons or Web2Py. They have all features you listed, and code
is as trivial and clean, as it could ever be. Its surprising that you
present trivial ORM as 'advanced modules and libraries which are not
available for Python', while in fact it have been done long time ago
and in several flavors.

-- 
With best regards,
Daniel Kluev