Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

True Scala complexity

yz.mit.edu

Post reply on HN
Print view View original

51–60 of 152 posts

Re: True Scala complexity

#51

Post by saucetenuto »

modersky wrote: post #45
saucetenuto wrote: post #44

Earlier quoted context omitted.

> The author tries to add arbitrary operations to Scala's Seq abstraction without changing its source code and wants them to work also on arrays (which are plain old Java arrays) Are we sure that's true? In the first half, with RichSeqs and isMajority() and so on, the author appears to define all her own types, and gives her examples entirely in terms of those types. For example: scala> class Seq[A] { def head = 0 }…

The author tries to add "ident" to Seq, and have it work automatically on native Java arrays.

When? The author appears to define her own Array type as well:

    scala> class Array
    defined class Array

    scala> class WrappedArray(xs: Array) extends Seq // a Seq adapter for Arrays
    defined class WrappedArray

    scala> implicit def array2seq(xs: Array): Seq = new WrappedArray(xs)
    array2seq: (xs: Array)WrappedArray

    scala> new Array().ident
    :13: error: value ident is not a member of Array
              new Array().ident

Re: True Scala complexity

#52

Post by aaronh »

modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

unfortunate that there needs to be a --enable-flaming option :(

Re: True Scala complexity

#53

Post by modersky »

saucetenuto wrote: post #51
modersky wrote: post #45

Earlier quoted context omitted.

The author tries to add "ident" to Seq, and have it work automatically on native Java arrays.

When? The author appears to define her own Array type as well: scala> class Array defined class Array scala> class WrappedArray(xs: Array) extends Seq // a Seq adapter for Arrays defined class WrappedArray scala> implicit def array2seq(xs: Array): Seq = new WrappedArray(xs) array2seq: (xs: Array)WrappedArray scala> new Array().ident :13: error: value ident is not a member of Array new Array().ident

Arrays are not sequences, in either the standard Scala library or his condensation of it. The goal is still to define a single extension method for two unrelated types.

Re: True Scala complexity

#54

Post by dxbydt »

modersky wrote: post #45
saucetenuto wrote: post #44

Earlier quoted context omitted.

> The author tries to add arbitrary operations to Scala's Seq abstraction without changing its source code and wants them to work also on arrays (which are plain old Java arrays) Are we sure that's true? In the first half, with RichSeqs and isMajority() and so on, the author appears to define all her own types, and gives her examples entirely in terms of those types. For example: scala> class Seq[A] { def head = 0 }…

The author tries to add "ident" to Seq, and have it work automatically on native Java arrays.

> have it work automatically on native Java arrays

Correct me if I'm wrong, but he is not operating on native Java arrays at all.

He redefines Array, redefines Seq and redefines WrappedArray as a subtype of Seq. He adds ident to Seq, and since Array isn't a subtype of Seq, ident is not a member of Array ( he points that out too, and provides a solution as well. He is operating in his own "tiny parallel universe" as he says in the post. He even redefines String and CharSequence (which threw me off because isn't java.lang.String & java.lang.CharSequence already in the namespace so the conflicts etc...) Then he wants a Seq[Char] ( not the scala Seq but his redefined Seq ) to mimic the redefined String! The whole thing is quite crazy & terribly fascinating imo.

Re: True Scala complexity

#55

Post by modersky »

akeefer wrote: post #41
michaelochurch wrote: post #28

Earlier quoted context omitted.

First of all, the things he shows aren't inherently complex: adding an additional function to the existing collections library is something that's possible in other languages in less confusing ways (see other examples in this post). It's very easy to write a new function for your particular case. You can write an acceptable map function for your new collection, or a new list-munching function, just as easily as in ML…

But again, other languages do offer the ability to write methods that apply to all collections, without the "complexity." Sure, it's different, but in Gosu for example you can write an enhancement method on the Collection interface, or on the List interface, and now everything that implements Collection or List has that method. It's then a matter of whether or not the objects in question implement that appropriate in…

Arrays are not collections, either in Scala, or in the blog's condensation of it. But the blog nevertheless tries to define a single extension method that works for both sequences and arrays. I do not think this problem has a simple solution in any language.

Re: True Scala complexity

#56

Post by barrkel »

raganwald wrote: post #38
modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Speaking as someone who sometimes writes controversial things and never enables comments on my posts... I view collections of comments as discussions. Readers often form into communities, like Hacker News. If there are…

