The most interesting point that you raise is how fragmented the libraries/frameworks are in Python.
The reason why this hurts Python is because there is no "one true framework" for web development. From my count, there are TWENTY-TWO web development frameworks for Python. It is simply impossible to be able to objectively evaluate each one, and, more importantly, figure out which one will continue to be developed and supported. If I choose to go with Django, am I sure that the project will still be actively developed 3 years from now? However, you can be pretty darned sure that Ruby on Rails and .NET will be.
How can you be so sure about Ruby on Rails and not Django? They are both similar in community support and development, but yet somehow ROR will surely survive while Django will not?
.Net will survive because it is backed by MS, but If 37signals goes out of business, or if DHH gets hit by a bus, ROR might start to look a little shakey, no?
I think the ease of using a library in Python can't be overstated.
The Python culture seems to encourage developers to say upfront exactly what their library is for and how to use it for many common tasks. Almost every library I've downloaded had a transcript of a REPL loop showing how to use it, and I could get started without any documentation.
My experience with Java has been the exact opposite. I'm not sure how C# fares, but it's definitely important to consider how much time you'll spend learning a new class hierarchy just to find out that the library doesn't even do what you wanted.
Reasons that RoR will continue to be developed:
1) It is THE framework for Ruby development
2) It is more popular than Django
3) It is solidly in the 1.x development cycle (has at least a 1 year head-start on Django, who is at .91)
4) It has the backing of BOTH 37signals AND the open source community. If everyone at 37signals stops working on Rails, development will still continue. Version 1.1 had 100+ contributors- 3 or 4 of those probably came from 37signals.
5) It has a bigger backing by industry heavyweights and a better selection of books (Amazon shows 1 Django book, at least 14 for RoR)
There are more, I'm sure- I didn't even touch on stability, feature set, or any of the arguments surrounding use of the actual frameworks.
It is true that for a while there was a void -- or if not a void, a jumbled state of affairs -- in the world of Python web frameworks. This very problem caused me grief on several occasions over the past 2 or 3 years.
So the situation is much better now, but (now to the point of my comment) Dharmesh's comments about the importance of both breadth and quality in standard libraries and a platform's ecosystem are spot on, especially if you're the sole developer on a startup. Without an ecosystem, you'll waste a lot of time fighting the wrong battles or reinventing wheels, which is why you don't see a lot of LISP or Haskell-based websites (here come the flames :P). For about a year and a half I built a web-based SAT prep course based on Skunkweb, a Python web framework that was far better designed than its competitors at the time (early '04) but never amassed an ecosystem, meaning that Googling error messages was often unhelpful and I was forced to hack in some missing features and to fix some bugs myself. Some would argue this is a victory of open source that you can even do this; I agree, but from a business perspective realize your competitors are solving real problems while you're stuck hacking "LIMIT x OFFSET y" SQL into your web framework's underlying glue.
I've just finished moving our SAT prep course to Turbogears (repaying some technology debt along the way while probably introducing some new bugs, but such is life) and it's much easier to add new features and a much more elegant design overall. Furthermore, when it comes time to add that second and third developer it will be much easier to find someone with Turbogears experience -- another benefit of an established ecosystem.
Anyway great article, Dharmesh (and good running into you at the Startup Meetup the other week) and for anyone out there who has been wishing for Python-on-Rails, check out Turbogears.
A few comments about this quite good writeup:
1) Events in recent days (the resignation of Zend's lead developer on the PHP project, and the abandonment of NDoc by essentially its only developer) make it clear that open source by itself isn't a protection against language / project viability. If you elect to go with an open source platform, you better be prepared to take ownership of its source base (though you'd not expect to have to in cases like Python or Apache). But if your company's lifeblood depends on that platform, you better be prepared to.
2) While Python has a very wide body of libraries, every time I go to use them, I feel like I have to re-learn them (granted I'm not in them on a daily basis). My point is that there dont' seem to be good standards for coding conventions, naming & capitalization, etc. With .NET, the depth and breadth of the standard library is a sufficient example to other library writers on the conventions that they should follow.
3) Python definitely lacks a web framework approaching RoR, let alone asp.net 2.0. Perhaps it will come. I'm a fan of RoR, but I'd never choose it over asp.net unless a client required the app to execute on a non-Windows. In addition to a first-class IDE to develop the app in, I get unbelievably complex but trivial to use controls (GridView, TreeView - and now the new Atlas ones) as part of the platform. Even though RoR provides fantastic productivity and a standard way to develop apps, it doesn't give me those kinds of features.
4) Now that IronPython 1.0 RC1 is out, I wonder if that changes the dynamic any. You get Python's productivity, improved performance over (C) Python, plus the .NET library and the ability to write libraries of your own in other languages if needed.
The Django community is very similar to that of the ROR community. It has 9 core devs and 80+ contributors *, has been around since 2003 (though only publicly since last year), etc., etc. Making a blanket statement that framework x will not but around, but your super-duper framework of choice will be, is disingenuous at best. In fact, these types of statements that are continually made by ROR fanboys keeps me away from the framework. Everyone needs to take a deep breath and realize that there is more than one way to build a web app, and more than one language that can be used. Yes, ROR is a great framework, but there are others out there that are just as good.
Now, as a disclaimer, I don't use Django. I actually use TurboGears. Nonetheless, it irks me when uninformed statements are made with regards to other frameworks that are not ROR.
I never said that Django will 'not be around'. I said that it is impossible to be certain that it will be, simply given the sheer number of web frameworks that exist for Python. Now that it appears that 2 frameworks have been established, how is an IT manager going to be sure that the one he picks will survive for the next 3 years? It is entirely possible that TurboGears is crowned by the Python community as "THE framework"- which would be fantastic for everybody but people using Django. That is a risk that certainly exists, and one that counts against (but doesn't, in and of itself eliminate) using any Python framework.
I know that there are more frameworks and languages than Ruby on Rails. I have used C#/.NET and have spoken very favorably about it. At this point (and until a surefire Python solution exists), there are really only 2 production-capable solutions: C#/.NET and Ruby on Rails. I'm not eliminating the possibility of a Python framework in the future, I'm just saying that no Python framework is there quite yet.
(It is entirely possible that, to you, the benefits of using Python outweigh the obsolescence risk involved with choosing a framework. I'm totally cool with that. It's just that, to me, Python and Ruby are equivalently good languages, and so the better framework wins. )
"At this point (and until a surefire Python solution exists), there are really only 2 production-capable solutions: C#/.NET and Ruby on Rails"
Just wondering, has anyone of you guys heard about that new Java, J2EE, Struts, Tomcat stuff?
Thanks for your response. Though I disagree with your statement that there are only 2 production capable solutions (Java?), I can understand your point of view.
You actually got it right in your last paragraph - I use Python because of the language rather than the framework. For example, I've recently used Python to create applications that interact with the Windows api via the win32 package, embedded a scripting environment into a Java application via Jython, and created web apps using TurboGears with MySQL and MSSQL. Though I have to learn new APIs (e.g. win32), I can still get things done in a language that I know very well.
I also like having the choice of web framework because each has its own strengths and weaknesses. Django is very popular for sites that are content driven like online newspapers (take a look here - http://code.djangoproject.com/wiki/DjangoPoweredSites), while TurboGears seems better suited towards traditional consumer oriented web apps. The point is that I can pick and choose according to the situation, but that's my personal preference.
Most programmers who don't use Delphi don't know about this, but the ecosystem of Delphi used to be one of it's extremely strong points. There are tons of quality third-party libraries and components for Delphi - check out http://www.torry.net for a list of components. Many of these come with free source code.
As a C++, Delphi and VB programmer I can say that 2-3 years back the Delphi community was more supportive than C++ and VB communities. Lots of code is available, lots of components, etc.
Why was such a strong community possible? Because Delphi was in an unique position back then - a language powerful enough so you can build extremely powerful libraries (unlike VB) but which also allowed RAD - Rapid Application Development.
A few years ago this was unique. Other choices were C++ (powerful language but no RAD), VB (RAD but very weak language), Java (no RAD, not good enough for building desktop applications when comparing to alternatives), Python (same as Java), etc.
So there was a very strong group of very smart people who gravitated towards Delphi because it occupied that unique market position (very powerful language, RAD, suitable for developing desktop applications easily, native code compiler so the resulting code was as fast as C++ code).
At the time of Visual Studio .NET 1.0, Delphi was still unrivalled. It was a lot more mature and more powerful.
However, Microsoft kept developing VS .NET and the .NET framework and so today Delphi has few advantages when compared to VS .NET 2005.
So now Visual Studio .NET 2005, C# and the .NET Framework take almost the same market position that Delphi has (and many other market positions as well).
Borland made very serious mistakes. They did not invest enough in Delphi development. They jumped on the .NET band-wagon instead of focusing on the native code compiler (which is still a huge advantage, even with Pentium 4 3 GHz processors available - if you believe that Java or C# programs are faster than Delphi programs, just do a benchmark yourself - you'll be astounded at the speed of Delphi's compiled native code).
The same group of smart people who were drawn towards Delphi are now drawn towards C#, VS .NET 2005 and the .NET Framework.
The Delphi community still kicks ass. Lots of information and components are available. When I need something, I just search using Google or Google Groups and I find Delphi information, source code, etc, more easily than C# .NET information.
But, the community is indeed on the decline.
Borland is now willing to sell it's tools division (including Delphi, C++ Builder, JBuilder) and claims it found a buyer. Frankly, this adds a lot of uncertainty.
I blame Borland for the bad situation Delphi is now.
They should have continued investing in Delphi and breaking new grounds, instead of just slightly improving what was already available and of jumping on the .NET band-wagon.
Java is not (and hasn't ever really been) a viable option for web applications for a startup.
Maybe if you're a huge organization and can afford the massive amounts of programming time and the huge time-to-market that developing a web app in Java demands, then it might be a viable solution. But since this is a startup blog and 99.9% of startups shouldn't consider building a web app on Java, I completely left it off the table.
The .NET framework is awesome (ok, I'm biased and MS don't pay for this honest!!), but the CLR is the reason why you need to use .NET.
Target the CLR and amazing things happen, ASP.NET is such a powerful platform and coupled with C# is really very hard to compete against.
As for the java comment I disagree, I have created apps in java that have taken around the same time as asp.net.
I think also the IDE is another factor, but Sun Creator goes a way to narrowing the gap for web stuff.
Java struts, JSF etc is a great technology and has its market and its a big one but for me ASP.NET is hands down the winner because I can do so much stuff and leverage the CLR.
"Borland is now willing to sell it's tools division (including Delphi, C++ Builder, JBuilder) and claims it found a buyer."
--> is this confirmed/reported or your guess?
Great post, but that point #5 has got to be the longest paragraph I've seen since reading the Gettysburg Address translated into Hawaiian! :)
I'm rather puzzled by this discussion! The *main* point of Java seemed to be "write once, run everywhere". Of course in practical terms it's never that easy, but that seemed to be the main point of it. I've always thought that a *main* point of .NET is to allow you to *write* in more than one language. A huge value of IronPython (to MS) is that it hammers out most of the issues of supporting dynamic languages in a framework that started out with only static languages. Other dynamic languages will (and does) follow. And with mono, you can still hope to "run anywhere".
In other words, if you have to decide between .NET and anything else, you probably shouldn't compare C# to another (supported) language, but rather if the .NET framework itself supports everything you will need.
Choosing .NET does however allow you to hire *both* C# and Python programmers, so many issues discussed so far seems slightly irrelevant to me.
Note that allowing use of "any" language creates a need for programmers willing to at least understand source code in other languages, as well as a company philosophy of programming that supported interchangeable source code. I suspect "agile programming" is relevant here. I'd like to point out that both attitude and philosophy seems to be widespread in the Python community.
On a more personal note:
I used to be a VB programmer, so I know how it hurts to depend on MS for anything. As I'm out of this business for a while, I've had time to look around and evaluate where I should spend time upgrading my skills. Cross platform is an obvious criteria, learning both dynamic and static languages well is another.
I choose to start with Python early, and C# soon after, even at a time when the Python community thought .NET was unusable for dynamic languages. The readability of Python was the first that attracted me to it, but the thing that made me stay was the friendly and quite fair attitude towards other languages. (See earlier comments to your articles for examples of how unusual that is...)
C# was not so easy to choose, with VB.NET calling. My mind was made up by all the negative VB.NET reports from former VB programmers, and my impression that C# was cleaner and in many ways quite similar to Python. Of course without a credible mono making sure of cross platform support, non of this would have mattered, but with both mono and dynamic languages aboard I can't see how .NET will not be part of my future.
Of course, just as it seems wise to make websites work in standards supporting browsers first then adjust to also work in IE, I'll make my programs run in mono first before adjusting to also make sure they work on the MS OS and .NET. If I've learned on thing, it's that you have to be on the alert to keep MS honest...
Bob, here is a link to a news article stating that Borland has found a buyer for Delphi.
However, they don't specify who the potential buyer is.
Why is cross-platform support so important? Who are the customers who require this?
In my mind, if I write a desktop application, then it must be for Windows, because Windows has over 90% of the market.
If I write a server application, then it must be for Linux.
I have worked for lots of clients and the requirement of writing a cross-platform app appeared very rarely.
Also, many times when writing a cross platform desktop app, the resulting application doesn't have the right look-and-feel on any supported system.
So in my opinion cross platform development is:
- rarely needed
- even in the very rare cases when the clients claim they need it, in fact they don't
- a poison, because it produces apps which don't have the right look and feel on any system
I find it interesting that in this whole commentary on frameworks/languages, we devolved somewhat into 'whose first'. And thru this entire discussion, everyone has avoided mentiioning the 800# gorilla in the room. The product has been around since 1998 as open source. It has a huge following. The company that supports it has a 8 figure income stream. They provide a full training program behind the product as well.
The product? Why Zope of course. It's as far as I am concerned the grand daddy of open source frameworks. RoR, Django, Plone, Turbogears geeks were still doing highschool composition when Zope was in some major corporations. And the language that Zope runs on....(wait for it)....Python.
To a certain extent I can agree that there are aspects of Python that lack documentary excellence as opposed to MS. Sadly the mechanism is there to use right in the language. As opposed to a nice fat manual for .NET. And if the docs for .NET are wrong how are your to fathom how to use a particular function? Spend a couple of hours scratching thru MSDN Knowledgebase? No thanks. I'll pop open the Module in Python and take a gander at the args list for myself.
As to framework fragmentation in Python. Yes and No. Yes, since if you go out to the Python.org site there is like 20 templating systems alone. More than a dozen parsers. And 2 to 3 dozen web helper tools. Dang confusing I agree.
But you have to ask yourself, why? Could it be that is just too easy in Python to do so? I say yes. For in the foundation modules that come with Python are a couple of extremely powerful tools -- urllib2, HTTP, HTTPBase, written and ready to go. With these you can pretty much develop anything from a full blown web server (4 lines of code) to an entire framework.
For eample the other day I wrote a forms input presentation tool in a couple of hours. Just a couple of base modules, YAMIL and a previously written DOM module. The reader sucks in the YAMIL strings and there is the input form page fully formed. Yes I could have used MochKit. But it was really overkill for what was such a simple web page. Could I have written the page in the same time with hand coded HTML strings, sure. But not the next time. If the next customer needs full validation of input then I pull MochKit off the shelf and use it. Point is sometimes I need a hammer, sometimes a pile driver. But I have always believed that needs drives the tools.
The other consideration on Python as a whole is the belief in certain business circles that its use is a strategic advantage to them. If staff productivity is 2-4x higher (as some claim) with this language and you are a tech company that lives by its bits then anything, including a language choice, will not shout that advantage from the roof tops. It will be a quiet murmur of 'yes we use it' and the topic will be changed.
Poppycock? But consider, Google admits they use Python but they won't say to what extent. But it is interesting that in the end Google extended an offer to Guido to work for them, which he accepted. I would say that is a clear indicator that Google wishes to protect what is probably their biggest strategic asset by keeping the creator in house and assuring that the language will remain in development. So in a sense, as I view it, Python has a corporate benefator now that ranks to the of MS itself.
Nice followup post.
A previous commenter asked why cross-platform support is so important? If you're doing development work for a client, then that's not as big an issue. You develop for whatever platform they have in-house. But since this is a startup blog there's a presumption that you'r either building products for distribution or web-based services. If you're building products and it doesn't cost you that much more to go cross-platform it's silly not do it. Yes, Windows has 90% of the market (and nothing anyone outside Microsoft builds will ever get to all of them) but that's like McDonalds saying they'll *only* build new outlets in New York and Los Angeles because that's where most of the people live. Your most passionate users who help build the all-too-valuable word-of-mouth may very well come from niche communities and platforms. Ignore them at your own peril.
I like what C#/.NET/CLR is doing in unifying client and server side development, but other than some cool widgets, I don't see much advantage over Java/J2EE/Struts/JSF. With wxPython on the desktop and Twisted+Django on the server, you get the same thing, but cross-platform (albeit with a native GUI) and much less resource hungry, esp. for a small startup. As I mentioned in the comments in the last post, the productivity gains with Python make it a lot more compelling if you have a small team.
I don't think it's productive to engage in a Rails vs. Django dispute. Each have their pros and cons. For those interested, the creators of both frameworks gave a talk last year in Chicago and the video is here: [http://www.djangoproject.com/snakesandrubies/]. I personally found it very illuminating to hear from both camps.
The ecosystem around a platform is one of its biggest selling points. However, these things take time to develop and require people like us to be participants rather than what Bittorrent calls 'leeches' ;-). There seems to be an ebb-and-flow to these things and it's hard to gauge what stage your favorite tool is at. For me, it's always been a gut feeling rather than the hype factor or the number of books up on Amazon (quite a few of which are slapped together me-too efforts driven by publishers rather than demand).
I personally like the fact that there is more than one framework in Python. It gives me more options and hopefully spurs the framework developers to try to borrow good ideas from other tools.
I have a few other thoughts on startups creating their own micro-ecosystems but it's not directly related to this post. It's here if anyone's interested: [ http://ramin.wizen.com/2006/05/09/micro-ecosystems/ ].
BTW, I tried posting this once and it came back with a time-out. My apologies if it shows up twice.
I have been a Delphi developer for over 7 years now and I agree with Mikes comments regarding the slow decline of the community and Borlands large part in that.
I'm in the midst of a Web startup and have chosen not to use Delphi, it' sjust the wrong solution for a web app.
I'm trying to pick a framework/language to use myself for this startup. I have basically come down to Ruby/RubyOnRails or Php/??.
I'm leaning towards Php just becaus eit's so pervasive on the net and seems to have lots of resources. But I have spent the last week trying to find a suitable framework and nothing sticks out as being mature and well supported in the community. Really not sure what to do.
in any case , if you choose to use c# , what about using python for unit testing c# code ? great productivity and readability imporvements , with most of the issues mentioned in the articles not relevant .
the major drawbacks of using such an approach are :
1.switching between 2 languages
2.learning the 2 languages (altought learning python to a usefull level is quite easy and fast)
Great series of articles. But I have to point out that your navigation system is completely broken. I have to keep going to Google if I want to go to the next article.
. If I choose to go with Django, am I sure that the project will still be actively developed 3 years from now
Well, it's 2009.. and um.. RoR is not doing so great compared to fast, robust and ever improving django.