Programming tastes evolve over time. At one point, and for at least a few years, I believed Python was the one true language revealed mystically to GVR. Up until that point, I'd done most programming in C++, so you can imagine how much fun Python was, in comparison. After further development and discovery of other programming languages, the shortcomings of Python have become obnoxious, much like torturing someone by dripping water on their forehead incessantly. Part of the problem is that I have to use Python for my professional work now. Using a language for your day job is a sure way to reveal all the issues.
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.
I went through a similar progressions, or I guess I'm still in it. I have found multiple languages to replace aspect sof what I liked about Python but not one that addresses all of it. I think if F# existed on *nix in strong way I'd consider it a Python replacement.
I've found I like almost every aspect of Clojure. I've yet to try to seriously replace Python with Clojure for any large project, but I plan to try it soon.
Ocaml, as a language, is amazing. But it's implementation isn't much better than Python's. No parallelism for example. And its ecosystem is worse than Python's in many ways, such as building code. I love the language, it's just the implementation that makes it an incomplete solution for me.
Did you consider Scala? From my POV it could fit your bill pretty well.
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 care for Scala. I find the language to be complicated without any strong benefit. The type inferencing isn't particularly good either, which is annoying. The JVM also hasn't made life easier for functional programmers yet. Compare Scala to Ocaml, in terms of language, and I think Ocaml simply blows it away for power relative to complexity.
I wonder whether the increasing popularity of Ruby for web development has created pressure for Ruby to compromise its original philosophy.
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'm curious though, what was the uptake on Ruby before Rails?
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""
While I wouldn't quite recommend the TIOBE index in general, it's still useful for attempts to identify significant events in the history of a language's popularity. Here's its historical graph for Ruby:
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.
I'm curious though, what was the uptake on Ruby before Rails?
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.
> But Ruby has missed the boat on being a popular, general programming language in the way Python is big time.
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).
I originally avoided Ruby, back at the beginning of Rails's popularity, simply because Matz admitted it was slow and he had no intention of making it faster. It has improved now of course, but I still have something lurking in the back of my mind that says Python is faster than Ruby.
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.
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
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.
I'm a Ruby developer who never uses Rails, and I think this is a major problem. It makes it hard for me to embrace "Ruby developer" as a career path because that means I'll be typecast as a Rails dev, and I don't want to use Rails.
It's hard enough trying to be a professional male programmer under 50 without being pandered to as a mountain dew swilling minecraft playing hoodie wearing brogrammer, so for sure adding Rails to the mix is just asking to be typecast.
Yeah, I was trying to use some of the mathematics libraries for ruby, and found that we've got a lot of ports of things like NumPy that were created around 2006, and haven't been maintained - and there are multiple half-baked forks floating around trying to keep them running, and so the documentation is wrong.
It's bad enough that I'm just going to switch to Python for this project.
Here in Poland there are two kinds of 'Python' job offers:
- 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.
So I agree that Ruby's reached an equilibrium at the moment, and is looking for what's next.
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.
I definitely wish I was writing something other than python. I did choose it, but it's not the language I want to be writing in. It's just the language that happens to have numpy, django, etc.
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.
Do you have pylint integrated with your IDE? It greatly, greatly speeds up the cycle around fixing basic problems like undefined variables or wrong method arguments. I don't know how I ever coded in python without it.
Is there another specific language that you would prefer to code in, or is it that python is simply your only, albeit inferior, option (i.e. the worst programming language except all the others that have been tried)?
I agree with you on static typing and functional style being strongly preferable, and that Python makes that style of programming irritatingly difficult, but it's not like JavaScript has static typing or pattern matching either, so it seems odd that it would be your preferred replacement. Why not wish for a replacement that actually has all of the features you want?
Haskell is my preferred replacement, but I don't really expect Haskell to replace Python. It might replace C++ or Java, however, or form it's own new niche.
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'm going to try and say this carefully, because I don't want to start a language war. Quite the opposite: I desperately want to change my views on programming languages.
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 wrote poorly, I wasn't meaning to imply js is haskell-like. It's scheme like.
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 })
My views are almost entirely functional - take a model as input, create some dom elements as output, and one side effect when updating the view.
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.
Thanks for the response. As I told Kibwen, the underscore library looks pretty neat. Also, my problems may have just been some brain damage on my part. I'd gathered that object hierarchies were the more idiomatic way to code javascript.
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.
I can't answer your question, but if you're looking to emulate a functional style in Javascript I'd be remiss if I didn't point you toward Underscore.js:
How likely is this hypothetical cleanup of JavaScript to happen, though? It seems about as likely to me as the likelihood of Haskell replacing C++ or Java; i.e. not very likely at all (even though I share your opinion that it would be a wonderful thing if Haskell were more popular).
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.
Javascript isn't Haskell-esque, it's scheme-esque. I didn't mean to imply it was a substitute for Haskell, merely that it's a better version of Python.
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
]
When you say "proper closures", do you mean anonymous functions? I can't think of any other reason why Python's closures wouldn't be considered proper.
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()
However, after reading the rationale[1], I tend to agree with this requirement:
"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'.)"
This is an annoying behaviour, but it is consistent with Python's design . It is not exactly caused by broken closure, rather by the object model of python, and how named are bounds to objects. While this does not make it less annoying, it explains why the difference between using x vs x.val is logical from python POV.
Nice point, and really, how many folks actually find writing code in Python cumbersome or "work" like some languages? It's not perfect and of course if you need really fast computing, it's obviously not (even close to) the best for speed, but it's expressiveness & readability are a pretty big step up from most other languages.
Also, I hadn't seen this essay by PG before (from the comments); a bit old, but interesting take:
Just for the record: I used Python at work because I had to; I'd rather have been writing Java.
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.
In terms of imperative languages, python is #2 for me. And really I haven't done much python in the last couple of years mainly because anything I would want to do in python I'd rather do in ruby. Of course you will definitely hear me say, "I'd rather use python than Y" but I'd also say, "I'd rather use ruby than python"
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?
> I don’t know much about the Ruby world, but I wonder whether the increasing popularity of Ruby for web development has created pressure for Ruby to compromise its original philosophy. And I wonder whether Ruby’s creator Yukihiro Matsumoto has “dictatorial” control over his language analogous to the control Guido van Rossum has over Python.
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.
Agreed, but I confess that I'm also a bit unclear as to Matz's active involvement with the language. Every "Ruby expert" post on HN seems to originate from either Yehuda Katz or DHH... is it just that Matz prefers to communicate in Japanese, on Japanese mailing lists?
Matz is deeply involved with the language's design and a couple of its implementations but as a community leader, in the West, at least, he doesn't do much or have much impact IMHO. This is part of the reason people, rightly or wrongly, have seen the well known Rails developers as figureheads for both Ruby and Rails and then poured scorn on Ruby for their actions.
It is false because I am a person who writes LabTalk and I did not choose to write LabTalk. I hate LabTalk with a passion. However, I am forced to write LabTalk to interface with one of the systems at work. The following statement is also false:
People who write Tcl choose to write Tcl.
I had a coworker who was forced to learn Tcl to maintain a legacy system. He hated Tcl, mostly because it wasn't Fortran. Honestly, though, I have a soft spot for Tcl, so the following statement is true:
Some people who write Tcl choose to write Tcl.
Now that statement is trivially true and most of your original argument applies to it. In fact, I'll even agree with you that
Some people who write X choose to write X
applies to virtually every language. All people who write a language different than Python are people. The original statement does not make that claim. It makes the claim that the set of people who write python does not contain any elements from the set of people who did not choose to write python. That claim is not true for Java, Perl, C, C++, LabTalk, or Tcl. It may not even be true for Python. However, it is a meaningful claim.
I suppose there are degrees of how free your choices are. Do people choose to use JavaScript for client-side scripting? Technically you have other options, but most people write JavaScript whether they like it or not.
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.
Another way to put it would be to say that some languages are easier to avoid than others. I claim that it's easier to avoid Python than it is to avoid, for example, JavaScript.
EDIT: Python is my favorite language. But I wish a LOT more very lazy people or people who can't apply algorithms to solve their own problems (and hopefully in all the same domains that I work in) used it, discussed and asked questions, etc.
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.
I am having difficulty figuring out your point. Is it that, when you Google for examples for how to do something in Python, you usually don't find satisfactory results? But that other languages (Perl, PHP) do provide such results?
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.
I'm sorry my point was unclear. Often I place speed (i.e. time-until-I'm-not-doing-this-anymore) at an incredible premium to the point where I don't care what the language is! For example, say that you want to attach a process to monitor a logfile of your web-server(apache, say) and SEND YOU AN EMAIL when a string enters that logfile.
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.
I understand what you're saying, but I still don't feel that its relevant. Your example is the sort of thing that I would expect myself and other developers to be able to produce a more reliable solution on their own than what they could copy-and-paste from the web. In other words, I wouldn't do it myself because I felt like I "had to scratch that itch." I would do it myself because otherwise I would have no trust that it would work.
Right, I think your final sentence gets at the crux of what I'm talking about. I have 0 trust in PHP that my script really 'works' -- however, very often I have a lot more confidence in being able to get to something that 'seems to work' within 30 seconds. Whereas, in Python I am pretty much guaranteed to spend 5-15 minutes on it.
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.
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.