This post originated from an RSS feed registered with Python Buzz
by maxim khesin.
Original Post: .NET training week
Feed Title: python and the web
Feed URL: http://feeds.feedburner.com/PythonAndTheWeb
Feed Description: blog dedicated to python and the networks we live in
I am on the last day of company-sponsored .NET training week. And... it's good.
Ok, I am a bit of an anti-MS bigot, and it took me forever + huge pain of doing Windoze GUI in C++ to start looking into this. My bad. I think the technology is fabulous, and here is why, so you don't repeat my mistakes.
One part of .NET is a huge library API, similar to JVM. One notable difference: .NET started off as a layer that is meant to support multiple languages. This shows, not only in its technical characteristics, but also culturally (which is arguably more important). There are historical reasons for it, C++ and VB, but it's gone well beyond that now. MS seems to have (once again, historically) become a valueble contributor to language innovation. Don Box, 'the Essential COM' guy, likes quite a few cool languages. MS Research released Visual Haskell.
And while Java was always technically capable of hosting other languages, they lost the war there by overmarketing Java, which many hackers (deservedly ;) hate. I mean, calling your platform Java is not very inviting for other language developers.
So, the platform is build from ground-up with multiple languages in mind. In return, the languages get quite a bit of goodness back from the platform.
Take for example the currently-defunct restricted python execution. As far as I understand it became deprecated because security holes kept on getting found, and given Python's philosophy of giving a lot of freedom to the programmer plugging them all was not really economical. But the idea of restricted execution is definitely valueable, now what? Well, .NET takes care of it. This is possible A) because .NET is closer to the OS, with the hosted languages sitting on top B) it is economical for a platform to solve this problem. Not only some kind of solution, but really fine-grained control over what each programming artifact (modules, namespaces, classes and functions are all 'types' under .NET) is allowed to do. I think this is pretty cool.
Now, C#. Quite good! As I was listening to the course I was thinking of all the pains that C#/.NET would have saved me in the main project I work on. It's a Windows/C++/ATL app. Now, I happen to be a sucker for some of C++ incredible power, particularly the crazy things you can do with templates (and stop sneering, Peter Norvig for one recommends studying C++ for this reason). Using these tricks the martians who run boost.org managed to implement quite a few higher-language constucts (currying, lambda, multicasting) right in C++. I love this stuff, but it's hard for busy people who didn't 'get into it' in 1990's (read: coworkers) to jump on the learning curve of specifying just the right things in the quirky template syntax. So we often end up using more code, in different styles, and reimplementing some common patterns (Observer, for example) in 15 different ways.
C# gets a lot of this stuff as 'batteries included'. Here is a brief list of features:
- anonymous functions (python: ~lambda) - function objects via delegates - observer via multicast delegates - closures - generators! (python: generators) - foreach loop (pyton: for) - using blocks (pyton2.5 'with') - nice asynchronous execution model (part of delegate functionality) - attributes (some sililarity to decorators, but they do not get automatically executed, only create type metadata)
So, at least some or our dayjobs are going to be (a lot!) more tolerable. I am not the only one who noticed (scroll to the end of the post).
Previous Topic
