Why I and my company have moved away from Scala. An honest critique.

Why I and my company have moved away from Scala. An honest critique.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

I never thought of myself as a mad scientist, but now that you mention it, I finally know what to put on my next batch of Lightbend business cards!

Thanks for the feedback (although it came with a slight sense of déjà vu -- where have I seen your post before?). I am proud of the progress that we've made with making Scala a language for everyone to be productive with, and my team is hard at work making it even better -- essentially along the lines that you describe.

In the mean time, I think the sharp edges such as macros and implicits are well documented. Avoid them when they don't warrant the investment. When you do need them, you do need them.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

I never thought of myself as a mad scientist, but now that you mention it, I finally know what to put on my next batch of Lightbend business cards!

Thanks for the feedback (although it came with a slight sense of déjà vu -- where have I seen your post before?). I am proud of the progress that we've made with making Scala a language for everyone to be productive with, and my team is hard at work making it even better -- essentially along the lines that you describe.

In the mean time, I think the sharp edges such as macros and implicits are well documented. Avoid them when they don't warrant the investment. When you do need them, you do need them.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

It's unfortunate that Scala hasn't been working out as well as hoped for your team.

There are three issues that you address: (1) is Scala working well for your team, and if not why not?; (2) is Scala suitable for business and/or other widespread (non-niche) use?; and (3) to the extent that there is a problem, is it because the development is driven by too many Ph.D.'s?

For your own productivity and the benefit of people with teams like yours, it's best not to mix the three up too much.

Taking the first two, "It didn't work for us" is different than "it doesn't work for anyone in business", and both are different than "it is a niche language".

For instance, Python isn't exactly a niche language, and its "monkey-patching" is way, way harder to track down than implicits are. C and C++--not exactly niche languages!--have #define which can make anything look like anything else, pretty much. Even in Java, reflection can be used to make pretty much everything impossible to follow.

None of these things have prevented these languages from enjoying widespread use, because a combination of lore (i.e. "best practices") and tooling can be employed to tame the worst of the problems while still benefiting from the advantages of the feature or at least of the language as a whole.

And, I would argue, exactly the same is true of Scala.

So I don't think you make a very compelling case that there is a problem with (2) in general, though there may certainly be difficulties for various application areas.

On the other hand, (1) is undoubtedly true if you have felt it necessary to rewrite in Java. I have had trouble fully understanding why from the reasons you gave, which makes it difficult to either think of how to improve Scala (without turning it into a different language) or understand how to warn others not to fall into the same difficulties you did.

For instance, you complain about implicits and mention that the tooling helps but still isn't enough. But then, when implicits stand to rescue you in an easy-to-inspect way from "gymnastics", you blame them? I don't understand how having a compact library that transforms huge boilerplatey gymnastics into something that happens automatically or with what looks like a simple method call is a problem.

So I can't really tell if you mean, "The way Play and Akka use implicits is too extensive and we can't find any practices that adequately keep them under control", or you mean, "We used implicits heavily and now we can't keep track of anything any more". If the former, well, that's no consolation to you as a user of the library, but you needn't consign the entire language to "niche" because someone can (and presumably will) write a more business-friendly set of libraries if there's demand for it. If the latter, well, sadly there aren't great resources for learning Scala best practices the way there are for Java. It's kind of an organic process. Maybe you ended up with a chapter or two's worth of antipatterns.

Anyway, you wrote a post on this about 11 months ago, and didn't engage with the community to try to find ways to improve the practices of your team, as far as I can tell (e.g. I gave you a bunch of reasons why implicits are better than other solutions in a number of areas, and suggested trying to limit uses where they cause trouble; other people shared other perspectives; but you didn't reply to the thread at all).

So it didn't work out; that's too bad. But I don't think your post has gone into enough detail to enable others to avoid the same mistakes (except maybe to commiserate if they already had the same problems--"yeah, I hate implicits and macros too"). And it doesn't seem, though it's hard to tell for sure, like you've tried very hard to understand how and why Scala is working well for those who claim it is.

Maybe in a few more years after a few "Scala: Patterns and Antipatterns for Robust Business Systems"-style books, you'll be able to hire people who don't need infeasible amounts of training. And hopefully tooling will be better yet so the essential information leaps out at you all the more and faster.

