13 ms·

Why Python is Important for You

391 points by zzzeek 15y ago

deleted 15y ago
[deleted]
ak217 15y ago
I like to call this cognitive compatibility - the amount of effort required from an uninitiated English-speaking observer to understand what a program does. Most people who are deeply familiar with a language will have a tendency to discount this effort, but really it is essential because it minimizes the translation layer that your brain has to use any time you read code. Python encourages code which is readable in English and reasonably brief. Having readability, consistency, and the "principle of least surprise" as primary language and community principles ultimately saves developers time and makes them more efficient. And the maturing of PyPy is incredibly exciting.
- iandanforth 15y ago
  I could not agree more with this comment and just wanted to thank you for expressing this so clearly.
- andolanra 15y ago
  I want to make what I think is an important qualification which conflicts with a reading of your comment: Python is readable to people who are familiar with conventional Algol-based programming, i.e. every modern programmer. That does not make it readable to an arbitrary English-speaker, which is an assertion I sometimes hear: "Oh, Python is so much like English, people who aren't even programmers can read some of it!" Which I can say from experience is not the case in the slightest. If it were, my job—which involves teaching Python to non-programmers—would be inestimably easier. Python is simple and easy because it takes everything you know from other languages and systems and makes those things simple and easy and pleasant to do. I've even seen Python used as a kind of runnable pseudocode for projects that would eventually be written in other object-oriented Algol-based imperative languages, which is a testament to how well it distills those concepts down and makes programming simple. But it is not "readable in English." It is readable in pseudo-Algol.
  - tsunamifury 15y ago
    Thankyou! So many programmers seem to forget they have an enormous base of syntax and logic which is not at all like natural language. They see python and say, oh wow this is so easy to read, just like English! But its only an easier way to express a syntax that really is nothing like what a nonprogrammer would consider English.
    - shazow 15y ago
      It varies. When I was helping @limedaring learn Python, I'd read source with her and explain what it does. Quite often I'd feel somewhat embarrassed when explaining what a line does by verbatim reading what it says. "for user in users: ..." "if user.is_admin: ..." It was especially nice that the topic of "what code block does this condition apply to?" did not even occur to either of us. The indentation-based blocks made it completely organic. (Try explaining Bash to someone and when to use do/done, if/else/fi, case/esac.) But sure, things get weird with decorators and generators and other advanced features.
      - loxs 15y ago
        IMHO, decorators, although very useful are a big departure away from python's "simplicity" in syntax. I remember having lots of headaches several years ago wile trying to fit it in my brain. Even after I realized it is something as simple as JavaScript's myfun(fun(){}), my brain somehow continued denying to absorb it.
        dcosson 15y ago
        Agreed that they can be tricky initially and hard to debug, but I think they're totally worth it for eliminating repetitive code. And IMO as long as there isn't a bug in the decorator itself, code with decorators can be just as readable (if not more so) to someone else (e.g. decorating your functions with @authenticated instead of if self.user.is_authenticated: # blah, blah blah)
        15y ago
- luriel 15y ago
  Python code is superficially easy to read, but to know what a piece of code really does can be extremely hard, specially when metaclassed, generators and the like are involved. Also there is plenty of Python code that is not particularly readable even superficially, particularly convoluted uses of list comprehension come to mind. And I don't think 'consistency' is one of python's main qualities, when even in the stdlib there are plenty of very different naming styles. (Yes, this is improving in Python 3, but has been a big issue for a very long time.)
  - aangjie 15y ago
    +1 for the metaclasses example... list comprehension doesn't seem that big a deal, but then am biased way too much.. Also agree with consistency part.... but personally python is beginning to lose some of it's charm with the move towards consistency...
- thehotelambush 15y ago
  This is the kind of reasoning that lies behind LFMs: that it is better to cater to someone who knows nothing about the language (but maybe has a few mainstream languages under their belt already) than to someone who has put in the work to understand it. I'd rather pay to learn a difficult but more abstract language feature just one time, than pay all the time for its absence.
- Too 15y ago
  A programming language being similar to spoken english isn't necessarily a good thing. SQL being a prime example of this.
jtchang 15y ago
I work with python daily. I find that when I first started I avoid a lot of the "fancy" constructs such as list comprehensions, dynamic arguments, and decorators as well as meta programming. The great thing is the bar to being effective in the language is so low. You can pretty much pick up most python code and just read it and get a general feel for what it does. Not only that but it is much easier to read because of whitespace delimiting. I can generally tell the quality of a python program but how nicely indented it is. If there are lots of indents like 5 or 6 levels deep I know something is wrong. For a newbie if your code is hard to understand and it is in Python you are writing it wrong.
- Luyt 15y ago
  I find a great way to avoid deep nesting is to move code to functions, and bail out when some conditions are not met. As an example, this deeply nested code: def frob(someargs): if something > 2: ... # do some processing if that == "CONNECT": ... # some more processing if verdict in blessedsolutions: ... # even more processing print "Happy birthday!" I tend to write like this: def frob(someargs): if something <= 2: return # Not our concern. ... # do some processing if that != "CONNECT": return # Not handled here. ... # some more processing if verdict not in blessedsolutions: return ... # even more processing print "Happy birthday!" I do the same thing in loops, using 'continue'. The above second example looks rather flat, but in practice the 'do some processing' statements often need identations due to conditions and loops. I added the processing to demonstrate that it's not always possible to combine conditions. And, of course this way of 'bailing out early' vs. 'nested ifs and processing' is not Python specific. The dogma that a function should have only one exit point (as proposed by 'structured programming' adepts and Pascal afficionados) often leads to deeply nested control structures and convoluted testing. Brian Kernighan has written a paper on this[1]. [1] http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.html http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.htm...
  - rmcclellan 15y ago
    Neither solution is great. Excessive use of return and continue is an incredibly fast way of making code completely incomprehensible. Such complicated control flows should be treated as a major, fundamental problem. Keeping them in place will cause bugs and prevent future contributors from having confidence that their changes are correct. The problem of complicated control flow is too deep to be solved with a band-aid like this, although perhaps syntactically it looks a bit nicer. In fact, this is exactly what people did before the so-called "structured programming adepts" came around, except using gotos instead of continues. It didn't work so well back then, and it doesn't work so well now.
keypusher 15y ago
See also: http://xkcd.com/353/ http://xkcd.com/353/
yason 15y ago
It's important because it reminds me I should keep looking. I should keep looking instead of turning it into my Blub. I love Python but its boundaries have been hitting me frequently for years. There probably never will be a total sweet spot between functionality, syntax, compatibility, support, and platform-crossing but I know I have to keep looking for a language that's more sophisticated yet more practical.
- deleted 15y ago
  [deleted]
DodgyEggplant 15y ago
True. The real magic: The basic constructs are so simple, so how the output is so robust? And picking old or library code is always easy!
wging 15y ago
As a commenter on the article wrote: what about Ruby? I say this as a happy Python user. Ruby seems very similar but I'm reminded of a pg essay on language power: looking up the power curve, you see '$Language plus a bit of weird stuff that is probably irrelevant.' So I don't trust myself. As someone who loves Python and doesn't know any Ruby beyond a few bits of syntax and the obvious bits that are common to most languages, what am I missing?
- Game_Ender 15y ago
  In my opinion Ruby has a slightly more obscure syntax with custom symbols, and it's C API is not as clean and well put together as Python's.
  - 16s 15y ago
    Which is more obscure? Reverse a string in ruby: string.reverse() Reverse a string in python: string[::-1]
    - evincarofautumn 15y ago
      Slice syntax in Python always bothered me. This would be slightly more readable: ''.join(reversed(string)) Except it requires you to have an idea of how iteration works (beginners don’t) and why that “join” needs to be there, and it’s still an order of magnitude slower. But hey. Ruby is prettier in some ways, Python in others, and beggars, as they say, can’t be choosers.
      - 16s 15y ago
        Way way slower than the slicing.
    - TylerE 15y ago
      What an odd example. Other than perhaps a palindrome detector, I'm having a really hard time coming up with a use for a reversed-strings. Python DOES provide a reverse for arrays.
khyryk 15y ago
I like Python the language, but the standard library can often annoy me as there is no unified style. thereAreMethodsLikeThis or_there_are_methods_like_this orevenworsefullylowercase. Gah.
- ndefinite 15y ago
  PEP 8 covers this: http://www.python.org/dev/peps/pep-0008/ http://www.python.org/dev/peps/pep-0008/
- cbs 15y ago
  Thats a thing where the standardization came after those libraries. It doesn't get to me that much, but I have a coworker it does bother a fair bit. I poke fun at him for this, but what he does is just take 15 minutes and write a "proxy" module (I think he was actually able to automate it...). If `baz.fooBar` is bugging him, he'll just create a `mybaz` module where mybaz.foo_bar either calls or is just a new name for baz.fooBar and then he just does an `import mybaz as baz`.
- hcarvalhoalves 15y ago
  My biggest gripe too. Hopefully stdlib got more love lately on Python 3.
keypusher 15y ago
I do love Python, but I often wish there was more rigor for some things. I currently work on a large project (>500K LOC) and have started to see it fall apart with a bigger team. Lack of enforced typing in function arguments, inability to create strict interfaces, inconsistency in standard library conventions, and package management would probably be my biggest gripes.
- underwater 15y ago
  I've seen projects that use decorators for type checking. You could turn it into a noop for production.
- bugsbunnyak 15y ago
  Curious: what is this 500k LOC project (if you can say) and how much of that is Python? If it's an in-house codebase that's a really neat datapoint because it would rank among the largest open-source Python projects.. Also, Traits (from Enthought) is an attempt to deal with some of the issues of typing and interfaces. It's led to some great software (the Chaco plotting package is fantastic, as is Mayavi), but I've yet to figure out how to debug a Traits error and stay sane. There is a lot of auto-configured magic that happens, and when something goes wrong the backtrace is often pages long and doesn't actually show the offending line.
  - keypusher 15y ago
    Project is automated testing for an enterprise private cloud platform. 500K of tests and test library is all python, the application itself is probably 2M+ LOC, Java + C running on Linux.
- cdavid 15y ago
  On most projects I have seen where python was seen as problematic, I think that having types ala C++/Java would not have improved much. The real problem is that the function is not documented, nor is the function expectations. Typing in C++/java does not replace that (more advanced typing systems do much better, though). Package management and generally deployment is certainly a pain in python. I think it is one of the main issue in typical "corporate environments"
tete 15y ago
I am kinda afraid of getting down voted, but I have used Python and I feel like I get all this and more (CPAN) when using Perl. The major difference in my opinion is that Perl gives you even more freedoms, which causes you to need some self discipline, but you get stuff done even quicker that way. It feels a bit like Python is better for programming beginners or people that tend to be too lazy sometimes and Perl is for people who want to be able to be lazier since they know what they are doing. Also, I think Python (and most other language projects) should clone CPAN (including CPAN testers). Seriously it's a major deficit. I also think Python is the easiest to grasp for people coming from static languages. Perl and Ruby are way harder.
- mekoka 15y ago
  Like the author said, you’ll spend a lot more time reading code than writing it, and [python] focuses on guiding developers to write readable code. As someone who reads a reasonable amount of source, I'm grateful for that.
- achompas 15y ago
  It feels a bit like Python is better for programming beginners or people that tend to be too lazy sometimes and Perl is for people who want to be able to be lazier since they know what they are doing. I'm sorry, I don't understand this at all. What does this mean? Also, I think Python (and most other language projects) should clone CPAN (including CPAN testers). Seriously it's a major deficit. The Python Package Index (http://pypi.python.org/pypi http://pypi.python.org/pypi) is no CPAN, but I've never had a problem with it.
- to3m 15y ago
  The point about static languages is definitely well-made. Python's two key aspects are its lack of dynamism, its structural rigidity, and... oh, THREE key aspects!, because I forgot its famously rigorous static type-checking system. Coming from a C/C++ background myself, I found this very reassuring. I don't like languages that keep you constantly on your toes due to providing insufficient structure and too much dangerous freedom and flexibility.
- aangjie 15y ago
espeed 15y ago
Python doesn't have the glyph noise that brace-based languages do, and well-written Python is beautiful and easy to read. But lately I have been having an internal debate on whether using autodoc and inline docstrings detracts from its beauty and makes it harder to read because it reduces the amount of code you can see on the screen (see Steve Yegge's rant on this http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm... from a few years back). If you use Sphinx to document a method's description, params, param types, and return type, then it can easily turn a three-line method into a 12 line method, and then you can only see ~5 methods on the screen at a time. So if the code is already readable, would it not be better to put the docstring comments in an external file to keep the code density? Django does this, and I'm starting to think it's the right balance.
- mekoka 15y ago
  Docstrings should already be easy to detect by editors, so it would be trivial to add a show/hide functionality. Incidentally, one could also use Sphinx to create a plugin for that.
  - odiroot 15y ago
    I just noticed Sublime Text 2 has an ability to fold multiline docstrings. If there only was a way to do this automatically.
  - espeed 15y ago
    But not all editors have this, nor is it widely used in editors like Emacs. And GitHub doesn't have it so it can make it harder to get a big-picture view and see the structure of a module when evaluating different libraries online.
