Why did Quora choose Python (over PHP and others) for its development?
quora.com
quora.com
As far as I can tell there seems to be a lot more peripheral innovation in the ruby camp though, particularly in testing tools. Are there python equivalents to rspec, cucumber, factory_girl/machinist, shoulda, passenger, haml, webrat etc?
The ruby world seems to focus its innovation around the major framework whereas the python world seems to be experimenting at a more fundamental level.
I got two theories.
First theory.
Ruby allows developers to make really nice DSLs. (Domain Specific Languages) It makes sense to me that there would only be two major frameworks. Rails fills the need for a batteries-included framework and Sinatra is the a light weigh, nothing included framework. Both have expressive enough implementations that the community doesn't build their own frameworks.
Python doesn't make as pretty code for a DSL which makes it more likely to hit pain points in expressing what you want. Then you end up with a fragmented community around these different pain points.
Second theory.
People start using ruby because of rails. If rails is too heavy, they move to sinatra. Most of the people using ruby can't be bothered to write their own framework.
Most people using python learned python before web development. They are more experienced in the language and used to doing their own stuff. They try out different frameworks and if they get disgusted enough with them they create their own.
Disclaimer:
I'm a ruby guy. I used python for two years before learning ruby and then rails. These are only theories. I probably look at ruby more nicely than I should but I tried to be somewhat objective.
Writeability and readability. The ability to bring in domain experts which have no knowledge whatsoever in programming as well.
> but can't really think of many use cases for DSLs (apart from business rules).
Any domain-specific knowledge/data may be encoded as a DSL, and benefit from it. The rules of your business, the URL mapping of your framework, the GUI layout of your application, the steps of your tests, ... In fact, they often are (in WPF, XAML is used as a GUI definition DSL; Ant is a domain-specific language for building applications, so is Make).
The great advantages of the likes of Ruby, however, is that you can build DSLs in the language itself (you don't have to build your own compiler and translator from DSL to language), which rids you of most of the complexity and limitations of usual DSLs, and lets power users realize that there is a full-blown general-purpose language under the DSL (and use that power when they need it).
But I agree, I learned Python because it seemed like a great language, and learned Django because I was moving into web dev after years of other work with Python. I don't believe I'll ever pick up Ruby for anything other than learning Rails (and I doubt I'll even do that, since Python is so similar).
http://www.google.com/insights/search/#q=ruby%20AND%20rails%...
Just take a look; the django bar is not even a bar, more like a square. Rails seems to have a 40:1 edge over Django in popularity.
The other thing you will notice is that India is where Rails is most popular; but try to pull back the timeline slider and play with it a bit. See how different countries discover rails at different times but soon after lose interest? Except for India, it stays popular there.
Comparing search traffic for django/python to ruby/rails has nothing to do with this.
But note that most people searching for Django will use only the name Django, whereas Rails is often called "Ruby on Rails", meaning searches for "ruby and rails" will naturally tend higher than "python and django". Again, I'm not sure I understand your point, so I don't know if this means anything.
rspec: I'd argue doctest does the same thing, but without being clever consultantware. I've seen passing mentions to similar things in Python.
cucumber: http://lettuce.it/
factory_girl: I can't keep up with data fixture libraries, but there's quite a few
machinist: I don't quite understand it. It seems like a mocking library to me? There's a half dozen of those at least...
shoulda: Seems like Cucumber? I don't get this one either. Just a bunch of comparison helpers for your testing?
passenger: as in mod_passenger? Technically it supports Python. mod_wsgi is very similar.
haml: there's a bunch of more-or-less direct ports.
webrat: Twill, WebTest, zope.browser are a couple.
There's a lot of testing tools in Python; this list is very out of date, but at least shows some of them: http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy
Interesting that they took this bit of wisdom away from programming in PHP.
I say this because I've never heard anyone consider a lack of type-checking as an issue when considering Python. It's a feature. You either need type-checking or you don't. I suspect that the Quorum engineers didn't need type-checking, so I don't understand why the felt the need to consider it an "issue" with choosing Python.
Spare yourself this yammering rant. They chose Python because that's what everyone else at the company was cool with. End of story.
That's not really correct. In general, nobody needs type checking (it's not like there's any actually done where it would be needed the most), but it's "free" error checking. Always nice to have.
But it is a feature to balance against others.
Anyway, considering how weak the type systems of "industry standard" languages are as opposed to Ada, or MLs, or Haskell, the common type-checking trope is mostly a huge joke.
It just seems that in most cases it isn't actually required.
I don't think it's a bad idea to evaluate the alternatives, even if you are very comfortable with a specific language. Granted we were pretty cool with Python and that is definitely a major factor in the decision, but it can't be the only one.
For example, we were all very comfortable using SVN (another technology Facebook uses and is now locked in with). But we didn't use Subversion; we decided to use Git, because the advantages of using a DVCS outweigh our personal sense of comfort.
I just don't understand why type-checking and speed were factors in choosing the language you were after. If they were, then why even bother looking at Python at all? It isn't a fast language and doesn't have type-checking.
The rest of the article is spent telling me why these features aren't important. Both C# and Java have type-checking (though C# perhaps is a little more loose) and are pretty fast. Yet the article claims that Python is fast enough and that type-checking isn't a requirement because you're more concerned with value assertions (and unit-tests are good enough to validate them).
So essentially the article sets up false premises and knocks them down one by one. Type-checking wasn't actually a requirement. Neither was speed. The only reason we are left with for why Quora chose Python was because that's what most people were familiar with.
I'm not saying it's a bad choice or that your conclusions were incorrect. I just don't think it was a good article.
Let's put it this way: if any of those languages had half the library support that Python did, then it would've been a decent fight. But as it goes right now it's not even close.
EDIT: Sorry, the library support only applies to ML and Haskell, and I forgot about Scala. I'll have to think about this one; I'm not sure the reasoning for that was entirely well fleshed out.
Can anyone elaborate on that or point to some reading?
then incrementally add code as you need it, how/where you need it, including how to persist
But if I'm very confident it's going to become part of a long-lived dynamic web service with enough of the features Django provides anyway -- especially that awesome built-in admin UI -- then yes I start with Django. The mindshare/community factor is helpful too. I know there are other web frameworks which are decent but going with a big framework other than Django in the Python space today is a bit like going with FreeBSD rather than Linux when all you really need is some sort of free Unix. To pick Linux is to get a bigger ecosystem today and therefore probably also a longer supported future.
But why wouldn't you use a relational database? It works, the ORM's good, it's fast enough, you're probably not going to hit scaling problems. If you do hit scaling problems, then that's a really really good problem to have.