But implicits will still be there, if it's Scala, because implicits, despite having the capacity to confuse and mislead, are the best way to tell the compiler to safely take some of the repetitive burden off your hands, so you can remember less, need to pay less attention to minutia, and spend your concentration on big/difficult logic where the real challenge ought to be.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

Shrug .. Whatever. Was trying to provide an honest critique. I have used and will continue to use Akka, but my staff will use the Java API. I guess this is the reception in this community that you get (not just your post but the other two on the thread) when you post anything critical in the slightest. Not, in my opinion, the best way to engage but heck, it's the internet. Par for the course I guess. Actor Systems are a great idea and Lightbend is a great product, despite you blasting me personally. Furthermore, I even credited many ideas and aspects of the Scala language but if you dare critique it the community drops on you like a ton of bricks? Whatever. What do you think my motivation was in posting this? Boredom? Fame? No, neither. It was a hope that maybe some criticism will make things better but if Scala is so far down the road that criticism is not welcome, then they might as well drop the 'its an evolving language' PR because there is no functional difference between the inertia in the JDK and that of Scala. And yes, I have posted similar concerns before but I gave the language time and benefit of the doubt and now am even more certain my original feeling was correct.

At any rate I am apparently wasting my time. So don't worry, I will see my own way out. I think the door is over here. I apologize for trying.

I never thought of myself as a mad scientist, but now that you mention it, I finally know what to put on my next batch of Lightbend business cards!

Thanks for the feedback (although it came with a slight sense of déjà vu -- where have I seen your post before?). I am proud of the progress that we've made with making Scala a language for everyone to be productive with, and my team is hard at work making it even better -- essentially along the lines that you describe.

In the mean time, I think the sharp edges such as macros and implicits are well documented. Avoid them when they don't warrant the investment. When you do need them, you do need them.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="Ud7s2AmLCQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">scala-user+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="Ud7s2AmLCQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">scala-user+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

It's unfortunate that Scala hasn't been working out as well as hoped for your team.

There are three issues that you address: (1) is Scala working well for your team, and if not why not?; (2) is Scala suitable for business and/or other widespread (non-niche) use?; and (3) to the extent that there is a problem, is it because the development is driven by too many Ph.D.'s?

For your own productivity and the benefit of people with teams like yours, it's best not to mix the three up too much.

Taking the first two, "It didn't work for us" is different than "it doesn't work for anyone in business", and both are different than "it is a niche language".

Given the hiring potential its hard to argue this point. I live and work in one of the biggest tech areas around. Finding Scala people who even know the language, not even looking for experts, is near impossible. Furthermore, I work with a group of people I would consider to be at the top of their game development wise and they have difficulty grasping the language issues. Sure they can absorb the basics quickly but become immensely frustrated at things happening magically and non-deterministic code in the system. These aren't lightweight developers but guys that code million transaction a day systems for breakfast. If it stalls these people how is it going to react to the commodity engineers out there. After 2 years I have the answer to that. it doesn't work at all. This is my empirical observation from business. People can drop scorn on that all they want but its still an empirical observation.

For instance, Python isn't exactly a niche language, and its "monkey-patching" is way, way harder to track down than implicits are. C and C++--not exactly niche languages!--have #define which can make anything look like anything else, pretty much. Even in Java, reflection can be used to make pretty much everything impossible to follow.

Which is the reason its much easier for staff a company with Java engineers than either of those languages. Java didnt take over the market because its cross platform. All of that PR is rubbish. It took over because of the difficulties in the C and C++ world made time to market a nightmare. Very few companies other than tool vendors care one whit about cross platform. They care about the fact that they can staff and implement a system to get it to the market in the smallest time. So Scala's answer is to derive a java compatible language, implement some frankly awesome constructs and then completely shoot it in the foot by introducing some of the difficult and "magical" issues of C and C++ that cause the mass dev market to flee from those languages? Perplexing! At least to this developer.

None of these things have prevented these languages from enjoying widespread use, because a combination of lore (i.e. "best practices") and tooling can be employed to tame the worst of the problems while still benefiting from the advantages of the feature or at least of the language as a whole.

A comment on tooling, after years of the language being out, why hasn't the community teamed up with IntelliJ and Eclipse to get the tooling right? Not a priority? Ahh but this is how languages die.

And, I would argue, exactly the same is true of Scala.

