|
|
Re: A Brief History of Scala
|
Posted: Jun 12, 2006 3:30 PM
|
|
Scala is definitely an advance in the realm of the "curly-bracket" languages. However, there are a number of improvements or missed opportunities that I would like to see in a modern language, some of which I consider more fundamental to advances in language design than the typed vs. untyped war.
1. References: IMO, references should be generics, R[T], where R has all the operations of T, but allow sharing of the same underlying object.
Some semantics:
R[R[T]] = R[T].
x,y : T x==y means value equality
x, y: R[T] x==y means pointing to same object
C++ unfortunately has only a nebulous notion of this.
2. Why do we need short, int, long? Why different names for data types that just differ in the size of their value domains? Fortran 90 did a better job and defined int<kind>
where typically kind=1,2,4,... defined 1 byte, 2 byte, 4 byte sized integers. Similarly for float and double.
In other words, we need integer constants to parametrise types to indicate the size of their domain.
3. Why use :: to concatenate lists when + could do the same?
4. Making arrays properly generic is a good move. Java needs to get rid of the "pseudo-object" array[] notation.
However, I'd like to see proper consideration and support for array notation and semantics, rectangular arrays (not just arrays of arrays), vectors (not the C++ but the mathematical version arising from vector-spaces), matrices, tensors, ...
5. OO programming is lot about structures, and their relationships. Mathematics, esp. algebra, has a lot to teach about that. So why do I never see language designers provide a language where I can express well-defined algebraic structures like groups, rings, fields properly.
Why aren't the basic types like integers expressed as an implementation of a ring, double as a field. Where is the field of complex numbers?
If we can express these structures, we should be able to express others as well. That would be a real advance in language design. (One can partially define such structures but there are still a lot of stumbling stones.)
6. As a long-time Fortran programmer quite a while ago, I still feel that Fortran 90's notation for declarations has some advantages:
type, <attributes> :: variable(s)
Example: integer(kind=4), parameter :: i, j, k
Parameter is Fortran's version of constant, or final in Java. (Fortraners didn't get it everything right: arrays are defined by qualifier rather than as a generic.)
The other advantage is that there are no reserved key words. The above notation makes clear that type names and variable names live in two separate spaces and can never be confused. It is strange that after 50 years of language design, we are still doing this, though the first language, Fortran, never required this. This seems to be legacy of C that casts its shadow far too long and wide.
7. Is there work planned to add Design-By-Contract to Scala?
The addition of assert in Java is nothing but a fudge and actually should never be mentioned together with DBC.
I wanted to point out the issues above so that Martin and his team may think about them and, ideally, even implement solutions to some of them.
Of course, I am aware that with limited resources (man power, time) one cannot achieve all of these things easily. And Scala is already much better defined than most popular languages. Since it has an Eclipse plugin and can make use of the vast Java libraries, I think it has a better chance of being more than just an academic language but it's a tough world where betterness does not always bring success, though I wish Scala (or something similar) would.
Werner
|
|
Previous Topic
