Why did Quora choose Python for its development?
Beliavsky
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.
Dotan Cohen
> http://mail.python.org/mailman/listinfo/python-list
>
They considered Haskell and OCaml and not a single mention of Perl?
--
Dotan Cohen
Chris Angelico
> 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
Octavian Rasnita
>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
> 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
> On Sun, May 22, 2011 at 6:44 PM, Octavian Rasnita <oras...@gmail.com> wrote:
>> Because of its flexibility, Perl offers more advanced modules and libraries which are not available for Python.
>
> What 'flexibility' are you talking about? This seem to be very biased
> statement, based on lack of according python experience.
I am talking about that flexibility which was criticized in the previous messages telling that this flexibility allows any programmer to use his own way.
Perl doesn't force anyone to indent the code, don't force the programmer to define a hash element before using it, allow the programmer to interpret the variables in strings directly. These things should be not used always, but if in some cases if the programmer wants to use them, he can use them with no problems. And this means flexibility.
> There are many python web frameworks which allow you to use w/e
> interfaces, template languages and ORMs you want - Pyramid/Pylons is
> good example.
> 'Very powerful' and 'great' are 'very useless' descriptions of these
> modules. Please, show us what exactly is so 'advanced' about them
> which cannot be done in python.
Every language can do almost anything, so this is not important, because the Python programmers didn't chose Python because it can do what other languages cannot do.
It is important how easy is to create an app with it, and while Python offers helpful features for creating desktop apps, for creating web apps Perl is better.
Here is a text from the documentation of Pyramid/Pylons:
"We finally need to add some routing elements to our application configuration if we want our view functions to be matched to application URLs.
...
# routes setup
config.add_route('list', '/')
config.add_route('new', '/new')
config.add_route('close', '/close/{id}')
"
...
First, this is a bad style of mapping urls, because this list must be maintained every time the programmer changes something in a controller that makes the app need to use other urls.
Catalyst don't need this overhead and don't need to specify the url mapping in a separate module. If the controllers change, then the url dispatching also changes.
Second, this way of url dispatching is not so flexible, because it doesn't allow as many types of url mappings.
Catalyst allows to dispatch the urls to actions based on controllers and subroutines names, globally or locally (based on the current controller), it allows dispatching based on regular expressions, it allows a chained dispatch where more actions are executed in a certain order on a single request, and all these without typing code outside of the subroutines that do the actions.
The module DBIx::Class which is used usually as an ORM can create the class files for all the tables from a database (MySQL, Oracle, PostgreSQL, SQLite, MS SQL, etc), and it can be used to search using unions, sub-selects, can define views at ORM level, can accept to insert different types of objects like DateTime objects and can also return those type of objects, and many other things, and most of the things it can do can be done without using SQL code at all, but only standard Perl code and Perl data structures.
HTML::FormFu form processor is one of the most used form processors in Catalyst applications and it can generate and parse forms created directly in the code of the application, or as external configuration files defined using JSON, or YAML, or Apache configuration style, or Perl data structures, or XML...
The forms defined are very easy to create and the elements from those forms, for example the list of elements in a combo box can be taken directly from a database by specifying just a few configuration elements. The results of a form submit can be also inserted in a database using a connector with DBIx::Class without specifying any database table column name in the programming code, and for doing this are required just a few lines of code that checks if the $form->submitted_and_valid() and that does the redirection after the submit, the insertion in the database requiring just:
$form->model->create;
or
$form->model->update( $db_record );
...after that record was defined using just something like:
my $db_record = $c->model( 'DB::TableName' )->find( $record_id );
And HTML::FormFu can do filtering based on many conditions, impose the specified constraints, specify different inflators/deflators from the inserted strings to their corresponding object types, do a validation eventualy based on a database query that checks for duplicates or other things, transform the data automaticly after the form was processed, can use I18N for displaying the field labels or values translated in the active language, have its own rendering engine or can render custom form fields made using Template-Toolkit, etc.
Yes, for web apps I have seen more things which can be done much better in Perl, much easier and clear, with less code, and not because the programmer needs to do not-recommended tricks for shortening the code, but because there are very many modules on CPAN that do the hard work.
Octavian
Terry Reedy
> I've noticed that on many Perl mailing lists the list members talk
> very rarely about Python,
Interesting. I learned about Python on comp.lang.perl, but that was over
a decade ago.
> 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.
This list really has very little other-language bashing.
> 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.
I forget the exact question you asked, but this list is not the doc. The
doc section on dicts gives dict(list_of_key_value_pairs) as the one true
way, given such an input. The Perl way cannot be clearer and can only be
shorted if it uses something shorter that dict().
If the list is a flat list of alternating keys and values, then yes,
they must be paired, and there are several ways to do that, partly
depending on the exact specifications, including allowed input and how
an odd key left over should be treated. In any case, unpaired keys and
values strikes me as an unusual input format for a dict. They typically
would have been paired as some point and in Python, should not need to
be unpaired.
--
Terry Jan Reedy
Daniel Kluev
> From: "Daniel Kluev" <dan....@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.
John Bokma
> I forget the exact question you asked, but this list is not the
> doc. The doc section on dicts gives dict(list_of_key_value_pairs) as
> the one true way, given such an input. The Perl way cannot be clearer
> and can only be shorted if it uses something shorter that dict().
my %hash = @list_of_key_value_pairs;
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
Octavian Rasnita
>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
Octavian Rasnita
> On Sun, May 22, 2011 at 11:47 PM, Octavian Rasnita <oras...@gmail.com>
> wrote:
>> From: "Daniel Kluev" <dan....@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
Chris Angelico
> From: "Dennis Lee Bieber" <wlf...@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
Terry Reedy
> 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
Carl Banks
> 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.
Evidently Perl users choose to bash other languages in those languages' own mailing lists.
> If Python would be so great, you wouldn't talk so much about how bad are
> other languages,
Sure we would. Sometimes it's fun to sit on your lofty throne and scoff at the peasantry.
> 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.
I would suggest that envy isn't the reason, the reason is that Perl is just that much worse than Visual Basic, Pascal, and Delphi. We only make fun of the really, really bad langauges.
(Or, less cynically, it's because Perl and Python historically filled the same niche, whereas VB, Pascal, and Delphi were often used for different sorts of programming.)
What I'm trying to say here is your logic is invalid. People have all kinds of reasons to badmouth other languages; that some mailing list has a culture that is a bit more or a bit less approving of it than some other list tells us nothing. In any case it's ridiculous to claim envy as factor nowadays, as Python is clearly on the rise while Perl is on the decline. Few people are choosing Perl for new projects.
Carl Banks
Chris Angelico
> On Sunday, May 22, 2011 12:44:18 AM UTC-7, Octavian Rasnita wrote:
>> If Python would be so great, you wouldn't talk so much about how bad are
>> other languages,
>
> Sure we would. Sometimes it's fun to sit on your lofty throne and scoff at the peasantry.
It's also fun, and sometimes productive, to sit on many different
lofty thrones, and then to have a Jedi Council meeting in which we
discuss which thrones are hard to climb onto, which ones are easy for
a child to sit on but hard to get any work done on, and which ones are
really comfortable and ergonomic, but have just that one little hard
bit to the right of where your arm wants to rest, but if you're
careful it won't jab into you too badly... and in those discussions,
Perl is a literal Swiss Army Knife. :)
> I would suggest that envy isn't the reason, the reason is that Perl is just that much worse than Visual Basic, Pascal, and Delphi. We only make fun of the really, really bad langauges.
I'm not sure that Perl deserves to be put alongside Visual Basic. I'm
not sure that ANY language deserves that...
Chris Angelico
Daniel Kluev
> 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.
Aleksandar Radulovic
I'm going to skip the Perl vs. Python flame-bait and correct your one statement.
On Sun, May 22, 2011 at 7:44 AM, Octavian Rasnita <oras...@gmail.com> wrote:
> 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.
Neither of those are proprietary and can, in fact, be used freely. GNU
compiler compiles objective-c code with no problem and then there's
Mono for C# and .NET development on multiple platforms.
But if by proprietary you mean the libraries and APIs that complement
those languages, the it's worth noting that Mono implements most of
.NET framework and it is free. If you want "free" Cocoa APIs (or other
Obj-C frameworks) look into GnuSTEP.
Best regards,
alex.
--
a lex 13 x
http://www.a13x.info
Octavian Rasnita
> On Mon, May 23, 2011 at 3:31 PM, Octavian Rasnita <oras...@gmail.com>
> wrote:
>> From: "Dennis Lee Bieber" <wlf...@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
Octavian Rasnita
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
Octavian Rasnita
> On Mon, May 23, 2011 at 5:06 PM, Octavian Rasnita <oras...@gmail.com>
> 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
> 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}
Daniel Kluev
> From: "Daniel Kluev" <dan....@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.
Ulrich Eckhardt
> 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.
Ahem, is this Java the language that a certain, well-known service provider
is getting screwed over hard currently, because they forgot to read the
fineprint in the declaration of freedom? And this Objective C, isn't this
the language that GCC had support for since before it properly supported
C++, and that on a multitude of targets?
I'm probably just confusedly feeding flames here, but I like it snug and
warm. (:
Uli
--
Domino Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
Octavian Rasnita
...
>> 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
Duncan Booth
> Ahem, is this Java the language that a certain, well-known service
> provider is getting screwed over hard currently, because they forgot
> to read the fineprint in the declaration of freedom?
That would be the case where the plaintiff has been ordered to drop all but
3 of their 132 claims? It isn't at all obvious yet who is going to be
'screwed over hard'.
--
Duncan Booth http://kupuguy.blogspot.com
Daniel Kluev
> From: "Daniel Kluev" <dan....@gmail.com>
> 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.
John Bokma
> 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,
Use an editor that can with a single command comment out a selection
(and revert this), like Emacs.
Terry Reedy
> 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,
Agreed. The latter is simply incorrect for Python and I don't know why
people say that. The statement from the Zen of Python is as follows:
"There should be one-- and preferably only one --obvious way to do it."
where 'it' is some reasonable common operation. This is a statement of
*intent* that is opposed to "All possible ways of doing things should be
included". The key word that people too often omit is *obvious* (once
one learns Python). There are usually, of necessity, multiple ways to do
something, but for common operations, there should be one way that is
obvious to the experienced Python programmer.
For instance, if you want to process the items of a collections, you can
use normal recursion, tail recursion, while iteration, or for iteration.
For the first three, you can use explicit or implicit conditions for
flow control. (Implicit conditions are by try-except.) One can use
various access methods to get the items. However, the one obvious,
compact, and efficient way is 'for item in collection:'. This works with
*any* collection with a proper __iter__ method.\
People accustomed to using tail recursion for this in other languages
sometimes request that tail-call space optimization be added to make
tail recursion a second 'obvious' way. Guido has refused because 1)
there are real problems with the idea and 2) one obvious way is enough.
Similarly, the obvious way to define a function is a def statement. One
alternative, which Guido allowed to be added for the specific purpose of
passing simple functions as arguments in function calls, is a lambda
expression. Guido has rejected requests to expand lambda expressions to
general function definitions. Again, there are real problems and one
obvious way is enough.
> 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.
Here I disagree. As I replied before, you are either ignoring the
obvious Python way or talking about a rare need.
--
Terry Jan Reedy
Octavian Rasnita
> On 5/23/2011 4:49 AM, Octavian Rasnita wrote:
>
>> 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,
>
> Agreed. The latter is simply incorrect for Python and I don't know why
> people say that. The statement from the Zen of Python is as follows:
> "There should be one-- and preferably only one --obvious way to do it."
> where 'it' is some reasonable common operation. This is a statement of
> *intent* that is opposed to "All possible ways of doing things should be
> included". The key word that people too often omit is *obvious* (once
> one learns Python). There are usually, of necessity, multiple ways to do
> something, but for common operations, there should be one way that is
> obvious to the experienced Python programmer.
Yes you are right. And it is exactly the same in case of experienced Perl programmers.
There is even a Perl book regarding the best practices, with many recommendations for the obvious way to do various things, and there is the module Perl::Critic with its command line percritic that follows those best practices very closely, so it is also just a buzzword that "there is more than one way to do it" for experienced Perl programmers.
> > 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.
>
> Here I disagree. As I replied before, you are either ignoring the
> obvious Python way or talking about a rare need.
I was talking about the method of creating a dictionary from an array which is much shorter and clear in Perl than in Python, and if you are using this very rarely, others might need to use it often.
Octavian
Octavian Rasnita
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
> 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
John Bokma
> From: "Daniel Kluev" <dan....@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
> Ahem, is this Java the language that a certain, well-known service
> provider
> is getting screwed over hard currently, because they forgot to read the
> fineprint in the declaration of freedom? And this Objective C, isn't this
> the language that GCC had support for since before it properly supported
> C++, and that on a multitude of targets?
Someone also said that C# can be used under Mono and even though this is
true, C# still remains a proprietary language that can be totally changed if
MS wants that, as well as Objective C can be changed if Apple wants that.
So what matters is if the most important developers for a specific
language/platform are releasing the code as open source or they keep it
proprietary and I don't see a big number of programmers developing code in
C# and Objective C.
About Java... you may be right. :-)
Octavian
Octavian Rasnita
> 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
Octavian Rasnita
> On Mon, May 23, 2011 at 10:17 PM, Octavian Rasnita <oras...@gmail.com>
> wrote:
>> From: "Daniel Kluev" <dan....@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
Stefan Behnel
> I thought this essay on why one startup chose Python was interesting.
Since everyone seems to be hot flaming at their pet languages in this
thread, let me quickly say this:
Thanks for sharing the link.
Stefan
Octavian Rasnita
Maybe I have missed a message, but if I didn't, please provide that link.
I am always interested to find the best solutions.
Thanks.
Octavian
Chris Angelico
At the beginning of the thread, three days and forty-odd messages ago,
this was posted:
http://www.quora.com/Why-did-Quora-choose-Python-for-its-development
It's the reason for the thread title, regardless of the current thread
content :)
Chris Angelico
Daniel Kluev
> 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.
D'Arcy J.M. Cain
"Octavian Rasnita" <oras...@gmail.com> wrote:
> So, again, in Perl is just:
>
> %d = @l;
>
> 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 <da...@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.
D'Arcy J.M. Cain
John Bokma <jo...@castleamber.com> 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.
Teemu Likonen
> On Tue, 24 May 2011 09:00:14 +0300
> "Octavian Rasnita" <oras...@gmail.com> 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.
Kevin Walzer
> 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.
Proprietary?
Licensing options for C# in its Mono (Free Platform) implementation:
http://www.mono-project.com/Licensing
Licensing options for Objective-C in its GNUStep (Free Platform)
implementaiton
http://www.gnustep.org/information/aboutGNUstep.html
It may be true that these languages are more widely used on their
originating platforms (Windows, OS X) than on Linux, but these
implementations are definitely open source.
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Chris Angelico
> Proprietary?
>
> Licensing options for C# in its Mono (Free Platform) implementation:
>
> http://www.mono-project.com/Licensing
>
> Licensing options for Objective-C in its GNUStep (Free Platform)
> implementaiton
>
> http://www.gnustep.org/information/aboutGNUstep.html
Just a side point: Are these *languages* free, or merely these
*implementations*?
Chris Angelico
Kevin Walzer
I kind of thought that other posters might also chime in on why they
chose Python instead of <insert other language here>. Since no one else
has, I'll bite.
I've been programming for about seven years, and am basically
self-taught. I got my first taste of writing code when trying do to some
basic hacking on my (then) shiny new G3 iBook. (Even though it was a
Mac, I was enthralled by its Unix underpinnings.) C was too hard for a
programming newbie, and (at the time) I only understood shell to be a
sequential series of commands. (cd ~/.Trash; ls; rm *)
My goal was to write desktop GUI apps, and looking around at the
available languages, libraries, and toolkits for Unix and the Mac, I
settled on Tk as the UI toolkit, since it seemed to be the simplest one
out there, and on Tcl and Python as the programming languages. (A brief
detour with AppleScript convinced me that it is a useful scripting
language for hooking into various parts of OS X, but it is not very
powerful.)
While Tcl doesn't get a lot of love or respect on this list, it is quite
powerful in its way, and an understanding of Tcl is quite useful in
particular for understanding Tk and its Python wrapper, Tkinter. After
becoming productive with Tcl and writing a couple of applications in it,
I turned to Python in earnest and set about learning its capabilities as
well, and have since released a couple of Python desktop apps on the Mac
(commercial apps, using Tk as the toolkit).
With that background, here are my reasons for keeping Python in my toolbox:
1. Its core libraries and third-party packages address nearly every
imaginable need. The size of its community is a real asset here. Tcl is
a more compact language, with a smaller core library and fewer
third-party packages (no library comparable to Mark Pilgrim's
feedparser, for instance), which means that for some use cases, using
Tcl would mean more work.
2. Python has excellent tools for deployment of desktop apps. Since I
only work on the Mac, I'm not that familiar with py2exe, but py2app and
bundlebuilder have always allowed me to wrap up my apps with an embedded
Python interpreter with a minimum of fuss. Tcl also excels in deployment
of desktop apps; other languages, such as Perl and Ruby, seem to lag
behind in this respect. (I could find no actively-maintained,
open-source, Mac-viable desktop app bundling tools for either Ruby or
Perl, which cooled my interest in them considerably.)
3. Python's binding to Tk makes writing GUI apps a straightforward
process. Since I already knew Tk quite well, learning its Python
bindings was much simpler than learning another GUI toolkit such as PyQt
or wxPython. The strategies I learned from Tcl to develop sophisticated
Tk-based UI's translate quite well to Python.
Python isn't perfect; for some instances, I find Tcl a more lightweight
and accessible tool to use. I also spend a lot of time digging into Tcl
and Tk's C API to extend their capabilities in certain ways; this also
allows my Python apps to access such enhancements, via Tkinter. But all
in all I'm a happy user of Python, and it will continue to have a
primary place in my toolbox.
Octavian Rasnita
>>
>>
>> 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
> ([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
Octavian Rasnita
> On Tue, May 24, 2011 at 5:00 PM, Octavian Rasnita <oras...@gmail.com> 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.
>>
>>
>> %d = @l;
>
> 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
Octavian Rasnita
> On Tue, 24 May 2011 00:17:55 -0500
> John Bokma <jo...@castleamber.com> 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
Octavian Rasnita
Hi Kevin,
Thanks for your message. It is helpful to know why some programmers prefer a certain OS, programming language, module or program, because this way the newbies can find its benefits rapidly.
Yes there are packiging solutions for Perl under Mac, but I haven't tried them because I never used a Mac, however, I agree that python is better than Perl for creating desktop apps, because the modules which are used for creating GUIs are better developed.
Too bad that you prefer Tk-based GUIs, because they are simple to use, I agree, but they create and promote discrimination because they are not accessible at all for the screen readers used by the blind.
The standard Win32 GUIS/MFC or the libs that use those GUIs like Java SWT and wxWIDGETS used by WxPerl, WxPython... are much better accessible. Somebody told that he will try to make Tk accessible, but just as I expected, I haven't heard anything until now about any kind of success of that project.
Octavian
Octavian Rasnita
Exactly, this is why I said that it matters only the distributions used by the most users.
Octavian
John Bokma
> * 2011-05-24T06:05:35-04:00 * D'Arcy J. M. Cain wrote:
>
>> On Tue, 24 May 2011 09:00:14 +0300
>> "Octavian Rasnita" <oras...@gmail.com> 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?
John Bokma
> On Tue, 24 May 2011 00:17:55 -0500
> John Bokma <jo...@castleamber.com> 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
"Octavian Rasnita" <oras...@gmail.com> wrote:
> > If I was even considering using Perl, this one exchange would send me
> > screaming in the opposite direction.
>
> 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.
Chris Angelico
> 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
D'Arcy J.M. Cain
John Bokma <jo...@castleamber.com> 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.
John Bokma
> On Wed, May 25, 2011 at 2:50 AM, John Bokma <jo...@castleamber.com> 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.
John Bokma
> On Tue, 24 May 2011 11:52:39 -0500
> John Bokma <jo...@castleamber.com> 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.
And someone can't misspell dict, for example? Are we now going to judge
a language on a typo someone just made?
> When I first looked at Perl it looked like line noise. When I first
> looked at Python it looked like pseudo-code.
When people who are used to a latin alpabeth look at Devanagari they
probably see scratches make by chickens. I saw beauty (and still see
it). To someone fluent in Devanagari the latin alpabeth might look like
Perl ;-).
Anyway, I have been exposed to pseudo-code a lot before I picked up
Perl, and yet, Perl somehow stuck with me. I learned about Python a
little later (IIRC), and have tried to pick it up several times over the
years that followed. Last year I have been more serious about picking it
up; and I even did some paid for work in it. I /can/ program in Python,
I do /like/ Python, but somehow I like Perl more; even when I am fully
aware of its shortcommings each time I use it.
As for line noise: very often it turns out that people mean the regular
expressions by this. But a similar dialect is used by many other
programming languages that I know of. The difference is that Perl has
dedicated operators for it.
A Perl programmer will call this line noise:
double_word_re = re.compile(r"\b(?P<word>\w+)\s+(?P=word)(?!\w)",
re.IGNORECASE)
for match in double_word_re.finditer(text):
print ("{0} is duplicated".format(match.group("word"))
(p500 of Programming in Python 3, 2nd edition, any typos by me).
> Look, I couldn't care less what other people use.
In that case you're an exception here. Or maybe the weekly Perl bashers
are way more vocal here and drown people like you out. One thing I hate
about comp.lang.perl.misc is the ivory tower attitude there. One thing I
hate about comp.lang.python is the weekly Perl bashing; to me it makes
those people look like extremists (Pythonistas, what's in a word), and
to be honest, it does affect how I view Python.
> 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.
Yet it seems to be accepted behavoir here to weekly bash Perl...
> 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.
Doesn't surprise me. I did switch to Emacs a few years back (used
Textpad for many years) but I don't think I now produce more code /
hour. But I am able to do some things way easier compared to using
Textpad, and that gives me pleasure.
Octavian Rasnita
> "Octavian Rasnita" <oras...@gmail.com> writes:
>
>> From: "Daniel Kluev" <dan....@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
Chris Angelico
> Chris Angelico <ros...@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
> On Wed, May 25, 2011 at 3:56 AM, John Bokma <jo...@castleamber.com> wrote:
>> Chris Angelico <ros...@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.
Chris Angelico
> My point was that even proponents of the language can make a
> 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
> On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain <da...@druid.net> 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
> Chris Angelico <ros...@gmail.com> writes:
>
>> 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
> On Wed, May 25, 2011 at 9:16 AM, John Bokma <jo...@castleamber.com> wrote:
>> Chris Angelico <ros...@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
>
> On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain <da...@druid.net> 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
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
Roy Smith
Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
> On Tue, 24 May 2011 13:39:02 -0400, "D'Arcy J.M. Cain" <da...@druid.net>
> declaimed the following in gmane.comp.python.general:
>
>
> > 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.
> >
> Only if one didn't declare the type ahead of time...
>
> And even then it wasn't that hard to remember (using a non-PC
> mnemonic): Indian's are integer (variables starting I to N inclusive
> were integers)
Remembering that I, J, K, L, M, and N were integer was trivial if you
came from a math background. And, of course, Fortran was all about
math, so that was natural. Those letters are commonly used for integers
in formulae. If I write $ x sub i $, anybody who knows math would
immediately assume that the range of x was reals and the range of i was
integers.
Chris Angelico
> Remembering that I, J, K, L, M, and N were integer was trivial if you
> came from a math background. And, of course, Fortran was all about
> math, so that was natural. Those letters are commonly used for integers
> in formulae. If I write $ x sub i $, anybody who knows math would
> immediately assume that the range of x was reals and the range of i was
> integers.
When I studied maths, x and y were reals, and i wasn't. But it wasn't
integer either... :)
Chris Angelico
John Bokma
> Python books than after six months of trying to understand PERL... And
Perl is the language, and perl is what runs Perl.
John Bokma
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?
Roy Smith
Chris Angelico <ros...@gmail.com> wrote:
I was talking of i in the context of a variable, not as a constant. If
I write $ 3 + 7i $ in one place and $ x sub i $ in another, most people
will figure out from the context which is which.
D'Arcy J.M. Cain
Roy Smith <r...@panix.com> wrote:
> Remembering that I, J, K, L, M, and N were integer was trivial if you
> came from a math background. And, of course, Fortran was all about
The easiest way to remember was that the first two letters of INteger
gave you the range.
Chris Angelico
> The easiest way to remember was that the first two letters of INteger
> gave you the range.
>
G for Green and R for Right, which are the first two letters of Green.
(I wonder how many Pythonistas are familiar with that?)
Chris Angelico
Steven D'Aprano
> On Wed, 25 May 2011 07:36:40 -0400
> Roy Smith <r...@panix.com> wrote:
>> Remembering that I, J, K, L, M, and N were integer was trivial if you
>> came from a math background. And, of course, Fortran was all about
>
> The easiest way to remember was that the first two letters of INteger
> gave you the range.
Huh. I never knew that. I just learned from use that I, J, K, M and N
were traditionally integers. I never used L for an integer variable, and
don't know anyone who does.
I for integer is obvious. If you need a second one, you use the next
letter J, and if you need a third, the one after that, K. If you need
four, you're probably doing something wrong.
Likewise, N for number (as in, *counting* number). If you need two, using
N and O is stupid, because O can be confused with 0, so you go backwards
and use M.
However, using P and Q for integers is merely arbitrary convention.
--
Steven
Matty Sarro
you always have to wonder if its an l or a 1 in a terminal window.
-Matthew
Terry Reedy
> 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?
[you meant 'than Perl'] You are one of the people whose brain fits Perl
(or vice versa) better than most. So enjoy it. Ignore anyone who says
otherwise.
--
Terry Jan Reedy
Ethan Furman
> On 5/25/2011 8:01 AM, John Bokma wrote:
>
>> than Python readability wise, why do I have such a hard time dropping
>> Perl and moving on?
>
> (or vice versa) better than most. So enjoy it. Ignore anyone who says
> otherwise.
+1
If everybody's brain worked the same, we wouldn't have so many different
languages to choose from.
~Ethan~
John Bokma
So, this means that in general language readability is not as clear cut
as some seem to advertise ;-).
Matty Sarro
> http://mail.python.org/mailman/listinfo/python-list
>
General readability is a farce. If it was true we would only have one
section to the library. Different people enjoy reading, and can
comprehend better in different ways. THat's why some people are super
verbose - hell, just look at this here post! :)
the...@nospam.net
[snip]
> 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.'"
exams are written, no?
The point is that puzzling through arcane bits of code are crucial to
learning
any language. It's a valuable exercise.
Steven D'Aprano
> if Python is really so much better than Python [Perl]
> readability wise, why do I have such a hard time dropping
> Perl and moving on?
My guess is that you have an adversarial view of computer languages,
therefore after investing so much time and energy and, most importantly,
self-image into becoming a Perl programmer, dropping it and moving on
would be tantamount to admitting to yourself that you were "wrong" to
have wasted so many years on the wrong language.
Whether it is objectively "wrong" or not rarely enters into these things.
That *you personally* can't or won't let go of Perl says nothing about
the relative readability of Perl and Python code.
--
Steven
Steven D'Aprano
> On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain <da...@druid.net>
> wrote:
>> 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.
Er, yes it does.
Writing code is primarily for *human readers*. Once you've compiled the
code once, the computer never need look at it again, but human being come
back to read it over and over again, to learn from it, or for
maintenance. We rightfully value our own time and convenience as more
valuable than that of the computer's, which is why we use programming
languages at all, instead of having custom-made hardware built for every
task we want the computer to do:
"I have to rename a file before August 2015, but the rename itself needs
to be done in under a picosecond. Know any bespoke chip manufacturers who
do small runs?"
From that perspective, COBOL is an improvement on assembly, which is why
there are probably still more COBOL programmers around than people who
work exclusively on assembly.
Sometimes we compromise, or even subvert, that trade-off: for speed
critical code where we do care more about the computer's time than our
own, or for esoteric languages designed to be as hard to read as
possible. My personal favourites, Oook and Whitespace.
But generally, people spend more time reading code than writing it,
therefore we should weigh "ease of reading" higher than "ease of
writing". (My guess is, the weights should be about 5:1.)
> Pseudo-code is not a viable language for a computer to parse,
Only because "pseudo-code" implies that the code is ambiguous or
otherwise cannot be parsed. If it could be, it wouldn't be *pseudo*, it
would be real code (possibly for some compiler that hasn't been written
yet).
> 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.
That depends on the nature of pseudo-code. "Pseudo-assembly" has all the
disadvantages of assembly with none of the advantages, i.e. it doesn't
actually work. So in that sense, pseudo-code is not necessarily a good
thing nor a bad thing.
But in general conversation, pseudo-code is usually implied to mean that
the language is as close to human language as you can make it, while
still be parsable by a compiler.
> 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.)
True. That's one of the limitations of the xtalk family of languages
derived from Apple's (defunct) Hypertalk: it's awfully verbose, which is
good for newbies but not quite so good for experts.
--
Steven
Steven D'Aprano
You seem to miss the point that a good language shouldn't make it
possible to write arcane code that needs to be puzzled out.
Although in fairness, what's arcane to me might be straightforward to
you... and vice versa.
In that sense, there probably aren't any "good languages", because it is
impractical to have a language that cannot be obfuscated in any way.
Nevertheless, we can distinguish "less good" from "more good" in
languages in the sense of readability. The fact that some languages not
just allow such obfuscation but encourage it makes the language great for
puzzles but not so good for when you actually want to get work done and
have to deal with code written by someone else. *Especially* if they're
significantly smarter, or dumber, than you.
Worst of all is dealing with code written by somebody who *thinks*
they're smarter but is actually dumber.
--
Steven
RainyDay
> Ethan Furman <et...@stoneleaf.us> writes:
> > Terry Reedy wrote:
> >> On 5/25/2011 8:01 AM, John Bokma wrote:
>
> >>> 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?
>
> >> [you meant 'than Perl'] You are one of the people whose brain fits
> >> Perl (or vice versa) better than most. So enjoy it. Ignore anyone
> >> who says otherwise.
>
> > +1
>
> > If everybody's brain worked the same, we wouldn't have so many
> > different languages to choose from.
>
> So, this means that in general language readability is not as clear cut
> as some seem to advertise ;-).
>
I only know a tiny bit of Perl but I think you may
prefer it because it gives you some advantages in
short term but you have to pay more than it's
worth (arguably) in the long term. When you sit
down to write a new program, it's easier to do
than in python because it's quicker to type and,
of the proverbial "many ways", you chose the ones
that suit your taste better.
However, when you sit down to read someone else's
code, it's harder to read because you don't know
the intent of their authors. If they had different
taste for idioms or formatting style than you do,
you will chalk it up to them being bad programmers
and having bad coding or formatting style, so it's
not perceived as a perl's failing.
Python way has more of an emphasis on everyone
agreeing on some preferred, standard idioms so
that everyone can pick up each others' code
quickly.
Similarly, when we write in english, we have
conventions of, for instance, capitalizing at the
start of a sentence and having a period at the end
of it, and following rules of grammar. However, if
I'm writing notes for my own use, I might write:
similarly when we write in english we have
conventions of eg capitalizing at start of
sentence and having period at the end &
following rules of grammar but since i'm
writing for my own use maybe it's easier to
write in lower caps and use 3 spaces at the
end of sentences, since no-ones has to read
it but me?
John Bokma
> On Wed, 25 May 2011 07:01:07 -0500, John Bokma wrote:
>
>> if Python is really so much better than Python [Perl]
>> readability wise, why do I have such a hard time dropping
>> Perl and moving on?
>
> My guess is that you have an adversarial view of computer languages,
Well, it's clear that you are indeed the fuckwit I suspected you
are. What's a pity is that you are so vocal in this group and to me at
least makes it a way less pleasant experience to read this group.
Get a life. Or better, just fuck off and die. It will improve both the
world and the Python community, of which you are nothing but a little,
smelly shitstain.
Ben Finney
> Get a life. Or better, just fuck off and die. It will improve both the
> world and the Python community, of which you are nothing but a little,
> smelly shitstain.
That abuse is entirely unwelcome in this community, against any person.
Please desist.
If you find any contributing members so difficult to deal with, please
don't respond at all.
--
\ “We have met the enemy and he is us.” —Walt Kelly, _Pogo_ |
`\ 1971-04-22 |
_o__) |
Ben Finney
Thorsten Kampe
> Thorsten Kampe <thor...@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 <da...@druid.net> 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.
You've made that "alphabet" argument more than once. Nevertheless it's
nonsense (sorry). Perl uses the same alphabet as Python. Only the
"words" Perl uses ("$|" for instance) are only found in a Perl
dictionary not in a English or math dictionary like the one that Python
uses.
That's why you can /read/ Python but you have to /decode/ Perl to
understand the source code.
> 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?
What kind of argument is that?
Thorsten
Neil Cerutti
> General readability is a farce. If it was true we would only
> have one section to the library. Different people enjoy
> reading, and can comprehend better in different ways. THat's
> why some people are super verbose - hell, just look at this
> here post! :)
Despite individual proclivities, there remain standards of
readability enshrined in our dictionaries and grammar handbooks.
Claiming that code readability of code is to be judged solely
subjectively by each individual absolves code of the
responsibility to communicate to more than just its author.
--
Neil Cerutti
Roy Smith
Neil Cerutti <ne...@norwich.edu> wrote:
Also, the purpose of source code is to transmit information (to both the
compiler and to human readers). That is a much narrower purpose than is
served by books in a library, many of which are written as
entertainment. Sometimes, the real enjoyment (in literature) comes in
figuring out what the author really meant.
Ben Finney
> Also, the purpose of source code is to transmit information (to both
> the compiler and to human readers).
And the relative importance of readability for those two purposes is
often misunderstood.
Composing source code so that the *machine* will understand it is one
thing, and can be unambiguously verified.
Composing the same source code so that its meaning will be clearly
transmitted to *other humans* is quite another matter: certainly more
difficult, and arguably far more important:
“Programs must be written for people to read, and only incidentally
for machines to execute.”
—Abelson & Sussman, _Structure and Interpretation of Computer
Programs_
> Sometimes, the real enjoyment (in literature) comes in figuring out
> what the author really meant.
Right. Unlike that kind of writing, in functional code like a computer
program, ambiguity of meaning is a curse.
Programmers, if you feel the urge to be subtle and clever and nuanced,
take up poetry or literature as a separate pursuit. In your program
source code, please be as straightforward and unambiguous and
predictable as possible.
--
\ “Very few things happen at the right time, and the rest do not |
`\ happen at all. The conscientious historian will correct these |
_o__) defects.” —Mark Twain, _A Horse's Tale_ |
Ben Finney
Steven D'Aprano
Bravo!
+1 Quote of the Thread
--
Steven
the...@nospam.net
> On Wed, 25 May 2011 17:30:48 -0400, the...@nospam.net wrote:
>
>> On 5/24/2011 1:39 PM, D'Arcy J.M. Cain wrote: [snip]
>>> 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.'"
>> I dunno. That sounds about like how most programming course exams are
>> written, no?
>> The point is that puzzling through arcane bits of code are crucial to
>> learning
>> any language. It's a valuable exercise.
>
> You seem to miss the point that a good language shouldn't make it
> possible to write arcane code that needs to be puzzled out.
Try to stay focused please.
Perl hackers show each other arcane bits of code because such impractical
puzzle programs are good for learning.
Such puzzles can be created in any language. For example, I have had formal
coursework in a number of languages (Pascal, C++, ML, Scheme, and others)
and in each one an important exercise was to puzzle through arcane bits
of code
in each of those languages.
The post I was replying to seemed to question the value of such
'I bet you can't guess what this does.' type challenges.
John Bokma
>> Get a life. Or better, just fuck off and die. It will improve both the
>> world and the Python community, of which you are nothing but a little,
>> smelly shitstain.
>
> That abuse is entirely unwelcome in this community, against any person.
> Please desist.
You should have spoken up sooner, especially as the spokes person of
"this" community. But every bully has is fan club.
the...@nospam.net
Maybe they should have focused more on content instead of
the bits under the hood?
Ethan Furman
You say English is not your first language. Let me assure you that the
words you chose to use in reply to Stephen were vulgar as well as rude,
and did more to lesson the overall friendliness of this forum than
Stephen's adversarial style.
You usually have interesting and informative posts -- please don't
resort to this tactic.
~Ethan~
Terry Reedy
> Ben Finney<b...@benfinney.id.au> writes:
>>>> [impolite comment not quoted]
>>> Get a life. Or better, just fuck off and die. It will improve both the
>>> world and the Python community, of which you are nothing but a little,
>>> smelly shitstain.
>>
>> That abuse is entirely unwelcome in this community, against any person.
>> Please desist.
>
> You should have spoken up sooner, especially as the spokes person of
> "this" community. But every bully has is fan club.
I agree that the original impolite comment was just that -- impolite --
and perhaps enough so that it should have been spoken out against. But I
also agree that the quoted response is at least three times as bad,
enough so to understandably push someone to respond. Both comments are
atypical here.
--
Terry Jan Reedy
Karim
> On 5/26/2011 11:36 AM, John Bokma wrote:
>> Ben Finney<b...@benfinney.id.au> writes:
>
> >>>> [impolite comment not quoted]
>>>> world and the Python community, of which you are nothing but a little,
>>>> smelly shitstain.
>>>
>>> That abuse is entirely unwelcome in this community, against any person.
>>> Please desist.
>>
>> You should have spoken up sooner, especially as the spokes person of
>> "this" community. But every bully has is fan club.
>
> -- and perhaps enough so that it should have been spoken out against.
> But I also agree that the quoted response is at least three times as
> bad, enough so to understandably push someone to respond. Both
> comments are atypical here.
>
Original one impolite perhaps but only truth could cause such hatred.
Cheers