

Just why did people start using Python anyway? - prakash
http://ndanger.org/blog/2008/10/08/adopting-functional-programming-or-just-why-did-people-start-using-python-anyway/

======
olefoo
Because one of the major problems of writing code in collaboration with other
programmers is communicating the meaning of existing code. And python is one
of the few languages out there that had an explicit goal of being legible.

~~~
mdasen
I'd argue that Python goes beyond legibility of code since most of the Python
community seems to have settled on very similar coding standards. Not just
silly things like 4-space indents, but the way the code is written. It makes
it really easy to pick up foreign Python code.

The explicit over implicit here also helps. Yes, it is a pain when dealing
with only your code (why do I have to keep doing self.var_name when Java just
lets me say var_name), but when dealing with foreign code, it means you have
explicit scope.

I'd also argue that Python's import is just wonderful. Where many languages
like their secret-sauce methods, Python's explicit imports makes it incredibly
simple to find where a name is coming from. While Java has the convention of
import java.util.*, Python has the convention of from math import log - which
imports the name log into your file. So, you see log used in the file, you can
easily look at the import to see where it's coming from - and yes, it isn't
hard to imagine identical names in different libraries and you shouldn't need
to know that something with the same name is defined in two places that
usually aren't used together. Want the whole math library, just import math
and then use math.func() so that you still know where everything is coming
from!

For what it's worth, I think Python's syntax is a bit ugly, but it's standard!
Python code never looks that foreign and having foreign code look familiar to
you is just wonderful. It might not matter when you have your 1-person
project, but when dealing with the code of other's, it's wonderful.

~~~
silentbicycle
_It makes it really easy to pick up foreign Python code._

You really can't overestimate how big a deal this is.