- abecedarius 15y ago
  I generally write docstrings like "Return the n-fold frobulation around the center (x,y)." That's one line that way and about a half dozen in Javadoc style, without the latter adding much to pay its freight. What would be worth putting inline but with auto-folding, to me, would be examples.
agentgt 15y ago
I have used Python for a rather long time (I think 1997 when I was 17 was when I first used it). As the the writer of the article stated Python is awesome for writing "tools" and throughout my career I have used it for such. However I have used Python also for big projects and that is where its gets a little messy. I know I am going to get down-voted to kingdom come but I think Java is a better language for big projects mostly because of the static typing (try renaming a class in Python compared to Java). Modern Java is for sure more verbose than Python and more complicated but the languages are extremely similar (Guido has even take some of the design consistency from Java for Python 3.0). The reason I bring it up is Java is very often in various circles crapped on to no end. The reality its basically just more verbose Python. Not to mention Java offers an introduction to Parametric/algebraic typing (generics) and more sophisticated concurrency (futures ... yes actors are better but python really has neither).
- tikhonj 15y ago
  In my mind--probably not the majority opinion, but so be it--it's really the opposite: Python is a dynamically typed Java. So it's not that Java has been underrated but rather that Python has been overrated. I do not like working with either. Also, I'm not quite sure what generics have to do with algebraic types.
