(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Saturday, May 26, 2007
We really have a lot in common
Tell me what you like about static typing, and I’ll tell you what I like about functional programming.
Tell me what you like about automated refactoring in your IDE, and I’ll tell you what I like about referential transparency.
Tell me what you like about imperative programming, and I’ll tell you what I like about dynamic typing.
Tell me what you like about objects that execute methods, and I’ll tell you what I like about components that execute domain-specific languages.
Tell me what you like about configuring your programs with XML, and I’ll tell you what I like about writing literate software.
Tell me what you like about Inversion of Control, and I’ll tell you what I like about first-class functions.
And hey, if you tell me why dynamically extending and changing classes bothers you, I’ll tell you why mutable local variables bother me.
See? We have a lot in common. Is there anything else I’ve missed?
Tell me what you like about static typing, and I’ll tell you what I like about functional programming.
Tell me what you like about automated refactoring in your IDE, and I’ll tell you what I like about referential transparency.
Tell me what you like about imperative programming, and I’ll tell you what I like about dynamic typing.
Tell me what you like about objects that execute methods, and I’ll tell you what I like about components that execute domain-specific languages.
Tell me what you like about configuring your programs with XML, and I’ll tell you what I like about writing literate software.
Tell me what you like about Inversion of Control, and I’ll tell you what I like about first-class functions.
And hey, if you tell me why dynamically extending and changing classes bothers you, I’ll tell you why mutable local variables bother me.
See? We have a lot in common. Is there anything else I’ve missed?
Comments on “We really have a lot in common”:
<< Home
So are "mutable vocal variables" ones that scream when you step on them? Granted I know what you really meant, but the idea of logs being filled with "Variable foo really doesn't like to be touched" is really amusing.
One thing I've been trying to wrap my brain around lately is the way that, in a good-sized code base, you may not want to have to commit to certain architectural choices for the entire code base.
Static typing -- especially when you use type inference to minimalize type annotation -- rocks for a lot of code, especially when you have things like higher order functions that operate on other higher-order functions.
But in other cases, dynamic typing may be the best choice. In fact, in some cases what you really need is not just dynamic, but runtime-extensible types.
In some code, you may want the ability to ban mutable local variables and keep all your state and other side effects very carefully encapsulated.
But other blocks of code virtually beg for the elaborate state designs of an object system.
I think what I want is a code base where it's easy to localize these decisions, perhaps on a per-module basis. I don't have a code base like that yet, but I think that's where I want to go.
Static typing -- especially when you use type inference to minimalize type annotation -- rocks for a lot of code, especially when you have things like higher order functions that operate on other higher-order functions.
But in other cases, dynamic typing may be the best choice. In fact, in some cases what you really need is not just dynamic, but runtime-extensible types.
In some code, you may want the ability to ban mutable local variables and keep all your state and other side effects very carefully encapsulated.
But other blocks of code virtually beg for the elaborate state designs of an object system.
I think what I want is a code base where it's easy to localize these decisions, perhaps on a per-module basis. I don't have a code base like that yet, but I think that's where I want to go.
I'm experimenting with JRuby in the hope that I can bundle it up into a JAR and install it alongside a J2EE server (not Rails for BigCo reasons).
I can then use the Ruby-Java API, or even better, wrap the Ruby component up as a "web service."
I can then use the Ruby-Java API, or even better, wrap the Ruby component up as a "web service."
I'm getting ready to pilot a similar solution using IronPython for .Net. The main thing I'm currently looking at is a content-management-system-like approach to managing Python scripts that provide runtime-customizable presentation-level extensions.
In the long term, though, I can't help thinking that all of these features could be provided by a single language with optional type annotations in which you could enforce things like static typing and immutable variables using module-level declarations.
In the long term, though, I can't help thinking that all of these features could be provided by a single language with optional type annotations in which you could enforce things like static typing and immutable variables using module-level declarations.
<< Home
