Python is a voluntary language
johndcook.com
johndcook.com
Here's what rubs me raw day-in and day-out:
1. Lack of immutable/persistent data structures. 2. Lack of multi-line anonymous functions/lambda. 3. Variable scoping fail, causing hacks like the new `nonlocal` keyword. 4. worst_possible_variable_name_convention. 5. Python evangelism. (community issue, mostly) 6. Hypocritical "explicit is better" and "flat over nested" values with insane amounts of magic built into language and class system. 7. No switch. 8. GIL. (Actually the CPython runtime in general) 9. No macros. 10. the insane way "unicode" is supported. 11. and on and on...
At this point I write Python code, but not generally by choice. Mostly my coworkers can't even imagine writing code in another language, given that we have been allowed to choose our implementation language(s) as a team.
It has tons of data structures for pretty much every usecase, and even lists the complexity of various operations. All the data structures share the same API so replacing one with another is fairly painless.
2. — 8. are all no problem in Scala and running on the JVM means not having to worry about speed or stability anymore, while having all the superior tools of the JVM ecosystem for monitoring and debugging available to you.
9. Macros will ship as an experimental feature in 2.10, to make sure everything can be adjusted and fixed as necessary before declaring it stable.
10. Perl 5/6 is still ahead in Unicode, but judging from the Unicode presentation by Tom Christiansen the JVM is more or less on the second place, which fits with my experience.
Overall Scala is a impressively well-designed language imho, although some people really dislike that it doesn't restrict method names like Java does.
I don't think it has. The original philosophies, as much as they exist, oriented around ease of use, programmer happiness, and pure OO - things Rubyists still enjoy. But Ruby has missed the boat on being a popular, general programming language in the way Python is big time. Most Ruby jobs are related to building Rails apps in some way or another and the majority of the Ruby ecosystem (in the West, at least) orients around Web development (and not gaming, scientific programming, education, or the many niches Python has found a home in).
Ruby is an interesting language and one that's worth learning and using IMHO, but in the West, Ruby has become "typecast" as a life support system for Rails essentially. (Before people note the non-Rails things they're doing with Ruby, I said most Ruby jobs and the majority of the Ruby ecosystem. Reporting on Ruby developments has been much of my job for the last 6 years but I am more than happy to be swayed :-))
I wasn't aware of Python/Ruby back in those times, but my impression now is Python was widely used prior to Rails existence... in academia, science, mathematics, etc, but Ruby was not much on the map until Rails came along.
I'm not saying this is how is was - I honestly don't know, just my impression as someone fairly new to this stuff. I would appreciate if someone who was familiar with the Ruby community prior to Rails could shed some light on this. Doing some google searches turns up minimal clues. The wikipedia on Ruby says "Around 2005, interest in the Ruby language surged in tandem with Ruby on Rails, a popular web application framework written in Ruby. Rails is frequently credited with making Ruby "famous""
http://www.tiobe.com/index.php/paperinfo/tpci/Ruby.html
According to this, Ruby really exploded in 2006 after holding steady for quite some time in relative obscurity. Now you just need to figure out when Rails became hugely popular to check for a correspondence.
Prior to 2005, reasonable in Japan and poor in the West. Analogous to the position of Erlang, say, in 2012.
The influx of new users and attention after 2005 could have turned into a more mainstream success for the language and for years, I thought it would pan out, but I'm not sure it has.
Why do you think this is? My biggest hurdles were documentation quality, frequently flaky Windows compatibility (not necessarily in core, but definitely in a ton of gems), and figuring out to deal with the volatile nature of many gems (New Ruby versions are awesome! Monkey patching is awesome! API compatibility between versions is lame).
It seems like it's almost a cultural issue.
Documentation is a huge thing. I found the docs difficult to navigate, and only in the last few months (whenever the latest change was) are they easier to navigate. But the descriptions are still pretty spartan and it's hard to find what function your looking for if you don't know what it's called. The way names are chosen doesn't match with my experience from other languages (Java, C, PHP, Scheme). So I tend to use Stack Overflow a lot more than the Ruby docs themselves.
A good book helps get past the hurdles of knowing what function to use for what. However, the only real examples in the Ruby books I've read are in Rails books. So that might be part of the cultural issue jamesgeck refers to. Poor docs + book focus on Rails means you can only learn Ruby for the purpose of Rails, and that typecasts it as a web language.
Note that PHP is stuck as a web language even more than Ruby. PHP is meant to be one, of course, but it's still usable as a general systems scripting language. I've written a nightly cronjob billing system in PHP since then the web frontend, which was PHP, and the cron job back end could all share the same billing libraries. I've also written small compilers and other scripts in PHP. That was before I was very comfortable with Python and Ruby (and had most of PHP's standard lib memorized), but PHP still worked fine.
I tend to use Ruby now for most scripts, except where other people require me to use Python, like where some shared team library I need only works with Python. So, there are at least SOME cases where Python is mandatory and not voluntary.
I find that confusing as there are plenty of good Ruby books that aren't Rails focused all the way from beginner to advanced. Maybe they're just not promoted properly, though.
It's bad enough that I'm just going to switch to Python for this project.
- web development, with "knowledge of Django a plus" - a job title without Python in it (Software Tester etc) requiring "a scripting language (Bash/Perl/Python/Ruby)"
Ruby job offers are almost exclusively Rails offers. Ruby is not even widely acknowledged as a scripting language.
I don't discount the possibility that it will break into other niches. The language is a better known quality, but there are still plenty of worlds to conquer.
While writing it, I often wish it were statically typed with pattern matching. The write/test/type error or undefined variable cycle is very frustrating to me. The lack of pattern matching makes my code verbose and also makes it harder to spot edge cases I missed.
I also wish functional programming in it were as easy as in Javascript. I often find myself writing a bunch of front end code, finding it elegant, then thinking "damn, back to python to update the api". (This includes multiline lambdas.)
It's still my go-to language for most purposes, but I constantly feel that it could be a lot better. I'm looking forward to the day when javascript completely subsumes the niche python occupies.
People seem to want a simple, dynamically typed scripting language. Javascript can fill that niche while being a big improvement on Python. (Particularly if we accept some breakage of backwards compatibility, add a module system, and clean up the warts.)
I've only recently started in Javascript, so I'm probably missing something, but I've been finding it a large step backward from Haskell when compared to Python. Specifically, list comprehensions and generators give Python a more functional feel. Meanwhile, the object system in Javascript has had me generating far more state than I ever would have in my Python code, while also requiring more manual type checking than I ever needed in Python.
I'm new to the language, so I'm sure that I'm missing something. I've read _Javascript: The Good Parts_ and it's helped me grow less frustrated, but I'd love to find out that this language is better than Python.
So, how do you write functional code in Javascript?
I write js using underscore and backbone, so while I have state, it's pretty well encapsulated.
So I've got a few stateful backbone models. The inside of their methods tends to be primarily functional, followed by a stateful update:
var intermediateResult1 = _.map( input, function (ss) {...});
var intermediateResult2 = _.map(input, function(ss) {...});
var intermediateResult3 = _.intersect(intermediateResult1, intermediateResult2);
....
this.setState({ "my_attribute" : result })
They may be just syntax, but multiline lambdas certainly help. And some of this is just library support. But all put together, it makes my js code far more functional than my python code.
I've been trying to write Javascript and then make it functional. I think I need to start writing functionally and just fit that into the Javascript. From what you've written, that looks pretty doable.
The main advantage that JavaScript seems to have over Python is multi-statement lambdas. In other respects it seems no more Haskell-esque than Python is. Python at least lets you do a very limited form of pattern matching on tuples. And JavaScript brings along so much hastily-designed ugliness that it seems like it would take ages to break free of its historical warts.
I'd personally be happy if some flavor of Scheme became the dynamic language du jour, though I realize I'm living in a fantasy world there.
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
Javascript also has proper closures, and it's support for event driven programming (admittedly, not part of the language) is also quite nice.
[edit, since I can't reply. By proper closures, I mean this shouldn't happen:
> x = 0
> def foo():
> x = x + 1
> print x
> foo()
UnboundLocalError: local variable 'x' referenced before assignment
]EDIT: Interesting, I've never run into that behavior before. Looks like you'd have to explicitly mark that variable as global if you want to mutate it:
x = 0
def foo():
global x
x = x + 1
print x
foo()
"This isn't a bug; it's by design. Because there's an assignment to 'a' in the function 'y', 'a' is considered local to that function. (It doesn't matter where the assignment happens within the function; the presence of an assignment anywhere is enough to make 'a' local for the entirety of 'y'.)"
class BoxedInt(object):
def __init__(self, v):
self.val = v
x = BoxedInt(0)
def foo():
x.val = x.val + 1
print x.valAlso, I hadn't seen this essay by PG before (from the comments); a bit old, but interesting take:
The titanic investment bank that I used to work for started a major rewrite of its entire set of booking and risk systems in which everything was to be written in Python. It immediately assigned hundreds of programmers to the task, shepherded by a "core team" eager to use every feature of the language. The result was a perfect example of the problems with Python in the large. Enormous type hierarchies mingled with copious use of eval; there was no structure at all to much of the code.
It's possible to write terrible code in any language, of course, but using Java would have been one way to curb some of the worst impulses of the low-quality programmers.
I don't even get what he's trying to get at in paragraph three. From looking at jobs for startups and jobs in the Bay Area I can see that a large majority of them are using python over ruby. So python compared to ruby is relatively more popular at least from a job-seekers perspective.
So even though this is true, he singles out that ruby may possibly have compromised it's original philosophy with rails because of its popularity but yet python hasn't been affected at all by its mass popularity from most startups and science/academia companies using it? Python also has a pretty popular framework in django yet I don't really see any pressure by Guido to change python because of it.
Really this article is a pretty ignorant view of ruby since he himself admits he does not know much about ruby. So why bother writing that last paragraph other than for the sole purpose of putting down ruby? The last paragraph feels pretty tacked on and seems to be a nice jab at ruby for no reason other than he likes python.
Let me just end by saying, I love python, but I love ruby more. I don't have any ill-will towards python. But consider if this article was written about ruby and dhh wrote it. How much vitriol do you think dhh would get from writing an article like that?
This is a some what irritating speculative musing, given the fact that it is a question that could easily be answered by talking to any number of Rubyists who are available and interested in answering such a question.
One of the major points of tension in the Ruby community is the extent to which the non-Japanese Ruby community has input and control over the destiny of Ruby as a language. Given a number of alternative implementations of Ruby (JRuby, Rubinius, MacRuby just to name the popular ones), alternative implementors have gone well out of their way to ensure conformance with the mainline Ruby implementation.
In fact they went so far out of their way to build a spec suite to characterize the behavior of Ruby the programming language from it's actual implementation. And on top of that there's even a new ISO spec for Ruby.
So, yeah. Matz does have control of Ruby, and Ruby does resemble Python in its voluntariness.
People who write X choose to write X.
There's virtually no language that can't fit the bill. It may surprise some, but there are people who choose to write Java, Perl, C, and even C++.
edit: Didn't realize that people who choose a language different than Python aren't actually people.
People who write LabTalk choose to write LabTalk.
People who write Tcl choose to write Tcl.
Some people who write Tcl choose to write Tcl.
Some people who write X choose to write X
Sure, it's not true for any of them, even Python, but it's meaningful for any language including Java, Perl, C, C++,...
It's easy to forget that computing is a huge field and that hackers diverse in their tastes and fetishes.
I often write R, not because I want to, but because I'm working with people who don't know any other language. In that case I choose to write R, but that doesn't mean I'm happy about it.
I was just pointing out that what you said about Python I could say about Ruby or Perl, some other guy about C++, ...
For example, I hate significant white space and if I had to use Python I would be miserable, but for you it's the best language in the world.
Sure, we can argue about what percent of the total users of a given language would use it if they had a freedom to choose a different one.
edit: I can't reply to your reply so here it is:
My point is that People who write Python choose to write Python. is as true as People who write X choose to write X.
My claim is not that "Everybody who writes X chooses to write X"
It is in this vein that I write...
"Python is popular enough to have a critical mass of users" - on this point unfortunately I have to disagree.
Often the way I write a script is to put in a little extra effort up-front: I do three or four Google searches with the hard part of the task + Python, Perl, PHP, etc -- just to see if someone has already done this for me. I must say that if it's something hard and remotely web-related, the Python part is usually not even worth trying. Either I can do it off of the top of my head, or some fool is asking how to do this thing they can do in PHP in Python and, well, not really getting an answer. (It's not that it's wrong to code things up the long way, it's just that, like I said, it's not even worth doing the Google search).
In this sense there is not a 'critical mass' of users. Let me give you a simple example. Say you want to do fancy appointment-matching like people saying "next friday"...you want to try to pick up on that and offer to set an appointment. So, Google "appointment regular expression next friday php" "apppointment regular expression next friday python" "appointment regular expression next friday perl". You can go ahead and do it, I don't even have to check. If you don't find anything, play around for less than 15 seconds with alternate search terms (more general, more specific, or just different.)
I did the above search just now, and in my case I went off on this tangent and within a couple of minutes had an answer that was satisfactory for me.
I would say, well, there are simply lots of fast scripts that you KNOW can take you 2-3 days of head-scratching to get right OR that the community already has bumped their heads against. Which do you do? If you're NASA, of course you go through scratching your head and getting the RIGHT answer. If you're trying to get a demo out the door, then you go for the low-hanging fruit, with as much leaning on the community as possible. Of course, if its creation, trajectory calculations, whatever, involve a scripting language in any way, would I want a rocket to use Python over PHP. But if I need a script that creates a GIF file of a rocket blasting off off-screen, based on a static image of the rocket that I have? (Forget whether the gif is the correct solution, I just want to see what it looks like, maybe as part of investigating lots of possible ways to do this). Well, then I would do a couple of minutes of Googling first... (As above, though I didn't try this one). Usually, I'm sorry to say, Python doesn't win.
If this get smore downvotes I'll try the Python search on creating a gif file programmatically.
If that's the case, then what particular task you're asking about is going to impact how successful you are. People write much more than just "web-related" things in Python. And, personally, I don't consider that to be important for what I consider a critical mass of users. Rather, what I think is important is that there is enough of a community to provide good online documentation, plenty of technical books, maturity of the toolchain, and integration in most systems.
Hopefully, you should be able to complete this task in every single programming language that appears on your resum, including javascript if you have put it there.
In practice, if you are a one-man show trying to get a whole startup off the ground (including all of the biz dev, all of the back-end, all of the front-end, all of the customer e-mails, EVERY SINGLE THING YOUR COMPANY IS DOING) then you don't have the luxury to scratch every itch. There are itches that you can scratch if someone has done it and you can find this out in 15-20 seconds, otherwise, you just don't have the time.
In this sense PHP wins where Python has not yet won.
As for web work. I actually just did try "how to tail a file in php" and "how to tail a file in python". On the PHP side I instantly saw this stackoverflow question http://stackoverflow.com/questions/1102229/how-to-watch-a-fi... which links to this:
http://code.google.com/p/php-tail/
Ability to tail small and big files for updates using PHP and AJAX. Includes the ability to grep results for a specific keyword.
- Fully documented
- Fully customizable
- Updates the page with new information without a page refresh
- Change GREP keyword / invert on the fly without a page refresh
- Uses JQuery / JQueryUI libraries
- Simple to use UI
- Automatic scrolling when required (if a user scrolls up, the automatic scroll is disabled until the user scrolls to the bottom again)
Wow, that is pretty amazing. If someone just HAPPENS to be looking for a quick tail through a web-browser, with grep functionality, this is a drop-in solution. It's not what I needed, but this is my whole point about community-size. As it gets larger and larger, there is a greater and greater possibility that just what you need is 30 seconds away. It would literally take you hours to do all of the above in Python.