- Peaker 15y ago
  Just replace Java with Haskell, and you've got yourself a nicer Python replacement. Less code than either Java or Python, far more compile-time guarantees than either, and nearly as fast as Java when speed matters (speed takes a bit more effort in Haskell than in Java, but compared to Python, it is a no-brainer).
user0398 15y ago
Mostly true 'cept for pythons built in pasta makers: http://www.python.org/dev/peps/pep-0318/ http://www.python.org/dev/peps/pep-0318/
- Luyt 15y ago
  Yeah, that's fun ;-) I wish there was a if main: ... # do some processing instead of having to write: if __name__ == "__main__": ... # do some processing That'd make DHH happy, too ;-)
  - anthonyb 15y ago
    I find that the best way to fix this is to write your program as a library, then the part that you're supposed to run as a script which imports and runs it. No __underscore__magic__ required.
- olefoo 15y ago
  Decorators can be misused, but they can also succinctly express an aspect of the program that is repeated many times in different contexts. My own rule is that a decorator should do one thing, and that thing should be described by it's name. Being able to look at a method that has the @has_permission decorator on it and know that it is getting checked for against a package wide permission model is more clear than having boilerplate to check permissions on every method that needs that check. Any language construct can be misused. And people can hide stupid things in decorators and name them in misleading ways. That doesn't mean that it's the fault of the syntax.
pranjalv123 15y ago
My biggest problem with Python is that projects larger than a given size tend to become unmaintainable rather quickly. This is in large part because of the lack of strong typing and type annotations; if you aren't the only author or can't keep the codebase in your head, it takes real effort to figure out what a function does. Even the type annotations provided in a language like Java or C++ make this task much easier, not to mention languages with real strong type systems like Haskell. That's not to say that building large systems in Python is impossible, but it takes a lot more effort and documentation that it would in other languages.
- agentgt 15y ago
  I agree and I was worried I was the only who would say it :)
- mef 15y ago
  Yup. This is also the case with Ruby, and is one of the challenges when trying to dive in to a large unfamiliar project. For example, when something in Rails doesn't behave correctly and you flip deep into a source file, it's not always easy to track down exactly what kind of arguments a method expects. Often you'll have to breakpoint inside the method just to inspect what's around.
- niels 15y ago
  Just to be clear, Python is strongly typed but not statically typed. But I definitively agree with your comment. The startup I'm working for is Python based, but I'm currently learning Haskell, because I'd like to take advantage of a good type system for my larger efforts.
  - lelele 15y ago
    Aren't you concerned about unpredictable memory requirements?
    - niels 15y ago
      To be honest I don't have enough experience with lazily evaluated languages to be concerned about it yet.
Peaker 15y ago
"Weirder languages (e.g: Haskell)" sounds like something a Blub programmer would say. How is Haskell "weird"? I've used Python for many years, but only recently have I migrated my last Python niche (simple scripts) from Python to Haskell. I've found that even there, Haskell has become more productive.
- masklinn 15y ago
  > How is Haskell "weird"? Functional the world (of wide-spread computing languages) is imperative, lazy the world is eager, objects-less when the world is object-oriented, curried when the world is uncurried, pattern-matched when the world is conditional and brings up "strange" concepts from mathematical bowels like "monads", "functors" or "zippers" when the world barely iterates on arrays. How is Haskell not weird from the point of view of 99% of the developers population? Knowing, liking or using Haskell is not even relevant there, Haskell is weird because it is an alien to the majority in the same way Smalltalk, Erlang or Clojure are weird (but for different reasons, for the most part).
  - Peaker 15y ago
    I understand "different". Not "weird".
    - masklinn 15y ago
      They reify to the same thing, something different looks weird, and something weird is different.
    - njharman 15y ago
      You seem to be attaching a non-existent negative connotation to weird. Weird means different. Weird is "more" different.
  - deleted 15y ago
    [deleted]
  - whateverer 15y ago
    The world is mostly parallel and asynchronous, yet most languages are sequential and synchronous. And the object-orientedness claim is overstated, as you drink from a cup, rather than use rather than think it in terms of cup.spill(), signals propagate, but 'return' is nowhere to be found... unless of course you are just talking about programming, but that's a bit of a circular argument.
kevinburke 15y ago
When I was at Google there was a paper titled "Please don't use Python for large programs." Can someone post that? It would be an interesting counterpoint.
- nostrademons 15y ago
  I don't think it's public. In any case, its argument basically boiled down to "Python doesn't have static types, without static types it's too hard to communicate API information between programmers, Google has thousands of programmers that need to communicate, so please don't use Python."
- sunqiang 15y ago
  what type of paper, Google's coding policy? there is a mail-list post, https://groups.google.com/forum/?fromgroups#!topic/unladen-swallow/TtvEBvVEZD4 https://groups.google.com/forum/?fromgroups#!topic/unladen-s...
- olalonde 15y ago
  What language do they recommend for large programs?
  - sunqiang 15y ago
    don't know for sure, it might be C++, Java, and now they have Go.