------
SirWart
Python is simple, easy to read, and has been around and active since 1991.
Because of that, it also benefits from being a very stable, fast platform (for
an interpreted language), and has a huge standard library
(<http://docs.python.org/modindex.html>). If it's not in the standard library,
you can probably find it somewhere. A "killer app" is a paradigm that computer
people have been using since visicalc, but I'm not sure it applies to every
situation.

------
baha_man
"Haskell... even has an Emacs mode."

Is there a programming language which _doesn't_ have an Emacs mode?

~~~
silentbicycle
I don't think there are major modes for brainfuck or unlambda.

I thought about writing one, but then came to my senses.

~~~
razzmataz
if you are writing brainfuck code, I doubt you are going to use emacs as your
environment. More likely ed or cat...

~~~
silentbicycle
I know, it was a joke.

I wrote an ed mode for Emacs once, though...

------
ii
No killer apps? What about this <http://www.python.org/about/quotes/> ?

------
gopher
Because other people used it, composed good code and even others adopted it.
This resulted in a high-profile Python scene and good code. I think that many
new ideas were contributed and it was fun to share ideas. This resulted in a
rapid development of toolkits, frameworks and software. If you wanted to be
part of this, you had to use Python.

But I think it is the same with JavaScript, Ruby, FreeBSD, PosgreSQL and many
more hip foobars; In contrast, Java, PHP, many (not all) Microsoft products,
Linux (partly) allured so many bad coders that it is simply boring to work
through their code.

------
jcl
The article is mistitled. The question it actually poses is: "Why isn't
Haskell as popular as Python yet?"

While I dearly love Python, I don't know enough about Haskell to adequately
answer this. The article makes it sound like Haskell is doing all the same
right things as Python -- although this apparently isn't paying off yet, so
the article must be overlooking some factors.

------
silentbicycle
I tried Python out right when I was getting incredibly frustrated with a Perl
program that had grown too large for its own good. Python seemed so much
cleaner that I switched _immediately_. Its standard library is quite nice,
though not quite as large as CPAN.

Ironically, I may be switching from Python to Lua now, for the same reason.

~~~
nuclear_eclipse
In all seriousness, the only reason I use Python over Lua is for the library.
Lua is far more flexible and extensible, but it has a very sore lack of
standard libraries like you can find with Python. But I keep my fingers
crossed, and continue to use Lua as an interpreter inside my C apps, where the
lack of libraries is a non-issue because everything I need to use is a custom
API exported from C.

~~~
silentbicycle
> but it has a very sore lack of standard libraries like you can find with
> Python

Agreed. I find it quite a bit more elegant overall, and I decided to just jump
in and do my throwaway scripts in Lua and see how much of a difference that
makes. If I like it enough to write a few small libraries along the way,
everybody wins.

Lua has tail-call elimination, coroutines, closures, and lambdas. I'm pretty
sure Python has none of these, except for (possibly) a limited form of
coroutines. (The Python lambda is too crippled, its closures are broken.) Lua
is also one of the most deliberately portable languages I've seen, too. I have
a hunch it would be a great language for bootstrapping a Lisp or Scheme
compiler, though I haven't tried this yet.

~~~
eru
Python closures work well. (The lambda is syntactically crippled.)

~~~
silentbicycle

       >>> def makeAdder(x):
       	def inc(y):
       		return y+x
       	return inc
       
       >>> f = makeAdder(3)
       >>> f(4)
       7
    

So far, so good.

    
    
       >>> def makeAdder2(x):
       	v = x
       	def inc(y):
       		v += y
       		return v
       	return inc
       
       >>> f2 = makeAdder2(3)
       >>> f2(4)
       
       Traceback (most recent call last):
         File "<pyshell#15>", line 1, in <module>
           f2(4)
         File "<pyshell#13>", line 4, in inc
           v += y
       UnboundLocalError: local variable 'v' referenced before assignment
       >>>
    

It looks like you can't mutate variables in a closure. Am I doing it wrong? If
you really can't, that seriously limits their power.

\--

In Lua:

    
    
      > function adder(x)
          local v = x
          function inc(y)
              v = v + y
              return v
              end
          return inc
          end
      >> >> >> >> >> >> >> > f = adder(3)
      > =f(4)
      7
      > =f(4)
      11
      > =f(4)
      15
      >
    

Works fine. (Also, the syntax is really clean.)

~~~
EliAndrewC
Python 3.0 fixes this with the nonlocal statement. However, you are correct
that this doesn't work in Python 2.5 and earlier.

~~~
silentbicycle
Ok, thanks.

------
tricky
I found Stackless Python while trying to throw together an idea for a
massively parallel algorithm... worked beautifully and led me to django.
Python's simplicity made me feel like I could hit the ground running, but I'd
say the frameworks got me hooked.

------
davidw
I started using Python in 1999, because I was tired of Perl's weirdness and
looking for something new. I don't use it much these days, but still have a
lot of respect for it.

~~~
prakash
what do you use these days?

~~~
davidw
I got more involved with Tcl over time ( <http://tcl.apache.org/> and some
other stuff) and over the past couple of years have been moving towards Ruby
for most of my scripting/web needs.

~~~
hugh
Wait, you couldn't stand the weirdness of perl, but you like Tcl?

All I can remember about Tcl from my months of using it is the ugly, ugly
loops:

    
    
      for {set i 1} { $i <= 100 } { incr i } {
       puts "Well, that wasn't ugly syntax!"
      }
    

Incidentally, Fortran, for all its other ugliness, has the best for loop I
know:

    
    
      do i = 1, 100
       write(*,*) "Hooray, Fortran!"
      enddo

~~~
nuclear_eclipse
> Incidentally, Fortran, for all its other ugliness, has the best for loop I
> know:

How is that better than Python?

    
    
        for i in range( 1, 100 ):
            print "Python!"

~~~
abstractbill
That's not a good idiom, because it only allows you to loop over small ranges:

    
    
      >>> for i in range(1000000000):
      ...     print i
      ... 
      python2.4(1261) malloc: *** vm_allocate(size=4000002048) failed (error code=3)
      python2.4(1261) malloc: *** error: can't allocate region
      python2.4(1261) malloc: *** set a breakpoint in szone_error to debug
      Traceback (most recent call last):
        File "<stdin>", line 1, in ?
      MemoryError
    

Why attempt to allocate such a large list when you just want to do something
several times?

~~~
oofoe
for i in xrange(1000000000): print i

xrange() addresses the problem you describe and has been in Python since,
like, forever. However, range() is nicer for learning the language, since it's
easy to see how it composes into a list.

~~~
abstractbill
Yes, I know. It's just bad that people are taught one way of iterating, and
then may or may not learn the right way at some later time.