So I don't think you make a very compelling case that there is a problem with (2) in general, though there may certainly be difficulties for various application areas.

On the other hand, (1) is undoubtedly true if you have felt it necessary to rewrite in Java. I have had trouble fully understanding why from the reasons you gave, which makes it difficult to either think of how to improve Scala (without turning it into a different language) or understand how to warn others not to fall into the same difficulties you did.

I just finished converting the vast majority of our Scala code to Java, which was actually a bummer for me because I see a lot of the brilliant things in Scala. However, as a matter of practical business reality it made zero sense to continue the duality. I know people here would say "well you should reacthitect this way or that, or dont use RDBMS or use Akka persistence." Sure, in an academic would I could do that, but if I walk up to my CEO and say, "Hey, lets drop 5 million in capital investment in the system, rebuild it and in a year I will have the same requirements again but it will be way cooler." If I do this, I get fired, and rightly so.

For instance, you complain about implicits and mention that the tooling helps but still isn't enough. But then, when implicits stand to rescue you in an easy-to-inspect way from "gymnastics", you blame them? I don't understand how having a compact library that transforms huge boilerplatey gymnastics into something that happens automatically or with what looks like a simple method call is a problem.

So I can't really tell if you mean, "The way Play and Akka use implicits is too extensive and we can't find any practices that adequately keep them under control", or you mean, "We used implicits heavily and now we can't keep track of anything any more". If the former, well, that's no consolation to you as a user of the library, but you needn't consign the entire language to "niche" because someone can (and presumably will) write a more business-friendly set of libraries if there's demand for it. If the latter, well, sadly there aren't great resources for learning Scala best practices the way there are for Java. It's kind of an organic process. Maybe you ended up with a chapter or two's worth of antipatterns.

What I mean is implicits THEMSELVES are an antipattern. Scala went to a lot of effort to make a statically typed functional programming language and then crushed it with Rubyesque "magic" that is not statically typed. Unfortunate.

Anyway, you wrote a post on this about 11 months ago, and didn't engage with the community to try to find ways to improve the practices of your team, as far as I can tell (e.g. I gave you a bunch of reasons why implicits are better than other solutions in a number of areas, and suggested trying to limit uses where they cause trouble; other people shared other perspectives; but you didn't reply to the thread at all).

I responded to many people but I do work a lot and thread responses sometimes slip through the cracks. Also, being flamed for heresy gets a bit old when all I am trying to do is help. I dont make any money saying this and it certainly doesn't earn me any friends here. Im not by nature masochistic so my motivation must be something else.

So it didn't work out; that's too bad. But I don't think your post has gone into enough detail to enable others to avoid the same mistakes (except maybe to commiserate if they already had the same problems--"yeah, I hate implicits and macros too"). And it doesn't seem, though it's hard to tell for sure, like you've tried very hard to understand how and why Scala is working well for those who claim it is.

You cant avoid implicits in Scala. They are pervasive.

Maybe in a few more years after a few "Scala: Patterns and Antipatterns for Robust Business Systems"-style books, you'll be able to hire people who don't need infeasible amounts of training. And hopefully tooling will be better yet so the essential information leaps out at you all the more and faster.

Maybe. But then maybe Scala will re-evaluate some features and decide that they were a good thought but didn't work out in reality. But again, I cant afford to have the staff of our small little development company down 6 months and not seriously productive for another 6 months when I could have the product out by then. Learning a cool language is great and all but something has to pay the bills.

But implicits will still be there, if it's Scala, because implicits, despite having the capacity to confuse and mislead, are the best way to tell the compiler to safely take some of the repetitive burden off your hands, so you can remember less, need to pay less attention to minutia, and spend your concentration on big/difficult logic where the real challenge ought to be.

I can think of half a dozen techs that said they would take away repetition and went wrong. Repetition is a part of life for developers. Incurring a framework to keep me from casting an object or wrapping it in a decorator by hand is a little overkill don't you think?

--Rex

Anyway as I said in my other reply, clearly my opinions arent welcome. Good luck to the community. I tried to help.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="hWMB4AqQCQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">scala-user+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="619dh4GQCQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">scala-user+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

It's unfortunate that Scala hasn't been working out as well as hoped for your team.

