language parallax

I’m struggling with what language to use for the set of tools at work. The default choice is perl because it’s a sysadmin culture, and because perl is what the existing systems are written in, and because the person commissioning the work knows perl better than any other language.

I have many years of experience with both java and perl. And effectively none with python and ruby. I’ve been programming since age 8, and now 32, and working on a phd dissertation in the area of languages and development environments. So I think about this stuff a lot.

From my experience, the risk of not having static type checking is just too great as a system grows. This is non-negotiable for me. I do wonder if I’m being dogmatic, though. At the end of the day, perhaps it requires a few more QA cycles to catch those bugs that the static type checker would have caught. But in practice, perhaps that is outweighed by the time saved during implementation.

But I’d like to expand the debate to ask a few more questions related to static type checking and the various development features that are driven by it:

1) Refactoring
2) Code navigation
3) Auto-completion (IDE’s can infer a list of options based on the type of the object preceding the cursor)

What is the status of refactoring support in python and ruby environments? (I see very little evidence of this in the perl community.) I saw that someone had implemented strong typing for ruby, but actually discouraged the use of it because it got in the way of refactoring. There is some discussion of this issue here. One poster commenter points out that Smalltalk accomplished this by gathering runtime statistics — which of course requires that the language and the IDE be intimately bound: not the case for python and ruby.

Not to mention that this data would get stale as changes were made to the code between runs. No?

I think the grand vision of “language oriented programming” (Intentional Softare, JetBrains, …) will solve this stuff, but it’s going to be many years before that happens. From my perspective, java is the only language that makes these development environment features available now, and so I’m very tempted to stick to it.

One commenter on the post linked above references a paper from OOPSLA ‘04 that lauded optional type systems. I think that’s definitely the way to go. Why can’t ruby and python have optional syntax for a type system? I do see some evidence that people have explored these ideas, but I don’t see any broadly accepted solution in either language.

Another thought: I’ve seen a lot of discussion about “compile-time” catching of the errors vs. “run-time”. I think there’s another phase of development — call it “type-time” or “edit-time”. There’s no reason why developers can’t get instant feedback on certain types of errors as they type.

This is also why I think it’s not about implementing test cases. There’s a school of thought in the dynamically typed language camp that says that test-cases will catch these “method not understood” errors at test-time. I have two responses to that:

1) That’s fine as long as the language designer also ships a code-coverage tool with the compiler/interpreter. But who does that?

2) That’s fine as long as the language designer also ships a unit testing framework. But why not take it even further? Why can’t we store the traces of previously invoked test cases, and refactor/update them as we modify the code? Surely there’s a workable solution along those lines. I realize that some traces might be really large and impractical to store, but there’s got to be a way to summarize this information. The dream is to get instant feedback to the developer at edit time, and not have to wait for the test suite to be run.

All of this just strengthens my belief that we need LOP soon. As soon as we start taking a more holistic approach to the development process, good things are going to happen. Until then we’re just going to be shoving the problem around and taking lots of stop-gap measures.