Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #5859 > unrolled thread

Why did Quora choose Python for its development?

Back to article view | Back to comp.lang.python

Contents

  Why did Quora choose Python for its development? Beliavsky <beliavsky@aol.com> - 2011-05-20 09:39 -0700
    Re: Why did Quora choose Python for its development? Dotan Cohen <dotancohen@gmail.com> - 2011-05-20 23:47 +0300
    Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-22 15:01 +1000
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-22 10:44 +0300
      Re: Why did Quora choose Python for its development? Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2011-05-23 12:56 +0200
        Re: Why did Quora choose Python for its development? Duncan Booth <duncan.booth@invalid.invalid> - 2011-05-23 11:28 +0000
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 08:25 +0300
      Re: Why did Quora choose Python for its development? Kevin Walzer <kw@codebykevin.com> - 2011-05-24 10:09 -0400
        Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 00:43 +1000
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:11 +0300
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-22 19:20 +1100
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-22 15:47 +0300
    Re: Why did Quora choose Python for its development? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-22 12:09 -0700
    Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-22 18:01 -0400
      Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-22 18:55 -0500
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 10:42 +1100
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 08:31 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 09:06 +0300
    Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-23 16:37 +1000
      Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-23 10:26 -0500
    Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-23 02:37 -0400
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 19:05 +1100
    Re: Why did Quora choose Python for its development? Aleksandar Radulovic <alex@a13x.net> - 2011-05-23 08:52 +0000
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 11:49 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 12:01 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 12:41 +0300
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 20:58 +1100
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 21:16 +1100
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 14:17 +0300
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 22:32 +1100
    Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-23 13:08 -0400
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 22:05 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 14:10 +0300
      Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 00:17 -0500
        Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-24 06:09 -0400
          Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 11:52 -0500
            Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-24 13:39 -0400
              Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 13:17 -0500
                Re: Why did Quora choose Python for its development? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-27 15:48 +1200
                  Re: Why did Quora choose Python for its development? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-26 23:53 -0700
                  Re: Why did Quora choose Python for its development? Roy Smith <roy@panix.com> - 2011-05-27 09:47 -0400
                    Re: Why did Quora choose Python for its development? Karim <karim.liateni@free.fr> - 2011-05-27 22:10 +0200
              Re: Why did Quora choose Python for its development? "thegist@nospam.net" <thegist@nospam.net> - 2011-05-25 17:30 -0400
                Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-25 23:52 +0000
                  Re: Why did Quora choose Python for its development? "thegist@nospam.net" <thegist@nospam.net> - 2011-05-26 11:05 -0400
            Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 08:01 +1000
              Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 18:16 -0500
                Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 09:38 +1000
                  Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 20:48 -0500
              Re: Why did Quora choose Python for its development? Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-05-25 09:31 +0200
                Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-25 07:01 -0500
                  Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-25 12:54 -0400
                  Re: Why did Quora choose Python for its development? Ethan Furman <ethan@stoneleaf.us> - 2011-05-25 10:17 -0700
                    Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-25 14:14 -0500
                      Re: Why did Quora choose Python for its development? Matty Sarro <msarro@gmail.com> - 2011-05-25 17:19 -0400
                        Re: Why did Quora choose Python for its development? Neil Cerutti <neilc@norwich.edu> - 2011-05-26 12:44 +0000
                          Re: Why did Quora choose Python for its development? Roy Smith <roy@panix.com> - 2011-05-26 08:51 -0400
                            Re: Why did Quora choose Python for its development? Ben Finney <ben+python@benfinney.id.au> - 2011-05-26 23:11 +1000
                          Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-26 13:35 +0000
                      Re: Why did Quora choose Python for its development? RainyDay <andrei.avk@gmail.com> - 2011-05-25 17:15 -0700
                  Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-25 23:01 +0000
                    Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-25 22:00 -0500
                      Re: Why did Quora choose Python for its development? Ben Finney <ben@benfinney.id.au> - 2011-05-26 14:25 +1000
                        Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-26 10:36 -0500
                          Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-26 16:03 -0400
                            Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-27 03:07 +0000
                              Re: Why did Quora choose Python for its development? Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-05-27 10:10 +0200
                                Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-27 09:31 +0000
                                Re: Why did Quora choose Python for its development? Ethan Furman <ethan@stoneleaf.us> - 2011-05-27 10:12 -0700
                          Re: Why did Quora choose Python for its development? Karim <karim.liateni@free.fr> - 2011-05-26 22:27 +0200
                      Re: Why did Quora choose Python for its development? Ethan Furman <ethan@stoneleaf.us> - 2011-05-26 09:18 -0700
                  Re: Why did Quora choose Python for its development? Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-05-26 10:24 +0200
              Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-25 23:25 +0000
            Re: Why did Quora choose Python for its development? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-24 23:00 -0700
              Re: Why did Quora choose Python for its development? Roy Smith <roy@panix.com> - 2011-05-25 07:36 -0400
                Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 21:55 +1000
                  Re: Why did Quora choose Python for its development? Roy Smith <roy@panix.com> - 2011-05-25 08:25 -0400
                Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-25 10:23 -0400
                  Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-25 14:56 +0000
                    Re: Why did Quora choose Python for its development? Matty Sarro <msarro@gmail.com> - 2011-05-25 11:43 -0400
                Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-26 00:26 +1000
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:10 +0300
        Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-24 13:22 -0400
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 11:08 +0300
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-24 14:34 +1100
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 08:39 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 09:00 +0300
    Re: Why did Quora choose Python for its development? Stefan Behnel <stefan_ml@behnel.de> - 2011-05-24 08:23 +0200
      Re: Why did Quora choose Python for its development? Kevin Walzer <kw@codebykevin.com> - 2011-05-24 10:50 -0400
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:18 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 11:10 +0300
    Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-24 18:20 +1000
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-24 19:55 +1100
    Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-24 06:05 -0400
      Re: Why did Quora choose Python for its development? Teemu Likonen <tlikonen@iki.fi> - 2011-05-24 16:18 +0300
        Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 11:50 -0500
          Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 03:30 +1000
            Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 12:56 -0500
              Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 07:53 +1000
                Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 17:00 -0500
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:10 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:10 +0300
    Re: Why did Quora choose Python for its development? "thegist@nospam.net" <thegist@nospam.net> - 2011-05-26 11:52 -0400
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-27 08:33 +1100
      Re: Why did Quora choose Python for its development? RainyDay <andrei.avk@gmail.com> - 2011-05-26 16:41 -0700

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#5859 — Why did Quora choose Python for its development?

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

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

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

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

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

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

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

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

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

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


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

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

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

