
Scala turns 10 - psuter
http://article.gmane.org/gmane.comp.lang.scala/17
======
octo_t
However certain parts of Scala are slightly older (16/07/2003)[1]

[1] -
[https://github.com/scala/scala/blob/master/src/library/scala...](https://github.com/scala/scala/blob/master/src/library/scala/Option.scala#L303)

~~~
densh
It's been 10 years since the first Scala release, not since the inception of
the language.

------
VLM
My "favorite" feature is the case class airity limit of 22. Is that ever a fun
one to discover the hard way.

~~~
gourlaysama
This is finally going away in the next version (2.11, which will hit RC1 next
month) see [1].

[1]:
[https://github.com/scala/scala/pull/2305](https://github.com/scala/scala/pull/2305)

~~~
lmm
What are the implications of not implementing FunctionN? Will the apply method
still be there? Can I still pass the case class companion object to a higher
order function? Will shapeless' Iso.hlist still work? (that's the big one
really, as it allows dealing with case classes more-or-less generically)

~~~
gourlaysama
Yes the apply _method_ is still there. But since it has more than 22
arguments, you cant't lift it into a _function_ object anymore.

This will break some tools, like Play's forms, that need you to pass to a
couple of serialization/deserialization functions.

Shapeless will probably be fine, or at least, since it is macro based, it will
be able to go around the missing unapply and extract the fields directly, like
pattern matching does. (I don't know shapeless enough to go into more details)

~~~
caoilte
Aaaaah, interesting. Spray uses Shapeless heavily, so this should make it a
shoo-in for the Typesafe stack.

------
ExpiredLink
When I looked at Scala briefly in 2006 or so built-in support for XML
processing was a big selling point. Another one was 'multiparadigm' \- like
C++. It was clear at that time that Scala would not become a mainstream
language.

~~~
etrain
I don't follow the connection between your comments.

XML Support as selling Point + Multiparadigm == !mainstream?

I agree that scala has its quirks (IMO, the type system is way too
complicated), but to have dismissed it based on two apparently unrelated
features 8 years ago seems a little strange.

------
ucarion
It appears they've changed the look of the scala-lang website to celebrate
this:

[http://www.scala-lang.org/](http://www.scala-lang.org/)

(This is what it looked like yesterday:
[https://web.archive.org/web/20140119030617/http://www.scala-...](https://web.archive.org/web/20140119030617/http://www.scala-
lang.org/) )

~~~
saryant
The current design is actually the old design whereas the archive.org link is
the _real_ current design.

Either they're doing a throwback thing for the anniversary or that's a
remarkably coincidental server issue.

------
dkhenry
Wow I wouldn't have guessed it was that old.

~~~
cstuder
Hehe, I remember taking a compiler class by Martin Odersky when I was studying
at EPFL 8 or 9 years ago. We had to implement a compiler for a mini-Scala.

After that class, I thought I would ever see it again.

~~~
psuter
Was that mini-Scala any of the { Eins, Zwei, Drei, Vier } languages?

~~~
cstuder
I honestly don't remember, I hadn't spent too much attention in class.
(Mistakingly believing I would never ever write a compiler...)

------
stusmall
What ended up happening to the .NET target?

~~~
laureny
It died, because .net supports reified types, which make interoperability
pretty much impossible.

Contrary to popular opinion, erasure is a superior solution to reification for
many reasons, and this is one of them.

~~~
tomp
Can you be more specific? I know that reification can bloat runtime memory
requirements, but I'd like to know about other disadvantages.

~~~
noblethrasher
This might help: [http://beust.com/weblog/2011/07/29/erasure-vs-
reification/](http://beust.com/weblog/2011/07/29/erasure-vs-reification/)

~~~
tomp
Not really... this only mentions that reified generics would be incompatible
with current Java collections, which is obviously a problem that Java has, not
that reified generics have (C# does great!).

~~~
bad_user
C# was designed for the CLR and the CLR was designed for C#. F# on the other
hand has 2 generics systems in the same language, one inherited from C# and
one for ML-style Hindley–Milner based on type-erasure and they don't interact
well.

Java's generics can't be built on top of the CLR's reified generics, but this
goes for other languages as well - Haskell, ML, Scala, you name it. Basically,
reified generics work well in case you design the language in combination with
the VM, otherwise it becomes a huge PITA.

FYI, the CLR's reified generics is one reason for why the JVM is a better
target for other languages. For dynamic languages, they are a problem because
the bytecode generator has to work around them. For static languages, such as
Scala or anything in the ML family, it's a problem because either (a) they are
designed for co/contra-variance or (b) they don't support higher-kinded types
or (c) they don't support rank-2 types or (d) in case you do need co/contra-
variance rules, for some reason Microsoft chose to restrict the declarations
only to generic interfaces and delegates, so you can't design a List<+T> class
for example (to be honest, I'm not sure if this last one is a limitation of
the language or the CLR).

Also, having reified generics is less important than you think. Scala for
example can do specialization for primitive types and because the type-system
is much stronger, coupled with an awesome collections library and pattern
matching, the flow of the types is much better. For example, I can't remember
any instance in which I felt the need to do a (obj isInstanceOf List<int>)
check, immutable collections can be covariant without issues and for
everything else there are type-classes, something which C# sorely lacks.

IMHO, in spite of people's opinion on the matter, Java's type-erased generics
is one of its best features.

~~~
kvb
This seems inaccurate - generics aren't a problem for F# at all (the
integration between the .NET and ML type systems is seamless here, as far as
I'm aware). Indeed the people behind the .NET generics design (Don Syme and
Andrew Kennedy in MSR) were coming from an ML background, and Don is the
primary researcher behind F#. The big ML-.NET type system mismatches have to
do with things like pervasive overloading in .NET making type inference
difficult, nothing to do with reified generics.

~~~
bad_user
Don Syme, Andrew Kennedy and many others that work for Microsoft are awesome.
This doesn't make it any less of an appeal to authority that's not valid. The
reality is that their creativity was limited by the constraints of .NET

> _The big ML-.NET type system mismatches have to do with things like
> pervasive overloading in .NET making type inference difficult, nothing to do
> with reified generics_

You've hinted at a side-effect, but no, it has to do with subtyping [1], which
naturally leads to co/contra-variance [2]. Or to put it bluntly, in a nominal
type system that has sub-typing, Hindley-Milner type-inference is not only
"difficult" but actually impossible. And because F# had to be interoperable
with .NET, then it needed C# generics. Pity, because there's many things that
F# misses, like Ocaml functors, structural typing, type-classes, higher-kinded
types and the list can continue. And I just love how List.sum<^T> is defined
[3] (static member, FTW).

[1]
[https://en.wikipedia.org/wiki/Subtyping](https://en.wikipedia.org/wiki/Subtyping)

[2]
[https://en.wikipedia.org/wiki/Covariance_and_contravariance_...](https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29)

[3] [http://msdn.microsoft.com/en-
us/library/ee353634.aspx](http://msdn.microsoft.com/en-
us/library/ee353634.aspx)

~~~
kvb
Sure, subtyping adds additional pain points (mostly separate from overloading,
BTW). But I think this is mostly orthogonal to reified vs. erased generics. As
it is, the .NET runtime supports reified generics and declaration-site
variance (albeit limited to interfaces and delegates), and to my knowledge
there's nothing stopping a different language/runtime from implementing
reified generics even with usage-site variance (and Scala's type system only
has declaration-site variance, anyway, AFAIK).

