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.

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.

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/

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.

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

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