I see you're attempting to disregard my results by making assumptions about my workflow. I'm not going to respond to these comments.
> I just did a test for a project of mine and it took 5 seconds. Without line-counts such metrics are useless (how small is that module anyway?).
Obviously, comparing absolute times between two unknown systems isn't going to make sense. I was comparing how long it takes to accomplish the same thing on my machine in Haskell and Scala.
> In practice it's good to annotate the signature of public functions. Haskell developers do that too, because really, when a developer looks at the definition of "optBar" are you seriously going to suggest that they should be looking at other parts of the code to infer what it returns?
I agree, annotating type signatures of top-level functions is a good practice. However, in the above example `optBar` is an internal variable in class `Foo`. The point here is I found Scala's type inference to be incapable of dealing even with trivial code.
> The difference is that Scala gives you the means to document these implicits in the signature (referential transparency FTW). They are also statically type-safe, can be overridden and have the extra benefit that they make possible some powerful techniques, like type-classes, something that Ocaml isn't capable of.
Haskell does type classes without the need for implicits. Also, true referential transparency requires control over side effects, which is something neither OCaml or Scala are capable of, but Haskell is.
> Haskell does type classes without the need for implicits
If you really think about it, type-classes are all about passing around a global vtable implicitly. If anything, Scala's implicits are a superset of Haskell's type-classes and allows for techniques that Haskell isn't capable of.
We could debate all day about what's better. If you're going to make the case that Haskell's type-classes are easier to reason about, then I can make the case that a dynamic language beats Haskell on reasoning about it any day of the week. In the end it's all about tradeoffs.
> true referential transparency requires control over side effects, which is something neither OCaml or Scala are capable of, but Haskell is
With all due respect, that's just bullshit. First of all because there is no such thing as "true referential transparency", second because most techniques that are available in Haskell for dealing with side-effects are also available in Scala. As examples, Scala's library is filled with monadic types and the Play framework makes use of Iteratees for composing HTTP responses, something which makes Comet/WebSocket a peach to deal with.
> With all due respect, that's just bullshit. First of all because there is no such thing as "true referential transparency", second because most techniques that are available in Haskell for dealing with side-effects are also available in Scala.
A referentially transparent expression is guaranteed not to have side effects. A Haskell function which doesn't advertise in its type that it may have side effects, by being in the IO monad, can be trusted to be referentially transparent. This cannot be said about OCaml or Scala functions.
Pardon me...are you saying you want something in the type signature of a scala function that guarantees said function will not do input output to files sockets etc...and does not make a call to random number generators and does not modify global vars...so basically all it does is operate solely on params passed to it...absolutely no side effects...is that what you are asking for? That would be awesome from a testability standpoint...
Yeah I know exactly what you mean in Haskell. Its just that in scala given the java inter-op there are a whole hunch of escape hatches that will always be there. I remember in the coursera exercises when you submitted code that used mutable vars...it would flag your code and deduct points. So essentially even if someone provided a purefn annotation...to actually enforce that, the compiler would have to scan each function and disbar i/o, calls to rng, calls to global vars... tall order.
> If you really think about it, type-classes are all about passing around a global vtable implicitly. If anything, Scala's implicits are a superset of Haskell's type-classes and allows for techniques that Haskell isn't capable of.
First, I'm not a Haskell expert, but from what I understand there are no vtable passed around nor attached to "objects" in Haskell.
Type-classes are used to find an implementation given an instance. Without extensions you cannot do this:
> I just did a test for a project of mine and it took 5 seconds. Without line-counts such metrics are useless (how small is that module anyway?).
Obviously, comparing absolute times between two unknown systems isn't going to make sense. I was comparing how long it takes to accomplish the same thing on my machine in Haskell and Scala.
> In practice it's good to annotate the signature of public functions. Haskell developers do that too, because really, when a developer looks at the definition of "optBar" are you seriously going to suggest that they should be looking at other parts of the code to infer what it returns?
I agree, annotating type signatures of top-level functions is a good practice. However, in the above example `optBar` is an internal variable in class `Foo`. The point here is I found Scala's type inference to be incapable of dealing even with trivial code.
> The difference is that Scala gives you the means to document these implicits in the signature (referential transparency FTW). They are also statically type-safe, can be overridden and have the extra benefit that they make possible some powerful techniques, like type-classes, something that Ocaml isn't capable of.
Haskell does type classes without the need for implicits. Also, true referential transparency requires control over side effects, which is something neither OCaml or Scala are capable of, but Haskell is.