The Artima Developer Community
Sponsored Link

Weblogs Forum
A Brief History of Scala

61 replies on 5 pages. Most recent reply: Jun 23, 2006 11: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 | » ]
Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: A Brief History of Scala Posted: Jun 10, 2006 8:32 PM
Reply to this message Reply
Advertisement
> Another, as yet experimental, library for actors
> is event-based and scales up to hundreds of thousands of
> processes.

The potential for actors is really fascinating. I downloaded the Scala PDF doc and noticed that you only wrote the first couple of sentences of the actor section, so I'm looking forward to more. I'm personally tired of the constraints of the current mainstream languages (C++, Java, C#), but I need to see a lot of new leverage to make a language interesting to me. Solving the concurrency problem is definitely something I want to see.

One thing that wasn't immediately obvious from the site is the licensing of Scala and implementations. What is the situation there?

Re Generics: do they support duck typing?

The XML stuff is very cool -- makes me think the language is designed for real-world problem solving.

What is the state of the Scala compiler at this time? Do you consider version 2 to be production quality?

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: A Brief History of Scala Posted: Jun 10, 2006 10:36 PM
Reply to this message Reply
> Also, it became quickly apparent that any new language has
> a chance of
> being accepted only if it comes with a large set of
> standard
> libraries.</p>

I think there are two additional factors that determine whether a new language will be accepted:
1. The language should be supported by a stable/big corporation, like Microsoft, Sun, IBM, etc.
2. There should be enough interest in it by developers

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: A Brief History of Scala Posted: Jun 10, 2006 11:44 PM
Reply to this message Reply
> > Also, it became quickly apparent that any new language
> has
> > a chance of
> > being accepted only if it comes with a large set of
> > standard
> > libraries.</p>
>
> I think there are two additional factors that determine
> whether a new language will be accepted:
> 1. The language should be supported by a stable/big
> corporation, like Microsoft, Sun, IBM, etc.
> 2. There should be enough interest in it by developers

I think 1 is taken care of already since Scala targets the JVM (the CLR too?), and you can transparently use the libraries from those framworks.

I always contend that these days, in order to garner developer interest, you have to also supply a good addin/plugin for an already established IDE or supply a new IDE. Java and .NET developers are used to good IDEs and if they're trying something out in their spare time, they especially want a comfortable development environment. I can't comment on Scala's recent Eclipse plugin since I haven't tried it.

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: A Brief History of Scala Posted: Jun 10, 2006 11:46 PM
Reply to this message Reply
I'm curious what the status of macros are. I noticed Martin talked about it in a post on the mailing list in September. Any ETA on that?

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: A Brief History of Scala Posted: Jun 11, 2006 5:09 AM
Reply to this message Reply
> One thing that wasn't immediately obvious from the site is
> the licensing of Scala and implementations. What is the
> situation there?

It's an open source license, you find it at http://scala.epfl.ch/downloads/license.html
The source of all tools is available from a public subversion archive: http://scala.epfl.ch/downloads/svn.html.

> Re Generics: do they support duck typing?
>
Yes and no; it depends on your types. For class types there is no Duck Typing -- an object is a duck if it inherits from class Duck, not by having all duck methods. However, you can have structural `refinements' of a class type. Compatibility with one of those uses structural (=duck) typing. This is good food for future blogs!

> What is the state of the Scala compiler at this time? Do
> you consider version 2 to be production quality?

I think so, yes.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: A Brief History of Scala Posted: Jun 11, 2006 5:11 AM
Reply to this message Reply
> I'm curious what the status of macros are. I noticed
> Martin talked about it in a post on the mailing list in
> September. Any ETA on that?

We are still toying with designs. But at present there's no firm commitment yet to implement any of them.

niels hoogeveen

Posts: 1
Nickname: niels
Registered: Jun, 2006

Re: A Brief History of Scala Posted: Jun 11, 2006 7:07 AM
Reply to this message Reply
Thanks for starting this weblog and above all creating Scala. I already read the post about multi dispatch and want to add the following. In your papers you mention the work on gbeta and caesarj as related and spend some time discussing the concept of virtual classes. In the last few months I've seen two interesting papers co-authored by Klaus Osterman, related to the subject: "A virtual class calculus" and "Multidimensional Virtual Classes", the latter also addressing the issue of multi dispatch. I would like to know what your take is on these papers and if they form an inspiration for further enhancing Scala.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: A Brief History of Scala Posted: Jun 11, 2006 2:22 PM
Reply to this message Reply
> > Re Generics: do they support duck typing?
> >
> Yes and no; it depends on your types. For class types
> there is no Duck Typing -- an object is a duck if it
> inherits from class Duck, not by having all duck methods.
> However, you can have structural `refinements' of a class
> type. Compatibility with one of those uses structural
> (=duck) typing. This is good food for future blogs!

Yes, I'd like to see a blog on 'refinements'. As you may have read:
http://mindview.net/WebLog/log-0050
I have a hard time with a generic mechanism that doesn't provide structural typing.

Perhaps this can be handled at the function call, if you introduce macros.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: A Brief History of Scala Posted: Jun 12, 2006 5:24 PM
Reply to this message Reply
> > > Re Generics: do they support duck typing?
> > >
> > Yes and no; it depends on your types. For class types
> > there is no Duck Typing -- an object is a duck if it
> > inherits from class Duck, not by having all duck
> methods.
> > However, you can have structural `refinements' of a
> class
> > type. Compatibility with one of those uses structural
> > (=duck) typing. This is good food for future blogs!
>
> Yes, I'd like to see a blog on 'refinements'. As you may
> have read:
> http://mindview.net/WebLog/log-0050
> I have a hard time with a generic mechanism that doesn't
> provide structural typing.
>
> Perhaps this can be handled at the function call, if you
> introduce macros.

Bruce, reading over your blog entry, I can't help but having a re-occuring thought that duck-typing is just a lazy way to define an interface. If there's something I am missing about this, please let me know.

It seems to me that in your 'speaks' example, what you are really defining is an interface with method speak(). What I mean is that when you write this method, you have some sort of concept of what speak should do. When an Object is passed in with the required speak() method, they've most likely written it to satisfy this implicit interface. I mean, you aren't writing this with the hope that people will randomly assign the same name to a method that means something radically different and call your method, right?

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.

Take Python for example, (I'm still a newbie and I'm probably just missing something) but making a custom type act like a container type:

http://docs.python.org/ref/sequence-types.html

is a huge pain in the ass compared to Java. At least with Java the compiler tells me when I am done and there's an abstract class that I can extend, implement a method and be done in a lot of cases. With Scala's traits, I'm struggling to understand why we need duck typing.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: A Brief History of Scala Posted: Jun 12, 2006 5:38 PM
Reply to this message Reply
> One of the fundamental reasons to want to merge
> object-oriented and functional programming is that
> object-orientation gives you a convenient mechanism for
> adding new datatypes that respond in different ways to
> various functions without messing with the original code,
> while functional programming gives you a convenient
> mechanism for adding new functions without messing with
> the original code.

While there is some truth there, I think that people should also be aware of the fact that, excluding subtyping, it is not at all inconvenient or impractical to use basic single-dispatch object-oriented programming techniques in statically typed higher-order languages. Basically, you can define interfaces as recursive records of functions (closures) and classes as functions that construct such records. Programming in such a style, using a very basic Hindley-Milner typed language such as Standard ML, can actually be less verbose than equivalent code in the mainstream OO languages.

Werner Schulz

Posts: 18
Nickname: werner
Registered: May, 2005

Re: A Brief History of Scala Posted: Jun 12, 2006 6:30 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.

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

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: A Brief History of Scala Posted: Jun 12, 2006 7:02 PM
Reply to this message Reply
Werner, I'll say efficiency and social issues (e.g. Java is dumbed-down C++).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: A Brief History of Scala Posted: Jun 13, 2006 9:18 AM
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?

> 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.

We do?

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

Why use + when :: could do the same? I mean I agree that + makes more sense but...

> 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, ...

I've seen a lot of people make these scientific & mathematical demands for languages but I don't think they realize that these feautures offer no value to most developers.

> 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.)

I would like to understand how this would help me in developing software. Also, is there a fundamental reason these concepts cannot be modeled with OO?

> 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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: A Brief History of Scala Posted: Jun 13, 2006 9:22 AM
Reply to this message Reply
> Werner, I'll say efficiency and social issues (e.g. Java
> is dumbed-down C++).

You say 'dumbed-down', I say 'improved'. C++ is like a extremely obese man eating sticks of butter.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Defense from a happy C++ programmer Posted: Jun 13, 2006 4:10 PM
Reply to this message Reply
/* [assertion] I'll say efficiency and social issues (e.g. Java is dumbed-down C++).

[reply] You say 'dumbed-down', I say 'improved'. ...

I can't help but having a re-occuring thought that duck-typing is just a lazy way to define an interface. If there's something I am missing about this, please let me know.
*/

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), 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. But then you have to redefine the container to hold your new class, not the old one. And other code may be expecting the old class.

/* 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++.

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-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us