Sometimes comments are just comments. If you need a link to figure out whether to take a person seriously (i.e. their comment has no merit free-standing - I'm not sure this is true), a link to a blog ought to be sufficient.

I know I frequently click on the links people provide when they make blog comments, but I don't think I've ever looked at someone's Disqus history. Disqus cuts across multiple sites in potentially drastically different arenas; it's too horizontal. But when someone provides a link, they usually mean it to be relevant.

Re: True Scala complexity

#57

Post by CriasSK »

modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

I understand the suggestion, and adding a guard to the knife makes some sense, but where's the line?

As a library developer, let's say I use a few implicit conversions to make my library easy to use. I sign off on the use with a compiler flag, no big deal, but now every user of my library has to do the same?

Perhaps I'm misunderstanding, but wouldn't this suggestion effectively ruin "ArrowAssoc"? Because I can't think of a single application I write that doesn't use one of those, honestly.

Re: True Scala complexity

#58

Post by Dn_Ab »

jashkenas wrote: post #3

Fantastic post. The most salient excerpt for me: def filterMap[B,D](f: A => Option[B])(implicit b: CanBuildFrom[?,B,D]): D def filterMap[B,D Option[B])(implicit b: CanBuildFrom[?,B,D]): D def filterMap[B,D Option[B])(implicit b: CanBuildFrom[?,B,D]): D def filterMap[B,D[B]](f: A => Option[B])(implicit b: CanBuildFrom[?,B,D[B]]): D[B] def filterMap[B,D[B] Option[B])(implicit b: CanBuildFrom[?,B,D[B]]): D[B] def filter…

In F# this is approximated with:

  type 'a IEnumerable with
    member this.filterMap f = 
       [for x in this do if f x  None then yield (f x).Value]

  let j =  Map([("a",1) ; ("b",2) ]).filterMap(fun kv -> if kv.Value = 1 then Some(kv.Key,kv.Value) else None) |> Map.ofList

  let n = [1.;2.;4.].filterMap(fun x -> if x % 2. = 0. then Some(x**2.) else None)
The extension works with any Sequence (arrays, sequences, maps,etc.) with the caveat that it maps every enumerable to a list. You could also define an extension for a specific type where a broad definition does not make sense.

Personally, I lean more functional, I have never run across a need for extending things in this manner.

Re: True Scala complexity

#59

Post by saucetenuto »

modersky wrote: post #53
saucetenuto wrote: post #51

Earlier quoted context omitted.

When? The author appears to define her own Array type as well: scala> class Array defined class Array scala> class WrappedArray(xs: Array) extends Seq // a Seq adapter for Arrays defined class WrappedArray scala> implicit def array2seq(xs: Array): Seq = new WrappedArray(xs) array2seq: (xs: Array)WrappedArray scala> new Array().ident :13: error: value ident is not a member of Array new Array().ident

Arrays are not sequences, in either the standard Scala library or his condensation of it. The goal is still to define a single extension method for two unrelated types.

Well, sorta; the Array -> WrappedArray conversion relates them. The intent is to let you use Seq methods on Arrays, and that part works. But you don't also get RichSeq methods, even though you can use them on Seqs. I'm sure that seems obvious to you, but do you see how the author's intent is misaligned with the result?

I think that's the key takeaway: implicits aren't really a way of extending a library type, they just have some of the same effects. You still have to care about the distinction between the original type and the enhanced one, and that's, well, complex.

Re: True Scala complexity

#60

Post by Rayne »

pwpwp wrote: post #49
awj wrote: post #48

Earlier quoted context omitted.

One issue that Scala has been dealing with for ages is a "oh my god, look at these sharp edges, I'll hurt myself!" response. Even if an individual more or less trusts themselves to make good decisions about language constructs, there's the concern that an individual library can (or has) force inappropriate complexity on them. Giving people a mechanism to limit, or at least easily discover, the use of complicated lang…

Adding a "complexity safety switch" kind of defeats the claim that your language isn't complex.

Except that I'm pretty sure he isn't denying that the language is complex. From Martin's comment, it appears that he is saying that Scala provides powerful and complex language features to solve hard problems, but that it isn't Scala's fault that people are so persistent about abusing them.
Post reply on HN