1. 45

  2. 6

    while Swift looks not at all unlike the hypothetical trimmed-down and edited Scala we’ve been promised. Both languages were met with curiosity and enthusiasm when announced.

    Honestly, I kind of feel like it’s the opposite. Scala merges OO and FP more completely than Swift does, by far. I can’t help but feel that will translate to much greater complexity over time.

    1. 5

      I think that swift has in some ways traded a nice abstraction for simplicity. I think at scala’s level of complexity, this might be the right tradeoff. As @al3x pointed out, scala suffers from the C++ problem, where it’s so difficult to learn the entire language that people end up fencing off barriers around features with sharp edges because it’s too much of a hassle to understand the precise concurrency semantics of even simple seeming things like lazy vals. I work on a team where nearly everyone has at least two years of scala experience, and we use pretty much every feature available in scala, but in my experience, this is not terribly common.

      Worse, the C++ problem makes building tooling for scala very difficult. Even today, I still find weird edge cases in the emacs scala-mode2 formatting, and because scala has something like 23 compiler steps, finding the precise AST to hack if you want to apply a refactoring is quite tricky. Although scala fmt (sung to the tune of go fmt) should be as simple as pretty-printing the AST, the question quickly becomes, “Which AST?” The only fully-featured AST in the compiler unwraps for comprehensions to flatMap chains ended by a map, so we’d have to hack the AST-builder to construct an intermediate AST with for comprehension / destructuring sugar clarifying nodes if we wanted to pretty-print it.

      I think it will happen, but it’s not like in go, where a clean compiler and a small language make it simple (seemingly) to write all kinds of nice tooling.

      On the other hand, I sometimes look at swift, and think, “This would have been easy if they had actually slurped a little more of scala.” So I think I am happy to be working in scala and not swift today, but perhaps the learning curve for swift would have been kinder.

      1. 4

        Honestly I’m also not convinced that gluing OO, in the sense that this term is used in industry today, onto FP will ever produce a language with a simple clean core calculus. The track that Swift seems to be going on seems to end up just producing another Scala for good or for ill. I think there is some interesting work exploring this design space, but the prerequisite is going back and revising what objects mean in terms of Cardelli’s work and ML module systems. Though I speculate the resulting framework would probably look very little like the OO programming that a lot of folks do today.

        1. 6

          I am extremely interested in the program you describe at the end there. I do think that OO contains a lot of great ideas (ideas from “the other side of the expression problem”) but I don’t think “present day OO” expresses them nicely.

          Some day I’m going to explore Dotty and see what Odersky’s team has been up to there. I would love to see a tighter integration achieved through something like that.

          But in general, I completely agree. I don’t think Swift is “doomed” in any sense. It is a modern looking language which lets you compile against iOS/OS X APIs so there will be a huge user base. I hope that the investment there will allow a great deal of smoothing out of the sharp edges between FP and OO, though I fear they will instead become indoctrinated.

          The interesting thing will be to see how having both mechanisms at your fingertips in “real world” situations will allow for greater comparison between the two. It’s my hope that the FP side eventually gets buffed enough to shine (last I checked it’s full of compiler errors and usually requires “going via” the OO side and covering your eyes pretending there isn’t a mutable slot in there. I’m excited to see people begin to translate iOS and OS X idioms toward FP. Maybe it’ll bring a big bolus of users to FRP-enabled UX implementation. That would be wonderful.

          1. 1

            Many people are searching for the ultimate language that is as typed and expressive as FP while not having to sit down and study the computer science theory behind it. Forming solid ideas and then translating that structure into code can never be magically easy unless the problem you are forced to solve becomes magically easy. I find it really easy to write tons of objects and code in java with taxonomies and factories. Does this mean i’ve done a better job of solving the problem? No, but it sure feels more productive and “easy”. These taxonomies and factories seem rather orthogonal to the problem at hand most times. I don’t see how OO into FP will magically solve the fundamental problem of translating ideas and structure into working / maintainable code. I’m squarely on the “drop OO and focus on improving expressiveness of FP” side.

            1. 1

              I don’t think “taxonomies and factories” is the idea of OO that I care about. It’s much closer to how nice it is to compose modules in SML. When I say “OO” I tend to mean “final encoding focused, open recursion, composition of interface, genuine type/state abstraction/encapsulation”. Those are really great ideas and they’re not trivially introduced to FP.