[toc] | [next] | [standalone]

#5882

On Fri, May 20, 2011 at 19:39, Beliavsky <beliavsky@aol.com> wrote:
> I thought this essay on why one startup chose Python was interesting.
>
> http://www.quora.com/Why-did-Quora-choose-Python-for-its-development
>
> PHP was out of the question. Facebook is stuck on that for legacy
> reasons, not because it's the best choice right now.[1] Our main
> takeaway from that experience is that programming language choice is
> very important and is extremely costly to change.
>
> Python was a language that Charlie and I both knew reasonably well
> (though I know it a lot better now than I did when we started). We
> also briefly considered C#, Java, and Scala. The biggest issues with
> Python are speed and the lack of typechecking.
>
> C# seemed pretty promising. As a programming language, it's great,
> but:
>
> •We didn't want to be on the Microsoft stack. We were up for learning
> something new, and MS SQL Server actually seemed pretty good, but we
> knew we'd need to integrate with lots of open source code that has
> only second-class support for .NET, if it supports it at all. Also,
> most of the best engineers these days are used to open source stuff.
> •We didn't want to take the risk of being on Mono (an open source
> implementation of C#/.NET). It's not clear how long funding will be
> around for that project, and I'd heard of various performance
> problems. Plus, it seemed like everything else in the C# ecosystem
> would assume we were on the Microsoft stack.
>
> For a lot of little reasons, Java programs end up being longer and
> more painful to write than the equivalent Python programs. It's also
> harder to interoperate with non-Java stuff. Scala had a lot of the
> downsides of Java and the JVM, although it wasn't quite as bad. The
> language seemed a little too new and like it would bring some
> unnecessary risk (for example, who knows how good will support be in
> 10 years).
>
> Two other languages we very briefly thought about were OCaml and
> Haskell (neither had big enough ecosystems or good enough standard
> libraries, and both were potentially too hard for some designers/data
> analysts/non-engineers who might need to write code).
>
> We decided that Python was fast enough for most of what we need to do
> (since we push our performance-critical code to backend servers
> written in C++ whenever possible). As far as typechecking, we ended up
> writing very thorough unit tests which are worth writing anyway, and
> achieve most of the same goals. We also had a lot of confidence that
> Python would continue to evolve in a direction that would be good for
> the life of our codebase, having watched it evolve over the last 5
> years.
>
> So far, we've been pretty happy with the choice. There's a small
> selection bias, but all of the employees who'd been working with other
> languages in the past have been happy to transition to Python,
> especially those coming from PHP. Since starting the following things
> have happened:
>
>
> •Python 2.6 got to the point where enough of the libraries we used
> were compatible with it, and we made a very easy transition to it.
> •Tornado (web framework) was released as open source, and we moved our
> live updating web service to that.
> •PyPy got to the point where it looks like it will eventually be
> usable and will give us a significant speedup.
>
> All together, these give us confidence that the language and ecosystem
> is moving in a good direction.
>
> [1] What are the horrors of PHP? and Do Facebook engineers enjoy
> programming in PHP? and Why hasn't Facebook migrated away from PHP?
> and What are some of the advantages of PHP over other programming
> languages? for more on that.
> Via Nizameddin Haşim Ordulu and JR Ignacio.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

