The Artima Developer Community
Sponsored Link

Weblogs Forum
A Brief History of Scala

61 replies on 5 pages. Most recent reply: Jun 23, 2006 8:18 AM by James Watson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 61 replies on 5 pages [ « | 1 2 3 4 5 | » ]
Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Of course I'm no expert Posted: Jun 13, 2006 1:21 PM
Reply to this message Reply
Advertisement
Of course I'm no expert, but I have a few ideas:

/* 3. Why use :: to concatenate lists when + could do the same?
*/

Probably because (1) :: is commonly used to concatenate lists in functional languages, and, (2) math fans like to point out that 4+3 = 3+4, but that "Hello" + "World" is not equal to "World" + "Hello". In fact, using :: for concatenation leaves + open for, say, adding the first element of list1 with the first element of list2, and the second element of list1 with the second element of list 2 ... (I don't know if Scala does this, but it ought to, IMO).

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Defense from a happy C++ programmer Posted: Jun 13, 2006 1:25 PM
Reply to this message Reply
> For instance, std::sort by default compares elements with
> "<". This works great for builtin types, and for types
> with operator< defined. It's also possible to pass a
> different "comparator" to the template. I don't know of
> any way you'd do that with Java interfaces.

Using two overloaded versions of sort. One with an explicit Comparator (http://java.sun.com/j2se/1.5.0/docs/api/java/util/Comparator.html) argument and another without. The one without the Comparator argument would be implemented by calling the version with a Comparator argument with a default implementation of the Comparator interface based on using the Comparable interface.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Defense from a happy C++ programmer Posted: Jun 13, 2006 1:51 PM
Reply to this message Reply
> While I don't have experience with Java or C# Generics, I
> can explain one of the advantages to using templates in
> C++ compared to using interfaces in Java (and Eckel's blog
> post implied that Java Generics that aren't really just
> auto-casting to/from Object are really just another syntax
> for interfaces),

You read too much into it. His blog is specifically referring to one possilbe usage that has no real value.

> namely that they work well with code that
> you can't change.
>
> For instance, std::sort by default compares elements with
> "<". This works great for builtin types, and for types
> with operator< defined. It's also possible to pass a
> different "comparator" to the template. I don't know of
> any way you'd do that with Java interfaces. My
> understanding is that in Java you'd need to declare that
> the element's class supported an interface such as
> "comparable." What would you do if you only had the class
> files, and didn't have the ability to change them to
> implement comparable? Probably wrap the elements' type up
> in another class, and make that class implement
> comparable.

Actually there is a Comparator interface which can be used to sort any set of Objects regardless of whether they implement Comaparable or not. Your point is still understood, however.

The issue that you mention is something that I would like to see solved, possibly with dynamic adaptors or mixins i.e. a way to make an Object implement an interface without creating a new class. I was hoping that Scala would allow something like this but I'm starting to suspect it does not. I believe this is easy to do in languages where you can add methods to an Object.

>
> /* I can see why this is convienient but it seems very
> sloppy. Conidering a lot of the code I've seen, I really
> don't want to maintain a large application with tons of
> implicit interfaces.
> */
>
> The C++ Standard Committee agrees with you. There is work
> on C++ supporting "concepts" which would make those
> interfaces explicit. Java Generics have the interface
> requirement largely for this reason. But that requirement
> then gets rid of one of the largest potential advantages
> for Java Generics.
>
> Hmm, I think I'll keep my C++.

C++ has a lot of great features. The problem is that it has too many features. Java lacks some things that it really should have but it's a decent slim-down of C++.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Defense from a happy C++ programmer Posted: Jun 13, 2006 2:13 PM
Reply to this message Reply
> > While I don't have experience with Java or C# Generics,
> I
> > can explain one of the advantages to using templates in
> > C++ compared to using interfaces in Java (and Eckel's
> blog
> > post implied that Java Generics that aren't really just
> > auto-casting to/from Object are really just another
> syntax
> > for interfaces),
>
> You read too much into it. His blog is specifically
> referring to one possilbe usage that has no real value.

To be specific, the reason it has no value is because generics are implemented with erasure in Java.

He's right in a lot of cases but there are some cases where it can be useful. Let's say you want to create a copy method:
public <T> T copy(T in);

I can now call it like this:
String s = copy(aString);

Without the type parameters, you can't do this. You can only specify that the method takes an Object and returns and Object. The caller will then have to cast to the proper type.

The real problem with erasure is that the type parameter doesn't help you inside the method body because the information is not available at runtime. So the copy method above is actually pretty hard to implement or at least it's implementation is messy.

They are implemented with erasure in Scala too but there seem to be some subtle differences so they may not suffer from this problem.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Defense from a happy C++ programmer Posted: Jun 13, 2006 2:28 PM
Reply to this message Reply
Oh, yeah there is another thing you can do in Java with local generic types that you cannot do with interfaces:

<T extends List & RandomAccess> void sort(T list);


This is actually a really nice (although obscure) feature that Java lacked prior to generics.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Picking good examples Posted: Jun 13, 2006 2:32 PM
Reply to this message Reply
/* [me] For instance, std::sort by default compares elements with "<". This works great for builtin types, and for types with operator< defined. It's also possible to pass a different "comparator" to the template. I don't know of any way you'd do that with Java interfaces.

[Vesa] Using two overloaded versions of sort. One with an explicit Comparator (http://java.sun.com/j2se/1.5.0/docs/api/java/util/Comparator.html) argument and another without.

[Watson] Actually there is a Comparator interface which can be used to sort any set of Objects regardless of whether they implement Comaparable or not. Your point is still understood, however.
*/

I need to pick better examples. I am glad that the point was understood, however. The big win is that, so long as the interface exists, there is no need for an oject hierarchy. And the magic of template specialization allows you to say "if the object has interface X, call it, if the object is of type Y, then use this function instead."

Werner Schulz

Posts: 18
Nickname: werner
Registered: May, 2005

Re: A Brief History of Scala Posted: Jun 13, 2006 3:07 PM
Reply to this message Reply
> > 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.)
>
> I'm not familiar with Fortran but I can't get the old saw
> "you can write Fortran code in any language" out of my
> head. If you are not familiar with this phrase, it's
> meaning is that one can write incomprehensible code in any
> language no matter how great it is. I assume you take
> issue with this characterization of Fortran.

Yes, I do.

Fortran 77 & prior were not good, but Fortran 90 & later have a much cleaner syntax. Look for F, a subset of Fortran 90.

You could say the same of C, VB, ... but I certainly don't want to start comparing features. Just to point out that we can learn from other languages where designers may have been inspired to a very good/brilliant design of some features. Sticking to closely to C/C++/Java syntax is not necessarily a good recipe.

Werner

Werner Schulz

Posts: 18
Nickname: werner
Registered: May, 2005

Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 13, 2006 3:37 PM
Reply to this message Reply
James,

there are several advantages to asking for support for arrays and other numerical constructs.

To be precise, I am not necessarily asking for a huge class library etc. but language designers should play the What-If game: How could I write a library for numerical applications? How would I go about defining a generic interface for Fields? ...

Martin Odersky has taken some steps in this direction, e.g., with the XML support. However, I think there a more generic prolems out there that need support.

Algebraic structures, numerics, etc. would provide a good ground to see whether the language is up to these tasks as many problems in design have similar problems. Eric Evans in Domain-driven Design talks of providing closures to your domain objects. Algebraic structures have been doing this for centuries in mathematics.

I have been working mainly on enterprise-scale apps and done hardly any numerical calculations. Still, I have a need for arrays, esp. arrays where the index can be more flexible than just zero-based. Imagine some annual stats for the years 1996-2006. An array stats[1996 .. 2006] would be much more expressive than stats[11] ... And again, other languages have been much more forthcoming with support for this, but the C-family has been very myopic here.

Werner

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: A Brief History of Scala Posted: Jun 13, 2006 3:59 PM
Reply to this message Reply
> 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.
...
I sympathize with a lot of your comments. However, when designing a language you have to pick your goals, knowing that you can't have all desirables at the same time. For us, the overriding goal was compatibility with the Java/C# familiy of languages. Not because they are so great but because they are widely used and at the same time provide a decent foundation for more advanced designs. The C/C++ family seems harder to map to because implementations differ more and there is no standard garbage collector.

So most answers to your questions would be: Because Java does it that way and we did not want to alienate Java programmers by too many deviations.

Some comments are more fundamental however:

We use ::: instead of + for list concatenation because, ending in a colon, it's right associative. Also, if you want to use + for concatenation you could add it to the List class. You can even do that without touching the code of the List class, using an implicit conversion like the following:
  class Plus[T](x: List[T]) {
    def +(x: List[T]): List[T] = this ::: x
  }
  implicit def listsHavePlus[T](xs: List[T]) = 
    new Plus[T](xs)


[A question aside: How can I make code like the one above properly indented and highlighted according to Scala syntax? Right now it uses Java highlighting]

> 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, ...
>
Good point. But nobody prevents you from implementing multi-dimensional arrays in the library, as additional classes. I want to clearly state that while the language Scala is considered fairly complete, the same is not true for the libraries. We need more classes that support Scala and use its features, and we need your help in writing them!

> 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.
>
This can be done using implicit parameters. Another topic for a future blog...

> 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?
>
Again, this is possible, it only requires some library code
using implicit conversions like the one I showed above.

> 7. Is there work planned to add Design-By-Contract to
> Scala?

No concrete plans yet, but it's certainly an interesting avenue.

-- Martin

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: A Brief History of Scala Posted: Jun 13, 2006 4:03 PM
Reply to this message Reply
I put a typo in the "Lists can be concatenated with + example". Here's the corrected version.
  class Plus[T](x: List[T]) {
    def +(y: List[T]): List[T] = x ::: y
  }
  implicit def listsHavePlus[T](xs: List[T]) = 
    new Plus[T](xs)


-- Martin

Werner Schulz

Posts: 18
Nickname: werner
Registered: May, 2005

References as generics Posted: Jun 13, 2006 4:18 PM
Reply to this message Reply
> > 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.
>
> Can you elaborate on the advantage of this?

Sure.
First, Scala defines Array[T] rather than T[] because this is the right way round and is in line with other generic structures.

Reference vs value semantics is one of the most important design decisions in a language. E.g., Java has gone wholly for reference semantics, except for the primitive types, plus some subtleties, which make it practically impossible to write a generic swap a la C++.

The generic aspects of references are assignment and equality checking. That's it. See, for example, the various pointers in the Boost lib.

Now the syntax. In C++, it's mainly pointers (unless you are boosting) which reads T* x. That's the wrong way round in exactly the same way as C/C++/Java do it for arrays. So defining references as generics as I have done is a logical correction to syntax problems elsewhere. In my syntax, T x is always value semantics, R<T> x is reference semantics (any other letter than R will suffice).

Following Scala, you could express a more subtle reference semantics. R[T] allows references to objects of type T and only T, no variance. With R[T>A] or R[T<A] you could express co/contra-variant polymorphic references. We don't always want to deal with polymorphic types.

The decision by Java (and other languages) to solely use reference semantics is questionable. I've found myself in designs where I would have liked to use value semantics, have control over assignments etc. I think it should be left to the programmer to decide which semantics to use; he may want to use value semantics in one case, reference semantics in another one for the same object, depending on circumstances.
And as implied above, Java references are always polymorphic, whether I want it or not. Sometimes, it's even wrong in a domain.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 13, 2006 7:11 PM
Reply to this message Reply
> James,
>
> there are several advantages to asking for support for
> arrays and other numerical constructs.
>
> To be precise, I am not necessarily asking for a huge
> class library etc. but language designers should play the
> What-If game: How could I write a library for numerical
> applications? How would I go about defining a generic
> interface for Fields? ...
>
> Martin Odersky has taken some steps in this direction,
> e.g., with the XML support. However, I think there a more
> generic prolems out there that need support.

I'm not sure I understand. Are you asking for language support or library support. AFAIK, there is no language support for XML in Scala.

> Algebraic structures, numerics, etc. would provide a good
> ground to see whether the language is up to these tasks as
> many problems in design have similar problems. Eric Evans
> in Domain-driven Design talks of providing closures to
> your domain objects. Algebraic structures have been doing
> this for centuries in mathematics.
>
> I have been working mainly on enterprise-scale apps and
> done hardly any numerical calculations. Still, I have a
> need for arrays, esp. arrays where the index can be more
> flexible than just zero-based. Imagine some annual stats
> for the years 1996-2006. An array stats[1996 ..
> 2006]
would be much more expressive than
> stats[11] ... And again, other languages have
> been much more forthcoming with support for this, but the
> C-family has been very myopic here.

You mean like slices in Python?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: References as generics Posted: Jun 13, 2006 7:22 PM
Reply to this message Reply
> Sure.
> First, Scala defines Array[T] rather than T[] because this
> is the right way round and is in line with other generic
> structures.

That and it's really just a class, if I don't misunderstand.

> Reference vs value semantics is one of the most important
> design decisions in a language. E.g., Java has gone wholly
> for reference semantics, except for the primitive types,
> plus some subtleties, which make it practically impossible
> to write a generic swap a la C++.

I want to be clear that you mean that the Object variables are references, right? primitive variables and references are basically the same. They are assigned and passed as parameters in exactly the same way. The only difference is that you cannot dereference primitives.

> The generic aspects of references are assignment and
> equality checking. That's it. See, for example, the
> various pointers in the Boost lib.
>
> Now the syntax. In C++, it's mainly pointers (unless you
> are boosting) which reads T* x. That's the
> wrong way round in exactly the same way as C/C++/Java do
> it for arrays. So defining references as generics as I
> have done is a logical correction to syntax problems
> elsewhere. In my syntax, T x is always value
> semantics, R<T> x is reference semantics (any
> other letter than R will suffice).
>
> Following Scala, you could express a more subtle reference
> semantics. R[T] allows references to objects of type T and
> only T, no variance. With R[T>A] or R[T<A] you could
> express co/contra-variant polymorphic references. We don't
> always want to deal with polymorphic types.
>
> The decision by Java (and other languages) to solely use
> reference semantics is questionable. I've found myself in
> designs where I would have liked to use value semantics,
> have control over assignments etc. I think it should be
> left to the programmer to decide which semantics to use;
> he may want to use value semantics in one case, reference
> semantics in another one for the same object, depending on
> circumstances.
> And as implied above, Java references are always
> polymorphic, whether I want it or not. Sometimes, it's
> even wrong in a domain.

I understand the value. I just think it adds too much complexity. In the years I've been using Java, I've never had this be a serious issue.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 14, 2006 6:25 AM
Reply to this message Reply
> I'm not sure I understand. Are you asking for language
> support or library support. AFAIK, there is no language
> support for XML in Scala.

OK, that was WAY off.

I have to question the choice to add XML support to Scala
very strongly. In my current work, literally every thing I work on either receives data via XML, produces XML or both. In other words, I'm immersed in XML. I can't think of one good reason to embed XML in code. It really makes no sense to me. XML is a serialization format. Working with XML is something best done outside of the language.

Maybe the domain I am usaing XML in is somewhat unique but hardcoding XML in source code is asking for trouble, regardless of what problem is being solved.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 14, 2006 6:34 AM
Reply to this message Reply
> Working
> with XML is something best done outside of the language.

To clarify, languages like XPath are designed for working with XML and do really good job with XML but are terrible for business logic.

What would be nice is a clean way to produce schemas for types and serializing the data from Objects into those schemas. Then the mapping from Objects to custom XML formats can be done in XSLT. While I'm on the subject, what's with DTD-only support? Who writes new schemas using DTD in this century?

Werner, I conceed that your requests for mathematical constructs make more sense than XML support.

Flat View: This topic has 61 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: A Brief History of Scala Previous Topic   Next Topic Topic: Apprenticeship -- The untold story.

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use