Maybe, but it's just a generic statement about programming, it has no real value in a critique of Scala specifically. Part of the beauty of any flexible language is you can go back and refactor it down to a more elegant solution as you learn more. That doesn't mean you have to boil the code down to a point where it is largely impossible to read any more in Scala than any other language.
There are real pain points in Scala when you try and scale it from single developers to teams working on a project and most of them are to do with the flexibility of the language.
I think all companies working with Scala end up settling on a sub-set of the language that they are happy with. In that sense, the bad is irrelevant: you are never put in a situation where, say, you are forced into using implicits (apart from light use in external libraries like lift-json) so if you don't use them you never suffer their downsides. If you obsess over parts of a language you don't even have to use... then well I'm afraid I have nothing but scorn for people like that.
At team-scale then your main pain point is trying to get style of writing that everyone can get behind. Code reviews can be painful when developers with different ideas on how to solve a problem butt heads and pull requests turn into "That's not how I would have written it" instead of critiquing the actual code presented.
The tooling and compiling I completely agree with. SBT is a horrific mess. I don't have a single good word to say about it.
>
Maybe, but it's just a generic statement about programming, it has no real value in a critique of Scala specifically.
About Scala specifically? No, indeed. About languages which make it possible to create custom ASCII operators? Certainly. I don't know how the Scala culture about this is, but my experience with Haskell is that once people run with it, you get awful ASCII DSLs with cryptic operators all over the place.
> I think all companies working with Scala end up settling on a sub-set of the language that they are happy with.
So, pretty much like C++, a language that people love to hate. The problem is that, out in the wild, you're going to end up with legacy code made by people who picked a different sub-set.
There is an infamous library called dispatch. Someone put together http://www.flotsam.nl/dispatch-periodic-table.html to try and help other developers out when using it. I use it because it is good... but hell. The lack of discipline there is awful.
The problem is that, out in the wild, you're going to end up with legacy code made by people who picked a different sub-set.
This is the situation I've been in for the last year and I agree that for every point I make in praise of language flexibility this is the strongest counter-point.
Dispatch is a library that I initially found irritating, because in early versions it proved extremely opinionated in it's use of futures and symbolic operators.
However, as time has gone on, I've found that my coding style in Scala has evolved to the point where I want low-level libraries to work in an asynchronous way. There are now also overloaded, human-readable methods for most (if not all) of the symbolic operators.
> About Scala specifically? No, indeed. About languages which make it possible to create custom ASCII operators? Certainly.
IME, its possible to be just as unreadable with the more verbose custom alphanumeric operators (functions/procedures) that every structured/OO/functional programming language lets you create as with terse non-alphanumeric symbolic operators; all that eliminating the latter does is to limit how concise [1] it is possible for even a well-designed DSL to be.
[1] Note that concise isn't just terse, but also clear.
> I don't know how the Scala culture about this is, but my experience with Haskell is that once people run with it, you get awful ASCII DSLs with cryptic operators all over the place.
Yes, that happened in Scala too. Luckily another set of Haskell slingers wrote us Scalaz, so it's not all bad.
In its early stages Rust used to employ a lot of sigils (people joked that its a language which makes full use of all the keys on the keyboard), but the language has moved away with the cryptic operators and IMHO looks cleaner.
AFAIK, the sigils were used to express differences in data types (wrt to memory allocation scheme), which is quite different from ASCII operators. This doesn't bother me nearly as much, but it may be my Perl background.
You are right, they were mainly around pointers. As long as they are a handful and their meaning doesn't change (as opposed to using in a DSL), its easy to get used to them. Still, I find the explicit keywords a familiar territory and better to read.
There are real pain points in Scala when you try and scale it from single developers to teams working on a project and most of them are to do with the flexibility of the language.
I think all companies working with Scala end up settling on a sub-set of the language that they are happy with. In that sense, the bad is irrelevant: you are never put in a situation where, say, you are forced into using implicits (apart from light use in external libraries like lift-json) so if you don't use them you never suffer their downsides. If you obsess over parts of a language you don't even have to use... then well I'm afraid I have nothing but scorn for people like that.
At team-scale then your main pain point is trying to get style of writing that everyone can get behind. Code reviews can be painful when developers with different ideas on how to solve a problem butt heads and pull requests turn into "That's not how I would have written it" instead of critiquing the actual code presented.
The tooling and compiling I completely agree with. SBT is a horrific mess. I don't have a single good word to say about it.