They considered Haskell and OCaml and not a single mention of Perl?

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

[toc] | [prev] | [next] | [standalone]

#5954

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

+1 QOTW.

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

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#5967

From: "Hansmeet Singh" <hansmeetschool@gmail.com>

>i think we should end our butchering of perl on a light note (you may have
> already read this):
> EXTERIOR: DAGOBAH -- DAY
> With Yoda strapped to his back, Luke climbs up one of
> the many thick vines that grow in the swamp until he
> reaches the Dagobah statistics lab. Panting heavily, he
> continues his exercises -- grepping, installing new
> packages, logging in as root, and writing replacements for
> two-year-old shell scripts in Python.
> 
> YODA: Code!  Yes.  A programmer's strength flows from code
>      maintainability.  But beware of Perl.  Terse syntax... more
>      than one way to do it...  default variables.  The dark side
>      of code maintainability are they.  Easily they flow, quick
>      to join you when code you write.  If once you start down the
>      dark path, forever will it dominate your destiny, consume
>      you it will.
> 
> LUKE: Is Perl better than Python?
> 
> YODA: No... no... no.  Quicker, easier, more seductive.
> 
> LUKE: But how will I know why Python is better than Perl?
> 
> YODA: You will know.  When your code you try to read six months
>      from now.
> 


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

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

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

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

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

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

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

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

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

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

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

Octavian

[toc] | [prev] | [next] | [standalone]

#6065

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

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

[toc] | [prev] | [next] | [standalone]

#6067

Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#6115

From: "Ulrich Eckhardt" <ulrich.eckhardt@dominolaser.com>
> 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

[toc] | [prev] | [next] | [standalone]

#6138

On 5/22/11 3:44 AM, Octavian Rasnita 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.

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

