3 things I don't like about Scala:
1. It's based on the Java platform.
2. It's excessive use of operator overloading.
3. Mad implicit conversions all over the place.
(yes, I exaggrated a bit ;))
1. It's based on the Java platform.
2. It's excessive use of operator overloading.
3. Mad implicit conversions all over the place.
(yes, I exaggrated a bit ;))
2. Have you seen languages like APL or J? Now that's operator overloading. '+' is just a symbol, meaning a lot of different things even in mathematics. All meaning is a product of convention.
3. In modern Scala, implicit _conversions_ are discouraged unless you know what are you doing. Besides, Scala IDEs are excellent in showing applied implicits anywhere in the code (you do use an IDE, right?)
As always: cost/benefit! There is a price for the "context switch" out of one set of conventions into another. Sometimes, the benefit far outweighs the cost. For example, there are certain environments where you can jump out of the programming language and simply write a method in SQL. Not embed SQL in code in a string, you can simply write prepared statements as a method. For certain applications, this can be beneficial.
The problem I have with operator overloading, is that it allows the average programmer to switch conventions using some of the the most commonly used conventions with barely a sign that something special is going on. It's too easy to use. It's too easy to miss. It's too easy to get a moment of confusion from it when debugging. (What, I'm in a method? Oh, operator overloading!) And it doesn't produce a great benefit all that often. Yet it has a "nifty" factor that encourages in experienced programmers to make use of it -- precisely the people who probably shouldn't be making that decision.
1. Java platform is overengineered, everytime I had to set up stuff like Maven, I missed the easy JS days.
2. True story, I can infer what a '+' between two strings means, but what about all the non-intuitive operators? (List concats etc. pp.)
3. Not a big fan of IDEs. More of an editor dev, but good to know ICs are now discuraged. I got myself "Programming in Scala" back in the days and it seemed to me, that the Scala makers thought of IC as Scalas killer feature :D
It would be nice to be able to run an integrated debugger (as opposed to a port connection from an SBT spawned JVM), integrate directly with SBT (as opposed to having to run it side by side), provide a full featured REPL (not the neutered version with no completion and poor editor integration), as well as functional import organization, dead code identification, refactoring suggestions, real linting, real code formatting, working extract refactorings, etc..
Overloading at least some could be useful. Java 10+ will probably allow something like this, too. You ever worked with BigDecimal?
In Python, Scala where + (__add__) is overloadable you do.
BigDecimal(1) + BigDecimal(2) + BigDecimal(3)
(new BigDecimal(1).append(new BigDecimal(2)).append(new BigDecimal(3)
Enumeratee.take(4) &>> Iteratee.fold[Byte, Int](0){
case (acc, b) => acc * 256 + (b & 0xFF)
}
>>= "fffff...Pwip!" (the sound of monadic bind)
|==> "TCHvvvvvv..." (lightsaber igniting)
|@| "AAAAAAHHHH!" (Edvard Munch 1893 operator)p.s. I banned scalaz and shapeless on my company so there aren't too much operator noises.
Just wondering, do you have your own libraries that use some of the good stuff? I can't imagine living in a world where I'm banned from using...
* Traverse (do you write specialized versions for the cross product of [List, Vector, etc] x [Option, Either, etc] ?)
* Validation (how do you collect errors? mutable.Buffer?)
* NonEmptyList (I've written my own NonEmptyVector that wasn't that hard to write. Do you do that or just assume nonempty and it works out for you?)
* Unapply (maybe this doesn't apply to you because you never use HKT-generic typeclasses?)
I'm genuinely curious as all of these tools get used by me and my coworkers literally every day and without them we'd be writing boilerplate or making unchecked assumptions by the seat of our pants.
* Validation? Actually we are on HTTP so mostly a sealed trait structure is enough for us we barly use `Seq(ValidationError)` from Playframework (only class constructs that manually)
* NonEmptyList - I never came across a palce where I needed NonEmptyList?!
* never needed.
Just keep in mind other languages don't have such abstractions as well (maybe haskell has, but I don't know haskell). Some people need these high level abstractions and it's fine if you use it but most things are just syntactic sugar.
The only stupid thing is something like that:
- Future[Option[A1]] - Future[Option[A2]] ... - Future[Option[AN]]
and now I need a `case Some((a1, a2)) =>` without some magic you write a lot of boilerplate.
So a Monad is really something that would be great and probably we will evaluate if we get to use cats.
Edit: Code Snippet:
val h = (for {
ph <- OptionT(dbService.byId(id))
article <- OptionT(articleDao.by0A(ph.article))
} yield (ph, article)).map{ case (ph, article) =>
(ph.id, article.id)
}
h.value
Do you ever check the length of a list before applying a computation or dispatch based on a result list?
I guess we have something like 30 occurences of .isEmpty/.nonEmpty in one of our codebases
I came back to the JVM many times in the past and every time it was the same. It always seemed like things changed, but the baseline complexity stayed the same.