This page is no longer maintained — Please continue to the home page at www.scala-lang.org

martin's post on ycombinator

34 replies
d_m
Joined: 2010-11-11,
User offline. Last seen 35 weeks 2 days ago.

Hey everyone,

Was wondering if people had seen Martin's post [1] in response to
the "new" complexity blog post [2]?

I am sympathetic to Martin's point that the collections might not be
arbitrarily extensible (they certainly aren't in many other languages).

However, I'm not sure that taking away things like implicit conversion
will address many of the problems brought up later in the original post
(e.g. the sortBy failure) since this is code that doesn't look like
it's trying to do anything fancy. I don't think these are cases of a
developer cutting herself on a dangerous tool.

I'm also a bit nervous--if implicit parameters and enrichment become
frowned-upon (or "second-class") constructions in Scala then it will
have serious implications for things like the type class pattern (which
I am currently finding hugely useful).

What do you all think?

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator
"Truly advanced, and dangerously powerful, features such as implicit conversions and higher-kinded types will in the future be enabled only under a special compiler flag."
Wow... that's quite a piece of news.
For what it's worth, as opposed to Haskell, one of the top rules of the Java compiler since day one has been to never, ever allow a compiler flag to compile a different type of source. I think it was a risky bet but one that paid off quite a bit in terms of backward compatibility.
-- Cédric




On Mon, Jan 9, 2012 at 1:48 PM, Erik Osheim <erik [at] plastic-idolatry [dot] com> wrote:
Hey everyone,

Was wondering if people had seen Martin's post [1] in response to
the "new" complexity blog post [2]?

I am sympathetic to Martin's point that the collections might not be
arbitrarily extensible (they certainly aren't in many other languages).

However, I'm not sure that taking away things like implicit conversion
will address many of the problems brought up later in the original post
(e.g. the sortBy failure) since this is code that doesn't look like
it's trying to do anything fancy. I don't think these are cases of a
developer cutting herself on a dangerous tool.

I'm also a bit nervous--if implicit parameters and enrichment become
frowned-upon (or "second-class") constructions in Scala then it will
have serious implications for things like the type class pattern (which
I am currently finding hugely useful).

What do you all think?

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

On Mon, Jan 9, 2012 at 1:48 PM, Erik Osheim <erik [at] plastic-idolatry [dot] com> wrote:
I'm also a bit nervous--if implicit parameters and enrichment become
frowned-upon (or "second-class") constructions in Scala

I've been under this impression for a while, especially since I think I remember Josh himself saying in the very first Scala Types podcast that he had "successfully reduced the number of implicits in <some library> from four to two and was hoping to reduce it further" (am I remembering this correctly, Josh?).
-- Cédric
Lars Hupel
Joined: 2010-06-23,
User offline. Last seen 44 weeks 3 days ago.
Re: martin's post on ycombinator

> Was wondering if people had seen Martin's post [1] in response to
> the "new" complexity blog post [2]?

I think this post makes some good points. As already pointed out, these
are fairly advanced problems, which make them not less important but
rather relevant to library writers, not users. If we have to spend more
time on designing good libraries, fair enough.

FWIW, considering things as difficult or even impossible doesn't stop
smart people from coming up with smart workarounds. That's a good
property of the Scala community.

> I'm also a bit nervous--if implicit parameters and enrichment become
> frowned-upon (or "second-class") constructions in Scala then it will
> have serious implications for things like the type class pattern (which
> I am currently finding hugely useful).

I was a bit shocked upon reading the bit about the compiler flags.
However, I will happily add these flags to my build configuration as I
already do with "-unchecked" et al. (and "-Ydependent-method-types"
being the newest incarnation).

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: martin's post on ycombinator

Am 09.01.2012 22:48, schrieb Erik Osheim:
> Hey everyone,
>
> Was wondering if people had seen Martin's post [1] in response to
> the "new" complexity blog post [2]?
>
> I am sympathetic to Martin's point that the collections might not be
> arbitrarily extensible (they certainly aren't in many other languages).
>
> However, I'm not sure that taking away things like implicit conversion
> will address many of the problems brought up later in the original post
> (e.g. the sortBy failure) since this is code that doesn't look like
> it's trying to do anything fancy. I don't think these are cases of a
> developer cutting herself on a dangerous tool.
>
> I'm also a bit nervous--if implicit parameters and enrichment become
> frowned-upon (or "second-class") constructions in Scala then it will
> have serious implications for things like the type class pattern (which
> I am currently finding hugely useful).
>
> What do you all think?
>

Richard Wallace
Joined: 2009-07-14,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

My feeling is that we should go the other way. Keep scalac acting as
is and add flags to disable "complex" features, like --cripple-scala
or --im-scared-pls-hold-me or --will-you-hold-my-hand.

On Mon, Jan 9, 2012 at 2:48 PM, Erik Osheim wrote:
> Hey everyone,
>
> Was wondering if people had seen Martin's post [1] in response to
> the "new" complexity blog post [2]?
>
> I am sympathetic to Martin's point that the collections might not be
> arbitrarily extensible (they certainly aren't in many other languages).
>
> However, I'm not sure that taking away things like implicit conversion
> will address many of the problems brought up later in the original post
> (e.g. the sortBy failure) since this is code that doesn't look like
> it's trying to do anything fancy. I don't think these are cases of a
> developer cutting herself on a dangerous tool.
>
> I'm also a bit nervous--if implicit parameters and enrichment become
> frowned-upon (or "second-class") constructions in Scala then it will
> have serious implications for things like the type class pattern (which
> I am currently finding hugely useful).
>
> What do you all think?
>

Lars Hupel
Joined: 2010-06-23,
User offline. Last seen 44 weeks 3 days ago.
Re: martin's post on ycombinator

> My feeling is that we should go the other way. Keep scalac acting as
> is and add flags to disable "complex" features, like --cripple-scala
> or --im-scared-pls-hold-me or --will-you-hold-my-hand.

For the records, this discussion already took place:

Stefan Wagner
Joined: 2011-04-08,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Imho, adding a compiler flag is adding even more complexity to the
language, and in a very unusual way, on a layer, where you often don't
fiddle around. Now you will have to do so in your IDE, in the
editor-settings, in your build-tools.

Ben Hutchison 3
Joined: 2009-11-02,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

On Tue, Jan 10, 2012 at 8:48 AM, Erik Osheim wrote:
> I'm also a bit nervous--if implicit parameters and enrichment become
> frowned-upon (or "second-class") constructions in Scala then it will
> have serious implications for things like the type class pattern (which
> I am currently finding hugely useful).
>
> What do you all think?

I hope this proposed "dumbing down" of the Scala compiler doesn't go ahead.

I don't feel that the "Scala is too complex" viewpoint is more than a
vocal minority. I've run a Scala user group in Melbourne, Australia
for almost 3 years, so I have talked to plenty of Scala newbies. While
I observe people have some difficulty with Scala's learning curve and
new concepts, the interest and enthusiasm I see for Scala among
newcomers far outweighs it. If Scala gets dumbed down, I believe it
will be a victory of a few vocal complainers over the larger group who
are just quietly getting on with learning and using Scala.

As you mentioned, type classes are especially powerful. To opt out of
support for them by default would be a shame.

-Ben

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator
On Mon, Jan 9, 2012 at 9:46 PM, Ben Hutchison <brhutchison [at] gmail [dot] com> wrote:

I hope this proposed "dumbing down" of the Scala compiler doesn't go ahead.

Me too but for a different reason than yours, however, I'd like to address this point:   
I don't feel that the "Scala is too complex" viewpoint is more than a
vocal minority. I've run a Scala user group in Melbourne, Australia
for almost 3 years, so I have talked to plenty of Scala newbies.

That would probably qualify as selection bias. I think there is much more than a vocal minority, and you can see this for yourself just by reading some of the reactions on the very HN thread we're discussing ("I was planning to look at Scala but after reading this, I'll pass", etc...).
We might still be able to derive some information from your experience, though: how has the membership of your Scala user group been evolving over the past three years? Has it been growing steadily? Stagnating? Declining? Do you keep track of attendance? Do people drop out? Do they use Scala in their day job or is it just an extra curricular hobby? That kind of thing.
Another information we don't have is: for all the people you see at your user group, how many planned to come or join at some point but decided not to because they gained this perception that Scala is too complex?
Personally, I'm very happy to see Martin acknowledge that the "Scala is too complex" perception is real and crucial to address for Scala's success, even if I don't agree that the "compiler switch" approach will do much to remedy it.
-- Cédric
Ben Hutchison 3
Joined: 2009-11-02,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

2012/1/10 Cédric Beust ♔ :
> On Mon, Jan 9, 2012 at 9:46 PM, Ben Hutchison wrote:
>> I don't feel that the "Scala is too complex" viewpoint is more than a
>> vocal minority. I've run a Scala user group in Melbourne, Australia
>> for almost 3 years, so I have talked to plenty of Scala newbies.
>
>
> That would probably qualify as selection bias. I think there is much more
> than a vocal minority, and you can see this for yourself just by reading
> some of the reactions on the very HN thread we're discussing ("I was
> planning to look at Scala but after reading this, I'll pass", etc...).
>

Cmon... you're trying the line that the semi-anonymous comments on
controversial internet forum posts are more reliable indicator than
actually meeting and talking with real people trying to learn Scala
over a sustained period of time, with a glib dismissal of "selection
bias"...?

... and it's revealing that the extra lame one you chose as an example
("I was planning to look at Scala but after reading this, I'll pass",
etc...) was in that oh-so-common category of online Scala critic, the
"I haven't actually used Scala yet, but Ive heard some rumors that
it's complex... so I won't bother".

-Ben

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator
2012/1/9 Ben Hutchison <brhutchison [at] gmail [dot] com>

Cmon... you're trying the line that the semi-anonymous comments on
controversial internet forum posts are more reliable indicator than
actually meeting and talking with real people trying to learn Scala
over a sustained period of time, with a glib dismissal of "selection
bias"...?

Yes, by far. Replace "Scala User Group" with "Commodore 64 User Group" if you like. The existence of special interest groups has absolutely no correlation to the popularity or complexity of the topics they focus on.
Anyway, we don't have to agree on that but I'd love to get answers to my other questions (if you have them), which would actually provide some information on the topic at hand. Not much, but more than the mere continued existence of a user group.
... and it's revealing that the extra lame one you chose as an example
("I was planning to look at Scala but after reading this, I'll pass",
etc...) was in that oh-so-common category of online Scala critic, the
"I haven't actually used Scala yet, but Ive heard some rumors that
it's complex... so I won't bother".

It's revealing... what?
At any rate, like I said, the important part of this is that Martin gets it, even if what he's trying to accomplish seems to be lost on you.
-- Cédric
Gary Pampara
Joined: 2010-09-12,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

"Gets it" is very subjective and often very biased.

There is absolutely nothing wrong with the "complexity" of Scala. Its
great in every respect. The issue is, again, that people do not want
to understand the new concepts Scala is trying to introduce. People
need to see that Scala is Scala, not a new Java.

2012/1/10 Cédric Beust ♔ :
> 2012/1/9 Ben Hutchison 
>>
>>
>> Cmon... you're trying the line that the semi-anonymous comments on
>> controversial internet forum posts are more reliable indicator than
>> actually meeting and talking with real people trying to learn Scala
>> over a sustained period of time, with a glib dismissal of "selection
>> bias"...?
>
>
> Yes, by far. Replace "Scala User Group" with "Commodore 64 User Group" if
> you like. The existence of special interest groups has absolutely no
> correlation to the popularity or complexity of the topics they focus on.
>
> Anyway, we don't have to agree on that but I'd love to get answers to my
> other questions (if you have them), which would actually provide some
> information on the topic at hand. Not much, but more than the mere continued
> existence of a user group.
>
>> ... and it's revealing that the extra lame one you chose as an example
>> ("I was planning to look at Scala but after reading this, I'll pass",
>> etc...) was in that oh-so-common category of online Scala critic, the
>> "I haven't actually used Scala yet, but Ive heard some rumors that
>> it's complex... so I won't bother".
>
>
> It's revealing... what?
>
> At any rate, like I said, the important part of this is that Martin gets it,
> even if what he's trying to accomplish seems to be lost on you.
>
> --
> Cédric
>

roland.kuhn
Joined: 2011-02-21,
User offline. Last seen 35 weeks 3 days ago.
Re: martin's post on ycombinator

«There is absolutely nothing wrong with the "complexity" of Scala»

That this sentence is wrong is exactly the—well proven—point of the original blog post. Scala is definitely not perfect. The reason is that the problems it tries to solve are hard and the imperfection lies in the fact that some of the underlying complexity of the problem (the “feature interactions”) is not perfectly encapsulated, i.e. the features are not perfectly orthogonal. There are interactions between implicits, subtyping and type inference which are not easily described.

So, the main point is that there is room for improvement—at least that it is reasonable to strive for it. It is perfectly alright to say that for your current use cases Scala in its current form is well-suited. But this discussion has a broader scope.

Wrt. the feature-hiding proposal, I think that would not solve the issue (and adding condescendingly named options definitely does not help) and the added complexity due to less repeatable or more difficult to manage builds in my opinion outweighs any potential benefit.

Regards,

Roland

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

2012/1/9 Gary Pampara <gpampara [at] gmail [dot] com>
Its great in every respect.

Seriously?
There are a lot of things I love in all kinds of different domains (not just computer related), but I can't find a single one that's "great in every respect", and I would seriously be worried if I ever did. It's important to keep a critical mind, even for things you like. Especially for things you like.
-- Cédric
Chris Twiner
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

+100

On Jan 10, 2012 8:51 AM, "rkuhn" <google [at] rkuhn [dot] info> wrote:
«There is absolutely nothing wrong with the "complexity" of Scala»

That this sentence is wrong is exactly the—well proven—point of the original blog post. Scala is definitely not perfect. The reason is that the problems it tries to solve are hard and the imperfection lies in the fact that some of the underlying complexity of the problem (the “feature interactions”) is not perfectly encapsulated, i.e. the features are not perfectly orthogonal. There are interactions between implicits, subtyping and type inference which are not easily described.

So, the main point is that there is room for improvement—at least that it is reasonable to strive for it. It is perfectly alright to say that for your current use cases Scala in its current form is well-suited. But this discussion has a broader scope.

Wrt. the feature-hiding proposal, I think that would not solve the issue (and adding condescendingly named options definitely does not help) and the added complexity due to less repeatable or more difficult to manage builds in my opinion outweighs any potential benefit.

Regards,

Roland
debasish
Joined: 2011-06-19,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator
There are interactions between implicits, subtyping and type inference which are not easily described. 

Exactly and this may very well lead one to believe that adding a method in Seq can make it available in Arrays / Strings. I actually liked the post by @yaang. He worked through the whole process to finally hit the wall ..
Regards. 
On Tue, Jan 10, 2012 at 1:20 PM, rkuhn <google [at] rkuhn [dot] info> wrote:
«There is absolutely nothing wrong with the "complexity" of Scala»

That this sentence is wrong is exactly the—well proven—point of the original blog post. Scala is definitely not perfect. The reason is that the problems it tries to solve are hard and the imperfection lies in the fact that some of the underlying complexity of the problem (the “feature interactions”) is not perfectly encapsulated, i.e. the features are not perfectly orthogonal. There are interactions between implicits, subtyping and type inference which are not easily described.

So, the main point is that there is room for improvement—at least that it is reasonable to strive for it. It is perfectly alright to say that for your current use cases Scala in its current form is well-suited. But this discussion has a broader scope.

Wrt. the feature-hiding proposal, I think that would not solve the issue (and adding condescendingly named options definitely does not help) and the added complexity due to less repeatable or more difficult to manage builds in my opinion outweighs any potential benefit.

Regards,

Roland



--
Debasish Ghosh
http://manning.com/ghosh

Twttr: @debasishg
Blog: http://debasishg.blogspot.com
Code: http://github.com/debasishg
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: martin's post on ycombinator


On Tue, Jan 10, 2012 at 9:30 AM, Debasish Ghosh <ghosh [dot] debasish [at] gmail [dot] com> wrote:
There are interactions between implicits, subtyping and type inference which are not easily described. 

Exactly and this may very well lead one to believe that adding a method in Seq can make it available in Arrays / Strings. I actually liked the post by @yaang. He worked through the whole process to finally hit the wall ..

The interesting bit is that the wall he hit is due to the strong ties between the java language and the JVM, namely Strings and Arrays.

Cheers,

 

Regards. 
On Tue, Jan 10, 2012 at 1:20 PM, rkuhn <google [at] rkuhn [dot] info> wrote:
«There is absolutely nothing wrong with the "complexity" of Scala»

That this sentence is wrong is exactly the—well proven—point of the original blog post. Scala is definitely not perfect. The reason is that the problems it tries to solve are hard and the imperfection lies in the fact that some of the underlying complexity of the problem (the “feature interactions”) is not perfectly encapsulated, i.e. the features are not perfectly orthogonal. There are interactions between implicits, subtyping and type inference which are not easily described.

So, the main point is that there is room for improvement—at least that it is reasonable to strive for it. It is perfectly alright to say that for your current use cases Scala in its current form is well-suited. But this discussion has a broader scope.

Wrt. the feature-hiding proposal, I think that would not solve the issue (and adding condescendingly named options definitely does not help) and the added complexity due to less repeatable or more difficult to manage builds in my opinion outweighs any potential benefit.

Regards,

Roland



--
Debasish Ghosh
http://manning.com/ghosh

Twttr: @debasishg
Blog: http://debasishg.blogspot.com
Code: http://github.com/debasishg



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
Richard Wallace
Joined: 2009-07-14,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

2012/1/10 √iktor Ҡlang :
>
>
> On Tue, Jan 10, 2012 at 9:30 AM, Debasish Ghosh
> wrote:
>>>
>>> There are interactions between implicits, subtyping and type inference
>>> which are not easily described.
>>
>>
>> Exactly and this may very well lead one to believe that adding a method in
>> Seq can make it available in Arrays / Strings. I actually liked the post by
>> @yaang. He worked through the whole process to finally hit the wall ..
>
>
> The interesting bit is that the wall he hit is due to the strong ties
> between the java language and the JVM, namely Strings and Arrays.
>

Even more interestingly, the wrong conclusion has been drawn from his
post. That higher-kinded types and implicits should be disable by
default is ridiculous when the real complexity is the Java
interoperation and subtyping. If we have "complexity flags" in the
compiler, I'd much rather see those things disabled by default.

> Cheers,
> √
>
>>
>>
>> Regards.
>>
>> On Tue, Jan 10, 2012 at 1:20 PM, rkuhn wrote:
>>>
>>> «There is absolutely nothing wrong with the "complexity" of Scala»
>>>
>>> That this sentence is wrong is exactly the—well proven—point of the
>>> original blog post. Scala is definitely not perfect. The reason is that the
>>> problems it tries to solve are hard and the imperfection lies in the fact
>>> that some of the underlying complexity of the problem (the “feature
>>> interactions”) is not perfectly encapsulated, i.e. the features are not
>>> perfectly orthogonal. There are interactions between implicits, subtyping
>>> and type inference which are not easily described.
>>>
>>> So, the main point is that there is room for improvement—at least that it
>>> is reasonable to strive for it. It is perfectly alright to say that for your
>>> current use cases Scala in its current form is well-suited. But this
>>> discussion has a broader scope.
>>>
>>> Wrt. the feature-hiding proposal, I think that would not solve the issue
>>> (and adding condescendingly named options definitely does not help) and the
>>> added complexity due to less repeatable or more difficult to manage builds
>>> in my opinion outweighs any potential benefit.
>>>
>>> Regards,
>>>
>>> Roland
>>
>>
>>
>>
>> --
>> Debasish Ghosh
>> http://manning.com/ghosh
>>
>> Twttr: @debasishg
>> Blog: http://debasishg.blogspot.com
>> Code: http://github.com/debasishg
>
>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe - Enterprise-Grade Scala from the Experts
>
> Twitter: @viktorklang
>

Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: martin's post on ycombinator
-Xdisable-legacy-java-support
Yes please!  Can we start with that ridiculous implicit conversion to String that seems to keep getting in my way?

2012/1/10 Richard Wallace <rwallace [at] thewallacepack [dot] net>
2012/1/10 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>:
>
>
> On Tue, Jan 10, 2012 at 9:30 AM, Debasish Ghosh <ghosh [dot] debasish [at] gmail [dot] com>
> wrote:
>>>
>>> There are interactions between implicits, subtyping and type inference
>>> which are not easily described.
>>
>>
>> Exactly and this may very well lead one to believe that adding a method in
>> Seq can make it available in Arrays / Strings. I actually liked the post by
>> @yaang. He worked through the whole process to finally hit the wall ..
>
>
> The interesting bit is that the wall he hit is due to the strong ties
> between the java language and the JVM, namely Strings and Arrays.
>

Even more interestingly, the wrong conclusion has been drawn from his
post.  That higher-kinded types and implicits should be disable by
default is ridiculous when the real complexity is the Java
interoperation and subtyping.  If we have "complexity flags" in the
compiler, I'd much rather see those things disabled by default.

> Cheers,
> √
>
>>
>>
>> Regards.
>>
>> On Tue, Jan 10, 2012 at 1:20 PM, rkuhn <google [at] rkuhn [dot] info> wrote:
>>>
>>> «There is absolutely nothing wrong with the "complexity" of Scala»
>>>
>>> That this sentence is wrong is exactly the—well proven—point of the
>>> original blog post. Scala is definitely not perfect. The reason is that the
>>> problems it tries to solve are hard and the imperfection lies in the fact
>>> that some of the underlying complexity of the problem (the “feature
>>> interactions”) is not perfectly encapsulated, i.e. the features are not
>>> perfectly orthogonal. There are interactions between implicits, subtyping
>>> and type inference which are not easily described.
>>>
>>> So, the main point is that there is room for improvement—at least that it
>>> is reasonable to strive for it. It is perfectly alright to say that for your
>>> current use cases Scala in its current form is well-suited. But this
>>> discussion has a broader scope.
>>>
>>> Wrt. the feature-hiding proposal, I think that would not solve the issue
>>> (and adding condescendingly named options definitely does not help) and the
>>> added complexity due to less repeatable or more difficult to manage builds
>>> in my opinion outweighs any potential benefit.
>>>
>>> Regards,
>>>
>>> Roland
>>
>>
>>
ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: martin's post on ycombinator
I hope Martin is joking.  Scala without implicit conversions enabled would be abysmally less usable than a language with only extension methods.

Adding complaints like, "Scala out of the box lets me do less with more frustration than Ceylon" to the "Scala out of the box is too complicated" comments is _not_ a good way to increase adoption of Scala.

  --Rex

P.S. My comment there is:

With the flag disabled, Scala will be less powerful than Ceylon (which has extension methods) and Clojure (if you count macros).

Not a good idea.

What is a good idea is adding simplifying features and documenting them well.  [A: Manifest] is a lot easier to grapple with than (a: A)(implicit mf: Manifest[A]), which is in turn easier to grapple with than the case when you have to explicitly call the manifest at every opportunity you might need it.

With a limited (sane) implementation of MyType, a few enhancements to type inference, and a few patches of better documentation (including lookup of symbols), all the complaints here would go away.

For example,
  val x = add(1,_)
has no business requiring a type annotation.  It's utterly unambiguous: use whatever type the add method takes!  This isn't an issue of needing to turn on features with flags; it's just a silly limitation of the existing type inference engine that ought to be fixed.

The biggest source of complexity in any language (that I've seen) is the special cases.  Whether you make them explicit in your language spec or implicit because of implementation limitations and/or bugs doesn't matter; it still requires the user to know an awful lot more than they ought to to work around them.  (Specialization, for instance, is something that I find requires enormous testing and knowledge because of the multiple bugs; fix the bugs and Scala will be simpler _and_ more powerful.)

On Mon, Jan 9, 2012 at 4:48 PM, Erik Osheim <erik [at] plastic-idolatry [dot] com> wrote:
Hey everyone,

Was wondering if people had seen Martin's post [1] in response to
the "new" complexity blog post [2]?

I am sympathetic to Martin's point that the collections might not be
arbitrarily extensible (they certainly aren't in many other languages).

However, I'm not sure that taking away things like implicit conversion
will address many of the problems brought up later in the original post
(e.g. the sortBy failure) since this is code that doesn't look like
it's trying to do anything fancy. I don't think these are cases of a
developer cutting herself on a dangerous tool.

I'm also a bit nervous--if implicit parameters and enrichment become
frowned-upon (or "second-class") constructions in Scala then it will
have serious implications for things like the type class pattern (which
I am currently finding hugely useful).

What do you all think?

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: martin's post on ycombinator
i agree. if you cripple scala to make it less different from "the average language", what's the point of scala at all? it would just be another random language with no reason to be picked over another.

Am 10.01.2012 18:17, schrieb Rex Kerr:
CAP_xLa354j6n19cH65MseF4grZ3oWgXYUS9qT32TzMmhSD+NHA [at] mail [dot] gmail [dot] com" type="cite">I hope Martin is joking.  Scala without implicit conversions enabled would be abysmally less usable than a language with only extension methods.

Adding complaints like, "Scala out of the box lets me do less with more frustration than Ceylon" to the "Scala out of the box is too complicated" comments is _not_ a good way to increase adoption of Scala.

  --Rex

P.S. My comment there is:

With the flag disabled, Scala will be less powerful than Ceylon (which has extension methods) and Clojure (if you count macros).

Not a good idea.

What is a good idea is adding simplifying features and documenting them well.  [A: Manifest] is a lot easier to grapple with than (a: A)(implicit mf: Manifest[A]), which is in turn easier to grapple with than the case when you have to explicitly call the manifest at every opportunity you might need it.

With a limited (sane) implementation of MyType, a few enhancements to type inference, and a few patches of better documentation (including lookup of symbols), all the complaints here would go away.

For example,
  val x = add(1,_)
has no business requiring a type annotation.  It's utterly unambiguous: use whatever type the add method takes!  This isn't an issue of needing to turn on features with flags; it's just a silly limitation of the existing type inference engine that ought to be fixed.

The biggest source of complexity in any language (that I've seen) is the special cases.  Whether you make them explicit in your language spec or implicit because of implementation limitations and/or bugs doesn't matter; it still requires the user to know an awful lot more than they ought to to work around them.  (Specialization, for instance, is something that I find requires enormous testing and knowledge because of the multiple bugs; fix the bugs and Scala will be simpler _and_ more powerful.)

On Mon, Jan 9, 2012 at 4:48 PM, Erik Osheim <erik [at] plastic-idolatry [dot] com" rel="nofollow">erik [at] plastic-idolatry [dot] com> wrote:
Hey everyone,

Was wondering if people had seen Martin's post [1] in response to
the "new" complexity blog post [2]?

I am sympathetic to Martin's point that the collections might not be
arbitrarily extensible (they certainly aren't in many other languages).

However, I'm not sure that taking away things like implicit conversion
will address many of the problems brought up later in the original post
(e.g. the sortBy failure) since this is code that doesn't look like
it's trying to do anything fancy. I don't think these are cases of a
developer cutting herself on a dangerous tool.

I'm also a bit nervous--if implicit parameters and enrichment become
frowned-upon (or "second-class") constructions in Scala then it will
have serious implications for things like the type class pattern (which
I am currently finding hugely useful).

What do you all think?

-- Erik

[1] http://news.ycombinator.com/item?id=3444285

[2] http://yz.mit.edu/wp/true-scala-complexity/


Jori Jovanovich
Joined: 2011-04-24,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator
I agree very strongly that implicits should not be hidden behind a flag!  Implicits/type classes are one of my favorite features of Scala.
Instead I very much hope that additional investment into type classes will be made (like Josh's implicit class inlining proposal to put implicits on par with extension methods in terms of performance).
Also, couldn't the original poster's problem be resolved by allowing multiple implicit conversions to happen at once?  I know this is probably a Bad Idea and confusing in most cases, but maybe there are certain cases where it makes sense to allow it (via an annotation, or maybe something cleaner if possible).  i.e. I'd rather see this problem get resolved via strengthening of type classing than by admitting defeat.
(I'd also love it if we could write "type class <a>" instead of "implicit class <a>" in the new proposals I've seen.)
Keep up the awesome work Martin & team, don't get discouraged by some drama -- you'll never make everyone happy.
On Mon, Jan 9, 2012 at 3:48 PM, Erik Osheim <erik [at] plastic-idolatry [dot] com> wrote:
Hey everyone,

Was wondering if people had seen Martin's post [1] in response to
the "new" complexity blog post [2]?

I am sympathetic to Martin's point that the collections might not be
arbitrarily extensible (they certainly aren't in many other languages).

However, I'm not sure that taking away things like implicit conversion
will address many of the problems brought up later in the original post
(e.g. the sortBy failure) since this is code that doesn't look like
it's trying to do anything fancy. I don't think these are cases of a
developer cutting herself on a dangerous tool.

I'm also a bit nervous--if implicit parameters and enrichment become
frowned-upon (or "second-class") constructions in Scala then it will
have serious implications for things like the type class pattern (which
I am currently finding hugely useful).

What do you all think?

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: martin's post on ycombinator

On 1/10/12, Jori Jovanovich wrote:
> I agree very strongly that implicits should not be hidden behind a flag!
> Implicits/type classes are one of my favorite features of Scala.

I agree too. I wouldn't mind a flag to *disable* implicits, but since
they are so useful they should be on by default.

Note: I didn't say I *want* a flag to disable implicits, I just said I
wouldn't mind it, since it wouldn't affect me if I didn't use it. Then
again, I can envision a scenario where some regulatory authority might
require that implicits be disabled for ultra-safety-critical software.
I wouldn't want to be forced to program that way, but if it meant the
difference between using Scala without implicits or not using Scala at
all, I'd prefer to use it.

--Russ P.

Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: martin's post on ycombinator

When you or Martin say "disable" - you actually mean giving me the option to
generate compiler errors vs warnings vs nothing?

-----Original Message-----
From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com]
On Behalf Of Russ Paielli
Sent: January-10-12 2:35 PM
To: Jori Jovanovich
Cc: scala-debate [at] googlegroups [dot] com
Subject: Re: [scala-debate] martin's post on ycombinator

On 1/10/12, Jori Jovanovich wrote:
> I agree very strongly that implicits should not be hidden behind a flag!
> Implicits/type classes are one of my favorite features of Scala.

I agree too. I wouldn't mind a flag to *disable* implicits, but since they
are so useful they should be on by default.

Note: I didn't say I *want* a flag to disable implicits, I just said I
wouldn't mind it, since it wouldn't affect me if I didn't use it. Then
again, I can envision a scenario where some regulatory authority might
require that implicits be disabled for ultra-safety-critical software.
I wouldn't want to be forced to program that way, but if it meant the
difference between using Scala without implicits or not using Scala at all,
I'd prefer to use it.

--Russ P.

--
http://RussP.us

Matthew Pocock 3
Joined: 2010-07-30,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator


On 10 January 2012 19:11, Jori Jovanovich <jori [at] dimensiology [dot] com> wrote:
I agree very strongly that implicits should not be hidden behind a flag!  Implicits/type classes are one of my favorite features of Scala.

Same for me. Both implicits in general, and their support in making programming with type classes possible without drowning in verbosity are things I very much enjoy about scala. There is a way to go in the compiler and IDEs to make implicits and type classes as maintainable, refactorable and performant as OO-style code, and surely this effort is worth it.
Matthew --
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle Universitymailto: turingatemyhamster [at] gmail [dot] com gchat: turingatemyhamster [at] gmail [dot] commsn: matthew_pocock [at] yahoo [dot] co [dot] uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143
Cay Horstmann
Joined: 2009-09-04,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator

I would imagine that the flag, if it ever comes to be, is for
producers of libraries, not for consumers. You wouldn't get very far
consuming the standard Scala libraries without implicits.

I don't think it's a bad idea to have a flag that indicates the level
at which a programmer aims to produce code. Particularly for newcomers
to the language, one could give much better error messages. This works
nicely in Racket, for example.

Frankly, though, I don't think it would have solved the issue with
this particular blog. The author is an experienced Scala programmer
who would have cranked up the flag to level 11.

Anyway, the way to deal with the "Scala is too hard"/"Scala doesn't
solve my pet problem" blogs isn't to analyze each of them to death but
to drown them out. Instead of posting another email here, write a blog
about what makes Scala good :-)

Cheers,

Cay

On Tue, Jan 10, 2012 at 4:03 PM, Matthew Pocock
wrote:
>
>
> On 10 January 2012 19:11, Jori Jovanovich wrote:
>>
>> I agree very strongly that implicits should not be hidden behind a flag!
>>  Implicits/type classes are one of my favorite features of Scala.
>>
>
> Same for me. Both implicits in general, and their support in making
> programming with type classes possible without drowning in verbosity are
> things I very much enjoy about scala. There is a way to go in the compiler
> and IDEs to make implicits and type classes as maintainable, refactorable
> and performant as OO-style code, and surely this effort is worth it.
>
> Matthew
>

Ittay Dror 2
Joined: 2010-05-05,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator
body p { margin-bottom: 0cm; margin-top: 0pt; }



Cay Horstmann wrote:

CANs8r67y9PmGWfsy4o2aGYdRnfdePY6rDs56CQhyHVwLutKuZw [at] mail [dot] gmail [dot] com" type="cite">
I would imagine that the flag, if it ever comes to be, is for
producers of libraries, not for consumers. You wouldn't get very far
consuming the standard Scala libraries without implicits.

I don't think it's a bad idea to have a flag that indicates the level
at which a programmer aims to produce code. Particularly for newcomers
to the language, one could give much better error messages. This works
nicely in Racket, for example.

Frankly, though, I don't think it would have solved the issue with
this particular blog. The author is an experienced Scala programmer
who would have cranked up the flag to level 11.

Anyway, the way to deal with the "Scala is too hard"/"Scala doesn't
solve my pet problem" blogs isn't to analyze each of them to death but
to drown them out. Instead of posting another email here, write a blog
about what makes Scala good :-)

+1

And make adding extension methods to collections easy. Either through direct language support or a template/wizard that makes it trivial. Miles' gist on the subject seems like a good start...


CANs8r67y9PmGWfsy4o2aGYdRnfdePY6rDs56CQhyHVwLutKuZw [at] mail [dot] gmail [dot] com" type="cite">

Cheers,

Cay

On Tue, Jan 10, 2012 at 4:03 PM, Matthew Pocock
turingatemyhamster [at] gmail [dot] com (<turingatemyhamster [at] gmail [dot] com>) wrote:

On 10 January 2012 19:11, Jori Jovanovich jori [at] dimensiology [dot] com (<jori [at] dimensiology [dot] com>) wrote:
I agree very strongly that implicits should not be hidden behind a flag!
 Implicits/type classes are one of my favorite features of Scala.

Same for me. Both implicits in general, and their support in making
programming with type classes possible without drowning in verbosity are
things I very much enjoy about scala. There is a way to go in the compiler
and IDEs to make implicits and type classes as maintainable, refactorable
and performant as OO-style code, and surely this effort is worth it.

Matthew


debasish
Joined: 2011-06-19,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator
AFAIR Java interop was one of the core requirements that Martin had in mind when creating Scala. Otherwise Scala would have been a completely different language (without the baggages of imports, constructors with new and what not).
And regarding switching off subtyping refer to Miles Sabin's recent tweets - it may not be as straightforward as it seems. Here's one of Miles tweets on this ..
@DRMacIver I think the semantics of imports, member selection and method application are pretty much inextricably entwined with subtyping.

regards.
2012/1/10 Richard Wallace <rwallace [at] thewallacepack [dot] net>
2012/1/10 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>:
>
>
> On Tue, Jan 10, 2012 at 9:30 AM, Debasish Ghosh <ghosh [dot] debasish [at] gmail [dot] com>
> wrote:
>>>
>>> There are interactions between implicits, subtyping and type inference
>>> which are not easily described.
>>
>>
>> Exactly and this may very well lead one to believe that adding a method in
>> Seq can make it available in Arrays / Strings. I actually liked the post by
>> @yaang. He worked through the whole process to finally hit the wall ..
>
>
> The interesting bit is that the wall he hit is due to the strong ties
> between the java language and the JVM, namely Strings and Arrays.
>

Even more interestingly, the wrong conclusion has been drawn from his
post.  That higher-kinded types and implicits should be disable by
default is ridiculous when the real complexity is the Java
interoperation and subtyping.  If we have "complexity flags" in the
compiler, I'd much rather see those things disabled by default.

> Cheers,
> √
>
>>
>>
>> Regards.
>>
>> On Tue, Jan 10, 2012 at 1:20 PM, rkuhn <google [at] rkuhn [dot] info> wrote:
>>>
>>> «There is absolutely nothing wrong with the "complexity" of Scala»
>>>
>>> That this sentence is wrong is exactly the—well proven—point of the
>>> original blog post. Scala is definitely not perfect. The reason is that the
>>> problems it tries to solve are hard and the imperfection lies in the fact
>>> that some of the underlying complexity of the problem (the “feature
>>> interactions”) is not perfectly encapsulated, i.e. the features are not
>>> perfectly orthogonal. There are interactions between implicits, subtyping
>>> and type inference which are not easily described.
>>>
>>> So, the main point is that there is room for improvement—at least that it
>>> is reasonable to strive for it. It is perfectly alright to say that for your
>>> current use cases Scala in its current form is well-suited. But this
>>> discussion has a broader scope.
>>>
>>> Wrt. the feature-hiding proposal, I think that would not solve the issue
>>> (and adding condescendingly named options definitely does not help) and the
>>> added complexity due to less repeatable or more difficult to manage builds
>>> in my opinion outweighs any potential benefit.
>>>
>>> Regards,
>>>
>>> Roland
>>
>>
>>
>>
>> --
>> Debasish Ghosh
>> http://manning.com/ghosh
>>
>> Twttr: @debasishg
>> Blog: http://debasishg.blogspot.com
>> Code: http://github.com/debasishg
>
>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe - Enterprise-Grade Scala from the Experts
>
> Twitter: @viktorklang
>



--
Debasish Ghosh
http://manning.com/ghosh

Twttr: @debasishg
Blog: http://debasishg.blogspot.com
Code: http://github.com/debasishg
Simon Ochsenreither
Joined: 2011-07-17,
User offline. Last seen 42 years 45 weeks ago.
Re: martin's post on ycombinator
And make adding extension methods to collections easy. Either through direct language support or a template/wizard that makes it trivial. Miles' gist on the subject seems like a good start...

Every implementation of extension methods in languages I have seen has been a semantic nightmare. In my opinion, there is no need for extension methods in languages with traits/mixins or ("default methods", like Java 8).

Additionally, I don't get all these comparisons between implicits in Scala and extension methods in other languages.

Doesn't it make substantially more sense to compare implicits in Scala with the implicits in Java or C#?

Bye,

Simon
milessabin
Joined: 2008-08-11,
User offline. Last seen 33 weeks 3 days ago.
Re: martin's post on ycombinator

On Wed, Jan 11, 2012 at 4:15 AM, Cay Horstmann wrote:
> Anyway, the way to deal with the "Scala is too hard"/"Scala doesn't
> solve my pet problem" blogs isn't to analyze each of them to death but
> to drown them out. Instead of posting another email here, write a blog
> about what makes Scala good :-)

Cheers,

Miles

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: martin's post on ycombinator

here's a summary of everything, including the good stuff explained as simple as i could:

http://rapidshare.com/files/1247979869/scc.pdf

it's not completely finished yet, but it covers most features.
it'll (hopefully soon) replace the current scala cheat sheet :) (as soon as i solve some random problems with jekyll and charsets)

-------- Original-Nachricht --------
> Datum: Wed, 11 Jan 2012 09:23:42 +0000
> Von: Miles Sabin
> An: Cay Horstmann
> CC: scala-debate [at] googlegroups [dot] com
> Betreff: Re: [scala-debate] martin\'s post on ycombinator

> On Wed, Jan 11, 2012 at 4:15 AM, Cay Horstmann
> wrote:
> > Anyway, the way to deal with the "Scala is too hard"/"Scala doesn't
> > solve my pet problem" blogs isn't to analyze each of them to death but
> > to drown them out. Instead of posting another email here, write a blog
> > about what makes Scala good :-)
>
> +ѡ
>
> Cheers,
>
>
> Miles
>

ojow
Joined: 2009-10-21,
User offline. Last seen 37 weeks 3 days ago.
Re: martin's post on ycombinator

Anyway, the way to deal with the "Scala is too hard"/"Scala doesn't
solve my pet problem" blogs isn't to analyze each of them to death but
to drown them out. Instead of posting another email here, write a blog
about what makes Scala good :-)

Yes! And also about easy and elegant Scala libraries (you might have to create one before that).
Bernd Johannes
Joined: 2011-01-28,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: martin's post on ycombinator
p, li { white-space: pre-wrap; }

Am Montag, 9. Januar 2012, 23:30:56 schrieb Lars Hupel:

> > Was wondering if people had seen Martin's post [1] in response to

> > the "new" complexity blog post [2]?

>

> I think this post makes some good points. As already pointed out, these

> are fairly advanced problems, which make them not less important but

> rather relevant to library writers, not users. If we have to spend more

> time on designing good libraries, fair enough.

>

> FWIW, considering things as difficult or even impossible doesn't stop

> smart people from coming up with smart workarounds. That's a good

> property of the Scala community.

>

> > I'm also a bit nervous--if implicit parameters and enrichment become

> > frowned-upon (or "second-class") constructions in Scala then it will

> > have serious implications for things like the type class pattern (which

> > I am currently finding hugely useful).

>

> I was a bit shocked upon reading the bit about the compiler flags.

> However, I will happily add these flags to my build configuration as I

> already do with "-unchecked" et al. (and "-Ydependent-method-types"

> being the newest incarnation).


Throwing a compiler switch at implicits wouldn't solve the problem in my eyes. At least not in the case of implicits. They have many well justified use cases. I agree that higher kinded types (and delimited continuation by the way) are harder to get by - but if this justifies a switch is to be discussed.


The interesting part are those cases where things get messy or don't work at all. It can be incredibly frustrating to try to convince the compiler about something which is inherently not easy to express (or not sound first place or impossible because of language or system limitations). Yes - it's all about knowledge and know how.


I still don't know the solution space of scala well enough to directly decide / anticipate which solution is easy to achieve and which will pose problems (apart from the very straightforward nobrainers). I don't ascribe this to scala - it's just my java background which didn't prepare me for the "new world". But I guess these uncertainties and the correlated "time sinks" drive some of the complexity discussions and rants.


I would love to see more "patterns" stuff.

* typical solutions for common problems

* antipattern warnings

* don't try this at home - leave it to advanced librarians

* best practices - do it THIS way for good reasons


The scala levels are a good starting point regarding possible feature complexities. But they don't give (and are not intended to give) advice how to combine these features to achieve certain solutions.


And I think we should emphasise that scala is a splendid and reasonable simple tool for many simple to moderate problems and still provides solutions in complex cases where other languages simply refrain.


And maybe it's time to stress that not every scala application has to abstract any and all operations to the highest level just because the language allows this. Pragmatism can be a little ("wet" and unsafe) asInstanceOf solution - and I'd rather have a 80% working solution than a 100% not working solution which would be completely typesafe and perfectly DRY...


Just my 5 cents

Greetings

Bernd


tolsen77
Joined: 2008-10-08,
User offline. Last seen 1 year 38 weeks ago.
Re: Re: martin's post on ycombinator
I always felt the six levels of Scala programming was a half-baked response when it was posted. My own coding is what you would consider application development but still I require some features from all levels of the library designer. I do believe thinking about Scala in terms of application and library designer in general is a good thing, but like you say, some of the drawbacks associated with different features is well worth getting documented. Especially its performance characteristics etc. The problems experienced by Scala developers relating to language features could for instance be incorporated into "A Tour of Scala", "Scala by Example", and future revisions of books like Programming in Scala.

On 14 January 2012 00:58, Bernd Johannes <bjohanns [at] bacon [dot] de> wrote:

Am Montag, 9. Januar 2012, 23:30:56 schrieb Lars Hupel:

> > Was wondering if people had seen Martin's post [1] in response to

> > the "new" complexity blog post [2]?

>

> I think this post makes some good points. As already pointed out, these

> are fairly advanced problems, which make them not less important but

> rather relevant to library writers, not users. If we have to spend more

> time on designing good libraries, fair enough.

>

> FWIW, considering things as difficult or even impossible doesn't stop

> smart people from coming up with smart workarounds. That's a good

> property of the Scala community.

>

> > I'm also a bit nervous--if implicit parameters and enrichment become

> > frowned-upon (or "second-class") constructions in Scala then it will

> > have serious implications for things like the type class pattern (which

> > I am currently finding hugely useful).

>

> I was a bit shocked upon reading the bit about the compiler flags.

> However, I will happily add these flags to my build configuration as I

> already do with "-unchecked" et al. (and "-Ydependent-method-types"

> being the newest incarnation).


Throwing a compiler switch at implicits wouldn't solve the problem in my eyes. At least not in the case of implicits. They have many well justified use cases. I agree that higher kinded types (and delimited continuation by the way) are harder to get by - but if this justifies a switch is to be discussed.


The interesting part are those cases where things get messy or don't work at all. It can be incredibly frustrating to try to convince the compiler about something which is inherently not easy to express (or not sound first place or impossible because of language or system limitations). Yes - it's all about knowledge and know how.


I still don't know the solution space of scala well enough to directly decide / anticipate which solution is easy to achieve and which will pose problems (apart from the very straightforward nobrainers). I don't ascribe this to scala - it's just my java background which didn't prepare me for the "new world". But I guess these uncertainties and the correlated "time sinks" drive some of the complexity discussions and rants.


I would love to see more "patterns" stuff.

* typical solutions for common problems

* antipattern warnings

* don't try this at home - leave it to advanced librarians

* best practices - do it THIS way for good reasons


The scala levels are a good starting point regarding possible feature complexities. But they don't give (and are not intended to give) advice how to combine these features to achieve certain solutions.


And I think we should emphasise that scala is a splendid and reasonable simple tool for many simple to moderate problems and still provides solutions in complex cases where other languages simply refrain.


And maybe it's time to stress that not every scala application has to abstract any and all operations to the highest level just because the language allows this. Pragmatism can be a little ("wet" and unsafe) asInstanceOf solution - and I'd rather have a 80% working solution than a 100% not working solution which would be completely typesafe and perfectly DRY...


Just my 5 cents

Greetings

Bernd



Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland