happy_dino

Can you explain/give a link?

  > It seems we have different definitions of what type 
  > inference, higher order functions and Turing 
  > completeness means. :-)

I don't think so. The definitions are pretty much standard and those are the ones I'm using.

I think we can agree that the way Java supports those features ranges between unusable and pretty terrible in practice, but that's not what your claims were about.

Your notion of Scala having more features than a "standard" mainstream language might even be correct, it is just that the points you have given don't support your point here.

  > Regarding coroutines in Java: I don't know if libraries
  > using native continuation mechanisms or bytecode
  > manipulations prove that Java (the language) has
  > continuation support. :-)

Then Scala doesn't have continuation support either. Whatever definition is applied, it needs to be applied consistently.

  > I don't have anything against Scala.

I never suggested that and even if you had something against Scala, it would be perfectly fine – for me and probably for everyone else.

It's just that you have claimed a few things which I think are incorrect, either factually or in the way they were worded, and I'm offering some data points against it. This all happens in good faith and in the hope that we both will have gained some knowledge at the end of this discussion.

  > As you noticed with Java 8 Java is already borrowing a lot
  > of useful things from Scala. I am sure conservative
  > corporate decision makers will see less and less reasons
  > to switch to Scala as time passes by.

I think most Scala users would agree that Java 8 copying Scala is a good thing, because it strongly validates what the designers and users of Scala have been doing for the last 10 years. With Java moving closer to Scala, adopting Scala becomes a lot easier from a management POV which in turn removes a lot of the concerns corporate decision makers have.

  > If I have a function: def upcase(s: String): String [...]
  > A unit test can check if the returned string is really
  > the upcase version of the input parameter.

  def upcase(s: String): UppercasedString

Now the compiler can check it, too.

Go's GC is non-moving, exactly because they can't precisely know what a pointer is and what is just some random int.

So it's basically as if all objects are pinned in Go. I don't expect that to change. There are probably tons of Go code out there which will break in response to a change.

I guess it will be pushed back to some mystical "2.0" release, along with Generics.

They could, but I expect their "worse is better" attitude will prevent it.

Looks like you just managed to disprove my earlier claim:

  > Before I learned about Clojure, I certainly wouldn't have 
  > believed it if someone told me that there was a Lisp-like 
  > language without the pretentious assholes.

Too bad.

  > Java has no type inference, higher order functions,
  > coroutines, implicits (it has some standard implicit
  > conversions but not implicit conversions that can be
  > added by the user) and no Turing complete type system.

Type inference in Java:

  int bar = new Object(){ int foo = 42; }.foo;
  // Magic? No. Type inference.

Higher order functions in Java:

  http://download.java.net/jdk8/docs/api/java/util/stream/Stream.html
  Looks pretty higher-order to me.
  Also possible in older version in Java with stuff like Google Guava or FJ.

Coroutines in Java:

  http://stackoverflow.com/questions/2846428/available-coroutine-libraries-in-java

Implicits:

  Having them built into the language is even worse.
  In Scala you could just de-import them and have them gone.
  Anyway, pick C# as an example instead if you want to have
  user-defined implicit conversions.

No Turing complete type system:

  interface Interface<T> {}
  class Bang<T> implements Interface<Interface<? super Bang<Bang<T>>>> {
      static void bang() {
          Interface<? super Bang<Byte>> bang = new Bang<Byte>();
      }
  }

  Looks pretty undecidable to me. In a way, it is even
  worse than other languages: You are unable to tell
  whether the type checker will terminate in finite time
  (like some other languages), but don't get any additional
  expressivness in return (unlike those other languages).


  > As a side effect this will also find all type errors
  > a compiler will find.

No, absolutely not.

  > I have programmed a lot in Java and also in dynamic
  > programming languages and in my opinion type errors
  > just don't happen often enough to justify the
  > additional amount of work and complexity that comes
  > with static type systems.

This comment certainly explains a lot. You are suffering from the "I used Java and Java is statically typed and it sucks, therefore all statically typed languages have to suck" fallacy.

I guess it depends on where one comes from. If one compares Scala to Scheme, sure, Scheme is ridiculously simple compared to Scala.

But if one compares Scala to languages which are actually used in the wild like Java, C#, PHP or C++; Scala's footprint is just incredibly small.

All of the features you mentioned are available in languages like Java or C#, too. The difference is that in most cases the implementation is so poor and incoherent, that the feature is next to useless.

I guess one just "sees" more language features being used in Scala, because almost everything which ships in the language makes some sense, while in Java/C#/PHP/C++ you have tons of utterly useless "features" which don't add any benefit, but still force people to learn them in case somebody else used them.

I have never seen "On a sufficiently big project with one or more extra clever developers most probably every feature will be used" happen in real life. In my experience one of the strengths of Scala is the way one can use some advanced feature where it makes sense, without having it bleed through the whole code. Compare that with Java's, C#'s "Oh, you used some complicated Generic type over there? Guess what, we will make every user suffer from it throughout your whole code base!"

In a sense, I prefer a language (Scala) which ships with 100 features where 90 of them make sense to a language which ships with 400 features where only 50 make sense, like C# (multiply "feature" count by 10 for C++).

  > And I don't need a compiler to catch errors that a unit test would also catch.

Well, using the compiler means that it will also catch errors which you haven't written unit tests for. Tests can't prove the absence of certain categories of errors, compilers can.

  > but it will win in the next 15 years in a major way, 
  > because it is already one of the most interesting

the most interesting ... what?

Anyway, I think they have already won in a major way: The managed to build a community which is supportive and friendly. This is a huge deal when you have a look at the poisonous behaviours of individuals and the wide-spread arrogance typical in most Lisp communities.

Before I learned about Clojure, I certainly wouldn't have believed it if someone told me that there was a Lisp-like language without the pretentious assholes.

  > An enterprise Scala project, for example, is typically 
  > going to present the frustrations that come with 
  > components that live outside the language. Learning Scala 
  > isn’t that bad, but Maven and Spring and Hibernate? Ouch. 
  > In Clojure, most of the typically “external” needs are 
  > provided with idiomatic libraries that can be reasoned 
  > about within the language.

That doesn't make much sense. One can do exactly the same in Scala. The big improvement on Clojure is that it is completely pain-free and seamless to keep the old components around and migrate gradually to better solutions (or just keep the legacy parts which work – why bother changing it?).

  > while every static language worth its salt has an 
  > interactive mode (“REPL”) it doesn’t have the same
  > first-class-citizen feel

Maybe this has changed, but the last time I used Clojure's REPL, it was completely unusable, with basic things like auto-completion, history and navigation being completely non-functional.

I think the opinion voiced in the article is interesting, but past experience tells us that the chances of a Lisp to get even slightly popular is low to non-existing.

While I can't speak of traction in enterprises in Germany, I wonder what the notion of "Scala with its everything and the kitchen sink feature set" is about.

This seems to be a popular meme, right until someone asks for details – crickets chirp.

> But match exceptions do.

I'd call that non-sense.

You can use any templating system you want, including the one which was used in Play 1.

As a general policy, if I spend time explaining things I require people to do some homework on their own.

This way people who are lazy, whose interest is just strong enough to make ridiculous claims and complaints but don't actually care about the topic at hand, don't get things for free.

I protect my investment and everyone wins.

Can you give some details what caused the issues in your the 2.9 -> 2.10 migration?