I've had this discussion before (with Stephen of all people!)
I understand the reasoning for wanting to remove all of those features, but
generally wouldn't do so. There's a strong synergy between many of Scala's
features, and removing any of them would generally hurt other features that
you wanted to keep, or force them to be implemented with dedicated (and
limited) compiler support:
*View types* - I'm assuming you mean view bounds here. Okay, they're just
syntactic sugar and could be removed without too much pain. But they do a
great job of representing intent.
For example:
def fn[T <% Seq[Char]](arg: T) = ...
would accept any value that can be "viewed as" a sequence of chars, such as
a String. The unsugared alternative is not as pretty and struggles to
expose the intent:
def fn[T](arg: Seq[T])(implicit view: T => Seq[Char]) = ...
--
*Implicit conversions* - the main use case is to do what C# does with
extension methods, and those are simpler. I'd keep implicit
parameters, but only just.
They're also core to the mechanism that allows collections to just do the
Right Thing(tm). For example:
someBitSet map {_.toString}
is only able to return a Set[String] thanks to an mechanism based on
implicits, and this really just scratches the surface of what's possible.
(for example, look up type classes in Scala) I wouldn't give them up for
anything!
---
The many and varied uses of *underscore, _*. Just write 'ignored'
instead [for most uses].
Fair point... The humble underscore *is* too heavily overloaded
---
*Self types*. I don't care much about OOP (not to say I'm in the
immutable-only camp), and those seem only useful in that. The
encoding I'd normally use is more like Java's Enum type (trait Foo[F
<: Foo]) but when I'm coding without enforced designs, which is
luckily all the time now, it just doesn't come up.
I used a self-type only today! They just make some things so much
easier... Especially when coupled with structural typing, self types really
do make some problems a great deal more approachable. They also enable the
cake pattern, and who doesn't like cake, eh? The cake is *not* a lie...
---
*Incomplete pattern matches* - those should just be a compile error, as
should an incomplete switch over an enum in Java.
a.k.a partial functions. *far* too useful. For example, in implementing a
web server where you can chain together different partial functions, each
of which matches a different set of URLs. Though I'd readily admit that
the same can be done with a Function1[A,Option[B]] as is possible with a
PartialFunction[A,B]
----
*Existential types*. Wildcards were a mistake in Java, they don't
really need to be copied over. There are reasons for not having 100%
compatibility, and sanity is one of them.
They're also, sadly, a necessary evil for dealing with certain Java
libraries. If Scala were to remove features that enable interop, then
existential types most definitely would not be the first on my list! As it
is, interop was a core design choice of Scala, so existentials really can't
be removed.
---
On 23 November 2011 22:09, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> > Scala is anything but dynamically typed! One of the criticisms of that
> > article was that the type system is too imposing. Which is is, if you
> only
> > try and understand it by reading the language specs and not by e.g.
> actually
> > trying to program something in Scala. In practice, it gets out of your
> way
> > very nicely.
>
> I've found that to be true, but I find myself able to understand the
> type systems of C# and of Haskell (ok, not everything) simply by
> reading the language spec. Less true of Java, but I had 10 years less
> experience when I first read Java's than when I first read C#'s.
>
> There are things I would happily remove from Scala's type system and
> it could be that Java's real successor will be something like Scala,
> but minus a few features. Here's what I'd kill:
>
> View types - nobody knows what they are but they knock a bunch of
> lines off a number of use cases.
> Implicit conversions - the main use case is to do what C# does with
> extension methods, and those are simpler. I'd keep implicit
> parameters, but only just.
> The many and varied uses of underscore, _. Just write 'ignored'
> instead [for most uses].
> Self types. I don't care much about OOP (not to say I'm in the
> immutable-only camp), and those seem only useful in that. The
> encoding I'd normally use is more like Java's Enum type (trait Foo[F
> <: Foo]) but when I'm coding without enforced designs, which is
> luckily all the time now, it just doesn't come up.
> Incomplete pattern matches - those should just be a compile error, as
> should an incomplete switch over an enum in Java.
> Existential types. Wildcards were a mistake in Java, they don't
> really need to be copied over. There are reasons for not having 100%
> compatibility, and sanity is one of them.
>
> It's not part of the type system, but I'd also drop the XML literals
> as I think pretty much everyone using Scala today would too. They are
> probably *the* best advert for continuous code review I can think of
> (the literals aren't bad but the code backing them is).
>
> I think that without those features, sure, some code would be longer
> but I don't think it would be disastrous and it would be much easier
> to learn the language. That said, you can learn the language today
> and ignore all those features, but some libraries will make that
> difficult as they rely on the features.
>
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