pnathan 15y ago
I have a list I wrote up once about Python's problems. Some of these are more exotic than others. Most of them are kludgearoundable. A couple are fixed in Python 3. Some are simply design choices that are exactly different from my mental model of the world, and due to the TOOWTDI Python world, it is frustrating to work with them. Some Things Wrong With Python * Immutable strings[0] * Everything a reference[1] * Environment copied on loop entrance (implying assignments often break when done in loops) * Lack of braces[2] * Lack of enums[3] * Standard debugger pdb reminds me of the first debuggers ( used on the PDP-1 and EDSAC) in its feature list. * Exception-oriented design, which clutters code with "try/catches" everywhere. * Exceptions aren't just exceptions, they are also overloaded to provide signals. * Two forms of objects (old style vs. new-style) * Object inheritance is pointer to parent. Metaprogramming becomes an exercise in hackery. * Objects are actually dictionaries with some pointers behind the scenes. * Duck typing will automagically cast certain things[4] * As an interpreted language, code that is not tested can be assumed to be syntactically correct but in error (this is a horrible problem when testing for rare error conditions)[4.5] * When Python is fast, it's because it's calling out to C. * Python objects are gigantic. An empty string is 40 bytes, for example. This adds up. * Python can not meaningfully multithread, due to the global interpreter lock. * Python suffers from many different versions being installed on different versions of Linux[5] * Lambdas are totally broken[6] * Large-scale module importing is a half-baked job[7] * Python 3 routes around some these issues by using generators for everything[8]. [0] Ever try to step through a string and modify it in-memory? Well, you can't. Sorry. ;-) [1] I.e., a function can modify something unexpectedly. [2] Which means block commenting or commenting out tops of loops means a complete reindenting of the block, that is, editors can't do the smart thing, they don't have enough context. This is a waste of the engineer's time. Delimiters were figured out in Lisp, a very long time ago. [3] This was figured out long ago as well. [4] But not others. Object design is a bit funky. [4.5] This is a general design 'con' in dynamic languages. It's partially solvable with a sufficiently smart compiler, most compilers aren't that smart. [5] This is why serious Python programs (that don't come bundled with their own version of Python) are written to target Python 2.4, released in 2004. [6] A 'lambda' function in Python can not have statements. Most interesting functions have statements. [7] Python (similar to Java) relies on a very specific directory structure for a given program to be able to import libraries. This means that if you are doing anything remotely exotic with layouts (e.g., libraries are in a peer directory, not a child directory), you have to commit hackery. [8]This avoids the fact that the end result has to be emitted in some fashion.
a_a_r_o_n 15y ago
Executable whiteboard.
sdfjkl 15y ago
Many years ago I've decided it was time to pick up a modern programming language. In the past I had written lots of (Turbo) Pascal code, some x86 (and more exotic) Assembler and a bit of C, but then for several years I only did shell/awk scripts and ported C software to IRIX and SINIX/RU. So I sat down and decided to find a nice general-purpose language that I would focus on learning. I wasn't quite sure what for yet, but I decided I was going to pick one and stick with it. I didn't have the time to learn multiple languages and I didn't have a lot of time to try out different ones, so I just looked around a little bit. Some I ruled out early: C and it's relatives were just too verbose, I didn't want to spend the time writing all the error handling necessary just to read a damn file. I was doing a lot of sysadmin type work at the time and had therefore developed an intense disliking for Java. This was based on too much badly packaged Java software that even if you got it running at all was sluggish, hogging way too much memory and crashed with arcane error messages. I did like the quick & dirty way I could make things work in a shell script, so I looked mostly at scripting languages. I looked at Perl, which was the standard scripting language at the time and had a huge library (CPAN) of modules, which was great. I hated the syntax though and found the code often unreadable and there being too many ways of doing the same thing. I looked at Pike, which had the benefit of using a C syntax (which I already knew, so that was a plus), but it seemed not widely supported and nobody was using it (this hasn't changed since, it seems). I don't remember what else I looked at, but then there was Python. The syntax was a revelation. Here someone had finally made the most of creating a language from scratch and spent the time thinking about syntax and how to do away with largely pointless stuff (brackets), replacing it with things that everyone did anyways (indentation). It also came with a sizeable library of stuff that did almost everything I could dream of at the time. It was love at first sight. Recently I've spent £35 on a stainless steel mill that grinds salt when you twist it one way and pepper when you twist it the other way, just because I really love well thought out and engineered things that make stuff that's been around forever just a little bit better. That's how I feel about Python. It's not doing anything fantastically new or unique, but it's doing the stuff that others do just a little bit better. Today I'm doing lots of web stuff, some sysadmin stuff and random hacking of various things on the side. I'm still doing almost everything in Python and whenever Javascript bitches at me about a missed semicolon I do think: "All these fantastic things you can do in a web browser these days and you couldn't figure out that this command in an entirely different line isn't part of the previous line?". The only thing that I can't do in Python is write software for my iPhone, which bugs me a bit. But every time I try to get into Objective C I just get annoyed by the syntax and amount of cruft I have to write to do anything.
igorgue 15y ago
Haskell is not weird.
danbmil99 15y ago
Python is great in every way except one -- it isn't Javascript. (to clarify: I'm not saying JS is a superior language. I'm just saying it's going to win out in the end because of the history of its implementation. There is a serious benefit to having one language everywhere, and JS is the only viable candidate because of the investment in client-side sandboxing and performance -- two features which turn out to matter almost as much on the server as well.)
- alextgordon 15y ago
  I wasn't aware that Python and JavaScript were in competition. Or for that matter, that JS is by any stretch of the imagination "invested in performance". People don't use Python because of its merits as a programming language. They use it because of the excellent standard library, Scipy, Sage, etc. While it may be that in a decade JavaScript has built an ecosystem to match, I frankly don't see why anybody would bother. We already have Python, why would we invest such effort into a less suitable language? JavaScript is tolerated by web developers, because they're forced to use it on the client, and so there's a benefit to also using it on the server to prevent duplication of effort. But there is absolutely no reason why non-web developers would or will ever use it outside of that niche.
  - danbmil99 15y ago
    > non-web developers Sorry, not sure what that means </sarcasm> OK maybe not everything will be a web app, but pretty much everything that isn't some deep driver-level boot code or embedded firmware is already almost always part of some sort of web app, and the stuff that isn't is pretty much all written in C/C++. When is the last time you wrote a Python program that didn't interact over TCP or equivalent with some other process? And how often was that other process not something at least nominally webby?
    - alextgordon 15y ago
      > When is the last time you wrote a Python program that > didn't interact over TCP or equivalent with some other > process? My last python program was a set of scripts to help me analyze music harmony. Entirely CLI based. Before that? objcfix - a refactoring tool. Again, CLI based. That's not counting the multitude of small scripts I write on a day to day basis. I've written a large amount of Python code, and very little of it interacts with a network. Put it this way: Python was invented in 1991, the same time as the web. It didn't become a good tool for making websites until after 2005 when Django arrived. So, what did people do with it before then, if not make websites? > but pretty much everything that isn't some deep driver- > level boot code or embedded firmware is already almost > always part of some sort of web app, and the stuff that > isn't is pretty much all written in C/C++. This is not the reality we live in. There's: * Games (either written in C++, Objective-C or Java nowadays, plus a bit of Lua) * Big Software: MS Office, Photoshop, Avid, Logic, InDesign, etc. Written in C++ * Scientific Computing: Written in C++, Matlab, Mathematica, Python * Financial Computing: C, C++, Java, and a tiny spot of OCaml. * iPhone/Android Apps: again, Objective-C or Java. * "Enterprise Software", whatever that is. Java. And as you point out, embedded software. Everything around us runs Embedded C. The future is the same as the present: full of a rich and diverse selection of languages.
aDemoUzer 15y ago
I could not agree more. After learning the python idioms, I realized how much time I have wasted doing similar things in PHP. Python has gotten lot of things right. I don't feel cramped by a language as I have with Java. Python idioms : http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html http://python.net/~goodger/projects/pycon/2007/idiomatic/han...

391 points by zzzeek 15y ago

deleted 15y ago

[deleted]

ak217 15y ago

I like to call this cognitive compatibility - the amount of effort required from an uninitiated English-speaking observer to understand what a program does. Most people who are deeply familiar with a language will have a tendency to discount this effort, but really it is essential because it minimizes the translation layer that your brain has to use any time you read code. Python encourages code which is readable in English and reasonably brief. Having readability, consistency, and the "principle of least surprise" as primary language and community principles ultimately saves developers time and makes them more efficient. And the maturing of PyPy is incredibly exciting.

iandanforth 15y ago
I could not agree more with this comment and just wanted to thank you for expressing this so clearly.
andolanra 15y ago
I want to make what I think is an important qualification which conflicts with a reading of your comment: Python is readable to people who are familiar with conventional Algol-based programming, i.e. every modern programmer. That does not make it readable to an arbitrary English-speaker, which is an assertion I sometimes hear: "Oh, Python is so much like English, people who aren't even programmers can read some of it!" Which I can say from experience is not the case in the slightest. If it were, my job—which involves teaching Python to non-programmers—would be inestimably easier. Python is simple and easy because it takes everything you know from other languages and systems and makes those things simple and easy and pleasant to do. I've even seen Python used as a kind of runnable pseudocode for projects that would eventually be written in other object-oriented Algol-based imperative languages, which is a testament to how well it distills those concepts down and makes programming simple. But it is not "readable in English." It is readable in pseudo-Algol.
- tsunamifury 15y ago
  Thankyou! So many programmers seem to forget they have an enormous base of syntax and logic which is not at all like natural language. They see python and say, oh wow this is so easy to read, just like English! But its only an easier way to express a syntax that really is nothing like what a nonprogrammer would consider English.
  - shazow 15y ago
    It varies. When I was helping @limedaring learn Python, I'd read source with her and explain what it does. Quite often I'd feel somewhat embarrassed when explaining what a line does by verbatim reading what it says. "for user in users: ..." "if user.is_admin: ..." It was especially nice that the topic of "what code block does this condition apply to?" did not even occur to either of us. The indentation-based blocks made it completely organic. (Try explaining Bash to someone and when to use do/done, if/else/fi, case/esac.) But sure, things get weird with decorators and generators and other advanced features.
    - loxs 15y ago
      IMHO, decorators, although very useful are a big departure away from python's "simplicity" in syntax. I remember having lots of headaches several years ago wile trying to fit it in my brain. Even after I realized it is something as simple as JavaScript's myfun(fun(){}), my brain somehow continued denying to absorb it.
      - dcosson 15y ago
        Agreed that they can be tricky initially and hard to debug, but I think they're totally worth it for eliminating repetitive code. And IMO as long as there isn't a bug in the decorator itself, code with decorators can be just as readable (if not more so) to someone else (e.g. decorating your functions with @authenticated instead of if self.user.is_authenticated: # blah, blah blah)
        15y ago
luriel 15y ago
Python code is superficially easy to read, but to know what a piece of code really does can be extremely hard, specially when metaclassed, generators and the like are involved. Also there is plenty of Python code that is not particularly readable even superficially, particularly convoluted uses of list comprehension come to mind. And I don't think 'consistency' is one of python's main qualities, when even in the stdlib there are plenty of very different naming styles. (Yes, this is improving in Python 3, but has been a big issue for a very long time.)
- aangjie 15y ago
  +1 for the metaclasses example... list comprehension doesn't seem that big a deal, but then am biased way too much.. Also agree with consistency part.... but personally python is beginning to lose some of it's charm with the move towards consistency...
thehotelambush 15y ago
This is the kind of reasoning that lies behind LFMs: that it is better to cater to someone who knows nothing about the language (but maybe has a few mainstream languages under their belt already) than to someone who has put in the work to understand it. I'd rather pay to learn a difficult but more abstract language feature just one time, than pay all the time for its absence.
Too 15y ago
A programming language being similar to spoken english isn't necessarily a good thing. SQL being a prime example of this.

jtchang 15y ago

I work with python daily. I find that when I first started I avoid a lot of the "fancy" constructs such as list comprehensions, dynamic arguments, and decorators as well as meta programming. The great thing is the bar to being effective in the language is so low. You can pretty much pick up most python code and just read it and get a general feel for what it does. Not only that but it is much easier to read because of whitespace delimiting. I can generally tell the quality of a python program but how nicely indented it is. If there are lots of indents like 5 or 6 levels deep I know something is wrong. For a newbie if your code is hard to understand and it is in Python you are writing it wrong.

Luyt 15y ago
I find a great way to avoid deep nesting is to move code to functions, and bail out when some conditions are not met. As an example, this deeply nested code: def frob(someargs): if something > 2: ... # do some processing if that == "CONNECT": ... # some more processing if verdict in blessedsolutions: ... # even more processing print "Happy birthday!" I tend to write like this: def frob(someargs): if something <= 2: return # Not our concern. ... # do some processing if that != "CONNECT": return # Not handled here. ... # some more processing if verdict not in blessedsolutions: return ... # even more processing print "Happy birthday!" I do the same thing in loops, using 'continue'. The above second example looks rather flat, but in practice the 'do some processing' statements often need identations due to conditions and loops. I added the processing to demonstrate that it's not always possible to combine conditions. And, of course this way of 'bailing out early' vs. 'nested ifs and processing' is not Python specific. The dogma that a function should have only one exit point (as proposed by 'structured programming' adepts and Pascal afficionados) often leads to deeply nested control structures and convoluted testing. Brian Kernighan has written a paper on this[1]. [1] http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.html http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.htm...
- rmcclellan 15y ago
  Neither solution is great. Excessive use of return and continue is an incredibly fast way of making code completely incomprehensible. Such complicated control flows should be treated as a major, fundamental problem. Keeping them in place will cause bugs and prevent future contributors from having confidence that their changes are correct. The problem of complicated control flow is too deep to be solved with a band-aid like this, although perhaps syntactically it looks a bit nicer. In fact, this is exactly what people did before the so-called "structured programming adepts" came around, except using gotos instead of continues. It didn't work so well back then, and it doesn't work so well now.

keypusher 15y ago

See also: http://xkcd.com/353/ http://xkcd.com/353/

yason 15y ago

It's important because it reminds me I should keep looking. I should keep looking instead of turning it into my Blub. I love Python but its boundaries have been hitting me frequently for years. There probably never will be a total sweet spot between functionality, syntax, compatibility, support, and platform-crossing but I know I have to keep looking for a language that's more sophisticated yet more practical.

deleted 15y ago
[deleted]

DodgyEggplant 15y ago

True. The real magic: The basic constructs are so simple, so how the output is so robust? And picking old or library code is always easy!

wging 15y ago

As a commenter on the article wrote: what about Ruby? I say this as a happy Python user. Ruby seems very similar but I'm reminded of a pg essay on language power: looking up the power curve, you see '$Language plus a bit of weird stuff that is probably irrelevant.' So I don't trust myself. As someone who loves Python and doesn't know any Ruby beyond a few bits of syntax and the obvious bits that are common to most languages, what am I missing?

Game_Ender 15y ago
In my opinion Ruby has a slightly more obscure syntax with custom symbols, and it's C API is not as clean and well put together as Python's.
- 16s 15y ago
  Which is more obscure? Reverse a string in ruby: string.reverse() Reverse a string in python: string[::-1]
  - evincarofautumn 15y ago
    Slice syntax in Python always bothered me. This would be slightly more readable: ''.join(reversed(string)) Except it requires you to have an idea of how iteration works (beginners don’t) and why that “join” needs to be there, and it’s still an order of magnitude slower. But hey. Ruby is prettier in some ways, Python in others, and beggars, as they say, can’t be choosers.
    - 16s 15y ago
      Way way slower than the slicing.
  - TylerE 15y ago
    What an odd example. Other than perhaps a palindrome detector, I'm having a really hard time coming up with a use for a reversed-strings. Python DOES provide a reverse for arrays.

khyryk 15y ago

I like Python the language, but the standard library can often annoy me as there is no unified style. thereAreMethodsLikeThis or_there_are_methods_like_this orevenworsefullylowercase. Gah.

ndefinite 15y ago
PEP 8 covers this: http://www.python.org/dev/peps/pep-0008/ http://www.python.org/dev/peps/pep-0008/
cbs 15y ago
Thats a thing where the standardization came after those libraries. It doesn't get to me that much, but I have a coworker it does bother a fair bit. I poke fun at him for this, but what he does is just take 15 minutes and write a "proxy" module (I think he was actually able to automate it...). If `baz.fooBar` is bugging him, he'll just create a `mybaz` module where mybaz.foo_bar either calls or is just a new name for baz.fooBar and then he just does an `import mybaz as baz`.
hcarvalhoalves 15y ago
My biggest gripe too. Hopefully stdlib got more love lately on Python 3.

keypusher 15y ago

I do love Python, but I often wish there was more rigor for some things. I currently work on a large project (>500K LOC) and have started to see it fall apart with a bigger team. Lack of enforced typing in function arguments, inability to create strict interfaces, inconsistency in standard library conventions, and package management would probably be my biggest gripes.

underwater 15y ago
I've seen projects that use decorators for type checking. You could turn it into a noop for production.
bugsbunnyak 15y ago
Curious: what is this 500k LOC project (if you can say) and how much of that is Python? If it's an in-house codebase that's a really neat datapoint because it would rank among the largest open-source Python projects.. Also, Traits (from Enthought) is an attempt to deal with some of the issues of typing and interfaces. It's led to some great software (the Chaco plotting package is fantastic, as is Mayavi), but I've yet to figure out how to debug a Traits error and stay sane. There is a lot of auto-configured magic that happens, and when something goes wrong the backtrace is often pages long and doesn't actually show the offending line.
- keypusher 15y ago
  Project is automated testing for an enterprise private cloud platform. 500K of tests and test library is all python, the application itself is probably 2M+ LOC, Java + C running on Linux.
cdavid 15y ago
On most projects I have seen where python was seen as problematic, I think that having types ala C++/Java would not have improved much. The real problem is that the function is not documented, nor is the function expectations. Typing in C++/java does not replace that (more advanced typing systems do much better, though). Package management and generally deployment is certainly a pain in python. I think it is one of the main issue in typical "corporate environments"

tete 15y ago

I am kinda afraid of getting down voted, but I have used Python and I feel like I get all this and more (CPAN) when using Perl. The major difference in my opinion is that Perl gives you even more freedoms, which causes you to need some self discipline, but you get stuff done even quicker that way. It feels a bit like Python is better for programming beginners or people that tend to be too lazy sometimes and Perl is for people who want to be able to be lazier since they know what they are doing. Also, I think Python (and most other language projects) should clone CPAN (including CPAN testers). Seriously it's a major deficit. I also think Python is the easiest to grasp for people coming from static languages. Perl and Ruby are way harder.

mekoka 15y ago
Like the author said, you’ll spend a lot more time reading code than writing it, and [python] focuses on guiding developers to write readable code. As someone who reads a reasonable amount of source, I'm grateful for that.
achompas 15y ago
It feels a bit like Python is better for programming beginners or people that tend to be too lazy sometimes and Perl is for people who want to be able to be lazier since they know what they are doing. I'm sorry, I don't understand this at all. What does this mean? Also, I think Python (and most other language projects) should clone CPAN (including CPAN testers). Seriously it's a major deficit. The Python Package Index (http://pypi.python.org/pypi http://pypi.python.org/pypi) is no CPAN, but I've never had a problem with it.
to3m 15y ago
The point about static languages is definitely well-made. Python's two key aspects are its lack of dynamism, its structural rigidity, and... oh, THREE key aspects!, because I forgot its famously rigorous static type-checking system. Coming from a C/C++ background myself, I found this very reassuring. I don't like languages that keep you constantly on your toes due to providing insufficient structure and too much dangerous freedom and flexibility.
aangjie 15y ago

espeed 15y ago

Python doesn't have the glyph noise that brace-based languages do, and well-written Python is beautiful and easy to read. But lately I have been having an internal debate on whether using autodoc and inline docstrings detracts from its beauty and makes it harder to read because it reduces the amount of code you can see on the screen (see Steve Yegge's rant on this http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm... from a few years back). If you use Sphinx to document a method's description, params, param types, and return type, then it can easily turn a three-line method into a 12 line method, and then you can only see ~5 methods on the screen at a time. So if the code is already readable, would it not be better to put the docstring comments in an external file to keep the code density? Django does this, and I'm starting to think it's the right balance.

mekoka 15y ago
Docstrings should already be easy to detect by editors, so it would be trivial to add a show/hide functionality. Incidentally, one could also use Sphinx to create a plugin for that.
- odiroot 15y ago
  I just noticed Sublime Text 2 has an ability to fold multiline docstrings. If there only was a way to do this automatically.
- espeed 15y ago
  But not all editors have this, nor is it widely used in editors like Emacs. And GitHub doesn't have it so it can make it harder to get a big-picture view and see the structure of a module when evaluating different libraries online.
abecedarius 15y ago
I generally write docstrings like "Return the n-fold frobulation around the center (x,y)." That's one line that way and about a half dozen in Javadoc style, without the latter adding much to pay its freight. What would be worth putting inline but with auto-folding, to me, would be examples.

agentgt 15y ago

I have used Python for a rather long time (I think 1997 when I was 17 was when I first used it). As the the writer of the article stated Python is awesome for writing "tools" and throughout my career I have used it for such. However I have used Python also for big projects and that is where its gets a little messy. I know I am going to get down-voted to kingdom come but I think Java is a better language for big projects mostly because of the static typing (try renaming a class in Python compared to Java). Modern Java is for sure more verbose than Python and more complicated but the languages are extremely similar (Guido has even take some of the design consistency from Java for Python 3.0). The reason I bring it up is Java is very often in various circles crapped on to no end. The reality its basically just more verbose Python. Not to mention Java offers an introduction to Parametric/algebraic typing (generics) and more sophisticated concurrency (futures ... yes actors are better but python really has neither).

tikhonj 15y ago
In my mind--probably not the majority opinion, but so be it--it's really the opposite: Python is a dynamically typed Java. So it's not that Java has been underrated but rather that Python has been overrated. I do not like working with either. Also, I'm not quite sure what generics have to do with algebraic types.
Peaker 15y ago
Just replace Java with Haskell, and you've got yourself a nicer Python replacement. Less code than either Java or Python, far more compile-time guarantees than either, and nearly as fast as Java when speed matters (speed takes a bit more effort in Haskell than in Java, but compared to Python, it is a no-brainer).

user0398 15y ago

Mostly true 'cept for pythons built in pasta makers: http://www.python.org/dev/peps/pep-0318/ http://www.python.org/dev/peps/pep-0318/

Luyt 15y ago
Yeah, that's fun ;-) I wish there was a if main: ... # do some processing instead of having to write: if __name__ == "__main__": ... # do some processing That'd make DHH happy, too ;-)
- anthonyb 15y ago
  I find that the best way to fix this is to write your program as a library, then the part that you're supposed to run as a script which imports and runs it. No __underscore__magic__ required.
olefoo 15y ago
Decorators can be misused, but they can also succinctly express an aspect of the program that is repeated many times in different contexts. My own rule is that a decorator should do one thing, and that thing should be described by it's name. Being able to look at a method that has the @has_permission decorator on it and know that it is getting checked for against a package wide permission model is more clear than having boilerplate to check permissions on every method that needs that check. Any language construct can be misused. And people can hide stupid things in decorators and name them in misleading ways. That doesn't mean that it's the fault of the syntax.

pranjalv123 15y ago

My biggest problem with Python is that projects larger than a given size tend to become unmaintainable rather quickly. This is in large part because of the lack of strong typing and type annotations; if you aren't the only author or can't keep the codebase in your head, it takes real effort to figure out what a function does. Even the type annotations provided in a language like Java or C++ make this task much easier, not to mention languages with real strong type systems like Haskell. That's not to say that building large systems in Python is impossible, but it takes a lot more effort and documentation that it would in other languages.

agentgt 15y ago
I agree and I was worried I was the only who would say it :)
mef 15y ago
Yup. This is also the case with Ruby, and is one of the challenges when trying to dive in to a large unfamiliar project. For example, when something in Rails doesn't behave correctly and you flip deep into a source file, it's not always easy to track down exactly what kind of arguments a method expects. Often you'll have to breakpoint inside the method just to inspect what's around.
niels 15y ago
Just to be clear, Python is strongly typed but not statically typed. But I definitively agree with your comment. The startup I'm working for is Python based, but I'm currently learning Haskell, because I'd like to take advantage of a good type system for my larger efforts.
- lelele 15y ago
  Aren't you concerned about unpredictable memory requirements?
  - niels 15y ago
    To be honest I don't have enough experience with lazily evaluated languages to be concerned about it yet.

Peaker 15y ago

"Weirder languages (e.g: Haskell)" sounds like something a Blub programmer would say. How is Haskell "weird"? I've used Python for many years, but only recently have I migrated my last Python niche (simple scripts) from Python to Haskell. I've found that even there, Haskell has become more productive.

masklinn 15y ago
> How is Haskell "weird"? Functional the world (of wide-spread computing languages) is imperative, lazy the world is eager, objects-less when the world is object-oriented, curried when the world is uncurried, pattern-matched when the world is conditional and brings up "strange" concepts from mathematical bowels like "monads", "functors" or "zippers" when the world barely iterates on arrays. How is Haskell not weird from the point of view of 99% of the developers population? Knowing, liking or using Haskell is not even relevant there, Haskell is weird because it is an alien to the majority in the same way Smalltalk, Erlang or Clojure are weird (but for different reasons, for the most part).
- Peaker 15y ago
  I understand "different". Not "weird".
  - masklinn 15y ago
    They reify to the same thing, something different looks weird, and something weird is different.
  - njharman 15y ago
    You seem to be attaching a non-existent negative connotation to weird. Weird means different. Weird is "more" different.
- deleted 15y ago
  [deleted]
- whateverer 15y ago
  The world is mostly parallel and asynchronous, yet most languages are sequential and synchronous. And the object-orientedness claim is overstated, as you drink from a cup, rather than use rather than think it in terms of cup.spill(), signals propagate, but 'return' is nowhere to be found... unless of course you are just talking about programming, but that's a bit of a circular argument.

