Bill Venner's asks...
Do you think type inference will change the dynamics of the static versus dynamic typing debate?For some people, yes. But not (yet?) for me.
I do not see dynamic languages as only "saving key strokes". Dynamic languages for me also save the cycle time from a small idea to its incarnation as running code.
The languages like Scala and Haskell that I have tried, to the extent I have tried them, do save me key strokes. I have not crossed over the hurdle to where they save me cycle time to running code, for a few reasons:
- Running small snippets of code, especially code that I have changed out of a larger body, is easier for me in dynamic languages. Those type inferencers still want to infer everything and seem to have low tolerance for incomplete thoughts.
- Scenarios that are fairly easy for me to envision in a dynamic language, functional or imperative, tend to involve various type theories that I know little about. The literature is still not very good for programmers new to the modern type inferencing languages and modern type theory. My sense is picking this up by pairing with someone already imbued with "type-first" programming would be fairly easy, much easier than picking it up solo with the available beginner's books and web resources.
- Test-first programming has been done for a long time in dynamic language cultures. This pre-dates Kent Beck's Smalltalk sunit library by a couple of decades. The Lisp read-eval-print loop and the Smalltalk workspace have been the instruments for hypothesizing how some code should work, and then working it for a long time. xunit tools, Fit, etc. are somewhat more formal frameworks for the dynamic way or programming - writing a bit of code with a test, capturing the transcript, and repeating that every so often. Good testing is necessary to be successful with any programming language, and I can go fairly quickly with a simple language that stays out of my way, and a reasonable test framework for capturing and repeating many small theories of how the code should work.
If anything I predict the current static inferencing tools to drive more programmers to dynamic languages *because* they want the simplicity of better languages than the Java-like ones but they suffer too much from type inferencing and various type theories for languages like Scala and Haskell.
4 comments:
Hello,
I would like to make a small point in regards to "incomplete thoughts".
Personally, when I'm developing in Haskell, I will have the type of the function I am writing in mind (even if it is a complex one). You can think of that as a quantum-design-element up front. What I then do while coding this is simply fill in "undefined" for all the bits that I haven't thought through. That way I can iterate quickly and the compiler will catch me at any time I make a mistake due to the top-level type.
"incomplete thoughts" have the polymorphic type ∀α.α, and is spelled undefined, or "error::String -> a" in Haskell.
In a dynamic language I can modify a small bit of code and run just enough tests to try those changes. Then I can progressively run more tests and fix those that are broken because of my changes.
Is there a way in Haskell, or Scala for that matter, or OCaml, to "suspend" checking on things that are "already typed" in order to do something similar?
Another way of looking at this is it is "exploratory programming" -- I may break all kinds of things I don't care about as long as I can fix them incrementally as my explorations settle out.
Well, in OCaml, if you want to bypass the typechecker, you can always use Obj.magic. Though I wouldn't advise doing so except perhaps with phantom types (and even then...). If you just want to leave a piece of code undefined, just replace with "assert false" which unifies with any type. Of course, that blows up when the code reaches this point, but it's helpful for "incomplete thoughts". Enabling backtraces gives a precise info about which incomplete though needs to be completed. This way, I personnally do not have any problems with "incomplete thoughts" in OCaml.
Post a Comment