Python vs. C#: Frameworks, Libraries and Ecosystems

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.

Community

Google+

And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:

Google

Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Answers.OnStartups.com

Subscribe to Updates

 

30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn

OnStartups

Current Articles | RSS Feed RSS Feed

Python vs. C#: Frameworks, Libraries and Ecosystems

 


This is the third in a series of articles in looking at some of the tradeoffs between Python and C#, particularly for startups.  The first article is here (which is not necessary reading, as it provides some background).  The second article is here, which is likely worthwhile if you’re interested in the topic.  

In this third installment, I’ll take a look at the issue from the perspective of frameworks, libraries and ecosystems for the languages.  In response to the prior two articles, there have already been some great comments regarding this, so I’ll try and weave in some of those user-contributed points as well.  Apologies in advance for the length of this article, it’s a stream of consciousness type thing which will bring in a variety of semi-connected thoughts.  

First off, I think the availability and viability of existing code in the form of frameworks and libraries is likely as important as the structure and expressiveness of the language itself.  Chances are, if your startup is looking to pick a language, it has some product idea in mind (for example, a hosted web product).  In these cases, much of the code you’ll need to create your end product will be “foundation” code.  As such, most of the contemporary languages (including Python and C#) have frameworks that are oriented towards creating particular kinds of applications.  For purposes of this article, we’ll look primarily at web applications (because that happens to be what I’m interested in), but there are similar considerations if you’re building desktop applications or other types of applications.

Since I have not worked professionally with Python (yet), I will refrain from making any value judgments but will limit myself to things that I’ve heard from trusted sources and let the community respond and push back on points that I’m mistaken on.  (Note:  I like to number my thoughts, not to represent any type of linearity, but because it makes it easy to refer to specific points in the comments).
  1. You Need A Basic Web Framework:  Back in the day, when I did my first web development (1996, in C++ on Unix) hardly anything existed to ease the pain of web development.  Basically, our web applications had to do everything – including parsing the raw input stream (we used CGI back then) and building the requisite “response”.   We had our own state management system, and had to deal with things like load balancing and security.  Over time, we built a large and robust body of C++ code to abstract away much of the complexity.  This was a bit painful, but in the long run, we really understood what was going on under the hood and I think this gave us a better appreciation for how to design what we needed.  I also had the benefit of working with some really gifted C++ programmers, and the resulting proprietary framework gave us an “edge” for some time.  These days, there are web frameworks that take care of most of the basic stuff you need to do to write a web application.  For C# (and the other .Net languages), we have ASP.NET (now in version 2.0).  For Python, there are frameworks like Django.  Now, here’s the rub:  I think some Python programmers have felt the need to “roll their own” web framework.  It may be because projects like Django are relatively new.  This is troubling to me.  In my opinion, to create a robust body of foundation code for the web right now is non-trivial.  There are just a lot of “gotchas”, particularly when it comes to doing sophisticated state/session management, security and abstracting some of the UI so that you don’t have a bunch of HTML string concatenation all over the place.  I have a bias here, but I think that those that roll their own web framework code today do not have an appreciation for how hard it is to do this stuff right – regardless of what your language is.  So, if I were picking a language today, having a robust, well-tested and easy to use core web framework is essential.  From what I know, I think Python has these frameworks now – but they came a little late.  As such, too many people are out there running on their own custom web frameworks.  


From a comment to my first article by Eric Peterson:   “For me, that answer is Ruby on Rails for most web applications. Python just doesn't have a good enough Web framework for it to really be a contender- if you used Python without a framework, you'd essentially be rolling your own, which is a lot of overhead before you can even begin to concentrate on your actual business problems. .NET probably lies somewhere in between, with the only two big things being object persistence and testing.”  Though we’re not looking at Ruby On Rails in this series, I think Eric’s comment is somewhat telling.  Earlier in the comment he posits:  “The major question is this: Which language/framework will let me concentrate more on business problems and less on technical ones?”

I can’t substantiate Eric’s claim as to whether or not Python’s web frameworks match that of RoR (or ASP.NET) and whether they’re sufficiently evolved or not.  But, the basic point is this:  If you’re building a web application in today’s world, you need a robust framework on top of which to build.  Inexperienced developers too often trivialize this effort (because fundamentally, it seems simple).  It’s not.  Also, the state of web programming evolves.  If you roll your own, you will have a harder and harder time keeping up.  That’s code your competitors are not writing, so you are at a disadvantage.
  1. You Need Other Libraries:  Most web applications (particularly business applications) will need to do things other than just process a web request and send back a web response.  Common things are interacting with databases, file systems, XML documents and server software (LDAP, SMTP, POP3, FTP, etc.)  Based on how much of this you’re going to be doing, the availability of usable third-party libraries can be a critical decision factor.  Often this kind of code, can, in aggregate match the effort required for a basic web framework.  So, it’s important to take an inventory of the kinds of things you’ll want to be doing and figure out what libraries are available to you in the languages you are looking at.  In this regard, both Python and C# likely have sufficient existing code out there.  The difference is that most of what C# provides is buried inside the large (but mostly elegant) ..Net libraries.  For Python, you have a large and growing set of libraries for most things you would want to do today.  But, this does involve a “search and evaluate” process so you can pick the right ones.  There is certainly advantage to having a choice (so you can pick the library that best meets your need), but this choice has a cost.  We’ll look at this issue further below.

  1. Libraries Should Be Easy To Use:  One of the biggest challenges back in the day that I was using C++ was that it was very, very hard to take an existing library that was out there (and did something meaningful) and reuse it in your application.  Though C++ was cross-platform, the developers of the library had to ensure that they implemented the library in a way that made it usable across platforms (like Windows and Unix).  This was not always the case.  Further, using compiled libraries (without source) was near impossible.  On Windows, we had DLLs and COM and such but it was ugly.  Now, with languages like Python, reusing a library is simple and elegant.  That’s a great thing.  For C#, things are much better than they used to be (because the reuse model on .Net is much nicer than prior Windows technologies).  But, with C# you are somewhat limited to .Net and Windows.  Yes, I’m aware of the mono project but I still think that running .Net on something other than Windows requires a fair amount of rationalization.  Though at an academic level it’s nice to know that I can do it, I don’t know that I’d ever really want to in a commercial setting.  

  1. Standards vs. Choice:  We looked at this in an earlier section.  There is a tradeoff between having a single, highly popular library to do X vs. having a set of different libraries that do similar things but make different tradeoffs.  The advantage of choice (i.e. multiple libraries) is that you are likely to get something that more closely matches your needs.  Python definitely has the advantage here.  Most common needs in the Python world have more than one existing library.  With C#, the community relies mostly on what’s inside the .Net framework (though certain third-party libraries exist for specific kinds of tasks).  The advantage to a “standard” like .Net is that more people are familiar with the library.  For example, if you take a reasonably experienced .Net programmer (in whatever language), chances are, they have used the built-in libraries for most common things (serialization, database access, XML processing, etc.).  There’s a bit of an advantage to this, because libraries have a learning curve.  To find programmers that already know the core libraries is probably easier than finding programmers that know the particular library that you picked.  I compare this loosely to the splintering that happened back in the old Unix (before Linux) days.  We had Sun’s Solaris, IBM’s AIX and HP-UX.  All of these were certainly similar, but people became experts in one or the other.  This essentially divided the technical resources into one of the camps.  At a smaller scale, this kind of stuff also happens with libraries and frameworks.  If there are four different web frameworks, you’ll have four pools of developers.  Though there’s certainly conceptual overlap, there’s usually some advantage to the developers that have worked with this particular framework before.  So, this one is a case of balancing the tradeoff between standards (gives you a larger pool of people that likely know the body of existing code and how to use it) vs. choice – which gives you the advantage of picking the library that’s the most suitable for the purpose.  Choice also gives you, at some level, competition – which is a good thing.

  1. Ecosystems:  It’s going to be hard to fit all my thoughts on development platform ecosystems into one paragraph, so I’ll try and hit the hi-lights.  I would define an ecosystem (in this context) as all the resources that surround a core language and platform.  This includes developers that know and understand the technology, book authors that write about it, library developers that create reusable code for others, trainers that help people get up to speed, and tools companies that offer add-ons to make developing on the platform more efficient.  I cannot stress enough the importance of having a vibrant, growing and sustainable ecosystem for a programming language.  If you’re a startup, chances are that if you’re building a sufficiently sophisticated application, you’ll be needing one or more of these resources to create your application.  Further, unless you are “building to flip” (which I don’t recommend), you’ll need to support your application for years to come.  In fact, your margins will likely get higher over time as you have to write less and less code to meet new market needs.  As such, if the ecosystem surrounding your chosen language/platform declines significantly or dies, you are at a severe disadvantage.  Now, the issue is that nobody consciously chooses a language/platform with a dying ecosystem. It just turns out that way (usually 3+ years out from when the decision is made).  Thought it’s difficult to predict which ecosystems will endure and which ones won’t, we have enough history now to at least have a sense for some patterns.  Ecosystems that rely on a single company are vulnerable.  Hence the slow decline of so many custom development languages (Easel, PowerBuilder, Delphi, etc.)  [Note:  I have nothing against any of those languages, and I’m sure there’s a large pool of successful Delphi programmers still out there, but I will continue to maintain that the ecosystem for these languages is likely on a decline – of varying degrees of severity].  Of course, C# is also, for the most part, dependent on Microsoft.  (Despite the language itself now being released to the  ECMA).  But, Microsoft seems to be a special case.  Given their volume of resources and conviction around the importance of strong development platforms for their operating systems, it is unlikely that C# and ..Net will fail to maintain a vibrant ecosystem around them.  Evidence is already there in terms of the number of developers, books and third-party vendors creating technology on this platform.  Python has the power of a strong and vibrant open source community.  So, it does not face the same vulnerability of a single company “owner”.  This is a good thing.  Given the scale of use of Python already, it is unlikely that in the next several years we’re going to see a sharp decline in the vibrancy of the community.  Another reason that ecosystems decline is that the language was really good at a special kind of application and there is a technical shift that causes that kind of application to be less relevant.  For example, PowerBuilder was an immensely popular platform for creating client/server applications.  But, when the shift to the web happened, there wasn’t enough advantage anymore and other languages took over.  That’s why I like general purpose languages (C++, C#, Python, etc.).  They’re more likely to endure when the inevitable shifts in the technology landscape happen.  In short, ecosystems are important and should influence where you place your bets.  Both sides have pros and cons.  Microsoft has the resources and the incentive to make .Net work.  The Python community has the resources and the incentive (in aggregate) to keep Python evolving.  


Clearly, this is a complicated topic and I think I used way more words than should be allowed for so little concrete thought.  Apologies for that, but since I have not worked extensively in Python, I am not equipped to really take a hard stand on certain points.  As such, I’m simply commenting on patterns I see and identifying some of the tradeoffs.  If the past articles were any indication, we should see a robust discussion on some of these points by way of comments from my readership (which frankly, is the motivation for writing this series in the first place).

Thanks to everyone that takes the time to comment and share their viewpoints.  In the next (and last) part of the series, I’d like to integrate some of the reader comments themselves and get a sense of what people have said.  There will likely be 100+ comments across the various articles so this may take a few days to pull together.

Look forward to reading everyone’s thoughts.

Posted by on Fri, Jul 28, 2006

COMMENTS

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.

posted on Friday, July 28, 2006 at 12:44 PM by


Erik -

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?

posted on Friday, July 28, 2006 at 1:01 PM by Sean D.


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.

posted on Friday, July 28, 2006 at 1:36 PM by Toby Segaran


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.

posted on Friday, July 28, 2006 at 1:37 PM by


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.

However, now (maybe not "one true" but) at least two very solid and complete web frameworks have stabilized and started to gain traction. Dharmesh already mentioned Django, but I personally recommend Turbogears (http://www.turbogears.org). It's basically the amalgamation of several best-of-breed individual components including a robust templating system (Kid), object-relational mapper (SQLObject), HTTP server/request handler (CherryPy), and lots of tools to speed up AJAX development (JSON support and a javascript toolkit called Mochikit), handle forms, and generally smooth over most of the typical warts of web development. Having also navigated the murky waters from the mid-90s era CGI and server-side includes to the morasses of spaghetti code that PHP projects inevitably become, I can say that Turbogears is an order of magnitude more productive and maintainable. (Django is probably great too, I just haven't personally used it.)

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.

-Drew

posted on Friday, July 28, 2006 at 1:46 PM by Drew Houston


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.

FWIW...

Donnie

posted on Friday, July 28, 2006 at 1:59 PM by Donnie Hale


Erik,

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.


* http://code.djangoproject.com/browser/django/trunk/AUTHORS

posted on Friday, July 28, 2006 at 2:03 PM by Sean D.



Sean,

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. )

posted on Friday, July 28, 2006 at 2:31 PM by


"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?

posted on Friday, July 28, 2006 at 3:08 PM by fad


Erik,

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.

Thanks again,

Sean

posted on Friday, July 28, 2006 at 3:37 PM by Sean D.


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.

posted on Friday, July 28, 2006 at 4:53 PM by Mike Varian


fad, Sean-

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.

posted on Friday, July 28, 2006 at 5:40 PM by


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.

posted on Friday, July 28, 2006 at 6:40 PM by Granville Barnett


Mike,

"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?

Dharmesh,
Great post, but that point #5 has got to be the longest paragraph I've seen since reading the Gettysburg Address translated into Hawaiian! :)

posted on Friday, July 28, 2006 at 8:37 PM by Bob Walsh


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...

Nils

posted on Friday, July 28, 2006 at 11:31 PM by Nils R Grotnes


Bob, here is a link to a news article stating that Borland has found a buyer for Delphi.

http://www.channelregister.co.uk/2006/07/21/borland_tools_buyer/

However, they don't specify who the potential buyer is.

posted on Saturday, July 29, 2006 at 3:59 AM by Mike Varian


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

posted on Saturday, July 29, 2006 at 4:03 AM by Jack Halfmeister


To all,

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.

Erik,

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.

posted on Saturday, July 29, 2006 at 10:06 AM by John McGinnis


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.

posted on Saturday, July 29, 2006 at 1:30 PM by Ramin


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.

posted on Monday, July 31, 2006 at 3:47 AM by Max Powers


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)


posted on Tuesday, August 01, 2006 at 9:56 AM by anonymous


Hey, 
 
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.

posted on Wednesday, December 17, 2008 at 2:34 PM by Alex Krycek


. 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. 

posted on Monday, January 19, 2009 at 7:18 AM by drozzy


Comments have been closed for this article.