Bill Venners, recently intrigued by Scala, talks about the \<a href="http://www.artima.com/weblogs/viewpost.jsp%3fthread%3d209353"" target="_blank" rel="noopener noreferrer">advantages of type inference in this post. Type inference means that type assignments are implicit but static (that is, the programmer need not "finger type" the type intention, but the compiler will catch type-breaking behavior, such as assigning a string to an integer). The forthcoming LINQ-enabled .NET languages use type inference, so many will be exposed to it shortly.
In a forthcoming column in SD Times, I talk about my experiences with Ruby as I move from administrative and scripting tasks to using it in multi-thousand-line applications. My conclusions include:
- Contrary to the claims of some, type-breaking behaviors (e.g., bad assignments) do occur on a regular basis in larger codebases (ever work with dates and times?), and
- Dynamic typing can seduce you into ignoring a refactor (e.g., "Eh, I'll just change this function to return an array of values.")
But what's really hard with implicitly-typed languages is that knowing what types are being used in a method is essential to code comprehension in larger codebases. With explicitly-typed languages, that information is always available. With implicitly-typed languages, that information may become available in a sophisticated development environment. In a language where the compiler is based on type inference, the development environment ought to be expected to provide you "what type is this?" information (IntelliSense) instantly and accurately. With truly dynamic languages, it's much harder. It's quite easy to overwhelm the Intellisense / Code Completion of even the best of the new Ruby IDEs, such as \<a href="http://www.sapphiresteel.com/"" target="_blank" rel="noopener noreferrer">Ruby In Steel. Ruby In Steel allows optional type-explicitness in specially formatted comment fields, which I quite like, but optional explicit typing was tried in Visual Basic and I think the result was more-or-less a failure (as I said back in 2004).