Weakly Typed Dynamic Languages and Natural Selection

I’m not reading much in the way of blogs or twitter these days – way to heads down in my new job for that right now. But I did see Scott Hanselman’s post on method overloading and dynamic types and Ted Neward’s follow-on post static-typing fundamentalism. Even though I’ve moved on from the IronPython team, dynamic typing is a topic that’s still near and dear to my heart so I can’t resist throwing in my 2¢.

First off, I agree 100% with Ted’s post – though not the over-the-top mocking tone. These static > dynamic flame bait comments are so tired that they’ve literally become cliché. I agree with Ted’s points, but by answering fire with fire he’s just perpetuating the flame war that he claims to be so tired of. I really am tired of it, so I’m not going to bother to address any of the original anti-dynamic typing faux-arguments (fauxguments?) nor Ted’s artful and devastatingly mocking takedown of them.

But I do have a question for any static-typing fundamentalists in the audience: if static typing is so much better than dynamic typing, then how come dynamically typed languages are so popular? Doesn’t natural selection apply to type systems?

Those aren’t rhetorical questions. Building software takes time and effort. While developers often donate time and effort to projects (see: open source) typically they work for money. That money has to come from somewhere – usually it comes from someone who needs the software built for some business reason. And the people footing the bill for software construction demand the highest return on investment they can get.

If dynamic typing or VARIANT (which is actually weak not dynamic typing, but I digress) really did create “horrific devastation”, wouldn’t that have caused a negative feedback loop where the business people who actually foot the bills for creating software became wary and untrusting of using VB as the language of choice for their projects in favor of strong and statically typed languages that helped developers “make good choices”?

Yet the opposite happened. VB was the most popular programming language in the world for the better part of a decade. And while VB’s reign at the top is over, I’d argue that these days the most popular programming languages are PHP and JavaScript, both of which are weakly typed dynamic languages too.

Now clearly, popular != better. However, static-typing fundamentalism isn’t an argument about which way is “better” so much as an argument about which way is “worthy”. But how can you argue that you’re approach is the only worthy path when the opposite approach has been so successful? Remember, one developer’s “horrific devastation” might be another businessman’s “successful project because it helped me enter a new market faster than my competitors”.

Dynamic Languages in Architecture

In the comments from yesterday’s post, IronPython MVP and author extraordinaire Michael Foord asked:

Has your view on architecture as a discipline separate from coding changed since working with dynamic languages?

In a word:“No” (though as always, I reserve the right to be wrong and/or convinced otherwise.)

When I was an architect, I tried very hard to treat it as a “discipline separate from coding”. To use my last post as an example, building a central repository of system audit information is an architectural decision. A bad one IMHO – at least the way Dilbert’s PHB described it – but an architectural decision all the same. It was a decision about what kind of system to build, part of an overall application portfolio, as opposed to a decision about how to build the system.

I’ve held this opinion of architecture for a long time. Four years (and three jobs) ago, I wrote the following:

IMO, building a system that has a set of functional requirements (track customers, process orders, etc) and non-functional constraints (sub-second response time, support 10,000 concurrent users, use Microsoft Windows platform, etc) is an engineering problem. Coming up with the lists of functional requirements and non-functional constraints is the architecture problem.

Working with dynamic languages has dramatically changed my view of engineering and design of individual systems. But from the pure architecture perspective, I want to be able to treat individual systems as black boxes as much as possible. That means the programming language is an implementation detail that shouldn’t matter to the architect.

Note the significant bet-hedging language in the paragraph above. I’m using phrases like “shouldn’t matter” and “as much as possible” because we all know that there’s no such thing as a “pure architecture perspective”. Unlike building architecture, software architecture is in constant flux at every level. At the enterprise level, there are always new regulatory obligations, new competitors and new partners to consider. At the end-to-end process level, there are always new systems or new version of existing systems coming on line. And at the individual system level, there are always new – or at least new versions – of tools, frameworks and languages being released.

Once you introduce time into your architecture perspective, individual system engineering will affect the overall architecture, since system engineering affects the rate of change. Language choice will certainly have some engineering impact. However, in my experience language choice is rarely high on the list of concerns relative to things like project scope and team experience.

So my “No” answer to Michael’s question is predicated on the following:

  • As an architect, I want to consider individual systems as black boxes where implementation details like language choice are completely irrelevant.
  • As a practical architect, I realize that some system implementation details are relevant – especially over time – but in my experience language choice isn’t one of them.

On the other hand, most IT shops try to standardize on one programming language – certainly MS IT did – so maybe language choice would be more architecturally relevant in a mixed language shop. I’d love to hear from folks who have multiple standard languages in their IT shop – especially if you have both static and dynamic languages on your standards list.

Afternoon Coffee 174

You know, this gets pretty long when I go a week between morning coffee posts.

Dynamic Language Stuff

