
Scala, Part II - michael_fine
http://evrl.com/programming/scala/2017/04/04/scala-part-ii.html
======
serpix
Hot Reload in the year 2019 is still a hard problem,although DCEVM seems to be
solving it for now.

All the problems the author talks about were there in 2007 and are still there
today. I bailed after the countless breaking updates to Scala and SBT. the
level of productivity with a Lisp and REPL driven development is unmatched.

I just popped open an old Scala/Java source for doing a little maintenance
after using Clojure for the last few years. There are entire files that could
be replaced with a single function. Dozens of classes are complete unnecessary
complexity only due to the type system forcing type wizardry. The SBT file I
took one look and closed it immediately.

Clojure + Spec / Plumatic Schema and REPL driven development backed by tests
is so good I have trouble imagining how it could get better.

------
room271
I have six years programming in Scala and I unfortunately agree with
everything in this article. Our work experience is very similar; competing
approaches/styles, poor tooling, and slow feedback cycles. The language itself
is nice is many ways, but it turns out that these things are more important.

We've started using Typescript a lot for http-templating style use cases
(instead of Play) and I'd lean towards Go for the pure networky stuff.
Combined these give a much better experience than Scala for our types of use
cases.

~~~
paulddraper
I was a TypeScript skeptic -- sum types >>> union types -- but I was wrong.

TypeScript is simultaneously (1) incredibly practical, (2) allows for type-
level capabilities matching or exceeding Scala, (3) has excellent IDE support,
(4) is explicit, and (5) related to #3 can compile sans type checking.

I don't love Node.js for server-side, but from language perspective,
TypeScript really checks the boxes.

------
dagenix
> Sbt is probably the best example of what happens when you match academic
> thinking with actual code ...

> ... try to understand the library code that pulled in Scalaz and probably is
> written in the purely functional idiom of Scala that academics admire but
> mostly reminds me of Perl and other line-noise oriented programming
> languages.

> I really think that stuff like Scalaz has no place outside academia

It's hard to think of a type of criticism that is lazier than using "academic"
as a pejorative.

> I have found the run-time type error in [static languages] a fairly rare
> occurrence and not worth the trade-off of having to live with a retarded
> assistant in the form of a mandatory type-checking compiler

... and there it is

------
zmmmmm
> You want, at the very least, wrapper libraries to hide some of the nastier
> Java design patterns, so every time you add a Java dependency you will
> either have to find out its API and wrap the parts you need in some Scala
> code

Kind of describes why I have never succeeded in going beyond Groovy (despite
trying). Despite all the claims, all the JVM language's claims of interop
never pan out nicely in reality. Scala in particular is terrible because it
replaces all the collections with its own and then you need layers of
conversions between them which introduce overheads and idiosyncracies. On the
other hand Groovy explicitly tries to have as little impedance mismatch with
Java. It "automatically" enhances Java APIs with useful / functional methods
so every Java API magically gets better without you doing anythign. With
groovy you can _really have_ what most people wanted, which is a "nicer Java",
rather than a completely different language.

------
afpx
Even though I still enjoy Scala, the author’s perspective is valid. However,
some of his pain could be eased by using Gradle instead of sbt and IntelliJ as
an IDE.

The core frustrations that my team has are with the flexibility it provides
and the complexity it seems to encourage. But, those can be tempered by having
a team agree on a clearly-defined code style guide.

I feel like the original early adopters have moved on to other languages now.
So maybe now the language can be appropriated by people who are focused more
on productivity than novelty.

------
mcv
Yeah, parts of Scala have always struck me as the most beautiful language
ever, but if you dig a bit deeper, it turns into one of the most horrifying
languages ever. I think the future of the JVM looks more like Kotlin than like
Scale or Groovy.

~~~
rgoulter
There's a lot of stuff which is fine about Scala, but I still like this
presentation:
[https://nurkiewicz.github.io/talks/2014/scalar/#/](https://nurkiewicz.github.io/talks/2014/scalar/#/)

In particular, this slide is my favourite:
[https://nurkiewicz.github.io/talks/2014/scalar/#/22](https://nurkiewicz.github.io/talks/2014/scalar/#/22)

    
    
      // One of these doesn't compile
      seq foreach println
      seq.foreach{println}
      seq.foreach(println)
      seq.foreach{println(_)}
      seq.foreach(println(_))
      seq.foreach(x => println(x))
      seq.foreach(x: Int => println(x))
      seq foreach{x: Int => println(x)}
      seq.foreach{x: Int => println(x)}
      seq foreach{case x => println(x)}
      seq.foreach{case x => println(x)}
      seq foreach{case x: Int => println(x)}
      seq.foreach{case x: Int => println(x)}

~~~
mcv
Only one? If there's any justice in the world, it's the only one without any
brackets. I fear it's one of the many without a dot, though.

~~~
rgoulter
This all depends which syntactic conventions you're used to.

"a + b" is more readable than "a.+(b)", and so that's what scala allows. I
think it's a neat way of allowing operator overloading.

"iterable.foreach { ... }" is also readable for a callback.

FWIW, the one which doesn't compile is (apparently) "seq.foreach(x: Int =>
println(x))". [https://scastie.scala-
lang.org/krtG0VwgTmCNwIxATYFAbg](https://scastie.scala-
lang.org/krtG0VwgTmCNwIxATYFAbg)