There are three issues that you address: (1) is Scala working well for your team, and if not why not?; (2) is Scala suitable for business and/or other widespread (non-niche) use?; and (3) to the extent that there is a problem, is it because the development is driven by too many Ph.D.'s?

For your own productivity and the benefit of people with teams like yours, it's best not to mix the three up too much.

Taking the first two, "It didn't work for us" is different than "it doesn't work for anyone in business", and both are different than "it is a niche language".

Given the hiring potential its hard to argue this point. I live and work in one of the biggest tech areas around. Finding Scala people who even know the language, not even looking for experts, is near impossible.

I grant it isn't easy. This doesn't mean that Scala isn't destined to be a niche language, though. Its rise is not as meteoric as Java's was, admittedly.

Furthermore, I work with a group of people I would consider to be at the top of their game development wise and they have difficulty grasping the language issues.

Maybe you should tell us more about what you think a reasonable
training/learning scenario is? I mean, it's totally fair to say, "You
know, I have these top-notch Java devs with 15 years of experience
apiece and dropping them into Scala lowers their productivity and makes
them make a bunch of newbie mistakes." I'd expect that, actually. So
if your take home message is, "Scala isn't a good language for rapid productivity gains
when you're staffed with top-notch Java developers," it sounds eminently plausible.

Sure they can absorb the basics quickly but become immensely frustrated at things happening magically and non-deterministic code in the system.

Implicit resolution is deterministic. Any time it isn't, that's a bug. Macros should be deterministic (but it's technically possible to make them not).

These aren't lightweight developers but guys that code million transaction a day systems for breakfast.

I don't see how handling a million transactions a day in one language is going to make you an automatic expert in another language. You're no lightweight, obviously, if you can do that in *any* language. But it doesn't mean from knowing Java you'll just be able to pick up, I don't know, Node.js, and immediately do as well with it as the Node.js experts.

If it stalls these people how is it going to react to the commodity engineers out there. After 2 years I have the answer to that. it doesn't work at all. This is my empirical observation from business. People can drop scorn on that all they want but its still an empirical observation.

Sure, but you asserted in previous years that you *weren't* willing to invest in more than minimal training. With *that* proviso, sure. If your language isn't just "Java with better syntax and an immutable collections library", you may well run into problems.

Kotlin and Ceylon are both trying harder to be Java with better syntax. (Groovy 3 too, I guess, now that some types are in evidence.) So far, the market response seems to be, "Meh, you know, that's kind of nice but not really enough to be worth the effort of switching/adding a language."

For instance, Python isn't exactly a niche language, and its "monkey-patching" is way, way harder to track down than implicits are. C and C++--not exactly niche languages!--have #define which can make anything look like anything else, pretty much. Even in Java, reflection can be used to make pretty much everything impossible to follow.

Which is the reason its much easier for staff a company with Java engineers than either of those languages. Java didnt take over the market because its cross platform.

So you basically are dividing the world into "Java" and "niche"? Fair enough. It could well be that Scala remains a "niche" language.

It's really hard to tell if that is the only standard we're measuring by.

Otherwise, I reiterate: other languages that by most standards are not considered niche have features that are a lot worse, so the presence of the features you don't like isn't necessarily enough to keep a language as a niche language.

What I mean is implicits THEMSELVES are an antipattern. Scala went to a lot of effort to make a statically typed functional programming language and then crushed it with Rubyesque "magic" that is not statically typed. Unfortunate.

I am baffled by how you can say this and claim to be more than marginally familiar with Scala.

Implicits are completely statically typed. In fact, they are the main user-invokable mechanism for performing type computations. They underlie a huge amount of the machinery in libraries that do advanced type wizardry like scalaz, cats, and shapeless.

Maybe you mean something other than what you're saying.

Do you mean "explicitly typed" rather than "statically typed"?

You cant avoid implicits in Scala. They are pervasive.

This is true, but now this just sounds like I Hate Implicits For Reasons I Can't Express, because you've only made some handwavy comments about running into trouble with them, and I and (some) others don't run into (much) trouble with them.

I assume you/your team is doing something else with them than I am if you are *actually* having problems rather than just recoiling in horror when you realize one is there.

Again, consider Java reflection for comparison. You can get amazingly incomprehensible and awful stuff to happen with reflection. So Java devs don't do that. (Except occasionally when they must, and in almost every case I've seen there's a much clearer and less error-prone solution with implicits in Scala.) They don't say, "Oh, both these things have a `close` method but they're not related, so we'll make a method that takes an `Object` and reflect", because BOOM! type safety gone, runtime errors galore. Instead, they either write a box that encapsulates the two different things with close methods, or they overload the method to take the two different things at the position of that argument.

So--is the *problematic* part of implicits pervasive?

Or is it just once burned twice shy, so you want to get rid of all aspects of it, and can't? (There, I agree--they are too pervasive to get rid of the non-problematic aspects.)

But implicits will still be there, if it's Scala, because implicits, despite having the capacity to confuse and mislead, are the best way to tell the compiler to safely take some of the repetitive burden off your hands, so you can remember less, need to pay less attention to minutia, and spend your concentration on big/difficult logic where the real challenge ought to be.

I can think of half a dozen techs that said they would take away repetition and went wrong. Repetition is a part of life for developers. Incurring a framework to keep me from casting an object or wrapping it in a decorator by hand is a little overkill don't you think?

No, it's not overkill if the repetition and boilerplate is bad enough that it is one of your two main points.

Java has 143 different SAM function types. Being able to just bam! .asJava a Scala function you've already got to get the right one in Java saves an amazing amount of work. Trying do do it manually is awful. All your logic is completely lost inside boilerplate.

Repetition is part of life but it doesn't mean it's desirable.

--Rex

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

Assuming that you don’t want your statements to be immediately labeled as FUD (and they certainly look to be tending that way), you’ll need to specify here how you’re defining both “significant traction” and “business world” in order to justify such a claim.

My personal experience would lead me to conclude the exact opposite; specifically as regards the rate at which I’m approached by headhunters/recruiters, and how “business worldy” their clients are… presumably investment banks, hedge funds, petro-chemicals, media conglomerates, and other assorted multinationals can all be reasonably classed as belonging to the business world.

I work in a company that uses the Playframework and Akka to implement a business system. For a long time i was trying to push the implementation towards Scala and away from java. However, I have ultimately given up on that effort and have almost completed refactoring the work to Java. Here is why.

First of all the learning curve on Scala is very steep but unnecessarily so. Scala syntax is very brief and but that isn't what holds up the learning curve, nor is it the functional programming concepts, functions as first class entities. These are in fact the good facets of Scala. Pattern matching is absolutely awesome, immutable collections are something that Java is really lacking. In short there is a ton of good things in Scala that attract a developer from Java. But the problem is Scala shoots itself in the foot.

Without too much fanfare I will declare that Implicit conversions and Macros make the language very difficult to learn and, outside the academic world, almost inaccessible to business. Implicit conversions and indeed the entire 'implicit" keyword is just lethal to the learning curve as well as code maintenance. In a business world where effort is judged in ROI, anything that just magically transparently happens is a disaster waiting to happen. In fact such disasters do happen. We found that implicits float around in our code interacting in strange ways that were non-deterministic and opaque to reading the code. The beginner looking at a method wonders, "wait how can you call that method on that object?" Then they think and say "oh there is an implicit somewhere in some of my imports somewhere down the tree that convert the type. Its obscure, opaque, confusing and the antithesis of everything that an experienced business developer wants. I used to think that it was just a matter of tooling but IntelliJ has actually decent scala tooling and still implicits are a total disaster. Second problem is Macros. Like implicits they make things happen that are difficult to discern by looking at the code. The introduction of both of these and their rampant use in the language is, in my opinion, going to push Scala to be yet another niche language like lisp, scheme, Erlang and so on.

Secondly is the compilation tooling and interaction with java. Scala interacts transparently with java. Well, at least that is what the promotional materials say. In practice to achieve that interaction is a major PITA and I am not talking about flat bread here. Conversions of types require gymnastics. For example, try passing a list of Scala longs to a java method that takes a list of java.util.Long objects. Gymnastics. The function lambdas are non translatable so you cant just pass a Scala lambda to a java function that takes a java.util.Function. You can doctor this with ... wait for it ... an implicit conversion that wraps one into the other. Sigh. In our codebase we had tons of code in both languages and it was just a nightmare going between the two. The tooling doesn't help either because SBT gets in some wacked out logic loops and simply rebuilds the whole project multiple times. After years of Scala development SBT is still slow, and in such a bad state that it isn't even at 1.0.

I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java. It was a statically bound deterministic language with functional and Object oriented concepts but it has now strayed into things that happen "magically" and code that is generated with Macros. I personally think one of two things will happen. Either the maintainers of Scala will reverse this direction and get back to basics, dump the implicits and macros and find more deterministic ways to do things. Or, quite frankly, it will die on the vine as another Erlang, Lisp, Node.js or you name it. A language used in a small limited sector for a few projects but without wide acceptance.

I, for one would think that is a shame, a horrible waste. Scala could be the next super language if academics stop messing with it like mad scientists with a new toy. Until then, I cant have my whole staff down six months learning scala.

-- Robert,

-- Principal Software Architect.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

What I mean is implicits THEMSELVES are an antipattern. Scala went to a lot of effort to make a statically typed functional programming language and then crushed it with Rubyesque "magic" that is not statically typed. Unfortunate.

I am baffled by how you can say this and claim to be more than marginally familiar with Scala.

Implicits are completely statically typed. In fact, they are the main user-invokable mechanism for performing type computations. They underlie a huge amount of the machinery in libraries that do advanced type wizardry like scalaz, cats, and shapeless.

As an aerospace engineer who works fairly independently, I am not qualified to weigh in on the issue of Scala adoption in industry. However, I will say that I am very glad that I have the option of using Scala instead of Java. As far as I am concerned, there is no comparison in terms of elegance and simplicity once you learn to use Scala properly (e.g., lots of immutable case classes). If someone forced me to switch from Scala to Java, I would quit programming and find something else to do (programming is not a required part of my job).

As for implicits, I use them fairly rarely, but they do come in handy at times. For example, I have a implicit class that I call Vectorx, which extends the Scala Vector to do standard vector addition, subtraction, and multiplication or division by a scalar. It works beautifully, and it saved me the pain of finding another name for what really should be called a Vector (because it is implicit, the name Vectorx never needs to be explicitly invoked by the user).

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

Thank you Russ! That's an exemplary attitude toward judgments. Our knowledge, our scope is limited. Nobody can speak for the whole world of business, the whole scala community, the whole FP or math. We have our partial opinions, and share them. Generalization is no good even if we talk about Church thesis.

What I mean is implicits THEMSELVES are an antipattern. Scala went to a lot of effort to make a statically typed functional programming language and then crushed it with Rubyesque "magic" that is not statically typed. Unfortunate.

I am baffled by how you can say this and claim to be more than marginally familiar with Scala.

Implicits are completely statically typed. In fact, they are the main user-invokable mechanism for performing type computations. They underlie a huge amount of the machinery in libraries that do advanced type wizardry like scalaz, cats, and shapeless.

As an aerospace engineer who works fairly independently, I am not qualified to weigh in on the issue of Scala adoption in industry. However, I will say that I am very glad that I have the option of using Scala instead of Java. As far as I am concerned, there is no comparison in terms of elegance and simplicity once you learn to use Scala properly (e.g., lots of immutable case classes). If someone forced me to switch from Scala to Java, I would quit programming and find something else to do (programming is not a required part of my job).

As for implicits, I use them fairly rarely, but they do come in handy at times. For example, I have a implicit class that I call Vectorx, which extends the Scala Vector to do standard vector addition, subtraction, and multiplication or division by a scalar. It works beautifully, and it saved me the pain of finding another name for what really should be called a Vector (because it is implicit, the name Vectorx never needs to be explicitly invoked by the user).

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

What I meant is that implicits are. It directly linked to code you can see. If you look at a method and see the code it is not apparent that an implicit is involved. Because they happen "magically.

But I got the message. It was "F off, your opinions aren't wanted no matter how honestly you offer them." Message received. No more reason for me to post on this thread or indeed group anymore. Twitter abandoned Scalia. Linked in abandoned Scala. So by all means keep beating people upside the head when they offer constructive advice. Could have been wonderful but toss it on the heap of could have been languages.

Peace and good luck.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Aw: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.

my ide (intellij) highlights implicit conversions. it's the same for "call by name" parameters. this problem only exists for text editors, and in those, everything is magic because i can't jump to declaractions or check the type of an expression

What I meant is that implicits are. It directly linked to code you can see. If you look at a method and see the code it is not apparent that an implicit is involved. Because they happen "magically.

But I got the message. It was "F off, your opinions aren't wanted no matter how honestly you offer them." Message received. No more reason for me to post on this thread or indeed group anymore. Twitter abandoned Scalia. Linked in abandoned Scala. So by all means keep beating people upside the head when they offer constructive advice. Could have been wonderful but toss it on the heap of could have been languages.

Peace and good luck.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.

To be fair, this is everything but not an honest and constructive critique. Your statement:

> I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java.

Is not constructive and quite aggressive and populist. `those with PhDs` are the same people that we have to thank for the progress. Also saying that Scala was an alternative to Ruby is a nonsense. As Ruby and scala have completely different use cases, and so Ruby and Java.

You say Twitter and Linkedin have abandoned Scala, fair enough, but at the same time other, much bigger companies, like Expedia, are embracing it because more and more developers want to write Scala code.

my ide (intellij) highlights implicit conversions. it's the same for "call by name" parameters. this problem only exists for text editors, and in those, everything is magic because i can't jump to declaractions or check the type of an expression

Betreff: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.

What I meant is that implicits are. It directly linked to code you can see. If you look at a method and see the code it is not apparent that an implicit is involved. Because they happen "magically.

But I got the message. It was "F off, your opinions aren't wanted no matter how honestly you offer them." Message received. No more reason for me to post on this thread or indeed group anymore. Twitter abandoned Scalia. Linked in abandoned Scala. So by all means keep beating people upside the head when they offer constructive advice. Could have been wonderful but toss it on the heap of could have been languages.

Peace and good luck.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--

Filippo De Luca

about.me/FilippoDeLuca

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

With respect, I agree that implicits and the "magic" therein can mean that what's going on isn't immediately obvious to an external caller of functions involving them.

That said, lots of Java programmers use Spring and its magic without worrying about the fact that they don't know all about what's going on under the hood during the wiring/bean discovery processes (and the vast majority simply don't know, they just accept the Spring magic as long as it works). I don't really see why implicit magic at compile time is any worse than Spring magic at runtime. There are very strong arguments in favour of using implicits around/in (where necessary) to make code calling APIs, and its intent, much easier to read. I'm sure they can be overused, but it's also true that over the last few weeks, working on an API I'm writing in Java, I've more than once wished for implicits and implicit conversions to make a few very specific scenarios much easier to read and work with, both for me and the people who will be consuming the API. I'd prefer to write it in Scala but that's not an option given it will belong primarily to a Java-based team over which I do not have any control).

So yes, implicits can be a two-edged sword. They can also be a fabulous tool for helping convey intent more obviously by eliminating boilerplate adapters. On balance, while I wouldn't go out of my way to use them, there are definitely situations where I would vastly prefer to have them in my toolkit.

I won't comment on macros as, frankly, I've never used them at all so I haven't run into the pain points in any way.

On Tuesday, February 14, 2017 at 6:45:04 AM UTC, kraythe wrote:

What I meant is that implicits are. It directly linked to code you can see. If you look at a method and see the code it is not apparent that an implicit is involved. Because they happen "magically.

But I got the message. It was "F off, your opinions aren't wanted no matter how honestly you offer them." Message received. No more reason for me to post on this thread or indeed group anymore. Twitter abandoned Scalia. Linked in abandoned Scala. So by all means keep beating people upside the head when they offer constructive advice. Could have been wonderful but toss it on the heap of could have been languages.

Peace and good luck.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.

To be fair, this is everything but not an honest and constructive critique. Your statement:

> I think Scala has become too academic. Too controlled by those with PhDs. in computer science figuring out what they can do, rather than wondering if they actually should do these things and as a result the language has abandoned some of its roots. It started out as an alternative to Ruby and Java.

Is not constructive and quite aggressive and populist. `those with PhDs` are the same people that we have to thank for the progress. Also saying that Scala was an alternative to Ruby is a nonsense. As Ruby and scala have completely different use cases, and so Ruby and Java.

You say Twitter and Linkedin have abandoned Scala, fair enough, but at the same time other, much bigger companies, like Expedia, are embracing it because more and more developers want to write Scala code.

For what it's worth Twitter just joined the Scala Center advisory board as a full member. Don't believe the FUD.

my ide (intellij) highlights implicit conversions. it's the same for "call by name" parameters. this problem only exists for text editors, and in those, everything is magic because i can't jump to declaractions or check the type of an expression

Betreff: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.

What I meant is that implicits are. It directly linked to code you can see. If you look at a method and see the code it is not apparent that an implicit is involved. Because they happen "magically.

But I got the message. It was "F off, your opinions aren't wanted no matter how honestly you offer them." Message received. No more reason for me to post on this thread or indeed group anymore. Twitter abandoned Scalia. Linked in abandoned Scala. So by all means keep beating people upside the head when they offer constructive advice. Could have been wonderful but toss it on the heap of could have been languages.

Peace and good luck.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--

Filippo De Luca

about.me/FilippoDeLuca

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--

Martin OderskyEPFL and Lightbend

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Re: Why I and my company have moved away from Scala. An honest critique.

Being a C++ person, I too have had a lot of headache getting the Scala
community to help when one spares an honest criticism about the
language. Alas, I can't witness it getting any better. Yet, I think
Rex does have some valid point in trying to separate concerns. Maybe
his (1), (2), and (3) were not exactly the best. But, that's at least
an effort to see what lessons the language designers can take out of
your report.

Social aspects aside, there is something technical in your words which
absolutely tickles me to respond:

> What I mean is implicits THEMSELVES are an antipattern. Scala went to a lot of effort to make a statically typed functional programming language and then crushed it with Rubyesque "magic" that is not statically typed. Unfortunate.

I cannot help falling in love with your above words. :)

