Scala is a modern multi-paradigm programming language running on top of a Java VM or .NET runtime. Recently version 1.4.0.3 has been released.
Scala smoothly integrates features of object-oriented and functional languages.
In Scala, every value is an object and the language supports OOP for instance via subclassing , traits, and mixins.
Scala is also a functional language in the sense that every function is a value. The language supports anonymous, higher-order and nested functions as well as currying.
There is also integrated support for pattern matching, parametric polymorphism, etc.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
Yes, types can get very complicated, but only if you do complicated things. With dynamic typing you still have to mentally keep track of them, otherwise you'll just end up with dynamic type errors and have no idea where they come from, or how to fix them without breaking something else.
That's the thing. I've never found types to be particularly complicated. I have to mentally keep track of them, but I'd have to do that anyway because I generally need to know what I'm operating on in order to do anything with it. I suppose having the compiler double-check my work adds a layer of safety, but in practice, I cannot say I make enough type errors for the loss of flexibility to be worthwhile. This becomes especially true when using something like SBCL, which catches almost all of the type errors I do make. The rest are almost always the result of polymorphism, and I'm not willing to give up polymorphism to prevent the occasional runtime error.
Member since:2005-07-06
That's the thing. I've never found types to be particularly complicated. I have to mentally keep track of them, but I'd have to do that anyway because I generally need to know what I'm operating on in order to do anything with it. I suppose having the compiler double-check my work adds a layer of safety, but in practice, I cannot say I make enough type errors for the loss of flexibility to be worthwhile.
Fair enough. But that still leaves the documentation issue, unless you don't need to revisit your code at a later time.
Also, dynamic type errors can appear far from where the actual mistake was made. If you call a function with the wrong type the actual error might be thrown somewhere in any function invoked by that function. But at least in that case the problem is somewhere on the current call stack. Things get even more difficult if the offending value is just stored in some data structure, causing an error at some later point.
And of course dynamic type checks have a significant run-time cost, so any check that can be eliminated at compile time or even startup time is a good thing.
This becomes especially true when using something like SBCL, which catches almost all of the type errors I do make.
So I guess we're talking more about explicit vs implicit rather than static vs dynamic typing?
The rest are almost always the result of polymorphism, and I'm not willing to give up polymorphism to prevent the occasional runtime error.
You don't need to, that's why parametric types are finally making it into mainstream languages.
Simple type parameters suffice for most cases of polymorphism, particularly for handling lists or other
containers. More complicated cases can be expressed
with type bounds.
Sure, there'll always be examples that can't be expressed in a static type system, but with bounded parametric types they won't crop up terribly often, and they can of course be handled through explicit run-time checks (aka downcasts).
Member since:
2005-07-06
I've fiddled around with Haskell and the like, and honestly, there is a reason I'm in the dynamic typing camp. I'm an engineer, not a mathematician, and I see no particular value in trying to express everything through the type system.
Yes, types can get very complicated, but only if you do complicated things. With dynamic typing you still have to mentally keep track of them, otherwise you'll just end up with dynamic type errors and have no idea where they come from, or how to fix them without breaking something else.
Having to write the type down might help you get things clear in your own mind when you write the code, and it can certainly help yourself and others when trying to understand the code later.
Admittedly though, languages like Java and C require too many obvious and tedious type annotations. On the other hand I think full type inference like in Haskell is going too far, because it is often difficult to follow and produces confusing error messages in unexpected places.
Therefore local type inference, where function arguments and results have to be explicitly typed, while local variable types are inferred, seems like a very good compromise to me.