5 ms·

Kinda frustrating that the language comparaison is by syntax instead of features ( http://www.scribd.com/doc/227879724/Swift-vs-Scala-2-11 http://www.scribd.com

by rtpg 12y ago

Kinda frustrating that the language comparaison is by syntax instead of features ( http://www.scribd.com/doc/227879724/Swift-vs-Scala-2-11 http://www.scribd.com/doc/227879724/Swift-vs-Scala-2-11 is what's referenced in the article). I'm fairly convinced that Swift enums and Scala case classes are only superficially the same, and based off the discussions I've heard about generics in Swift, Swift is miles aways from even C++-levels of generics, let alone Scala's. Unless someone shows me otherwise, I'm convinced that Scala and Swift only have superficial similarities.

benvan 12y ago
I agree - the examples given are almost infuriating. Whilst I can't comment on how idiomatic the Swift code is, the Scala code is anything but. There's little benefit to using a language like Scala if you're going to count the number of apples and oranges in a list by incrementing a mutable var for each type.
- efnx 12y ago
  My problem with both languages is that you can count apples like that. If it can be done, it will be done.
densh 12y ago
Author of those slides here. They were made on the next day after the language was presented on WWDC and were based purely on the first draft of the Swift book published online by Apple. Needless to say the book was more of a tutorial than a full-blown spec at that time and many important aspects were not covered (generics were lightly documented without much details). Can you please provide details about generics in Swift and how exactly are they different from Scala's? Edit: changed 'superior' to 'different'.
- eklavya 12y ago
  Don't bother, people will just say X is better than Scala here. They don't know the amount of research done by Odersky on generics and why Scala can not be easily beaten in this area at least.
  - eropple 12y ago
    Scala can't be easily beaten there? Man...have you used C#? I mean, I use Scala every day, but C# gives you so much solely on reification and Scala manifests are a real poor patch.
    - eklavya 12y ago
      Holy shit you have got to be joking. Really trolling now, are we? Take a look at things like Shapeless (https://github.com/milessabin/shapeless https://github.com/milessabin/shapeless).
      - eropple 12y ago
        I've used Shapeless. It doesn't affect my actually writing code on a daily basis. Reified generics do.
        eklavya 12y ago
        How exactly?
- yohanatan 12y ago
  I think you meant 'inferior'.
- chrisoverzero 12y ago
  I think that poster is saying that Swift's generics are not as good as C++'s, and even more not as good as Scala's. "Miles away" is ambiguous, but I think it's "miles behind" in this context, given its proximity to "even" and "let alone."
tel 12y ago
Swift enums and Scala case classes both attempt to emulate ML/Haskell Algebraic Data Types. In the design goal there they both are identical. Swift's enums are a more faithful translation than Scala's case classes (since case classes are more ambitiously/granularly typed, and this leads to some weakness [0]). Right now they're a little broken, though, since recursive enums lead to compiler bugs (here's are a few of my attempts to fight this: [1], [2]). [0] http://stackoverflow.com/questions/25330359/what-are-the-problems-with-an-adt-encoding-that-associates-types-with-data-const http://stackoverflow.com/questions/25330359/what-are-the-pro... [1] http://tel.github.io/2014/07/30/immutable_enumeration_in_swift/ http://tel.github.io/2014/07/30/immutable_enumeration_in_swi... [2] http://tel.github.io/2014/07/27/calkin-wilf-in-swift/ http://tel.github.io/2014/07/27/calkin-wilf-in-swift/
- virtualwhys 12y ago
  Not sure what weakness you're referring to in that SO post; the OP is actually saying otherwise: > I have always considered the Scala variation to be on the advantageous side [relative to Haskell]. Daniel Spiewak does provide an answer that points out a weakness with scala collections when used with ADTs, but (G)ADTs of and in themselves are pretty damn elegant in Scala, arguably rivaling Haskell equivalent (provided we set aside Scala's slightly more verbose implementation).
  - tel 12y ago
    Daniel's answer is not specific to Scala's collections library but instead any generic type unless it's set to be invariant. That ultimately leads to a tradeoff between soundness and convenience (as mentioned in comment toward Scalaz's Monad impl). Ultimately, both of his points come from the idea that you genuinely want a mechanism for deferring information to runtime and case classes almost give that to you if it weren't for their default to greater typing granularity and covering it up with subtyping relations. The point I made in the comments is that this throws away syntax directness almost everywhere and that tosses out a lot of inference. Ultimately, Haskell's GADTs give you the same power as Scala's case classes, but they require you to actually ask for that level of type specificity and then provide an explicit and delimited family so that inference doesn't get as mucked up. So, I think Scala is certainly workable... but in general disallows precision of desired expression, ironically, by defaulting to greater precision of actual "type". (There's finally a totally pedantic argument to be had that "Inl and Inr aren't types" in some foundational sense. Of course you can consider them types and model a perfectly reasonable type system off of that consideration. That said, they're something a little different from your standard MLTT/BiCCC/TypeTheory/Logic types, fwtw)

by rtpg 12y ago

benvan 12y ago

I agree - the examples given are almost infuriating. Whilst I can't comment on how idiomatic the Swift code is, the Scala code is anything but. There's little benefit to using a language like Scala if you're going to count the number of apples and oranges in a list by incrementing a mutable var for each type.

efnx 12y ago
My problem with both languages is that you can count apples like that. If it can be done, it will be done.

densh 12y ago

Author of those slides here. They were made on the next day after the language was presented on WWDC and were based purely on the first draft of the Swift book published online by Apple. Needless to say the book was more of a tutorial than a full-blown spec at that time and many important aspects were not covered (generics were lightly documented without much details). Can you please provide details about generics in Swift and how exactly are they different from Scala's? Edit: changed 'superior' to 'different'.

eklavya 12y ago
Don't bother, people will just say X is better than Scala here. They don't know the amount of research done by Odersky on generics and why Scala can not be easily beaten in this area at least.
- eropple 12y ago
  Scala can't be easily beaten there? Man...have you used C#? I mean, I use Scala every day, but C# gives you so much solely on reification and Scala manifests are a real poor patch.
  - eklavya 12y ago
    Holy shit you have got to be joking. Really trolling now, are we? Take a look at things like Shapeless (https://github.com/milessabin/shapeless https://github.com/milessabin/shapeless).
    - eropple 12y ago
      I've used Shapeless. It doesn't affect my actually writing code on a daily basis. Reified generics do.
      - eklavya 12y ago
        How exactly?
yohanatan 12y ago
I think you meant 'inferior'.
chrisoverzero 12y ago
I think that poster is saying that Swift's generics are not as good as C++'s, and even more not as good as Scala's. "Miles away" is ambiguous, but I think it's "miles behind" in this context, given its proximity to "even" and "let alone."

tel 12y ago

Swift enums and Scala case classes both attempt to emulate ML/Haskell Algebraic Data Types. In the design goal there they both are identical. Swift's enums are a more faithful translation than Scala's case classes (since case classes are more ambitiously/granularly typed, and this leads to some weakness [0]). Right now they're a little broken, though, since recursive enums lead to compiler bugs (here's are a few of my attempts to fight this: [1], [2]). [0] http://stackoverflow.com/questions/25330359/what-are-the-problems-with-an-adt-encoding-that-associates-types-with-data-const http://stackoverflow.com/questions/25330359/what-are-the-pro... [1] http://tel.github.io/2014/07/30/immutable_enumeration_in_swift/ http://tel.github.io/2014/07/30/immutable_enumeration_in_swi... [2] http://tel.github.io/2014/07/27/calkin-wilf-in-swift/ http://tel.github.io/2014/07/27/calkin-wilf-in-swift/

virtualwhys 12y ago
Not sure what weakness you're referring to in that SO post; the OP is actually saying otherwise: > I have always considered the Scala variation to be on the advantageous side [relative to Haskell]. Daniel Spiewak does provide an answer that points out a weakness with scala collections when used with ADTs, but (G)ADTs of and in themselves are pretty damn elegant in Scala, arguably rivaling Haskell equivalent (provided we set aside Scala's slightly more verbose implementation).
- tel 12y ago
  Daniel's answer is not specific to Scala's collections library but instead any generic type unless it's set to be invariant. That ultimately leads to a tradeoff between soundness and convenience (as mentioned in comment toward Scalaz's Monad impl). Ultimately, both of his points come from the idea that you genuinely want a mechanism for deferring information to runtime and case classes almost give that to you if it weren't for their default to greater typing granularity and covering it up with subtyping relations. The point I made in the comments is that this throws away syntax directness almost everywhere and that tosses out a lot of inference. Ultimately, Haskell's GADTs give you the same power as Scala's case classes, but they require you to actually ask for that level of type specificity and then provide an explicit and delimited family so that inference doesn't get as mucked up. So, I think Scala is certainly workable... but in general disallows precision of desired expression, ironically, by defaulting to greater precision of actual "type". (There's finally a totally pedantic argument to be had that "Inl and Inr aren't types" in some foundational sense. Of course you can consider them types and model a perfectly reasonable type system off of that consideration. That said, they're something a little different from your standard MLTT/BiCCC/TypeTheory/Logic types, fwtw)