proj-plbook-plChFuncLangs

Table of Contents for Programming Languages: a survey

Haskell

Because it is so well-liked, Haskell gets its own chapter.

See chapter on chapter on Haskell

Scala

Scala is a multiparadigm language, both OOP and functional.

Tours and tutorials:

• http://docs.scala-lang.org/tutorials/tour/tour-of-scala.html
• https://twitter.github.io/scala_school/
• https://www.handsonscala.com (free chapters form a tutorial)
• http://lampwww.epfl.ch/teaching/archive/type_systems/2010/docs/week13.pdf
• https://www.scalawithcats.com/dist/scala-with-cats.html
• https://gist.github.com/jdegoes/97459c0045f373f4eaf126998d8f65dc#applied-functional-programming-with-scala---notes

Cons:

• big language
• slow compilation
• culture of punctuation-based DSLs can make readability hard

Best practices:

• http://docs.scala-lang.org/style/
• http://twitter.github.io/effectivescala/

Tutorials and books:

• http://learnxinyminutes.com/docs/scala/
• https://github.com/twitter/scala_school

Comparisons:

• https://agilewombat.com/2016/02/01/scala-vs-kotlin/
• https://leverich.github.io/swiftislikescala/

Features:

• higher-kinded types
• implicits
• " Scala is completely interoperable with Java (and with some qualifications also to C#). A Scala component can: • access all methods and fields of a Java component, • create instances of Java classes, • inherit from Java classes and implement Java interfaces, • be itself instantiated and called from a Java component. " -- [1]
• "Scala’s concepts subsume SML modules. More precisely, (generative) SML modules can be encoded inνObj,but notvice versa." -- [2]
• Abstract Types " Here is a type of “cells” using object-oriented abstraction. trait AbsCell? { type T val init: T private var value: T = init def get: T = value def set(x: T): Unit = { value = x } }

The AbsCell? class has an abstract type member T and an abstract value member init. Instances of that class can be created by implementing these abstract members with concrete definitions.

val cell = new AbsCell? { type T = Int; val init = 1 } cell.set(cell.get * 2)

The type of cell is AbsCell? { type T = Int }.

Path-dependent Types: You can also use AbsCell? without knowing the specific cell type:

def reset(c: AbsCell?): Unit = c.set(c.init);

Why does this work?

• c.init has type c.T
• The method c.set has type c.T => Unit.
• So the formal parameter type and the argument type coincide.
• c.T is an instance of a path-dependent type.

In general, such a type has the form x0...xn.t, where

• x0 is an immutable value
• x1, ..., xn are immutable fields, and
• t is a type member of xn " -- [3]

Some notes on Scala 3 features:

• https://scalacenter.github.io/scala-3-migration-guide/docs/incompatibilities/dropped-features.html
• https://blog.knoldus.com/a-beginner-guide-to-scala-3-0/
• https://dotty.epfl.ch/
• https://dotty.epfl.ch/docs/
• https://dotty.epfl.ch/docs/reference/overview.html
• https://dotty.epfl.ch/docs/reference/features-classification.html
• https://dotty.epfl.ch/docs/reference/contextual/motivation.html (talks about implicits, and what they are being replaced by)
• https://lichess.org/@/thibault/blog/lichess--scala-3/y1sbYzJX

example of scala 3 'givens' which are (part of) the successor to scala implicits:

https://alvinalexander.com/source-code/scala-3-dotty-complete-givens-using-example/

so afaict these are just similar to Haskell typeclass instances. I guess what scala is really contributing is that i think these are lexically scoped, rather than globals like (i think) in Haskell.

Extensions:

• Kepler macro system
• Compiles to Javascript (scala.js) (and this apparently works well [4])

Retrospectives:

• http://stackoverflow.com/questions/2682673/what-compromises-scala-made-to-run-on-jvm

Implementations:

• the canonical one
• http://scala-lang.org/news/2015/02/05/scala-js-no-longer-experimental.html
• https://www.scala-lang.org/blog/2017/03/14/scala-native-0.1-is-here.html (uses LLVM)
• scala 3 (dotty)

Opinions:

• "Scala is the single best language I've ever used. And I don't even use all of it. I just use the subset of Scala that is Everything Java Should Have Been. It has lambdas and closures. It has just enough type inference. It has mutability control for slots. It has object orientation and case-classes/pattern-matching and type-classes via implicit parameters. Scala lets me figure out what language paradigm I need to Get Stuff Done. It's the Python of statically-typed languages, and it interoperates with a vast outside ecosystem to boot." -- [5]
• "I do want a functional language like Scala, because I believe that school represents a better design. That school of language design saves me the headache of null pointers; it helps me write unit tests with QuickCheck?; it allows me to define custom generic collections; it places emphasis on having a fast GC; it features monadic style to help with error handling." -- [6]
• [7]
• "...problem with all of these languages is that they are still obscure compared to everything else, with all that this entails: It's harder to find developers...Scala has some good parts, but is overdesigned and way too complex, in my opinion. Last I checked, performance was worse Java. It also runs on the JVM, which means its memory usage is inherently inefficient." -- [8]
• "Scala has always seemed like an abomination to me, but I haven't used it enough." -- [9]
• http://grundlefleck.github.io/2013/06/23/using-scala-will-make-you-less-productive.html
• "Scala's the only one of these three languages with any adoption right now. Groovy is virtually only used in its original dynamic mode from 2003 for things like scripting and Gradle build files, and very few people use the @CompileStatic? mode introduced in 2012. Kotlin 1.0 has just been released, was subjected to stringent QA, and I expect JetBrains? to use it more and more in its own products like IntelliJ?, so it's a good bet it will become more popular with developers. So I'd say use Scala and Kotlin if you need static typing. Clojure, though it doesn't have static typing, has other features like syntactic macros for terseness, default immutability, and concurrency that would recommend it in many situations." [10]
• https://news.ycombinator.com/item?id=11678751 : "
• "While the fusion OOP + FP fusion is interesting I have grown wary of kitchen sink languages. There are so many ways people write Scala. " [11]
• Lends itself to DSLs (some people think this is good, others thing it is bad [12])
• "I remember when I first saw the potential issues of scaling Scala at Gravity back in 2009/10ish. It was close to the end of the day when we had a major issue reported in production that was affecting our large customers. Several of us started investigating and were able to track the source of the issue. The only problem was we had no idea what the code was doing at first. We came across a strange symbol we hadn’t seen in our projects before. The spaceship operator <

• slow build times
• "Scala has had big issues with the size of it's library that still haven't been resolved" [14]
• "I worked on a commercial project that used Scala. Never again. Compiles were slow, IDE support was terrible, everyone had their own subset they used. I'm sure it's improved since 2010. " [15]
• "The language and even the basic libraries are incredibly complex. Here's an example, a signature for List.map: final def map[B, That](f: (A) ⇒ B)(implicit bf: CanBuildFrom?[List[A], B, That]): That" [16] (other comments in that subthread explain what that signature means)
• vs Kotlin: https://elizarov.medium.com/why-im-not-enthusiastic-about-java-10-b2d789b6d42a
• Because all the other languages mentioned are better only from very specific perspectives. Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too.

Scala gets a bad rap precisely because people are big fans of their own way of writing code, call it better, and think that anyone that wants something else is deluded. The Scala way is to say 'sure, you can do that too, to hell with purity'. I'd rather have power over purity any day.

reply

duaneb 36 minutes ago

> Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too.

This also essentially describes C++. This is also why both languages can be so terrible to use: every library has its own dialect.

reply

the_af 20 hours ago

Note: I use Scala in my day job. I consider it better than Java, but worse than other languages. I definitely agree that all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable.

That said, in my opinion Scala's blunders are many. You can find out about many of them from Paul Philips, ex committer of Scala, but if he sounds too bitter to you (he does to me; at this point he sounds like there is bad blood between him and Odersky), here are some of mine:

• Null. Null will come back to bite you in Scala code, whenever you call Java libraries, and the occasional Scala library that didn't get the memo. Sure, you can wrap every suspect value with Option(...), but why should you do this?
• Type inference is not as powerful as in a language with a cleaner type system such as Haskell. I'm told this is because Scala tries to be both OOP (inheritance) and FP at the same time. Here is a clear case of Scala's attempt at being a "jack of all trades" resulting in it being inferior than the sum of its parts.
• Type signatures in Scala collections and core types are extremely hard to read. You do not need to read them, but if you try, you are in for a world of hurt. This in itself is not a mortal sin, but of course if you're willing to forgive Scala this much complexity, surely you're willing to forgive other languages as well?
• Tooling is bad. It's getting better, but it's still bad. SBT is painful to use. As for IDEs, IntelliJ? is now the recommended choice; I've tried both Scala IDE and IntelliJ?