6 ms·

Why is it so hard to keep your data structures immutable in C# or Java? C# (my primary language) has parallel collections as of .Net 4.0 and with .Net 4.5 you h

Why is it so hard to keep your data structures immutable in C# or Java? C# (my primary language) has parallel collections as of .Net 4.0 and with .Net 4.5 you have the async keyword support on top of the TPL. Could you elaborate on the differences between Scala and C# which make Sala more preferable for you? I'm not trying to start a war on C# vs Scala, I'm genuinely interested in the differences (I enjoy learning new languages, but for the right reasons)

karterk 13y ago
I can't talk too much about C#, but in Java there is no first class support for `map`, 'filter`, `reduce` etc. (with Google's Guava, you can imitate these things, but not so elegantly). So transforming a data structure involves a for-loop and lots of mutable operations. Iterating and transforming a collection in a functional style is much nicer.
- flipchart 13y ago
  I agree with you on the functional style. C#'s LINQ solves this problem quite well, although they named them differently (map -> select, filter -> where, reduce -> Aggregate). I've seen a number of people laud C# for being functional-ish because of such features.
  - seglo 13y ago
    LINQ is a fantastic DSL akin to Scala's collection types. Odersky gives C# the nod as one of the few other traditionally imperative languages to have such a rich way of transforming data in his Functional Programming with Scala coursera course. I do prefer Scala's collection types and for comprehensions over LINQ though. I find them much easier to read and more powerful.
  - _random_ 13y ago
    You are explaining it a bit wrong. C# provides delegates (Action, Func etc.), lambda expressions, expression trees, anonymous functions, anonymous types, extensions methods. Those features make it a functional language and make succinct monads possible. LINQ happens to be one of those monads, but you can implement yours (e.g. rename Select to map etc.).
    - flipchart 13y ago
      Yes I agree with you. I'm not as well versed in monads and the technicalities around them as I would like to be, so thank you for pointing that out!
bad_user 13y ago
It's hard because of the type-system. Experiment with Scala's immutable data-structures and try implementing them in Java. For example, lack of support for type-classes, not to mention the really shitty support for generics in Java, designed probably by sado-masochists, makes that really painful to do and there's a world of difference between Guava and Scala's library. For a real example, try designing generic data-structures in Java, that exposes the below functionality in a type-safe way: scala> val list = List(9, 7, 5, 10, 11) list: List[Int] = List(9, 7, 5, 10, 11) scala> list.sum res0: Int = 42 scala> list.sorted res1: List[Int] = List(5, 7, 9, 10, 11) scala> val stringList = List("a", "b", "c") stringList: List[java.lang.String] = List(a, b, c) scala> stringList.sum <console>:9: error: could not find implicit value for parameter num: Numeric[java.lang.String] stringList.sum ^ scala> val bitSet = collection.immutable.BitSet(1,2,3,4) bitSet: scala.collection.immutable.BitSet = BitSet(1, 2, 3, 4) scala> bitSet.map(_ + 1) // the result is still a BitSet res3: scala.collection.immutable.BitSet = BitSet(2, 3, 4, 5) scala> bitSet.map(_.toString) // the result is not a BitSet res4: scala.collection.immutable.Set[java.lang.String] = Set(1, 2, 3, 4) scala> map.map(kv => (kv._1 + 1, kv._2 + 1)) // result is still a Map res7: scala.collection.immutable.Map[Int,Int] = Map(2 -> 3, 4 -> 5) scala> map.map(kv => kv._1) // result will not be a map res8: scala.collection.immutable.Iterable[Int] = List(1, 3) In case you're wondering, you can't.
- eranation 13y ago
  > not to mention the really shitty support for generics in Java, designed probably by sado-masochists Ironically, Martin Odersy, creator of Scala, is one of the core people behind Java Generics [0] EDIT: Just to clarify, I'm a huge Scala fan, and understand Odersky had constraints and compromises to do on Java, which I think is probably one of the reasons he went on to create Scala. [0] - http://en.wikipedia.org/wiki/Martin_Odersky http://en.wikipedia.org/wiki/Martin_Odersky
  - hrjet 13y ago
    Ironical yes, but the reason generics is hampered in Java is backward-compatiblity, which was not Martin's decision from what I read.

karterk 13y ago

I can't talk too much about C#, but in Java there is no first class support for `map`, 'filter`, `reduce` etc. (with Google's Guava, you can imitate these things, but not so elegantly). So transforming a data structure involves a for-loop and lots of mutable operations. Iterating and transforming a collection in a functional style is much nicer.

flipchart 13y ago
I agree with you on the functional style. C#'s LINQ solves this problem quite well, although they named them differently (map -> select, filter -> where, reduce -> Aggregate). I've seen a number of people laud C# for being functional-ish because of such features.
- seglo 13y ago
  LINQ is a fantastic DSL akin to Scala's collection types. Odersky gives C# the nod as one of the few other traditionally imperative languages to have such a rich way of transforming data in his Functional Programming with Scala coursera course. I do prefer Scala's collection types and for comprehensions over LINQ though. I find them much easier to read and more powerful.
- _random_ 13y ago
  You are explaining it a bit wrong. C# provides delegates (Action, Func etc.), lambda expressions, expression trees, anonymous functions, anonymous types, extensions methods. Those features make it a functional language and make succinct monads possible. LINQ happens to be one of those monads, but you can implement yours (e.g. rename Select to map etc.).
  - flipchart 13y ago
    Yes I agree with you. I'm not as well versed in monads and the technicalities around them as I would like to be, so thank you for pointing that out!

bad_user 13y ago

It's hard because of the type-system. Experiment with Scala's immutable data-structures and try implementing them in Java. For example, lack of support for type-classes, not to mention the really shitty support for generics in Java, designed probably by sado-masochists, makes that really painful to do and there's a world of difference between Guava and Scala's library. For a real example, try designing generic data-structures in Java, that exposes the below functionality in a type-safe way: scala> val list = List(9, 7, 5, 10, 11) list: List[Int] = List(9, 7, 5, 10, 11) scala> list.sum res0: Int = 42 scala> list.sorted res1: List[Int] = List(5, 7, 9, 10, 11) scala> val stringList = List("a", "b", "c") stringList: List[java.lang.String] = List(a, b, c) scala> stringList.sum <console>:9: error: could not find implicit value for parameter num: Numeric[java.lang.String] stringList.sum ^ scala> val bitSet = collection.immutable.BitSet(1,2,3,4) bitSet: scala.collection.immutable.BitSet = BitSet(1, 2, 3, 4) scala> bitSet.map(_ + 1) // the result is still a BitSet res3: scala.collection.immutable.BitSet = BitSet(2, 3, 4, 5) scala> bitSet.map(_.toString) // the result is not a BitSet res4: scala.collection.immutable.Set[java.lang.String] = Set(1, 2, 3, 4) scala> map.map(kv => (kv._1 + 1, kv._2 + 1)) // result is still a Map res7: scala.collection.immutable.Map[Int,Int] = Map(2 -> 3, 4 -> 5) scala> map.map(kv => kv._1) // result will not be a map res8: scala.collection.immutable.Iterable[Int] = List(1, 3) In case you're wondering, you can't.

eranation 13y ago
> not to mention the really shitty support for generics in Java, designed probably by sado-masochists Ironically, Martin Odersy, creator of Scala, is one of the core people behind Java Generics [0] EDIT: Just to clarify, I'm a huge Scala fan, and understand Odersky had constraints and compromises to do on Java, which I think is probably one of the reasons he went on to create Scala. [0] - http://en.wikipedia.org/wiki/Martin_Odersky http://en.wikipedia.org/wiki/Martin_Odersky
- hrjet 13y ago
  Ironical yes, but the reason generics is hampered in Java is backward-compatiblity, which was not Martin's decision from what I read.