Why did Quora choose Python for its development?

[Teemu Likonen]

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.

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

 

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

Beliavsky, 20.05.2011 18:39:

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

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.

--Kevin

 

[Octavian Rasnita]

Once again. Suppose we have array of key-value pairs (two-dimensional
array),

This is a forced example to fit the way Python can do it with a clean syntax, but I don't think there are cases in which somebody wants to create hashes/dictionaries where the key is not a plain string but an array.

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

Octavian

 

[Octavian Rasnita]

So, again, in Perl is just:

%d = @l;

Please tell me if Python has a syntax which is more clear than this for
doing this thing.

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

The Perl programmers usually don't need to look in the dictionary when they are creating programs.
Perl is harder to learn, but it is easier to use.

Are Perl programmers aware of some imminent worldwide shortage of
electrons that Python programmers are not? Why is there this obsession
with shortness?

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

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

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

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

Octavian

 

[Octavian Rasnita]

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]

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

 

[Octavian Rasnita]

Subject: Re: Why did Quora choose Python for its development?

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.

--Kevin

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

 

[John Bokma]

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]

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]

If you didn't consider to change the language you prefer it means
that you are closed minded and use to fell in love with the tools you

Now you are just bordering on rudeness. I never made any disparaging
remarks about you. I only talked about a tool that you seem to like
and I don't. In fact, I did consider and investigate Perl many years
ago along with may other languages before I settled on Python. I
didn't like it then and I don't like it now. However, I have never
called someone "close minded" for preferring a different tool to me.

Don't make me tell here how many things I don't like in Perl.

Trust me, there is no need.

I use to tell those things on Perl mailing lists and make upset their

Good for you. I also have talked about things in Python that I don't
like on this list. No one has ever accused me of being afraid to speak
my mind. That facet of my personality has got me in a lot of trouble
in my life from parents, teachers, bosses and I have even been known to
speak out against the police while they were holding automatic rifles to
my head. I doubt that there will ever be enough peer pressure on a
mailing list to trump that.

Similarly, if you don't like something in Perl, why don't you tell
them what you don't like to the Perl programmers community and not just
have the guts to tell that in a group where the majority share your
preferences.

Because I am not a missionary. Someone came to my house and told me
why their way was better so I spoke up. Same thing when the JW come to
my front door but I have no interest in going to their Kingdom Hall to
tell them why they are wrong.

I came here on the list to find good things about Python and to learn
some things and use its good parts, and not to hear bashing about other
programming languages.

Same here but someone (I don't even know who started it) felt that it
was necessary to tell us all why their language was better.

 

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

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]

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]

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.

 

[Chris Angelico]

To me, and to a lot of Perl programmers it's not different.


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]

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
significant error based on the way the variable is named.  It's like
the old Fortran IV that I first learned where the name of the variable
determined whether it was an integer or a floating point.

I believe that's the origin of one of the proofs that God is real
(unless declared integer). And hey, I can't hate something that gave
us the classic use of i, j, k as loop indices!

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

Yes, I believe that was Perl. And an amusing quote. But most of the
point of it comes from the fact that Perl uses punctuation for most of
its keywords, whereas (say) Python uses English words; it's a lot more
fun to crunch something down when you can use $| and friends than when
you have to put "x and y", complete with spaces, for a simple boolean.
But that says nothing about which language is actually better for
working with... beyond the fact that Perl can get more mileage out of
an 80-character line!

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

When I first looked at assembly language it looked like random junk
left behind in memory. When I first looked at COBOL it looked like ...
COBOL. Doesn't make either of them better or worse.

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

Chris Angelico

 

[John Bokma]

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!


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