Sunday, August 5, 2007

Reflecting on development and types

After teaching a course on algorithm analysis and design for over a month and having it consume most of my time, I've come back to a flurry of words that gives the impression of a discussion in comp.lang.lisp and comp.lang.functional. It has given me pause to reflect on how I approach solving my coding problems. Specifically, this paragraph from Pascal Costanza caught my attention.

If I understand correctly, people who prefer static type systems tend to think in terms of structural invariants of their programs, while people who prefer dynamic type systems tend to think in terms of their programs' behavior. I am convinced this is a personal preference, nothing more, nothing less. I guess that static typers have equal problems developing in dynamically typed languages as dynamic typers have developing in statically typed languages. I don't see a problem here: If the requirements are such that a focus on static correctness is important, it's probably better to employ a static typer, whereas if the requirements are such that dynamic flexibility is more important, the job should better be done by a dynamic typer. There is nothing wrong with specialization, we don't need a grand unified theory of program development.

My recent work has me experimenting with ways to profile data processed by programs then analyzing that data to see how it can be used to optimize those programs. Additionally, I'm exploring ways to measure the specificity (an admittedly vague term) of programs. During this time, it's been tough to ascertain just what it is I want to collect data about and how it should be stored. In the process of figuring things out, I tend to throw information into lists and hash tables just so I can take a look at it later knowing full well that I don't really know what I'm going to be dealing with. Hence it is difficult, if not impossible, for me to specify much ahead of time.

As things become clearer, I come up with more specific types and data stores within an already working framework. In short, the program I'm writing helps me to figure out how to make the program “more specific” in some sense (say, for example, I know the kinds of things that will be put into a list). But at this point, things are behaving as required and the specific types are icing on the cake.

I switched to using Lisp for my work because it fit my problem solving methodology. I started out using OCaml and appreciated the language, but I didn't really enjoy writing in it; it didn't mesh with my approach to the problem. Is this the fault of the language? Hardly, and I would never make the claim that it was. It's also silly to claim that this approach is impossible in OCaml. I just didn't like it.

My personal experience suggests that Pascal's comment is accurate.

1 comments:

Anonymous said...

Kind of. The trend in lisp compilers is to allow prototype-phase development with jack-of-all-trades data structures, but then to facilitate narrowing to well-defined (and often statically checked) datatypes for correctness and efficiency. Taken to the limit, we DO need a "unified theory" there. Fortunately, such things are being worked on, CMUCL/SBCL themselves being examples thereof.