kevinburke 15y ago

When I was at Google there was a paper titled "Please don't use Python for large programs." Can someone post that? It would be an interesting counterpoint.

nostrademons 15y ago
I don't think it's public. In any case, its argument basically boiled down to "Python doesn't have static types, without static types it's too hard to communicate API information between programmers, Google has thousands of programmers that need to communicate, so please don't use Python."
sunqiang 15y ago
what type of paper, Google's coding policy? there is a mail-list post, https://groups.google.com/forum/?fromgroups#!topic/unladen-swallow/TtvEBvVEZD4 https://groups.google.com/forum/?fromgroups#!topic/unladen-s...
olalonde 15y ago
What language do they recommend for large programs?
- sunqiang 15y ago
  don't know for sure, it might be C++, Java, and now they have Go.

pnathan 15y ago

I have a list I wrote up once about Python's problems. Some of these are more exotic than others. Most of them are kludgearoundable. A couple are fixed in Python 3. Some are simply design choices that are exactly different from my mental model of the world, and due to the TOOWTDI Python world, it is frustrating to work with them. Some Things Wrong With Python * Immutable strings[0] * Everything a reference[1] * Environment copied on loop entrance (implying assignments often break when done in loops) * Lack of braces[2] * Lack of enums[3] * Standard debugger pdb reminds me of the first debuggers ( used on the PDP-1 and EDSAC) in its feature list. * Exception-oriented design, which clutters code with "try/catches" everywhere. * Exceptions aren't just exceptions, they are also overloaded to provide signals. * Two forms of objects (old style vs. new-style) * Object inheritance is pointer to parent. Metaprogramming becomes an exercise in hackery. * Objects are actually dictionaries with some pointers behind the scenes. * Duck typing will automagically cast certain things[4] * As an interpreted language, code that is not tested can be assumed to be syntactically correct but in error (this is a horrible problem when testing for rare error conditions)[4.5] * When Python is fast, it's because it's calling out to C. * Python objects are gigantic. An empty string is 40 bytes, for example. This adds up. * Python can not meaningfully multithread, due to the global interpreter lock. * Python suffers from many different versions being installed on different versions of Linux[5] * Lambdas are totally broken[6] * Large-scale module importing is a half-baked job[7] * Python 3 routes around some these issues by using generators for everything[8]. [0] Ever try to step through a string and modify it in-memory? Well, you can't. Sorry. ;-) [1] I.e., a function can modify something unexpectedly. [2] Which means block commenting or commenting out tops of loops means a complete reindenting of the block, that is, editors can't do the smart thing, they don't have enough context. This is a waste of the engineer's time. Delimiters were figured out in Lisp, a very long time ago. [3] This was figured out long ago as well. [4] But not others. Object design is a bit funky. [4.5] This is a general design 'con' in dynamic languages. It's partially solvable with a sufficiently smart compiler, most compilers aren't that smart. [5] This is why serious Python programs (that don't come bundled with their own version of Python) are written to target Python 2.4, released in 2004. [6] A 'lambda' function in Python can not have statements. Most interesting functions have statements. [7] Python (similar to Java) relies on a very specific directory structure for a given program to be able to import libraries. This means that if you are doing anything remotely exotic with layouts (e.g., libraries are in a peer directory, not a child directory), you have to commit hackery. [8]This avoids the fact that the end result has to be emitted in some fashion.

a_a_r_o_n 15y ago

Executable whiteboard.

sdfjkl 15y ago

Many years ago I've decided it was time to pick up a modern programming language. In the past I had written lots of (Turbo) Pascal code, some x86 (and more exotic) Assembler and a bit of C, but then for several years I only did shell/awk scripts and ported C software to IRIX and SINIX/RU. So I sat down and decided to find a nice general-purpose language that I would focus on learning. I wasn't quite sure what for yet, but I decided I was going to pick one and stick with it. I didn't have the time to learn multiple languages and I didn't have a lot of time to try out different ones, so I just looked around a little bit. Some I ruled out early: C and it's relatives were just too verbose, I didn't want to spend the time writing all the error handling necessary just to read a damn file. I was doing a lot of sysadmin type work at the time and had therefore developed an intense disliking for Java. This was based on too much badly packaged Java software that even if you got it running at all was sluggish, hogging way too much memory and crashed with arcane error messages. I did like the quick & dirty way I could make things work in a shell script, so I looked mostly at scripting languages. I looked at Perl, which was the standard scripting language at the time and had a huge library (CPAN) of modules, which was great. I hated the syntax though and found the code often unreadable and there being too many ways of doing the same thing. I looked at Pike, which had the benefit of using a C syntax (which I already knew, so that was a plus), but it seemed not widely supported and nobody was using it (this hasn't changed since, it seems). I don't remember what else I looked at, but then there was Python. The syntax was a revelation. Here someone had finally made the most of creating a language from scratch and spent the time thinking about syntax and how to do away with largely pointless stuff (brackets), replacing it with things that everyone did anyways (indentation). It also came with a sizeable library of stuff that did almost everything I could dream of at the time. It was love at first sight. Recently I've spent £35 on a stainless steel mill that grinds salt when you twist it one way and pepper when you twist it the other way, just because I really love well thought out and engineered things that make stuff that's been around forever just a little bit better. That's how I feel about Python. It's not doing anything fantastically new or unique, but it's doing the stuff that others do just a little bit better. Today I'm doing lots of web stuff, some sysadmin stuff and random hacking of various things on the side. I'm still doing almost everything in Python and whenever Javascript bitches at me about a missed semicolon I do think: "All these fantastic things you can do in a web browser these days and you couldn't figure out that this command in an entirely different line isn't part of the previous line?". The only thing that I can't do in Python is write software for my iPhone, which bugs me a bit. But every time I try to get into Objective C I just get annoyed by the syntax and amount of cruft I have to write to do anything.

igorgue 15y ago

Haskell is not weird.

danbmil99 15y ago

Python is great in every way except one -- it isn't Javascript. (to clarify: I'm not saying JS is a superior language. I'm just saying it's going to win out in the end because of the history of its implementation. There is a serious benefit to having one language everywhere, and JS is the only viable candidate because of the investment in client-side sandboxing and performance -- two features which turn out to matter almost as much on the server as well.)

alextgordon 15y ago
I wasn't aware that Python and JavaScript were in competition. Or for that matter, that JS is by any stretch of the imagination "invested in performance". People don't use Python because of its merits as a programming language. They use it because of the excellent standard library, Scipy, Sage, etc. While it may be that in a decade JavaScript has built an ecosystem to match, I frankly don't see why anybody would bother. We already have Python, why would we invest such effort into a less suitable language? JavaScript is tolerated by web developers, because they're forced to use it on the client, and so there's a benefit to also using it on the server to prevent duplication of effort. But there is absolutely no reason why non-web developers would or will ever use it outside of that niche.
- danbmil99 15y ago
  > non-web developers Sorry, not sure what that means </sarcasm> OK maybe not everything will be a web app, but pretty much everything that isn't some deep driver-level boot code or embedded firmware is already almost always part of some sort of web app, and the stuff that isn't is pretty much all written in C/C++. When is the last time you wrote a Python program that didn't interact over TCP or equivalent with some other process? And how often was that other process not something at least nominally webby?
  - alextgordon 15y ago
    > When is the last time you wrote a Python program that > didn't interact over TCP or equivalent with some other > process? My last python program was a set of scripts to help me analyze music harmony. Entirely CLI based. Before that? objcfix - a refactoring tool. Again, CLI based. That's not counting the multitude of small scripts I write on a day to day basis. I've written a large amount of Python code, and very little of it interacts with a network. Put it this way: Python was invented in 1991, the same time as the web. It didn't become a good tool for making websites until after 2005 when Django arrived. So, what did people do with it before then, if not make websites? > but pretty much everything that isn't some deep driver- > level boot code or embedded firmware is already almost > always part of some sort of web app, and the stuff that > isn't is pretty much all written in C/C++. This is not the reality we live in. There's: * Games (either written in C++, Objective-C or Java nowadays, plus a bit of Lua) * Big Software: MS Office, Photoshop, Avid, Logic, InDesign, etc. Written in C++ * Scientific Computing: Written in C++, Matlab, Mathematica, Python * Financial Computing: C, C++, Java, and a tiny spot of OCaml. * iPhone/Android Apps: again, Objective-C or Java. * "Enterprise Software", whatever that is. Java. And as you point out, embedded software. Everything around us runs Embedded C. The future is the same as the present: full of a rich and diverse selection of languages.

aDemoUzer 15y ago

I could not agree more. After learning the python idioms, I realized how much time I have wasted doing similar things in PHP. Python has gotten lot of things right. I don't feel cramped by a language as I have with Java. Python idioms : http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html http://python.net/~goodger/projects/pycon/2007/idiomatic/han...