Why did Quora choose Python for its development?

[Octavian Rasnita]

From: "Daniel Kluev" <dan.kluev at gmail.com>
> 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.


This means that you are forgetting Moose objects in Perl, right?
Moose is a very advanced object type system that will be the default type in 
Perl 6, but which was also implemented in Perl 5, which offers a lot of 
features for introspections in the object structure.

And the flexibility do offer the possibility of coding much easier and 
offering more features.
There are more, but a single eloquent feature is the possibility of 
interpreting variables in strings which cannot be done so nice in Python.

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


This is false. Explicit in this case means to write code in 2 places for 
doing a certain thing, and maintaining means changing the code in 2 places, 
which is harder and prone to errors.


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


In Catalyst you can also define the url mappings in any way you need, not 
only based on controller/actions locations, but you don't need to do this by 
creating code in 2 places so it would be easier to maintain.
In Catalyst all the mappers are done "automaticly", but they can be done in 
any way you like, even in more ways that under Pylons/Pyramid as I shown 
(unless in Pylons/Pyramid can be also defined chained mappings and mappings 
based on regular expressions).


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


Yes, the single difference is that Catalyst supports all of them, and it 
also supports using any templating system, and any ORM and any form 
processor, while some of the Python web frameworks don't support absolutely 
everything and you need to abandon some preferred modules for beeing able to 
use some other modules which are supported.


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


I've checked the documentation for some of them and I've seen that most of 
them don't support sub-selects and some of them require using plain SQL code 
in their construct for more complex queries.
Please tell me which of them supports sub-selects, and are able to return 
objects for date and datetime fields that have methods for beeing able to 
print just the year or day, or the months names in the specified locale 
because it would be useful.


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

Please tell me which of those ORMS can do what DBIx::Class can do as I asked 
above, before calling it "trivial", and which are those aditional features 
it can do but DBIx::Class cannot, because otherwise it would be very simple 
for anyone to just say "go to read the documentation and see how great it 
is".

Octavian