[toc] | [prev] | [next] | [standalone]

#6140

On Wed, May 25, 2011 at 12:09 AM, Kevin Walzer <kw@codebykevin.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#6155

From: "Kevin Walzer" <kw@codebykevin.com>

> On 5/22/11 3:44 AM, Octavian Rasnita 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.
> 
> 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.


Exactly, this is why I said that it matters only the distributions used by the most users.

Octavian

[toc] | [prev] | [next] | [standalone]

#5969

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

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

[toc] | [prev] | [next] | [standalone]

#5972

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

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

[toc] | [prev] | [next] | [standalone]

#5999

On Sun, 22 May 2011 15:47:33 +0300, "Octavian Rasnita"
<orasnita@gmail.com> declaimed the following in
gmane.comp.python.general:

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

	FORTRAN, Pascal, and Ada don't require indentation either -- but
other than my first year F-IV class(1976 -- we were limited to Hollerith
cards, and checking out drums to add tabbing columns was too painful to
use), once access to the Hazeltine terminals was permitted we always
used indentation to illustrate the logic. 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).

	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...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#6012

On 5/22/2011 3:44 AM, Octavian Rasnita wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#6027

Terry Reedy <tjreedy@udel.edu> writes:

> 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

[toc] | [prev] | [next] | [standalone]

#6026

On Sun, May 22, 2011 at 11:47 PM, Octavian Rasnita <orasnita@gmail.com> wrote:
> From: "Daniel Kluev" <dan.kluev@gmail.com>
> I am talking about that flexibility which was criticized in the previous messages telling that this flexibility allows any programmer to use his own way.
> Perl doesn't force anyone to indent the code, don't force the programmer to define a hash element before using it, allow the programmer to interpret the variables in strings directly. These things should be not used always, but if in some cases if the programmer wants to use them, he can use them with no problems. And this means flexibility.

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

> First, this is a bad style of mapping urls, because this list must be maintained every time the programmer changes something in a controller that makes the app need to use other urls.

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

> The module DBIx::Class which is used usually as an ORM can create the class files for all the tables from a database (MySQL, Oracle, PostgreSQL, SQLite, MS SQL, etc), and it can be used to search using unions, sub-selects, can define views at ORM level, can accept to insert different types of objects like DateTime objects and can also return those type of objects, and many other things, and most of the things it can do can be done without using SQL code at all, but only standard Perl code and Perl data structures.

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

> HTML::FormFu form processor is one of the most used form processors in Catalyst applications and it can generate and parse forms created directly in the code of the application, or as external configuration files defined using JSON, or YAML, or Apache configuration style, or Perl data structures, or XML...
> The forms defined are very easy to create and the elements from those forms, for example the list of elements in a combo box can be taken directly from a database by specifying just a few configuration elements. The results of a form submit can be also inserted in a database using a connector with DBIx::Class without specifying any database table column name in the programming code, and for doing this are required just a few lines of code that checks if the $form->submitted_and_valid() and that does the redirection after the submit, the insertion in the database requiring just:

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

> Yes, for web apps I have seen more things which can be done much better in Perl, much easier and clear, with less code, and not because the programmer needs to do not-recommended tricks for shortening the code, but because there are very many modules on CPAN that do the hard work.

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

-- 
With best regards,
Daniel Kluev

[toc] | [prev] | [next] | [standalone]

#6038

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


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


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


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

Octavian

[toc] | [prev] | [next] | [standalone]

#6039

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

[toc] | [prev] | [next] | [standalone]

#6041

On Mon, May 23, 2011 at 3:31 PM, Octavian Rasnita <orasnita@gmail.com> wrote:
> From: "Dennis Lee Bieber" <wlfraed@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

[toc] | [prev] | [next] | [standalone]

#6077

Chris Angelico <rosuav@gmail.com> writes:

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


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

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.python

csiph-web