This post is part of the “MIX10 – Pumping Iron on the web” series:
- Part 1 - Introduction
- Part 2.1 – Server-side web development with dynamic languages
- Part 2.2 – Client-side web development with dynamic languages
- Part 3 - Using scripting in static applications
- Coming soon: Part 4 - Web-app extensibility with scripts
The original post was mistakenly removed, so it’s been reposted with the original post date, 4/24/2010. Sorry if this confuses your blog readers or causes any other inconvenience.
This past week I had the pleasure of attending and speaking at MIX10 in Las Vegas about using IronRuby and IronPython on the web. If you’re a TV-person instead of a reading-person, here’s a video of the talk:
As I usually do, this series of posts will be a write-up of my talk … but first …
iron? - Jim Hugunin and John Lam have both been quoted as saying "Iron" stands for different acronyms; "Implementation running on .NET" and "It runs on .NET", respectively. I’m going to put my foot down and officially side with Jim, though really they are bacronyms; neither is actually the original meaning. A StackOverflow post explains more, and I hope that puts the wondering to rest.
This talk is all about the why and how of embrace dynamic languages on Microsoft's web platform - be it on the web-server (IIS) or in the web-browser (Silverlight), and even in existing applications. To start out with, here’s my rational for why we as a developer community should care:
It’s no secret that developers like things to be simple, and the web is pretty simple as far as application models go. While the web’s feature-set is pretty attractive itself (server-client oriented, instant client deployment, and cross-platform clients to name a few), the equally attractive development experience (simple UI mark-up system and a scripting language) still make it easy for people to build amazing websites.
Though the application model is simple, developers continue to evolve it; server and client frameworks are vital tools that make the web-development experience even more productive – it’s very rare that a website has no server side or client side dependencies.
These frameworks provide such innovative features because they stand on the shoulders of powerful and expressive dynamic/scripting languages, giving the frameworks the unique ability to model the "web" as they see fit.
While each web-framework is powerful in its own right, the power really comes from the choice to use whatever tools help get things done. Developers and designers for .NET have the same need to get things done, and if getting things done is essentially the result of programming language choice, what choices are there? Really only C# and VB, which are static programming languages, requiring a compile step before execution and relying on debugging to see code in action. Take a look at the other languages mainly used on the web again -- they're all dynamic languages, running from source code, and providing interactive environments for running code. Why is .NET static while the rest of the web is dynamic? Why can't they exist together? If .NET provided some language choice for developers, all the languages be used together, and the .NET community could benefit from the amazing work being done by dynamic language community, and visa versa.
We in-fact live in this world, and embracing dynamic languages is possible on .NET, but why would you want to do it? I'll discuss this in the following posts (links to posts coming soon):
- Server-side web development with dynamic languages
- Client-side web development with dynamic languages
- Using dynamic languages in your existing web-applications
- Coming soon: Opening up your applications to extensibility with scripts