Revision 103 not available (showing current revision instead)

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:

Cons:

Best practices:

Tutorials and books:

Comparisons:

Features:

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?

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

Some notes on Scala 3 features:

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:

Retrospectives:

Implementations:

Opinions:

*> . Someone said out loud “what the hell is that?”. There was some other implicit magic going on that wasn’t immediately apparent. A CMD+B to traverse into the method yielded nothing in our IDE as it couldn’t find the symbol (IDE’s have improved here since). A quick googling of “<*>” yielded nothing as well....That blip turned a fix that should have taken minutes into a fix that took hours....(((another example of hard to read code))) https://gist.githubusercontent.com/jiminoc/ea827cfaf0bb8b07df6b/raw/e6402f48c2a97d537c7d80ea1284f9d3a380730d/sample.scala....." -- [13]

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:

reply

airless_bar 20 hours ago

> all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable.

Scala devs deprecate and remove things that haven't worked out well. They have an established track record of making these migrations easier with each release.

> Null

Upcoming versions will make references non-nullable by default. If you want things to be nullable, you will have to opt-in explicitly with T

Null.

> - Type inference

Type inference is not a huge priority, because people think that it's a good thing that declarations require type annotations (just like it's recommended in Haskell, too). One of the last pain-points, higher-kinded unification of type constructors, has been fixed recently which will make type inference "just work" in exactly those cases where the lack of type inference was most annoying.

> - Tooling

I think tooling is pretty amazing. Sure, Java has still some advantages in some places. But the tooling is superior to almost all other languages out there. SBT is amazing. IDE support is getting vastly better, not only have Eclipse and IntelliJ? improved vastly, but also IDE support for Emacs, Vim, Sublime, etc. is coming along at a rapid rate, and it's just amazing to use. There are so many tools in the Scala ecosystem which just don't exist in this combination anywhere else.

airless_bar 19 hours ago

Alright. Sorry.

Regarding your question about nulls and Java:

I think that there is not much Scala can do here. All existing evidence from other languages that tried this shows that there is a large semantic gap between "nullable values" and "values of unknown nullability".

As Scala is much more independent of Java it is a much smaller issue, but improvements with Java interop require action from Java library authors first.

The approach of supplying external nullability meta data has largely been a failure, because

a) authors are not aware of the stated, external constraints, so they could break these assumptions in future releases without even knowing

b) it's really really hard to retrofit nullability guarantees into libraries which have been designed without this requirement in mind

c) the existing ecosystem is not very amenable to these guarantees, as nullability metadata would be largely limited to final classes and members, because everything else could be subclasses or overridden in third-party code, breaking these assumptions

As soon as Java library authors themselves start using @Nullable/@NonNullable? annotations everywhere, there is a good opportunity of reading these annotations and typing the values accordingly, but without it, benefits are very slim.

The planned changes are valuable for dealing with nullable types, but as mentioned "unknown nullability" needs a different solution, and I think it's currently not worth adding something to the languages as long as there is still hope for widespread adoption of nullability annotations.

reply

bad_user 17 hours ago

Btw, if you ask a C++ developer to describe OOP, he'll say it's the ability of having structs with a VTable attached. Most people think OOP is about state. That's not true, OOP is about single (or multi) dispatch and subtyping (having a vtable), hence it's not at odds with FP, unless you want it to be ;-)

And let me give an example: in IntelliJ? IDEA I can click on any identifier in any third-party dependency and it automatically downloads and shows me the source code and I can set breakpoints and debug any third-party dependencies that way. Such a simple thing, yet it's a tough act to beat. Try it out in Visual Studio sometimes.

reply

asragab 16 hours ago

What languages would you say have definitely better tooling: I'd say for sure the .NET languages, C++, Java, and Javascript but I'd put Scala just at a level below that, no? The tooling stories for Go, Rust, Haskell I don't think are as strong (yet), but that's definitely going to change though.

reply

airless_bar 16 hours ago

Not parent, but I would reduce it down to

Why not the others you mentioned?

reply

pjmlp 11 hours ago

reply

"

Opinioned comparisons:

Scala examples

" To give a feel for the language, here’s a Scala implementation ofnatural numbers that does not resort to a primitive number type.

trait Nat { def isZero: Boolean; def pred: Nat; def succ: Nat = new Succ(this); def + (x: Nat): Nat = if (x.isZero) this else succ + x.pred; def - (x: Nat): Nat = if (x.isZero) this else pred - x.pred; }

class Succ(n: Nat) extends Nat { def isZero: Boolean = false; def pred: Nat = n }

object Zero extends Nat { def isZero: Boolean = true; def pred: Nat = throw new Error("Zero.pred"); } " -- [26]

(S)ML

Pros:

Tutorials and books:

Comparisons and opinions:

Wishes:

Implementations:

Links:

Variants:

Retrospectives:

Ocaml

Tours and tutorials:

Features:

Library recommendations:

Retrospectives:

Updates:

Opinions:

Ocaml Opinions: