FAQ
I thought this essay on why one startup chose Python was interesting.

http://www.quora.com/Why-did-Quora-choose-Python-for-its-development

PHP was out of the question. Facebook is stuck on that for legacy
reasons, not because it's the best choice right now.[1] Our main
takeaway from that experience is that programming language choice is
very important and is extremely costly to change.

Python was a language that Charlie and I both knew reasonably well
(though I know it a lot better now than I did when we started). We
also briefly considered C#, Java, and Scala. The biggest issues with
Python are speed and the lack of typechecking.

C# seemed pretty promising. As a programming language, it's great,
but:

?We didn't want to be on the Microsoft stack. We were up for learning
something new, and MS SQL Server actually seemed pretty good, but we
knew we'd need to integrate with lots of open source code that has
only second-class support for .NET, if it supports it at all. Also,
most of the best engineers these days are used to open source stuff.
?We didn't want to take the risk of being on Mono (an open source
implementation of C#/.NET). It's not clear how long funding will be
around for that project, and I'd heard of various performance
problems. Plus, it seemed like everything else in the C# ecosystem
would assume we were on the Microsoft stack.

For a lot of little reasons, Java programs end up being longer and
more painful to write than the equivalent Python programs. It's also
harder to interoperate with non-Java stuff. Scala had a lot of the
downsides of Java and the JVM, although it wasn't quite as bad. The
language seemed a little too new and like it would bring some
unnecessary risk (for example, who knows how good will support be in
10 years).

Two other languages we very briefly thought about were OCaml and
Haskell (neither had big enough ecosystems or good enough standard
libraries, and both were potentially too hard for some designers/data
analysts/non-engineers who might need to write code).

We decided that Python was fast enough for most of what we need to do
(since we push our performance-critical code to backend servers
written in C++ whenever possible). As far as typechecking, we ended up
writing very thorough unit tests which are worth writing anyway, and
achieve most of the same goals. We also had a lot of confidence that
Python would continue to evolve in a direction that would be good for
the life of our codebase, having watched it evolve over the last 5
years.

So far, we've been pretty happy with the choice. There's a small
selection bias, but all of the employees who'd been working with other
languages in the past have been happy to transition to Python,
especially those coming from PHP. Since starting the following things
have happened:


?Python 2.6 got to the point where enough of the libraries we used
were compatible with it, and we made a very easy transition to it.
?Tornado (web framework) was released as open source, and we moved our
live updating web service to that.
?PyPy got to the point where it looks like it will eventually be
usable and will give us a significant speedup.

All together, these give us confidence that the language and ecosystem
is moving in a good direction.

[1] What are the horrors of PHP? and Do Facebook engineers enjoy
programming in PHP? and Why hasn't Facebook migrated away from PHP?
and What are some of the advantages of PHP over other programming
languages? for more on that.
Via Nizameddin Ha?im Ordulu and JR Ignacio.