Other Stuff

  • Don Syme blogs about an update to the F# CTP, a mere week after the original release. One week? That’s more often than even IPy releases. I can’t wait to see what they ship in next week’s release! 😄 Seriously, I hope they can keep the release sprints short, but every week would be a bit crazy!
  • Speaking of F#, Matt Podwysocki updates FsTest for the F# CTP and posts about Extension Everything in F#. Unlike C#, which only supports extension methods, F# also supports extensions properties, static methods and events, though like Matt I can’t think of a good use for extension events.
  • Still speaking about F#, Andrew Kennedy has a three part series on the new units of measure feature of F#. If you were going to use F# to build the physics engine of a game, I would suspect UoM would be extremely useful. (via Don Syme)
  • Oh look, Chris Smith built an F# version of artillery game that uses Units of Measure for the physics code. I’ll bet UoM was extremely useful. 😄
  • Talking about Live Mesh at TechEd Australia – where much to my surprise frankly they were demoing Live Mesh Apps – I pointed out to Scott Hanselman that Mesh is running an embedded CoreCLR (aka the same CLR from Silverlight 2). Scott went poking around and posted what he discovered. Looking forward to finding out what he digs up on using CoreCLR outside the browser.
  • Speaking of Scott, I need to set up a family video conference solution like Scott’s before my next trip.
  • Congrats to Glenn Block and the MEF team for their initial CodePlex source drop! I’ve been hearing about this possibility since Glenn joined the team, so I’m really excited to see it happen. I need to take a look at it in detail (in my copious spare time) because I want to find out how to make it work with IPy.
  • Bart de Smet has a whole series (starting here) on Dynamic Expression Trees. However, given that he specifically writes “This blog series is not about DLR itself” makes it seem pretty conceptual to me. Why not talk about DLR expression trees instead Bart?
  • I’m sure you noticed ASP.NET MVC preview 5 dropped last week. I really liked Brad Wilson’s discussion of the new view engine design.
  • Tomas Restrepo has started publishing his source code on GitHub. Personally, I haven’t published any source code lately but I am using Git for all of my non IPy core work (which is stored in TFS). Like Tomas, I’m still getting the hang of Git but I’m really digging it’s speed, it’s branching and the fact that there’s zero infrastructure requirements. SVN provides the lightweight svnserve, but Git is even lighter weight than that.
  • I liked Steve Yegge’s post on typing. I am a touch typer, but I doubt I type 70 words a minutes. I do know where the number keys are without looking though, so I guess that’s pretty good. I remember seeing Chris Anderson demo Avalon WPF long before it was public and being impressed at how fast he could type.

Morning Coffee 163

Between MVP summit last week, ALT.NET this past weekend and an internal brown-bag presentation yesterday, my unread email and blog posts have piled up. Most of the following is old news, but I wanted to get something out. Especially since I feel a case of Caps Fever coming on that will force – forceyou understand – me to head home early today.

DyLang Stuff

  • My teammate Srivatsn demonstrates how to make your static C# types act more dynamic in order to interop better with DLR languages. For example, by implementing GetBoundMember and SetMemberAfter, you can support setting arbitrary attributes on a C# class from Python. Cool.
  • Today’s Michael Foord link: On Testing: Some Programmers Refuse to Get it. He’s responding to a comment by Allen Holub suggesting that having 110k of test code for 30k of production code is “a real indictment of the language” (IronPython). I’m with Michael on this, Holub’s suggestion is laughable and worse radically uninformed. I like the way Larry O’Brien (who passed on Holub’s comment in the first place) describes the views of tests from inside and outside the agile community. I also like his description of tests as “quality diodes”.

Other Stuff

  • Werner Vogels posts about a new Amazon EC2 feature: Persistent local storage. Basically, you can create an empty volume up to a terabyte in size and then mount it to your images as a drive. The objective seems to be able to run relational databases in the images, rather than being limited to S3 and SimpleDB. Kinda interesting, but given Google’s announcement last week, I think the shine is off EC2 a bit.
  • This past weekend’s Twitter outage has Dave Winer re-thinking the idea of building networks on a single point of failure. While obviously I agree with the concept, I don’t agree with his solution that “We need some big infrastructure companies to get into this game”. While there are some big blog infrastructures out there, most of that network was built on a massive number of small infrastructures. Why wouldn’t the same thing work for microblogging?

Wanna Work on IPy + VS?

We’ve hired a few people around here recently (including me obviously). However, if you have a burning desire to work on IronPython (or IronRuby) and Visual Studio, we’re still hiring:

An important aspect of developing these dynamic languages [aka IronPython and IronRuby] is providing support in the Visual Studio IDE. This includes editing features (color-coding of source code, intellisense, go-to-definition, refactoring, etc), debugging features (breakpoints, data tool tips, etc), ensuring a language-specific look-and-feel (interactive console, etc), and integration into the Visual Studio project system. It includes integration with the various designers like the WPF designer via CodeDOM, and development of project templates for various scenarios (Silverlight 2 app, WPF app, ASP.Net website, VSTT unit tests, etc). We also want to integrate with Visual Studio technologies like profiling and code coverage. Your job will be to ensure that developers using dynamic languages built on top of the Dynamic Language Runtime (DLR) have the best development environment in Visual Studio.

We’re looking for a talented developer with exceptional programming ability and a passion for dynamic languages. Experience in these areas is a bonus though not strictly required: building developer tools like editors and debuggers, compiler implementation, reflection, dynamic languages, VM implementation, performance measurement and/or optimization, C#. Applicants should have a BS/MS in computer science or equivalent, and three or more years of industry experience.