Being a C++ person, I am used to all sorts of gotwas when it comes to
implicit conversions. Yet, I am amused by the C++ way of doing it and
have been severely beaten up by the Scala implicits many times. It
took me a lot of time to figure out what the reasons can be. It turns
out that the kind of applications I deal with all require what is
called "lightweight family polymorphism"; whereas, Scala is pro
"family polymorphism". (Sorry for the PL jargon; I'm a PL maverick.)
The specially relevant consequence is that the Scala implicits work
(and do creepy things) at runtime; whereas, the C++ conversions are
secured at compile-time. A Scala implicit, being an object, (by
design) enjoys all sorts of late-binding. In C++, however, the exact
conversions are completely known statically. Clearly, the former comes
with extra flexibility. But, for me too, the price is way beyond
affordable for it makes code unpredictable and out of the programmer's
control.

And, BTW, C++ has constantly been loosing market share for its
excessive difficulty to learn. Java, OTOH, ramped up because it lucky
coincidence to facilitate massive rubbish development with the time
when people could no longer focus on efficiency due to physical
barriers.

Cheers,
--Hossein

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Being a C++ person, I too have had a lot of headache getting the Scala
community to help when one spares an honest criticism about the
language. Alas, I can't witness it getting any better. Yet, I think
Rex does have some valid point in trying to separate concerns. Maybe
his (1), (2), and (3) were not exactly the best. But, that's at least
an effort to see what lessons the language designers can take out of
your report.

Social aspects aside, there is something technical in your words which
absolutely tickles me to respond:

> What I mean is implicits THEMSELVES are an antipattern. Scala went to a lot of effort to make a statically typed functional programming language and then crushed it with Rubyesque "magic" that is not statically typed. Unfortunate.

I cannot help falling in love with your above words. :)

Being a C++ person, I am used to all sorts of gotwas when it comes to
implicit conversions. Yet, I am amused by the C++ way of doing it and
have been severely beaten up by the Scala implicits many times. It
took me a lot of time to figure out what the reasons can be. It turns
out that the kind of applications I deal with all require what is
called "lightweight family polymorphism"; whereas, Scala is pro
"family polymorphism". (Sorry for the PL jargon; I'm a PL maverick.)
The specially relevant consequence is that the Scala implicits work
(and do creepy things) at runtime; whereas, the C++ conversions are
secured at compile-time. A Scala implicit, being an object, (by
design) enjoys all sorts of late-binding. In C++, however, the exact
conversions are completely known statically. Clearly, the former comes
with extra flexibility. But, for me too, the price is way beyond
affordable for it makes code unpredictable and out of the programmer's
control.

And, BTW, C++ has constantly been loosing market share for its
excessive difficulty to learn. Java, OTOH, ramped up because it lucky
coincidence to facilitate massive rubbish development with the time
when people could no longer focus on efficiency due to physical
barriers.

Cheers,
--Hossein

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.