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