Search Discussions

  • Dotan Cohen at May 20, 2011 at 8:47 pm

    On Fri, May 20, 2011 at 19:39, Beliavsky wrote:
    I thought this essay on why one startup chose Python was interesting.

    http://www.quora.com/Why-did-Quora-choose-Python-for-its-development

    PHP was out of the question. Facebook is stuck on that for legacy
    reasons, not because it's the best choice right now.[1] Our main
    takeaway from that experience is that programming language choice is
    very important and is extremely costly to change.

    Python was a language that Charlie and I both knew reasonably well
    (though I know it a lot better now than I did when we started). We
    also briefly considered C#, Java, and Scala. The biggest issues with
    Python are speed and the lack of typechecking.

    C# seemed pretty promising. As a programming language, it's great,
    but:

    ?We didn't want to be on the Microsoft stack. We were up for learning
    something new, and MS SQL Server actually seemed pretty good, but we
    knew we'd need to integrate with lots of open source code that has
    only second-class support for .NET, if it supports it at all. Also,
    most of the best engineers these days are used to open source stuff.
    ?We didn't want to take the risk of being on Mono (an open source
    implementation of C#/.NET). It's not clear how long funding will be
    around for that project, and I'd heard of various performance
    problems. Plus, it seemed like everything else in the C# ecosystem
    would assume we were on the Microsoft stack.

    For a lot of little reasons, Java programs end up being longer and
    more painful to write than the equivalent Python programs. It's also
    harder to interoperate with non-Java stuff. Scala had a lot of the
    downsides of Java and the JVM, although it wasn't quite as bad. The
    language seemed a little too new and like it would bring some
    unnecessary risk (for example, who knows how good will support be in
    10 years).

    Two other languages we very briefly thought about were OCaml and
    Haskell (neither had big enough ecosystems or good enough standard
    libraries, and both were potentially too hard for some designers/data
    analysts/non-engineers who might need to write code).

    We decided that Python was fast enough for most of what we need to do
    (since we push our performance-critical code to backend servers
    written in C++ whenever possible). As far as typechecking, we ended up
    writing very thorough unit tests which are worth writing anyway, and
    achieve most of the same goals. We also had a lot of confidence that
    Python would continue to evolve in a direction that would be good for
    the life of our codebase, having watched it evolve over the last 5
    years.

    So far, we've been pretty happy with the choice. There's a small
    selection bias, but all of the employees who'd been working with other
    languages in the past have been happy to transition to Python,
    especially those coming from PHP. Since starting the following things
    have happened:


    ?Python 2.6 got to the point where enough of the libraries we used
    were compatible with it, and we made a very easy transition to it.
    ?Tornado (web framework) was released as open source, and we moved our
    live updating web service to that.
    ?PyPy got to the point where it looks like it will eventually be
    usable and will give us a significant speedup.

    All together, these give us confidence that the language and ecosystem
    is moving in a good direction.

    [1] What are the horrors of PHP? and Do Facebook engineers enjoy
    programming in PHP? and Why hasn't Facebook migrated away from PHP?
    and What are some of the advantages of PHP over other programming
    languages? for more on that.
    Via Nizameddin Ha?im Ordulu and JR Ignacio.
    --
    http://mail.python.org/mailman/listinfo/python-list
    They considered Haskell and OCaml and not a single mention of Perl?
  • Dan Stromberg at May 22, 2011 at 1:50 am

    On Fri, May 20, 2011 at 1:47 PM, Dotan Cohen wrote:

    They considered Haskell and OCaml and not a single mention of Perl?
    Perl is like 10 languages smushed together. To write it, you need only
    learn one of the 10. To read someone else's, you don't know what subset of
    those 10 they've used until you get deep into the code.

    IOW, it's a kitchen sink language - the kind, I believe, that my comparative
    languages professor would have described as "offensive".
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20110521/d9c938f1/attachment-0001.html>
  • Chris Angelico at May 22, 2011 at 5:01 am

    On Sun, May 22, 2011 at 11:50 AM, Dan Stromberg wrote:
    Perl is like 10 languages smushed together.? To write it, you need only
    learn one of the 10. ? To read someone else's, you don't know what subset of
    those 10 they've used until you get deep into the code.
    +1 QOTW.

    Perl: The Swiss Army Knife of programming languages, including the bit
    where you can never find the right blade to open up.

    Chris Angelico
  • Hansmeet Singh at May 22, 2011 at 5:16 am
    i think we should end our butchering of perl on a light note (you may have
    already read this):
    EXTERIOR: DAGOBAH -- DAY
    With Yoda strapped to his back, Luke climbs up one of
    the many thick vines that grow in the swamp until he
    reaches the Dagobah statistics lab. Panting heavily, he
    continues his exercises -- grepping, installing new
    packages, logging in as root, and writing replacements for
    two-year-old shell scripts in Python.

    YODA: Code! Yes. A programmer's strength flows from code
    maintainability. But beware of Perl. Terse syntax... more
    than one way to do it... default variables. The dark side
    of code maintainability are they. Easily they flow, quick
    to join you when code you write. If once you start down the
    dark path, forever will it dominate your destiny, consume
    you it will.

    LUKE: Is Perl better than Python?

    YODA: No... no... no. Quicker, easier, more seductive.

    LUKE: But how will I know why Python is better than Perl?

    YODA: You will know. When your code you try to read six months
    from now.

    On Sat, May 21, 2011 at 10:01 PM, Chris Angelico wrote:
    On Sun, May 22, 2011 at 11:50 AM, Dan Stromberg wrote:
    Perl is like 10 languages smushed together. To write it, you need only
    learn one of the 10. To read someone else's, you don't know what subset of
    those 10 they've used until you get deep into the code.
    +1 QOTW.

    Perl: The Swiss Army Knife of programming languages, including the bit
    where you can never find the right blade to open up.

    Chris Angelico
    --
    http://mail.python.org/mailman/listinfo/python-list
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20110521/6cbf313a/attachment-0001.html>
  • Octavian Rasnita at May 22, 2011 at 7:44 am
    From: "Hansmeet Singh" <hansmeetschool at gmail.com>
    i think we should end our butchering of perl on a light note (you may have
    already read this):
    EXTERIOR: DAGOBAH -- DAY
    With Yoda strapped to his back, Luke climbs up one of
    the many thick vines that grow in the swamp until he
    reaches the Dagobah statistics lab. Panting heavily, he
    continues his exercises -- grepping, installing new
    packages, logging in as root, and writing replacements for
    two-year-old shell scripts in Python.

    YODA: Code! Yes. A programmer's strength flows from code
    maintainability. But beware of Perl. Terse syntax... more
    than one way to do it... default variables. The dark side
    of code maintainability are they. Easily they flow, quick
    to join you when code you write. If once you start down the
    dark path, forever will it dominate your destiny, consume
    you it will.

    LUKE: Is Perl better than Python?

    YODA: No... no... no. Quicker, easier, more seductive.

    LUKE: But how will I know why Python is better than Perl?

    YODA: You will know. When your code you try to read six months
    from now.

    I've noticed that on many Perl mailing lists the list members talk very rarely about Python, but only on this Python mailing list I read many discussions about Perl, in which most of the participants use to agree that yes, Python is better, as it shouldn't be obvious that most of the list members prefer Python.

    If Python would be so great, you wouldn't talk so much about how bad are other languages, or if these discussions are not initiated by envy, you would be also talking about how bad is Visual Basic, or Pascal, or Delphi, or who knows other languages.

    A few months ago I have asked how can I create a dictionary from a list, and there were so many techniques that I think that it is just a buzzword that in Perl there are many ways to do it, while in Python there is a single way. In Python I found from the messages I received on this mailing list that there are a lot of ways, without even beeing a "recommended" way, while in Perl there is a single way, of course much shorter and clearer.

    A bad program can be written in any language, no matter if it is so strict and forces the programmer to use spaces as a way of defining the blocks of code, so the fact that Perl is very flexible is an advantage for the programmer who writes the code.

    Perl offers the module Perl::Critic which offers a command line that checks the code for different levels of syntax errors which don't respect the good practices (which are also published in a book) so if the program has to be used by more programmers, it is very simple to bring it to a very standard syntax.

    Perl also has Perl::Tidy that offers another command line which re-arrange the code to a standard way, including the indentation type, the placement of parenthesis, spacing and other things, so the programs can look visually the same.

    And these are advantages for those that need to read the code by others also.

    Because of its flexibility, Perl offers more advanced modules and libraries which are not available for Python. For example, Catalyst web framework is much powerful and flexible than any other Python framework, because it can be used with any ORM, with any templating system, with any form processor, with any type of configuration files (Apache style, ini, JSON, XML, perl data structures, yaml), and it can run with its own web server, or with mod_perl, FastCGI, cgi, psgi without any change, and it has a very clean and flexible URL dispatcher that doesn't need to do (and maintain) the URL mapping in a distinct module made only for this.
    A Catalyst based application is very easy to maintain because it has a very clean structure and the command lines that can be used to automaticly generate the base for controllers, models or views also generate the base test files and also create a few basic tests for the created modules, beeing very easy to add new tests.

    And DBIx::Class ORM is a very powerful ORM and Template-Toolkit a great templating system, and Moose can be used to create a very powerful object model, and there are a lot of other very good modules which are not available for other languages.

    It can be hard to find the good quality Perl code while you don't know where to look for though. This is right, because the web is full of old-style Perl code since the era of Matt's Perl script archive, and the web is also full of pirated books about using CGI, but talking about that bad style code shows just that you are talking about something you don't know.

    Somebody told that C# and Objective C are good languages. They might be good, but they are proprietary, and not only that they are proprietary, but they need to be ran under platforms that cannot be used freely, so from the freedom point of view, Perl, Ruby, Python and Java are the ways to go.

    Octavian
  • Daniel Kluev at May 22, 2011 at 8:20 am

    On Sun, May 22, 2011 at 6:44 PM, Octavian Rasnita 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.

    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.

    --
    With best regards,
    Daniel Kluev
  • Octavian Rasnita at May 22, 2011 at 12:47 pm
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    On Sun, May 22, 2011 at 6:44 PM, Octavian Rasnita 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
  • Daniel Kluev at May 22, 2011 at 11:42 pm

    On Sun, May 22, 2011 at 11:47 PM, Octavian Rasnita 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
  • Octavian Rasnita at May 23, 2011 at 6:06 am
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    On Sun, May 22, 2011 at 11:47 PM, Octavian Rasnita 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
  • Daniel Kluev at May 23, 2011 at 8:05 am

    On Mon, May 23, 2011 at 5:06 PM, Octavian Rasnita wrote:
    There are more, but a single eloquent feature is the possibility of
    interpreting variables in strings which cannot be done so nice in Python.
    I've should probably mentioned it earlier, but I'm not Perl expert,
    not following its development and can't be bothered to read its docs.
    Could you please provide examples of features you mention with
    expected result, so I could suggest reasonable Python analogue?
    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.
    Not sure what do you mean by 'write code in 2 places'. All mapping
    code is located in routes config, including all needed args
    validation.
    But if you want to couple it with controller code, there, as I said,
    are numerous ways to do it. You can even do something like this:

    class SomeController(BaseController):
    ...
    @map(conditions=dict(method='GET'))
    def some_method(self, arg1:int, arg2:str):
    ...

    so it would be called via /somecontroller/some-method/1/blabla with
    trivial decorator.
    (unless in Pylons/Pyramid can be also defined chained mappings and mappings
    based on regular expressions).
    Not sure what do you mean by "based on regular expressions". Routes
    paths ARE regular expressions. Conditions are regexes too.

    As for chained mappings - no idea, never had the need in such thing.
    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.
    Pyramid and Pylons let you use pretty much any templating package and
    ORM as well. There is nothing in them that would block such modules.
    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.
    Python has builtin type for DateTime, and SQLAlchemy, for example,
    returns exactly that:

    #> python
    Python 2.7.1 (r271:86832, May 17 2011, 19:31:41)
    [GCC 4.4.5] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    from sadt import Test, Session
    import datetime
    Test(1)
    <Test(1, 1, 2011-05-23 18:53:39.459054)>
    Test(2)
    <Test(2, 2, 2011-05-23 18:53:51.859754)>
    t1 = Session.query(Test).filter(Test.val == 1).one()
    t1
    <Test(1, 1, 2011-05-23 18:53:39.459054)>
    t1.date
    datetime.datetime(2011, 5, 23, 18, 53, 39, 459054)
    t1.date.year
    2011
    t1.date.month
    5
    print Session.query(Test).filter(Test.date == datetime.datetime(2011, 5, 23, 18, 53, 39, 459054)).one()
    <Test(1, 1, 2011-05-23 18:53:39.459054)>
    print Session.query(Test).filter(Test.date > datetime.date(2010, 1, 1)).all()
    [<Test(1, 1, 2011-05-23 18:53:39.459054)>, <Test(2, 2, 2011-05-23
    18:53:51.859754)>]

    sadt sources here if interesting: http://pastebin.ca/2067372

    So as you see, datetime is not only returned properly, but you can
    also do queries with either date or datetime values, including
    comparison and range.

    Subqueries are fully supported too:
    ...
    Session.query(Test).from_self().all()
    2011-05-23 19:07:02,662 INFO sqlalchemy.engine.base.Engine.0x...552c
    SELECT anon_1.test_id AS anon_1_test_id, anon_1.test_val AS
    anon_1_test_val, anon_1.test_date AS anon_1_test_date
    FROM (SELECT test.id AS test_id, test.val AS test_val, test.date AS test_date
    FROM test) AS anon_1
    2011-05-23 19:07:02,662 INFO sqlalchemy.engine.base.Engine.0x...552c ()
    [<Test(1, 1, 2011-05-23 19:06:36.804128)>, <Test(2, 1, 2011-05-23
    19:06:36.808022)>, <Test(3, 1, 2011-05-23 19:06:36.810698)>, <Test(4,
    2, 2011-05-23 19:06:36.813357)>, <Test(5, 3, 2011-05-23
    19:06:36.816373)>]

    This is most trivial example of subqueries, since I'm too lazy to
    produce proper tables to demonstrate it, but SQLAlchemy has very good
    subquery support, as its typical way to deal with one-to-many
    relations (but it does support other loading strategies as well,
    including inner/outer joins or lazy loading).
    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".
    But "go to read the docs" argument works both ways - I have zero
    knowledge of DBIx::Class, so obviously I cannot say what features it
    lacks compared to SQLA.
    However this is what I wanted to highlight - you cannot simply state
    that "Perl offers more advanced modules and libraries which are not
    available for Python" if you don't have reasonable experience with
    according Python modules.


    --
    With best regards,
    Daniel Kluev
  • Octavian Rasnita at May 23, 2011 at 9:41 am
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    On Mon, May 23, 2011 at 5:06 PM, Octavian Rasnita wrote:
    There are more, but a single eloquent feature is the possibility of
    interpreting variables in strings which cannot be done so nice in Python.
    I've should probably mentioned it earlier, but I'm not Perl expert,
    not following its development and can't be bothered to read its docs.
    Could you please provide examples of features you mention with
    expected result, so I could suggest reasonable Python analogue?
    The ones that bash other languages on the mailing list for their prefered
    language should provide good comparisons and not just make false statements,
    considering that it is enough, since most of the list members will agree
    because they like Python more than other languages anyway.

    If they think that what they say is true, why don't they make those
    statements on Perl mailing lists, but again, offering valid comparisons.
    But if you want to couple it with controller code, there, as I said,
    are numerous ways to do it. You can even do something like this:

    class SomeController(BaseController):
    ...
    @map(conditions=dict(method='GET'))
    def some_method(self, arg1:int, arg2:str):
    ...
    so it would be called via /somecontroller/some-method/1/blabla with
    trivial decorator.

    Is the url something like /some_controller/some_method? Or the underlines
    are deleted from the name of the controller and replaced with "-" in the
    name of the method?
    Is it possible to also add a configuration here to call this some_method
    when the url /some_controller/some-method-string is accessed?
    (define another string than the name of the method)
    Is it possible to configure it to access this subroutine only if a certain
    number of parameters are sent in the URL?

    If yes, it means that its dispatcher is better than I've seen in the short
    tutorial on the web.
    (unless in Pylons/Pyramid can be also defined chained mappings and
    mappings
    based on regular expressions).
    Not sure what do you mean by "based on regular expressions". Routes
    paths ARE regular expressions. Conditions are regexes too.

    As for chained mappings - no idea, never had the need in such thing.
    The chained dispatcher is one of the best thing offered by Catalyst, because
    with it the same code should not be used twice.

    For example, one can define a subroutine in which a certain record is
    selected from the DB and is placed in stash.
    Then there may be other subroutines for different tasks, one for editing
    that record, one for deleting that record and so on.
    One chain can start with the base subroutine that makes the selection from
    the DB then executes the subroutine that makes the deletion and another
    chain can start with the base subroutine that makes the selection than
    continues with the one that starts the editting.
    Of course, the chain can have more links, not only 2, but this was just a
    very short example.
    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.
    Python has builtin type for DateTime, and SQLAlchemy, for example,
    returns exactly that:
    t1.date.month
    5
    Can it also set the current locale, for example romanian, and print the name
    of the current month?
    ...something like t1.date.set_locale('ro').month_name?
    SELECT anon_1.test_id AS anon_1_test_id, anon_1.test_val AS
    anon_1_test_val, anon_1.test_date AS anon_1_test_date
    FROM (SELECT test.id AS test_id, test.val AS test_val, test.date AS
    test_date
    FROM test) AS anon_1
    As I said, that ORM is not able to do those SQL constructs without using
    literal SQL code, but only Python variables and data structures...
    An ORM is usually prefered exactly because it doesn't force the programmer
    to concatenate strings for generating the SQL code, but he/she can use just
    standard Perl/Python code.
    Or this is possible in another way without using SQL code?
    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".
    But "go to read the docs" argument works both ways - I have zero
    knowledge of DBIx::Class, so obviously I cannot say what features it
    lacks compared to SQLA.
    Yes you are perfectly right, but not those programmers that also use Perl
    started to say that Perl can do this and Python can't, or that in Perl this
    is shorter and nicer than in Python.
    I just wanted to show that anything Python can do can be done in Perl also,
    and in some fields Python is better, in other fields Perl is better, and we
    should use whatever we like the most, and not say bad words about other
    languages or about those who use other languages, especially in a
    coward-way, on the group of programmers that prefer the praised language.

    Octavian
  • Daniel Kluev at May 23, 2011 at 10:16 am

    On Mon, May 23, 2011 at 8:41 PM, Octavian Rasnita wrote:
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    As I said, that ORM is not able to do those SQL constructs without using
    literal SQL code, but only Python variables and data structures...
    An ORM is usually prefered exactly because it doesn't force the programmer
    to concatenate strings for generating the SQL code, but he/she can use just
    standard Perl/Python code.
    Or this is possible in another way without using SQL code?
    Did you actually read the code? SQL there is debug output of
    SQLAlchemy for python code `Session.query(Test).from_self().all()`, I
    left it there to just show you that it emits subquery to RDBMS.
    All code in REPL is prefixed by `>>> `. Other lines are just output.
    Can it also set the current locale, for example romanian, and print the name of the current month?
    ...something like t1.date.set_locale('ro').month_name?
    There is separate module for date localization. You can pass datetime
    object to it and it will give you needed value.
    The ones that bash other languages on the mailing list for their prefered language should provide good comparisons and not just make false statements
    That would be valid if I would 'bash other languages', but I just
    responded to your claim that Perl has advanced modules which are not
    available for Python, esp. in web frameworks, as I find it one of
    areas where Python shines most.
    Sure Python has drawbacks, esp. its performance and poor threads
    support (GIL), but flexibility and modules of all flavors and types
    are not among them. Introduction of parameter annotations should make
    these modules even greater, once python 3.x is widely adopted.

    --
    With best regards,
    Daniel Kluev
  • Octavian Rasnita at May 23, 2011 at 11:17 am
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    ...
    Can it also set the current locale, for example romanian, and print the
    name of the current month?
    ...something like t1.date.set_locale('ro').month_name?
    There is separate module for date localization. You can pass datetime
    object to it and it will give you needed value.

    Aha, so with other words that ORM doesn't have that feature.
    DBIX::Class also use the DateTime module, but it can use it directly,
    without needing to write more code for that, and it can also return
    localized dates.

    The ones that bash other languages on the mailing list for their prefered
    language should provide good comparisons and not just make false
    statements
    That would be valid if I would 'bash other languages', but I just
    responded to your claim that Perl has advanced modules which are not

    No you haven't responded because you haven't shown any thing that can be
    done by the web framework and the ORM you are praising but can't be done by
    Catalyst and DBIx::Class, however I have shown you that DBIx::Class can
    return DateTime objects directly, without needing to load the DateTime
    module manually and to initialize the DateTime object manually...

    And don't take my words out of the context, because I have also answered to
    another list member that was bashing Perl without offering other helpful
    information than just that kind of jokes which are usually made by teenagers
    under 30.

    Octavian
  • Daniel Kluev at May 23, 2011 at 11:32 am

    On Mon, May 23, 2011 at 10:17 PM, Octavian Rasnita wrote:
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    Aha, so with other words that ORM doesn't have that feature.
    DBIX::Class also use the DateTime module, but it can use it directly,
    without needing to write more code for that, and it can also return
    localized dates.
    Once again. ORMs return _python builtin type_. Localization is not
    their responsibility, and plugging it there is code bloat, rather than
    feature. Sure you may ask ORM to handle JSONRPC requests on its own,
    but ORM responsibility is to map RDBMS features to language objects.
    All good python packages limit their functionality to specific field,
    so you could choose one you prefer for each different task
    independently.
    without needing to load the DateTime module manually and to initialize the DateTime object manually...
    This is basically stating that you didn't read the code I posted.
    Where did you ever find "initialize the DateTime object manually"?
    Sorry, but its pointless to discuss anything if you don't want to even
    read properly examples you receive.


    --
    With best regards,
    Daniel Kluev
  • Octavian Rasnita at May 24, 2011 at 5:39 am
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    On Mon, May 23, 2011 at 10:17 PM, Octavian Rasnita wrote:
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    Aha, so with other words that ORM doesn't have that feature.
    DBIX::Class also use the DateTime module, but it can use it directly,
    without needing to write more code for that, and it can also return
    localized dates.
    Once again. ORMs return _python builtin type_. Localization is not
    their responsibility, and plugging it there is code bloat, rather than
    feature. Sure you may ask ORM to handle JSONRPC requests on its own,
    but ORM responsibility is to map RDBMS features to language objects.
    Who said that? The ORM responsability is to map RDBMS to the objects you
    need, not to the language objects.
    If the ORM can do that directly by just adding a configuration instead of
    needing to manually use of other modules, why is this bloat? You add that
    configuration only if you need it, not always, and it is much more simple.
    All good python packages limit their functionality to specific field,
    so you could choose one you prefer for each different task
    independently.

    All the Perl modules do the same, but some of the Perl modules accept
    plugins that make easier the collaboration of different modules which are
    needed often, and the need of localizing the date is a feature used often.
    without needing to load the DateTime module manually and to initialize
    the DateTime object manually...
    This is basically stating that you didn't read the code I posted.
    Where did you ever find "initialize the DateTime object manually"?
    Sorry, but its pointless to discuss anything if you don't want to even
    read properly examples you receive.

    You told that you need to use another module for localizing the date because
    the ORM returns just a language date object that doesn't do that.


    Octavian
  • Octavian Rasnita at May 23, 2011 at 5:31 am
    From: "Dennis Lee Bieber" <wlfraed at ix.netcom.com>
    Since indentation seems so crucial to easy comprehension of the logical
    structure of a program,
    making it a mandatory syntactical structure becomes a desirable feature
    for code that must be maintained (by others, in many cases).

    Why "in many cases"? I wrote hundreads of programs which are working fine
    and which are maintained only by me. (But they would be very easy to
    maintain by other people if it would be necessary).
    So in that case, why to be forced to use a strict indentation?

    As for the dictionary from list... Do not confuse /algorithms/
    selected by the programmer from what is part of the native language.
    Otherwise one could complain that there is more than one way to code a
    spam-filter using Python...

    Exactly, I am not talking about a complex task that can be done in many ways
    in all programming languages.
    I am talking about a simple way of creating a hash/dict from an array, which
    is so simple that there should be really a single way to do it, or very few.

    Octavian
  • Chris Angelico at May 23, 2011 at 6:37 am

    On Mon, May 23, 2011 at 3:31 PM, Octavian Rasnita wrote:
    From: "Dennis Lee Bieber" <wlfraed at ix.netcom.com>
    Since indentation seems so crucial to easy comprehension of the logical
    structure of a program,
    making it a mandatory syntactical structure becomes a desirable feature
    for code that must be maintained (by others, in many cases).
    Why "in many cases"? I wrote hundreads of programs which are working fine
    and which are maintained only by me. (But they would be very easy to
    maintain by other people if it would be necessary).
    So in that case, why to be forced to use a strict indentation?
    The reason for clear code is maintenance, not maintenance-by-others.
    If you come back to something in a year, you'll appreciate proper
    variable names, indentation, etc.

    That said, though, I still do not believe in Python's philosophy of
    significant whitespace. I like to be able, if I choose, to put one
    entire "logical unit" on one line, such that it can be commented out
    with a single comment marker, or duplicated to another line and one
    copy commented out, or whatever. To that end, I sometimes want to put
    an if, its associated else, and sometimes a statement for both
    branches, all in the one line. And that's not possible when whitespace
    alone defines the end of an if/else block (the one-line form of a
    Python 'if' can't have a non-conditional statement after it at all),
    but is quite easy when things are delimited with braces.

    Bug report: The "from __future__ import braces" statement isn't
    working properly. Pls fix, kthxbye. :)

    But I still like Python overall. There's no such thing as a perfect
    language, and when it comes to syntax disagreements, I dislike
    Python's significant whitespace far less than I dislike PHP's adorned
    variable names. And Python, under the hood, is a very good engine for
    doing what I need to do.

    Chris Angelico
  • Octavian Rasnita at May 23, 2011 at 9:01 am
    From: "Chris Angelico" <rosuav at gmail.com>
    On Mon, May 23, 2011 at 3:31 PM, Octavian Rasnita wrote:
    From: "Dennis Lee Bieber" <wlfraed at ix.netcom.com>
    Since indentation seems so crucial to easy comprehension of the logical
    structure of a program,
    making it a mandatory syntactical structure becomes a desirable feature
    for code that must be maintained (by others, in many cases).
    Why "in many cases"? I wrote hundreads of programs which are working fine
    and which are maintained only by me. (But they would be very easy to
    maintain by other people if it would be necessary).
    So in that case, why to be forced to use a strict indentation?
    The reason for clear code is maintenance, not maintenance-by-others.
    If you come back to something in a year, you'll appreciate proper
    variable names, indentation, etc.

    That said, though, I still do not believe in Python's philosophy of
    significant whitespace. I like to be able, if I choose, to put one
    entire "logical unit" on one line, such that it can be commented out
    with a single comment marker, or duplicated to another line and one
    copy commented out, or whatever. To that end, I sometimes want to put
    an if, its associated else, and sometimes a statement for both
    branches, all in the one line. And that's not possible when whitespace
    alone defines the end of an if/else block (the one-line form of a
    Python 'if' can't have a non-conditional statement after it at all),
    but is quite easy when things are delimited with braces.

    Yes I also agree with that, and I also prefer *in some cases* to write short
    code in a single line like:

    print "..." if $var;

    print $var == 123 ? "abcd" : "cedf";

    print $var =~ /foo/ ? "abc" : "cdef";

    ...instead of writing a few lines of code. These constructs are not
    recommended for Perl either, and Perl::Critic would give a warning when it
    will be used with a certain level of errors checking, but it is preferable
    to be able to do what you want how you or your team want, not as the creator
    of the programming language wants.

    And I don't think that there are programmers that find the lines above hard
    to understand or maintain.

    Octavian
  • Terry Reedy at May 23, 2011 at 6:37 am

    On 5/23/2011 1:31 AM, Octavian Rasnita wrote:


    I am talking about a simple way of creating a hash/dict from an array,
    which is so simple that there should be really a single way to do it, or
    very few.
    Again, Python has such:
    dict([['one',1],['two', 2]])
    {'two': 2, 'one': 1}

    --
    Terry Jan Reedy
  • Octavian Rasnita at May 23, 2011 at 8:49 am
    From: "Terry Reedy" <tjreedy at udel.edu>
    On 5/23/2011 1:31 AM, Octavian Rasnita wrote:

    I am talking about a simple way of creating a hash/dict from an array,
    which is so simple that there should be really a single way to do it, or
    very few.
    Again, Python has such:
    dict([['one',1],['two', 2]])
    {'two': 2, 'one': 1}

    That is not an array, but a list. An array has a name and we can't do
    something like the following simple statement in Python:

    l = (1, 2)
    d = dict(l)

    While in Perl we can do:

    @l = (1, 2);
    %d = @l;

    But let's remember from what this discussion started. This is not a Python
    critique, because each language has its own ways.
    I just wanted to show that the fact that "there is more than one way to do
    it" in Perl and that "there is a single way" in Python are just buzzwords,
    because this was an example where in Python there are many ways to do it
    while in Perl there is a single way used usually, which is also more simple.

    Octavian
  • Daniel Kluev at May 23, 2011 at 9:58 am

    On Mon, May 23, 2011 at 7:49 PM, Octavian Rasnita wrote:
    That is not an array, but a list. An array has a name and we can't do
    something like the following simple statement in Python:

    l = (1, 2)
    d = dict(l)
    An array has a name
    What?
    In python there is no difference whether your object has any names
    mapped to it or not. Its all the same, and object itself does not even
    know.
    Moreover, (1, 2) is tuple rather than 'array'. If you mean array as
    implemented as array, then list is what you want. If you mean array
    literally, there is special type 'array' somewhere in stdlib.

    As for "can't do":
    a = [1,2]
    dict([a])
    {1: 2}
    a = (1,2)
    dict([a])
    {1: 2}


    --
    With best regards,
    Daniel Kluev
  • Octavian Rasnita at May 23, 2011 at 11:10 am
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    a = [1,2]
    dict([a])

    Yes, but

    d = dict([a])

    is not so nice as

    $d = @a;

    because it has exactly those numerous number of params and brackets which is
    used as a reason for bashing Perl and an aditional "dict" word.

    Octavian
  • Daniel Kluev at May 24, 2011 at 3:34 am

    On Mon, May 23, 2011 at 10:10 PM, Octavian Rasnita wrote:
    is not so nice as

    $d = @a;
    It is 'not so nice' only in your perception. Python clearly defines
    dict as container of (key, value) pairs, and therefore its constructor
    expects such pairs. Adding unjustified arbitrary ways to guess such
    pairs out of linear list is exactly what is being bashed here. Is is
    considered to be wrong and bad.

    Moreover, you are comparing apples to oranges here, and then
    complaining that apples somehow turned out to be not oranges.
    If we take python way of defining dicts and check it in perl, we find
    that it is not supported, so obviously perl is non-intuitive and does
    not support clear and easy way of defining hashes from list of
    key-value pairs:

    @l = ([1, 2], [3, 4],);
    %d = @l;
    for $k ( keys %d ) { print "$k\n"; }

    which outputs single ARRAY(0x804e158) instead of proper 1, 3, as it
    does in python:
    dict([[1,2], [3,4]]).keys()
    [1, 3]

    This is yet another example that you are just trolling here, making
    silly and unbacked claims, and ignoring any valid arguments you
    receive.

    --
    With best regards,
    Daniel Kluev
  • Octavian Rasnita at May 24, 2011 at 6:00 am
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    Moreover, you are comparing apples to oranges here, and then
    complaining that apples somehow turned out to be not oranges.
    If we take python way of defining dicts and check it in perl, we find
    that it is not supported, so obviously perl is non-intuitive and does
    not support clear and easy way of defining hashes from list of
    key-value pairs:
    @l = ([1, 2], [3, 4],);
    %d = @l;
    for $k ( keys %d ) { print "$k\n"; }

    which outputs single ARRAY(0x804e158) instead of proper 1, 3, as it
    does in python:
    dict([[1,2], [3,4]]).keys()
    [1, 3]

    This is yet another example that you are just trolling here, making
    silly and unbacked claims, and ignoring any valid arguments you
    receive.

    You are showing a code but tell another thing. If it would be as you said, I
    should have said that if in Perl a dictionary is made from a list using
    %d = @l;

    then in Python it should be
    l = d

    because it would be more nice. But I didn't say that. I said that it would
    be nice to be able to use something like
    d = dict(l)

    using the Python "dict" statement for creating dicts.

    And OK, Python needs another pair of brackets for doing that and this is no
    problem, but the result is that the Python's syntax is not as shorter and
    nice as Perl's, for the same thing.
    This is what that I said.

    And you are telling that in Perl should be used an even more complicated and
    ugly syntax just for beeing the same as in Python just for showing that I am
    wrong, but I was comparing just the shortness and cleraness of the code.

    So, again, in Perl is just:

    %d = @l;

    Please tell me if Python has a syntax which is more clear than this for
    doing this thing.
    It doesn't matter if it is different or if it follows another syntax.

    And again, I am not trolling anything. I am just defending a language which
    has a clearer syntax for doing some things, and a shorter code for other
    things, and which uses less braces and brackets than Python for other
    things, and which has a single-recommended way for doing some things, even
    though other list members were trolling about Perl, but nobody said
    something against.

    Octavian
  • Daniel Kluev at May 24, 2011 at 8:55 am

    On Tue, May 24, 2011 at 5:00 PM, Octavian Rasnita wrote:
    And you are telling that in Perl should be used an even more complicated and
    ugly syntax just for beeing the same as in Python just for showing that I am
    wrong, but I was comparing just the shortness and cleraness of the code.

    So, again, in Perl is just:

    %d = @l;
    Once again. Suppose we have array of key-value pairs (two-dimensional
    array), `l`. In python, converting it to dict is as simple as d =
    dict(l). In perl, %d = @l; produces meaningless value. Following your
    logic, this means that perl has ugly syntax.

    --
    With best regards,
    Daniel Kluev
  • Octavian Rasnita at May 24, 2011 at 4:10 pm
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    On Tue, May 24, 2011 at 5:00 PM, Octavian Rasnita wrote:
    And you are telling that in Perl should be used an even more complicated and
    ugly syntax just for beeing the same as in Python just for showing that I am
    wrong, but I was comparing just the shortness and cleraness of the code.

    So, again, in Perl is just:

    %d = @l;
    Once again. Suppose we have array of key-value pairs (two-dimensional
    array),
    This is a forced example to fit the way Python can do it with a clean syntax, but I don't think there are cases in which somebody wants to create hashes/dictionaries where the key is not a plain string but an array.

    This is not a rare case, but a case that probably nobody needs, ever.

    Octavian
  • Daniel Kluev at May 26, 2011 at 9:33 pm

    On Wed, May 25, 2011 at 3:10 AM, Octavian Rasnita wrote:
    Once again. Suppose we have array of key-value pairs (two-dimensional
    array),
    This is a forced example to fit the way Python can do it with a clean syntax, but I don't think there are cases in which somebody wants to create hashes/dictionaries where the key is not a plain string but an array.

    This is not a rare case, but a case that probably nobody needs, ever.
    This is far more popular case than converting flat lists into dicts in
    Python world. In fact, I *never* had need to convert flat list instead
    of properly structured one. Thats why we have both lists and tuples,
    after all.
    Sure, since perl does not support it at all, perl programmers do not
    use it and resort to idea of "guess which values are keys by index"
    due to lack of better approach, with need of obscure "=>"
    pseudo-syntax to cover it up.

    --
    With best regards,
    Daniel Kluev
  • RainyDay at May 26, 2011 at 11:41 pm

    On May 26, 5:33?pm, Daniel Kluev wrote:
    On Wed, May 25, 2011 at 3:10 AM, Octavian Rasnita wrote:
    Once again. Suppose we have array of key-value pairs (two-dimensional
    array),
    This is a forced example to fit the way Python can do it with a clean syntax, but I don't think there are cases in which somebody wants to create hashes/dictionaries where the key is not a plain string but an array.
    This is not a rare case, but a case that probably nobody needs, ever.
    This is far more popular case than converting flat lists into dicts in
    Python world. In fact, I *never* had need to convert flat list instead
    of properly structured one. Thats why we have both lists and tuples,
    after all.
    I agree that it's almost never needed to convert flat
    lists. I've used python for over 10 years and I remember
    exactly one time when I needed to do that. It turned out
    that it's a bit tricky and hacky to do in python, in
    the sense that it's hard to remember if I'll ever need
    it again, but it will only take minutes to google it.

    For example, in one piece of code I did recently I
    created a dict of range tuples and counts from a sequential list, like
    so:

    ranges = [(x*width, (x+1)*width) for x in range(y)]
    data = dict((x,0) for x in ranges)

    A perl programmer would instead create a flat list
    and then convert it to dict. And if he were new to
    python he'd create a flat list and then be annoyed
    that there's no quick and easy way to make it into
    a dict.

    Python way in this case is more structured and
    disciplined, and the only "flaw" I can see is that
    it doesn't meet expectations of perl programmers.

    -Rainy
  • D'Arcy J.M. Cain at May 24, 2011 at 10:05 am

    On Tue, 24 May 2011 09:00:14 +0300 "Octavian Rasnita" wrote:
    So, again, in Perl is just:

    %d = @l;

    Please tell me if Python has a syntax which is more clear than this for
    doing this thing.
    How is that clear? "Shorter" != "clearer." A Python programmer
    looking at that sees line noise. A Perl programmer looking at "d = dict
    ([a])" (or even "d = dict(a,)") sees something that has something to do
    with creating a dictionary. At least he would know in which section of
    the manual to look for more information.
    And again, I am not trolling anything. I am just defending a language which
    has a clearer syntax for doing some things, and a shorter code for other
    Are Perl programmers aware of some imminent worldwide shortage of
    electrons that Python programmers are not? Why is there this obsession
    with shortness?

    --
    D'Arcy J.M. Cain <darcy at druid.net> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
  • Octavian Rasnita at May 24, 2011 at 4:10 pm
    From: "D'Arcy J.M. Cain" <darcy at druid.net>
    On Tue, 24 May 2011 09:00:14 +0300
    "Octavian Rasnita" wrote:
    So, again, in Perl is just:

    %d = @l;

    Please tell me if Python has a syntax which is more clear than this for
    doing this thing.
    How is that clear? "Shorter" != "clearer." A Python programmer
    looking at that sees line noise. A Perl programmer looking at "d = dict
    ([a])" (or even "d = dict(a,)") sees something that has something to do
    with creating a dictionary. At least he would know in which section of
    the manual to look for more information.

    The Perl programmers usually don't need to look in the dictionary when they are creating programs.
    Perl is harder to learn, but it is easier to use.
    Are Perl programmers aware of some imminent worldwide shortage of
    electrons that Python programmers are not? Why is there this obsession
    with shortness?

    A shorter code can be typed faster, obviously, and there are fewer possibility of appearing errors, but the shortage is not the most important thing.

    The most important thing is that the chars @, $, or % are the same in all languages, while the English words used by the languages that use many such words are harder to remember especially for the non-native English speakers. Python is not a very bad language from this perspective like Java is though. :-)

    In Perl the programmers can also use English words for some things, like $OUTPUT_AUTOFLUSH, but personally I never liked those things. Using $| instead is much shorter and clear, because I don't need to remember the English words like autoflush, or maybe it was just flush, or it was autoflush_output, or output_flush... something like $| can't be forgotten.

    Yes, I know that the guys from Google would never like that since these chars are not "Googleable" :-)

    Octavian
  • John Bokma at May 25, 2011 at 11:58 am

    Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:

    Python books than after six months of trying to understand PERL... And
    Perl is the language, and perl is what runs Perl.
  • Teemu Likonen at May 24, 2011 at 1:18 pm

    * 2011-05-24T06:05:35-04:00 * D'Arcy J. M. Cain wrote:

    On Tue, 24 May 2011 09:00:14 +0300
    "Octavian Rasnita" wrote:
    %d = @l;

    Please tell me if Python has a syntax which is more clear than this
    for doing this thing.
    How is that clear? "Shorter" != "clearer." A Python programmer looking
    at that sees line noise.
    I'm a Lisp programmer who sees (some) Python code as line noise.
    I am just defending a language which has a clearer syntax for doing
    some things, and a shorter code for other
    Are Perl programmers aware of some imminent worldwide shortage of
    electrons that Python programmers are not? Why is there this obsession
    with shortness?
    I don't know but from the point of view of a Lisp programmer Python has
    the same obsession. Not trolling, I just wanted to point out that these
    are just point of views. I don't actually care that much about these
    things.
  • John Bokma at May 24, 2011 at 4:50 pm

    Teemu Likonen <tlikonen at iki.fi> writes:

    * 2011-05-24T06:05:35-04:00 * D'Arcy J. M. Cain wrote:
    On Tue, 24 May 2011 09:00:14 +0300
    "Octavian Rasnita" wrote:
    %d = @l;

    Please tell me if Python has a syntax which is more clear than this
    for doing this thing.
    How is that clear? "Shorter" != "clearer." A Python programmer looking
    at that sees line noise.
    I'm a Lisp programmer who sees (some) Python code as line noise.
    Exactly, and glad to see there are also non-extremists in this group.

    I have been programming Perl for well over 17 years. I've been trying to
    switch to Python /several times/ but yet, with all its shortcomings Perl
    somehow still suits me better. To D'Arcy and other Pythonistas --
    doesn't that sound like an extermistic organization or what -- it might
    look like a cat had an accident involving a keyboard but to me, and all
    those other people who do enjoy coding Perl it's beauty.

    The whole Python is so beatiful & perfect sounds to me like people who
    have embraced the latin alphabet calling Devanagari unreadable chicken
    scratches made by backwards and poor people. To me it's a writing system
    of beauty.
    I don't know but from the point of view of a Lisp programmer Python has
    the same obsession. Not trolling, I just wanted to point out that these
    are just point of views. I don't actually care that much about these
    things.
    Wise words. And I agree. To me Python vs. Perl has nothing to do with
    being a fanboy (unlike many other posters here). I like both languages,
    I have invested a lot of time in learning Python and I am really not
    dense. Yet, even though I can program in Python sufficient enough very
    often I just pick Perl. Now why is that?
  • Chris Angelico at May 24, 2011 at 5:30 pm

    On Wed, May 25, 2011 at 2:50 AM, John Bokma wrote:
    Wise words. And I agree. To me Python vs. Perl has nothing to do with
    being a fanboy (unlike many other posters here). I like both languages,
    I have invested a lot of time in learning Python and I am really not
    dense. Yet, even though I can program in Python sufficient enough very
    often I just pick Perl. Now why is that?
    To me, a language is a tool. The more tools you have competence with,
    the easier it will be to select the right one for any job. There are
    very few tools that have no use whatsoever; even Ook might be useful
    (although I have yet to be asked to port any code to OrangutanOS).
    This differs from the notion of having ten paradigms in one language,
    in that most source files will identify themselves fairly early on
    (possibly even out-of-band, such as filename extensions).

    Chris Angelico
  • John Bokma at May 24, 2011 at 5:56 pm

    Chris Angelico <rosuav at gmail.com> writes:
    On Wed, May 25, 2011 at 2:50 AM, John Bokma wrote:
    Wise words. And I agree. To me Python vs. Perl has nothing to do with
    being a fanboy (unlike many other posters here). I like both languages,
    I have invested a lot of time in learning Python and I am really not
    dense. Yet, even though I can program in Python sufficient enough very
    often I just pick Perl. Now why is that?
    To me, a language is a tool.
    To me, and to a lot of Perl programmers it's not different.
    The more tools you have competence with, the easier it will be to
    select the right one for any job. There are very few tools that have
    no use whatsoever; even Ook might be useful (although I have yet to be
    asked to port any code to OrangutanOS). This differs from the notion
    of having ten paradigms in one language,
    If this is referring to Perl: the myths surrounding "there is more than
    one way" are even more crazy than "there is only one way", maybe because
    "more than one" makes it so much easier to make those myths up?

    On top of that: how many paradigms does Python support? And which
    paradigms does Perl support and Python doesn't?

    Roughly there are two dialects of Perl [1]: what people who never took the
    time to learn it write, and the rest. Also, having more than one way to
    code something doesn't mean that there are no preferrences. Python has
    also several ways to do certain things; yet most skilled programmers
    have a preference for one way. It's not that different with Perl; in my
    experience exactly the same even.

    Of course one can say a lot about Perl; I can. But I have never had a
    rough time reading someone else's code, unless the person had no clue
    about programming to begin with [2].

    If Perl is really such a disaster, why are people using it? Or are they
    all short-sighted idiots who don't know better? Several Perl programmers
    I know, including myself, are fully aware of Python and other
    programming languages. Yet, somehow they still program in Perl...

    [1] http://www.bofh.org.uk/2010/07/25/a-tale-of-two-languages
    [2] I once had to port a piece of Pascal code and after some studying it
    turned out that the 100+ lines or so did some variant of bubble sort
    and near the end reversed the order in a separate loop.
  • Chris Angelico at May 24, 2011 at 9:53 pm

    On Wed, May 25, 2011 at 3:56 AM, John Bokma wrote:
    Chris Angelico <rosuav at gmail.com> writes:
    To me, a language is a tool.
    To me, and to a lot of Perl programmers it's not different.
    The more tools you have competence with, the easier it will be to
    select the right one for any job. There are very few tools that have
    no use whatsoever; even Ook might be useful (although I have yet to be
    asked to port any code to OrangutanOS). ?This differs from the notion
    of having ten paradigms in one language,
    If this is referring to Perl: the myths surrounding "there is more than
    one way" are even more crazy than "there is only one way", maybe because
    "more than one" makes it so much easier to make those myths up?

    On top of that: how many paradigms does Python support? ?And which
    paradigms does Perl support and Python doesn't?
    You miss my point. To me, BOTH Perl AND Python are tools; there is a
    time and a place for each. Also in my toolkit are C, C++, Pike, REXX,
    &c, &c, &c. Even Java and ActionScript/Flash (both of which I detest
    for several reasons) have their place - browser-based applications
    that aren't limited to HTTP (try writing an in-browser MUD client in
    Javascript). Every language has its downsides; every language has its
    unique feature that makes it special. And every language I've ever
    used has taught me something.

    Know both. Bash both (if you feel so inclined). Use both.

    Chris Angelico
  • John Bokma at May 24, 2011 at 10:00 pm

    Chris Angelico <rosuav at gmail.com> writes:
    On Wed, May 25, 2011 at 3:56 AM, John Bokma wrote:
    Chris Angelico <rosuav at gmail.com> writes:
    To me, a language is a tool.
    To me, and to a lot of Perl programmers it's not different.
    The more tools you have competence with, the easier it will be to
    select the right one for any job. There are very few tools that have
    no use whatsoever; even Ook might be useful (although I have yet to be
    asked to port any code to OrangutanOS). ?This differs from the notion
    of having ten paradigms in one language,
    If this is referring to Perl: the myths surrounding "there is more than
    one way" are even more crazy than "there is only one way", maybe because
    "more than one" makes it so much easier to make those myths up?

    On top of that: how many paradigms does Python support? ?And which
    paradigms does Perl support and Python doesn't?
    You miss my point.
    Could be, English is my second language. But to me "ten paradigms in one
    language" smelled of Perl bashing (or maybe Falcon bashing). My
    apologies if that was not the intent.
    To me, BOTH Perl AND Python are tools; there is a time and a place for
    each. Also in my toolkit are C, C++, Pike, REXX, &c, &c, &c. Even Java
    and ActionScript/Flash (both of which I detest for several reasons)
    have their place - browser-based applications that aren't limited to
    HTTP (try writing an in-browser MUD client in Javascript). Every
    language has its downsides; every language has its unique feature that
    makes it special. And every language I've ever used has taught me
    something.

    Know both. Bash both (if you feel so inclined). Use both.
    Can't agree more with you, thanks for the clarification.
  • John Bokma at May 24, 2011 at 5:17 am

    "Octavian Rasnita" <orasnita at gmail.com> writes:

    From: "Daniel Kluev" <dan.kluev at gmail.com>
    a = [1,2]
    dict([a])

    Yes, but

    d = dict([a])

    is not so nice as

    $d = @a;
    That will give you the number of elements in @a. What you (probably)
    mean is %hash = @array;
  • Octavian Rasnita at May 24, 2011 at 8:08 am
    From: "John Bokma" <john at castleamber.com>
    "Octavian Rasnita" <orasnita at gmail.com> writes:
    From: "Daniel Kluev" <dan.kluev at gmail.com>
    a = [1,2]
    dict([a])

    Yes, but

    d = dict([a])

    is not so nice as

    $d = @a;
    That will give you the number of elements in @a. What you (probably)
    mean is %hash = @array;

    Of course. Thank you for correction.

    Octavian
  • D'Arcy J.M. Cain at May 24, 2011 at 10:09 am

    On Tue, 24 May 2011 00:17:55 -0500 John Bokma wrote:
    $d = @a;
    That will give you the number of elements in @a. What you (probably)
    mean is %hash = @array;
    If I was even considering using Perl, this one exchange would send me
    screaming in the opposite direction.

    --
    D'Arcy J.M. Cain <darcy at druid.net> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
  • Octavian Rasnita at May 24, 2011 at 4:10 pm
    From: "D'Arcy J.M. Cain" <darcy at druid.net>
    On Tue, 24 May 2011 00:17:55 -0500
    John Bokma wrote:
    $d = @a;
    That will give you the number of elements in @a. What you (probably)
    mean is %hash = @array;
    If I was even considering using Perl, this one exchange would send me
    screaming in the opposite direction.

    If you didn't consider to change the language you prefer it means that you are closed minded and use to fell in love with the tools you use.
    Don't make me tell here how many things I don't like in Perl.
    I use to tell those things on Perl mailing lists and make upset their members. :-)

    Similarly, if you don't like something in Perl, why don't you tell them what you don't like to the Perl programmers community and not just have the guts to tell that in a group where the majority share your preferences.
    I came here on the list to find good things about Python and to learn some things and use its good parts, and not to hear bashing about other programming languages.

    Octavian
  • D'Arcy J.M. Cain at May 24, 2011 at 5:22 pm

    On Tue, 24 May 2011 19:10:56 +0300 "Octavian Rasnita" wrote:
    If I was even considering using Perl, this one exchange would send me
    screaming in the opposite direction.
    If you didn't consider to change the language you prefer it means
    that you are closed minded and use to fell in love with the tools you
    Now you are just bordering on rudeness. I never made any disparaging
    remarks about you. I only talked about a tool that you seem to like
    and I don't. In fact, I did consider and investigate Perl many years
    ago along with may other languages before I settled on Python. I
    didn't like it then and I don't like it now. However, I have never
    called someone "close minded" for preferring a different tool to me.
    Don't make me tell here how many things I don't like in Perl.
    Trust me, there is no need.
    I use to tell those things on Perl mailing lists and make upset their
    Good for you. I also have talked about things in Python that I don't
    like on this list. No one has ever accused me of being afraid to speak
    my mind. That facet of my personality has got me in a lot of trouble
    in my life from parents, teachers, bosses and I have even been known to
    speak out against the police while they were holding automatic rifles to
    my head. I doubt that there will ever be enough peer pressure on a
    mailing list to trump that.
    Similarly, if you don't like something in Perl, why don't you tell
    them what you don't like to the Perl programmers community and not just
    have the guts to tell that in a group where the majority share your
    preferences.
    Because I am not a missionary. Someone came to my house and told me
    why their way was better so I spoke up. Same thing when the JW come to
    my front door but I have no interest in going to their Kingdom Hall to
    tell them why they are wrong.
    I came here on the list to find good things about Python and to learn
    some things and use its good parts, and not to hear bashing about other
    programming languages.
    Same here but someone (I don't even know who started it) felt that it
    was necessary to tell us all why their language was better.

    --
    D'Arcy J.M. Cain <darcy at druid.net> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
  • John Bokma at May 24, 2011 at 4:52 pm

    "D'Arcy J.M. Cain" <darcy at druid.net> writes:

    On Tue, 24 May 2011 00:17:55 -0500
    John Bokma wrote:
    $d = @a;
    That will give you the number of elements in @a. What you (probably)
    mean is %hash = @array;
    If I was even considering using Perl, this one exchange would send me
    screaming in the opposite direction.
    To me as silly as all those people who give Python a wide berth because
    of significant whitespace. I am glad that I am not so limited in that
    respect. To me programming languages are like writing systems used by
    humans; each has its short comings and each has its beauty.
  • D'Arcy J.M. Cain at May 24, 2011 at 5:39 pm

    On Tue, 24 May 2011 11:52:39 -0500 John Bokma wrote:
    $d = @a;
    That will give you the number of elements in @a. What you (probably)
    mean is %hash = @array;
    If I was even considering using Perl, this one exchange would send me
    screaming in the opposite direction.
    To me as silly as all those people who give Python a wide berth because
    of significant whitespace. I am glad that I am not so limited in that
    respect. To me programming languages are like writing systems used by
    humans; each has its short comings and each has its beauty.
    My point was that even proponents of the language can make a
    significant error based on the way the variable is named. It's like
    the old Fortran IV that I first learned where the name of the variable
    determined whether it was an integer or a floating point.

    One of my favorite quotes (not sure if it was about Perl or APL) is "I
    refuse to use a programming language where the proponents of it stick
    snippets under each other's nose and say 'I bet you can't guess what
    this does.'"

    When I first looked at Perl it looked like line noise. When I first
    looked at Python it looked like pseudo-code.

    Look, I couldn't care less what other people use. I just don't see any
    reason for someone to come into a Python group and start proselytizing
    about why their tool is better than ours any more than I would feel any
    need to go to a Perl group and start trying to convert them.

    Bottom line - they did a study once (sorry, can't point to it any more)
    to determine the best tool for development. Turns out that the most
    productive tool was generally the one that the user believed was the
    most productive. In hindsight I think that that was rather obvious.

    --
    D'Arcy J.M. Cain <darcy at druid.net> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
  • Chris Angelico at May 24, 2011 at 10:01 pm

    On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain wrote:
    My point was that even proponents of the language can make a
    significant error based on the way the variable is named. ?It's like
    the old Fortran IV that I first learned where the name of the variable
    determined whether it was an integer or a floating point.
    I believe that's the origin of one of the proofs that God is real
    (unless declared integer). And hey, I can't hate something that gave
    us the classic use of i, j, k as loop indices!
    One of my favorite quotes (not sure if it was about Perl or APL) is "I
    refuse to use a programming language where the proponents of it stick
    snippets under each other's nose and say 'I bet you can't guess what
    this does.'"
    Yes, I believe that was Perl. And an amusing quote. But most of the
    point of it comes from the fact that Perl uses punctuation for most of
    its keywords, whereas (say) Python uses English words; it's a lot more
    fun to crunch something down when you can use $| and friends than when
    you have to put "x and y", complete with spaces, for a simple boolean.
    But that says nothing about which language is actually better for
    working with... beyond the fact that Perl can get more mileage out of
    an 80-character line!
    When I first looked at Perl it looked like line noise. ?When I first
    looked at Python it looked like pseudo-code.
    When I first looked at assembly language it looked like random junk
    left behind in memory. When I first looked at COBOL it looked like ...
    COBOL. Doesn't make either of them better or worse.

    Pseudo-code is not a viable language for a computer to parse, but it's
    a good language for scribbling down comments in. That doesn't
    necessarily mean that a programming language that's "closer to"
    pseudo-code is good. And verbosity doesn't necessarily equate to
    quality; for instance, when I'm working in both Python and PHP, I find
    it FAR tidier to use Python's {1:2,3:4] notation than PHP's
    array(1=>2,3=>4) - but on the flip side, I would prefer to have
    program structure defined by keywords like "if" and "while" than
    obscure random line noise. (Fortunately, most sane languages do indeed
    use keywords there.)

    Chris Angelico
  • John Bokma at May 24, 2011 at 11:16 pm

    Chris Angelico <rosuav at gmail.com> writes:
    On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain wrote:
    My point was that even proponents of the language can make a
    significant error based on the way the variable is named. ?It's like
    the old Fortran IV that I first learned where the name of the variable
    determined whether it was an integer or a floating point.
    I believe that's the origin of one of the proofs that God is real
    (unless declared integer). And hey, I can't hate something that gave
    us the classic use of i, j, k as loop indices!
    One of my favorite quotes (not sure if it was about Perl or APL) is "I
    refuse to use a programming language where the proponents of it stick
    snippets under each other's nose and say 'I bet you can't guess what
    this does.'"
    Yes, I believe that was Perl. And an amusing quote. But most of the
    point of it comes from the fact that Perl uses punctuation for most of
    its keywords,
    For example?
    whereas (say) Python uses English words; it's a lot more
    fun to crunch something down when you can use $|
    That's not a keyword but a special (global) variable. On top of that,
    you don't have to use it [1] and most people most likely encounter this in
    (badly) written CGI scripts originating in the last century.

    Yes, Perl is fantastic for writing hard to read obfuscated code. And
    yes, newbies are great at writing this from the very start, especially
    since they seem to copy paste examples written by other newbies (often
    written in the previous century...). But Perl doesn't force one to write
    unreadable code. If Perl was really so unreadable, why haven't I /still/
    not switched to Python? What keeps me going back to Perl?
    and friends than when you have to put "x and y", complete with spaces,
    for a simple boolean.
    Perl has also the and logical operator. This is legal Perl:

    if ( $x and $y ) {
    print "yes\n";
    }

    [1] You can use $OUTPUT_AUTOFLUSH (use English;), or use IO::Handle and
    use the autoflush method [2].

    [2] In Perl 5.14 IO::File is now loaded on demand:
    http://search.cpan.org/dist/perl/pod/perldelta.pod#Filehandle_method_calls_load_IO::File_on_demand
  • Chris Angelico at May 24, 2011 at 11:38 pm

    On Wed, May 25, 2011 at 9:16 AM, John Bokma wrote:
    Chris Angelico <rosuav at gmail.com> writes:
    Yes, I believe that was Perl. And an amusing quote. But most of the
    point of it comes from the fact that Perl uses punctuation for most of
    its keywords,
    For example?
    whereas (say) Python uses English words; it's a lot more
    fun to crunch something down when you can use $|
    That's not a keyword but a special (global) variable. On top of that,
    you don't have to use it [1] and most people most likely encounter this in
    (badly) written CGI scripts originating in the last century.
    Okay, poor example. But there's a lot of Perl that uses concise
    notation for things that in Python are keyworded; for instance,
    regular expressions. I'm insufficiently fluent in Perl to quote good
    examples; mainly what I'm referring to is the notion of operators that
    are separators, as opposed to keywords that get blank-delimited. I
    generally prefer syntactic elements to be punctuation (eg { } rather
    than BEGIN and END (or DO and END)). It does also make things easier
    to crunch, for better or for worse.
    and friends than when you have to put "x and y", complete with spaces,
    for a simple boolean.
    Perl has also the and logical operator. This is legal Perl:

    if ( $x and $y ) {
    ?print "yes\n";
    }
    That's at a completely different precedence level, isn't it? For
    operators up where you expect them to be, there's && and ||. A bit of
    digging (why isn't this sort of thing always the first hit for "<name
    of language> operator precedence" in Google?) brought up:

    http://perldoc.perl.org/perlop.html

    For instance:

    $a = $b && $c ? $e : $f;
    # versus
    $a = $b and $c ? $e : $f;

    The first one is an assignment to $a, conditional on two variables.
    The second is an unconditional assignment to $a, and then based on
    that, evaluates either $e or $f and does nothing with it.

    Python:
    a = e if b and c else f

    It's pretty similar, actually (although, coming from a C background, I
    do prefer to have the condition first); but I could crunch the first
    one down a lot, while the last one is almost as tight as it can be.

    $a=$b&&$c?$e:$f;
    a=e if b and c else f

    It's that crunched appearance that makes Perl look like line noise,
    and the open keyworded appearance that makes Python look like
    pseudocode. But that's not necessarily a good thing; a courteous
    programmer can space out Perl to keep it readable, and he then has the
    option of crunching pieces that are 'logically one' and spacing out
    the parts that aren't:

    $a= $b&&$c ? $e : $f;

    Silly, contrived example, but in production code I've often had
    situations where it makes sense to space out one part of an expression
    and crunch another. And when everything's an English word, that's not
    an available option.

    Oh, and that's ignoring the issue that not everyone is fluent in English.

    That said, though, I do find Python a lot easier for reading other
    people's code in. A LOT easier.

    Chris Angelico
  • John Bokma at May 25, 2011 at 1:48 am

    Chris Angelico <rosuav at gmail.com> writes:
    On Wed, May 25, 2011 at 9:16 AM, John Bokma wrote:
    Chris Angelico <rosuav at gmail.com> writes:
    Yes, I believe that was Perl. And an amusing quote. But most of the
    point of it comes from the fact that Perl uses punctuation for most of
    its keywords,
    For example?
    whereas (say) Python uses English words; it's a lot more
    fun to crunch something down when you can use $|
    That's not a keyword but a special (global) variable. On top of that,
    you don't have to use it [1] and most people most likely encounter this in
    (badly) written CGI scripts originating in the last century.
    Okay, poor example. But there's a lot of Perl that uses concise
    notation for things that in Python are keyworded; for instance,
    regular expressions.
    Perl does have indeed operators for matching and substitution. It's:

    ( my $foo = $bar ) =~ s/ ... / ... /;

    versus

    foo = re.sub(r" ... ", " ... ", bar )

    and:

    my $foo = qr/

    ...

    /xi;

    versus:

    foo = re.compile(r"""

    ...

    """, re.IGNORECASE|re.VERBOSE)

    It's just a matter of taste IMO. The regular expression noise stays the
    same ;-).
    and friends than when you have to put "x and y", complete with spaces,
    for a simple boolean.
    Perl has also the and logical operator. This is legal Perl:

    if ( $x and $y ) {
    ?print "yes\n";
    }
    That's at a completely different precedence level, isn't it?
    Yes, /but/ in this case it doesn't matter. Of course there are cases
    that it /does/ matter:
    For instance:

    $a = $b && $c ? $e : $f;
    # versus
    $a = $b and $c ? $e : $f;

    The first one is an assignment to $a, conditional on two variables.
    The second is an unconditional assignment to $a, and then based on
    that, evaluates either $e or $f and does nothing with it.

    Python:
    a = e if b and c else f
    Yes, "recently" added to the language, before that you had to and or
    your way out of it (or use lambdas).
    It's pretty similar, actually (although, coming from a C background, I
    do prefer to have the condition first); but I could crunch the first
    one down a lot, while the last one is almost as tight as it can be.

    $a=$b&&$c?$e:$f;
    a=e if b and c else f

    It's that crunched appearance that makes Perl look like line noise,
    So you just agree with what I earlier wrote: one /can/ write harder to
    read in Perl, like you can jump off a cliff. And I have seen a lot of
    extremely badly written Perl code, but never seen a disaster like the
    one above ;-).
    and the open keyworded appearance that makes Python look like
    pseudocode. But that's not necessarily a good thing; a courteous
    programmer can space out Perl to keep it readable, and he then has the
    option of crunching pieces that are 'logically one' and spacing out
    the parts that aren't:

    $a= $b&&$c ? $e : $f;

    Silly, contrived example, but in production code I've often had
    situations where it makes sense to space out one part of an expression
    and crunch another. And when everything's an English word, that's not
    an available option.
    I would write it like

    $a = ( $b and $c ) ? $e : $f;
    That said, though, I do find Python a lot easier for reading other
    people's code in. A LOT easier.
    Like I wrote earlier: I find Perl easier to read. And honestly, I don't
    know why. Partially it might have a lot to do with having been exposed
    to it much more. But many years back, when I could pick between several
    languages, Perl was the one that stuck with me. And that was before
    everybody and his mom was hacking CGI scripts in Perl (badly).

    And while I do want to switch to Python (or use it more often), for one
    reason or another it's hard. Maybe it's for similar reasons that one
    loves Spanish but hates German as a second language (or vice versa)?

    Both Perl and Python are evolving. Perl has a lot of bagage from the
    beginning, and more so since a lot got slapped on later on. Things are
    changing, but you just can't make major changes since people, like me I
    guess, are used to how things are right now.

    I now and then have peeks at Perl 6 and each time my first reaction is:
    this is Perl only in name; it's very, very different. On the other hand
    it still shares what I consider warts with Perl 5.
  • Thorsten Kampe at May 25, 2011 at 7:31 am
    * Chris Angelico (Wed, 25 May 2011 08:01:38 +1000)
    On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain wrote:
    One of my favorite quotes (not sure if it was about Perl or APL) is
    "I
    refuse to use a programming language where the proponents of it stick
    snippets under each other's nose and say 'I bet you can't guess what
    this does.'"
    Yes, I believe that was Perl. And an amusing quote. But most of the
    point of it comes from the fact that Perl uses punctuation for most of
    its keywords, whereas (say) Python uses English words; it's a lot more
    fun to crunch something down when you can use $| and friends than when
    you have to put "x and y", complete with spaces, for a simple boolean.
    But that says nothing about which language is actually better for
    working with... [...]
    It does say something about readibility. And yes, "readability counts".
    And yes, readability says a lot about how good a language is for reading
    and working with.

    Thorsten
  • John Bokma at May 25, 2011 at 12:01 pm

    Thorsten Kampe <thorsten at thorstenkampe.de> writes:

    * Chris Angelico (Wed, 25 May 2011 08:01:38 +1000)
    On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain wrote:
    One of my favorite quotes (not sure if it was about Perl or APL) is
    "I
    refuse to use a programming language where the proponents of it stick
    snippets under each other's nose and say 'I bet you can't guess what
    this does.'"
    Yes, I believe that was Perl. And an amusing quote. But most of the
    point of it comes from the fact that Perl uses punctuation for most of
    its keywords, whereas (say) Python uses English words; it's a lot more
    fun to crunch something down when you can use $| and friends than when
    you have to put "x and y", complete with spaces, for a simple boolean.
    But that says nothing about which language is actually better for
    working with... [...]
    It does say something about readibility. And yes, "readability counts".
    And yes, readability says a lot about how good a language is for reading
    and working with.
    To people used to the latin alphabet languages using a different script
    are unreadable. So readability has a lot to do with what one is used
    to. Like I already stated before: if Python is really so much better
    than Python readability wise, why do I have such a hard time dropping
    Perl and moving on?

Related Discussions

People

Translate

site design / logo © 2022 Grokbase