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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
115 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

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

jez prime
Again, I'd agree with you, but firstly this wasn't a startup but a fundamentally conservative organisation and secondly to be fair 2 or 3 Scala-experienced devs across a team of 50+ in total (that's really across multiple teams but you get the point), where those most experienced with Scala also have design and architecture responsibilities is not going to teach anyone Scala quickly enough to avoid a very sizeable productivity dip. I actually think adoption in a startup with a small team would be easier than in the scenario with which we were faced.

Like I said, I'm a fan, and I would vastly prefer to be working in Scala, but I can also see the counter-argument. We had trouble trying to teach these guys the Java 8 stream approach, but on the upside, at least now they get lambdas in that scenario, one part of a Scala move might be easier for them :) 

Many organisations, when faced with short term cost for long term benefits, will simply reject that option. Half their management won't be there 2 years from now, so what do they care about the long term benefit?

On Thursday, February 16, 2017 at 7:28:50 PM UTC, Oliver Ruebenacker wrote:

     Hello,

  If your team is a mix of Scala engineers and Java engineers, the Scala engineers can teach the Java engineers and help them find appropriate tasks for their level. Such team will be quickly productive and suitable even in a startup, where survival depends on your ability to produce results quickly.

  We can't predict the future of Scala, but many features of Scala are great features and will be part of the most popular language within the next five to ten years, regardless of whether that most popular language will be Java, Scala or something else. Then you want to have people who are familiar with these features.

     Best, Oliver

On Thu, Feb 16, 2017 at 2:12 PM, jez prime <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="oMckYMTDCgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mr.n...@...> wrote:
Devil's advocate time. There are vast numbers of Java developers who have no interest in learning anything new for themselves - i've worked with plenty in the past. Like it or not, that's the way it is. Similarly there are many organisations who are quite simply not prepared to spend money to train their existing staff to do new things. For a self-employed mercenary such as myself, your point holds true for the very simple reason that it's in my direct financial interest to find the time to learn new things. That isn't as clear for a developer in a permanent post in a fairly comfortable position. So yes, a steep learning conceptual learning curve does limit adoption. I recently worked in a sizeable UK government organisation that absolutely rejected Scala from the word go, despite a recommendation from one of their own architects to adopt it. Their concern was purely and simply (and correctly) about the size of the pool they'd have available to recruit from. 

I'm speaking as a Scala fan by the way, but I've witnessed this for myself as outlined above. They disregarded the argument that they wouldn't need as big a pool because the developers they would recruit would be more productive and ultimately the codebase would end up cleaner.

On Thursday, February 16, 2017 at 4:36:53 PM UTC, Vlad Patryshev wrote:
Get an average Java developer and train them to become a good FP Scala programmer? Done it; developers are happy. There are known, and well-explained steps to get Java OOP programmers into Scala FP world.

Thanks,
-Vlad

On Wed, Feb 15, 2017 at 10:41 PM, kraythe <[hidden email]> wrote:
Whatever FUD is, I don't know. 

I get harassed by headhunters, a good portion of them want to place me in inappropriate jobs. I get 60 mails a day sometimes. Its stupid. Ive thought of cancelling my linked-in account at times. That doesnt translate to penetration. Scala developers cannot be hired. Companies that are stuck in scala with millions in capital investment would MUCH RATHER be able to staff their shops, so they go back to Java. Because the scala language is too difficult to learn, the shortage of developers means new projects aren't started in scala and those with the ability either black box their old software and build on it with java or just start over in java. 

That is just business reality. Good or bad hardly matters. You can't take an average dev and train them in a couple weeks and have them reading the Scala SDK with comprehension and have them good at the language in a month. Businesses don't have time for their staff to spend six months getting good or the money to send them to expensive 3 week seminars. Hence no penetration. 

I realize my posts aren't popular and I am not making friends. So my motivation must be something else. I am not nearly bored enough to want to sit here answering for no reason and I have a quite excellent live with a wonderful family and no need to go troll anyone. Therefore my intentions must be honorable. They aren't given credit for being so but I am not surprised really. 

I would love Scala to replace java. On this trajectory it doesn't have a chance. 

-- Robert


On Sunday, February 12, 2017 at 5:58:27 PM UTC-6, Kevin Wright wrote:
“Scala has gained ZERO significant traction in the business world.”

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.


On 12 February 2017 at 21:54, kraythe <[hidden email]> wrote:
No its not. Scala has gained ZERO significant traction in the business world. It is not the next java. 

On Sunday, February 12, 2017 at 3:38:13 PM UTC-6, Vlad Patryshev wrote:
Oh, and Java of course is just perfect, compared to Scala.

Enjoy nulls and NPE, and mutability, and all the dumb frameworks designed by ignorants. You probably won't need generics; Java people just hate generics. They (Java people) are cheaper too.

The world is moving on; you decided to take a rest; it's okay, but don't expect others to join.

I wonder also what would be your opinion of Rust. Also worse than Java? I'm sure it is. No garbage collection. No Hibernate.

Thanks,
-Vlad

On Sun, Feb 12, 2017 at 9:16 AM, kraythe <[hidden email]> wrote:
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 scala-user+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" 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="oMckYMTDCgAJ" 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.



--
Oliver Ruebenacker
Senior Software Engineer, <a href="http://www.type2diabetesgenetics.org/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.type2diabetesgenetics.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFVE8xTGqlzANyuan2sVDo75uy-vA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.type2diabetesgenetics.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFVE8xTGqlzANyuan2sVDo75uy-vA&#39;;return true;">Diabetes Portal, <a href="http://www.broadinstitute.org/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.broadinstitute.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHloBLjHUP5Yhb6LyVOZ-JE5b4Y5A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.broadinstitute.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHloBLjHUP5Yhb6LyVOZ-JE5b4Y5A&#39;;return true;">Broad Institute

--
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.
Reply | Threaded
Open this post in threaded view
|

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

jez prime
In reply to this post by Brian Maso

I genuinely think I've got more hope of getting Kotlin adopted in some of my clients than Scala. I even had the "let's just use the nicer object construction syntax and not much else" argument rejected (maybe they realised I was really planning a Trojan horse approach - get the devs familiar with the basics, then build out from there at a pace the team could work with).

On Thursday, February 16, 2017 at 7:34:02 PM UTC, Brian Maso wrote:
The learning curve is indeed steep. It took me at least a couple years working evening and weekends with Scala -- with no real FP background -- to start feeling like I was guaranteed more productive in Scala than Java. At this point I see FP on the JVM as my extreme advantage over Java developers.

I know there are shops who don't want to change to other languages -- similarly there weren't shops who wanted to move from classic VB to .Net, from craptaculous HTML and server-side code to CSS/JavaScript, from COBOL to almost anything else, etc. There are definitely niches and industrial enclaves where those technologies make sense from a business POV even to this day.

If you are in a position to ride the Java wave all the way to retirement, and you are satisfied and enjoy the solutions you are able to create, that's great. Both personally and professionally I am more than satisfied with Scala, at least in part because I can look forward to the staff-heavy Java shops that I can compete with very handily.

Brian Maso



On Thu, Feb 16, 2017 at 11:12 AM, jez prime <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="pWtfDg3ECgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mr.n...@...> wrote:
Devil's advocate time. There are vast numbers of Java developers who have no interest in learning anything new for themselves - i've worked with plenty in the past. Like it or not, that's the way it is. Similarly there are many organisations who are quite simply not prepared to spend money to train their existing staff to do new things. For a self-employed mercenary such as myself, your point holds true for the very simple reason that it's in my direct financial interest to find the time to learn new things. That isn't as clear for a developer in a permanent post in a fairly comfortable position. So yes, a steep learning conceptual learning curve does limit adoption. I recently worked in a sizeable UK government organisation that absolutely rejected Scala from the word go, despite a recommendation from one of their own architects to adopt it. Their concern was purely and simply (and correctly) about the size of the pool they'd have available to recruit from. 

I'm speaking as a Scala fan by the way, but I've witnessed this for myself as outlined above. They disregarded the argument that they wouldn't need as big a pool because the developers they would recruit would be more productive and ultimately the codebase would end up cleaner.

On Thursday, February 16, 2017 at 4:36:53 PM UTC, Vlad Patryshev wrote:
Get an average Java developer and train them to become a good FP Scala programmer? Done it; developers are happy. There are known, and well-explained steps to get Java OOP programmers into Scala FP world.

Thanks,
-Vlad

On Wed, Feb 15, 2017 at 10:41 PM, kraythe <[hidden email]> wrote:
Whatever FUD is, I don't know. 

I get harassed by headhunters, a good portion of them want to place me in inappropriate jobs. I get 60 mails a day sometimes. Its stupid. Ive thought of cancelling my linked-in account at times. That doesnt translate to penetration. Scala developers cannot be hired. Companies that are stuck in scala with millions in capital investment would MUCH RATHER be able to staff their shops, so they go back to Java. Because the scala language is too difficult to learn, the shortage of developers means new projects aren't started in scala and those with the ability either black box their old software and build on it with java or just start over in java. 

That is just business reality. Good or bad hardly matters. You can't take an average dev and train them in a couple weeks and have them reading the Scala SDK with comprehension and have them good at the language in a month. Businesses don't have time for their staff to spend six months getting good or the money to send them to expensive 3 week seminars. Hence no penetration. 

I realize my posts aren't popular and I am not making friends. So my motivation must be something else. I am not nearly bored enough to want to sit here answering for no reason and I have a quite excellent live with a wonderful family and no need to go troll anyone. Therefore my intentions must be honorable. They aren't given credit for being so but I am not surprised really. 

I would love Scala to replace java. On this trajectory it doesn't have a chance. 

-- Robert


On Sunday, February 12, 2017 at 5:58:27 PM UTC-6, Kevin Wright wrote:
“Scala has gained ZERO significant traction in the business world.”

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.


On 12 February 2017 at 21:54, kraythe <[hidden email]> wrote:
No its not. Scala has gained ZERO significant traction in the business world. It is not the next java. 

On Sunday, February 12, 2017 at 3:38:13 PM UTC-6, Vlad Patryshev wrote:
Oh, and Java of course is just perfect, compared to Scala.

Enjoy nulls and NPE, and mutability, and all the dumb frameworks designed by ignorants. You probably won't need generics; Java people just hate generics. They (Java people) are cheaper too.

The world is moving on; you decided to take a rest; it's okay, but don't expect others to join.

I wonder also what would be your opinion of Rust. Also worse than Java? I'm sure it is. No garbage collection. No Hibernate.

Thanks,
-Vlad

On Sun, Feb 12, 2017 at 9:16 AM, kraythe <[hidden email]> wrote:
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 scala-user+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" 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="pWtfDg3ECgAJ" 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.



--
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="pWtfDg3ECgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">br...@...

--
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.
Reply | Threaded
Open this post in threaded view
|

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

jez prime
In reply to this post by Brian Maso
Another small note, I'm not as pessimistic as the OP, despite my comments on what I've observed recently, because I also observed something else.

The people I've seen having most problems learning Scala (or the functional stuff in Java 8) are mainly the most experienced Java devs on the team. In other words it's their experience working in Java that holds them back most. The ones who took it on faster were more junior devs who hadn't already shaped a mental model based purely on OO and the Java language. So there is room for evolution in thinking. 

On Thursday, February 16, 2017 at 7:34:02 PM UTC, Brian Maso wrote:
The learning curve is indeed steep. It took me at least a couple years working evening and weekends with Scala -- with no real FP background -- to start feeling like I was guaranteed more productive in Scala than Java. At this point I see FP on the JVM as my extreme advantage over Java developers.

I know there are shops who don't want to change to other languages -- similarly there weren't shops who wanted to move from classic VB to .Net, from craptaculous HTML and server-side code to CSS/JavaScript, from COBOL to almost anything else, etc. There are definitely niches and industrial enclaves where those technologies make sense from a business POV even to this day.

If you are in a position to ride the Java wave all the way to retirement, and you are satisfied and enjoy the solutions you are able to create, that's great. Both personally and professionally I am more than satisfied with Scala, at least in part because I can look forward to the staff-heavy Java shops that I can compete with very handily.

Brian Maso



On Thu, Feb 16, 2017 at 11:12 AM, jez prime <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="pWtfDg3ECgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mr.n...@...> wrote:
Devil's advocate time. There are vast numbers of Java developers who have no interest in learning anything new for themselves - i've worked with plenty in the past. Like it or not, that's the way it is. Similarly there are many organisations who are quite simply not prepared to spend money to train their existing staff to do new things. For a self-employed mercenary such as myself, your point holds true for the very simple reason that it's in my direct financial interest to find the time to learn new things. That isn't as clear for a developer in a permanent post in a fairly comfortable position. So yes, a steep learning conceptual learning curve does limit adoption. I recently worked in a sizeable UK government organisation that absolutely rejected Scala from the word go, despite a recommendation from one of their own architects to adopt it. Their concern was purely and simply (and correctly) about the size of the pool they'd have available to recruit from. 

I'm speaking as a Scala fan by the way, but I've witnessed this for myself as outlined above. They disregarded the argument that they wouldn't need as big a pool because the developers they would recruit would be more productive and ultimately the codebase would end up cleaner.

On Thursday, February 16, 2017 at 4:36:53 PM UTC, Vlad Patryshev wrote:
Get an average Java developer and train them to become a good FP Scala programmer? Done it; developers are happy. There are known, and well-explained steps to get Java OOP programmers into Scala FP world.

Thanks,
-Vlad

On Wed, Feb 15, 2017 at 10:41 PM, kraythe <[hidden email]> wrote:
Whatever FUD is, I don't know. 

I get harassed by headhunters, a good portion of them want to place me in inappropriate jobs. I get 60 mails a day sometimes. Its stupid. Ive thought of cancelling my linked-in account at times. That doesnt translate to penetration. Scala developers cannot be hired. Companies that are stuck in scala with millions in capital investment would MUCH RATHER be able to staff their shops, so they go back to Java. Because the scala language is too difficult to learn, the shortage of developers means new projects aren't started in scala and those with the ability either black box their old software and build on it with java or just start over in java. 

That is just business reality. Good or bad hardly matters. You can't take an average dev and train them in a couple weeks and have them reading the Scala SDK with comprehension and have them good at the language in a month. Businesses don't have time for their staff to spend six months getting good or the money to send them to expensive 3 week seminars. Hence no penetration. 

I realize my posts aren't popular and I am not making friends. So my motivation must be something else. I am not nearly bored enough to want to sit here answering for no reason and I have a quite excellent live with a wonderful family and no need to go troll anyone. Therefore my intentions must be honorable. They aren't given credit for being so but I am not surprised really. 

I would love Scala to replace java. On this trajectory it doesn't have a chance. 

-- Robert


On Sunday, February 12, 2017 at 5:58:27 PM UTC-6, Kevin Wright wrote:
“Scala has gained ZERO significant traction in the business world.”

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.


On 12 February 2017 at 21:54, kraythe <[hidden email]> wrote:
No its not. Scala has gained ZERO significant traction in the business world. It is not the next java. 

On Sunday, February 12, 2017 at 3:38:13 PM UTC-6, Vlad Patryshev wrote:
Oh, and Java of course is just perfect, compared to Scala.

Enjoy nulls and NPE, and mutability, and all the dumb frameworks designed by ignorants. You probably won't need generics; Java people just hate generics. They (Java people) are cheaper too.

The world is moving on; you decided to take a rest; it's okay, but don't expect others to join.

I wonder also what would be your opinion of Rust. Also worse than Java? I'm sure it is. No garbage collection. No Hibernate.

Thanks,
-Vlad

On Sun, Feb 12, 2017 at 9:16 AM, kraythe <[hidden email]> wrote:
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 scala-user+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" 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="pWtfDg3ECgAJ" 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.



--
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="pWtfDg3ECgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">br...@...

--
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.
Reply | Threaded
Open this post in threaded view
|

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

Rex Kerr-2
In reply to this post by kraythe
On Wed, Feb 15, 2017 at 10:32 PM, kraythe <[hidden email]> wrote:

Oh by all means be a mad scientist but realize this:
1. I have nothing to gain from this in either fame or fortune, so what is my motivation?  

Frustration is another possible motivator.
 
2. If you have a language that an experienced senior java programmer can't grasp in a couple weeks and be good at in 2 months or requires expensive training, then it will not get past those startups and little projects. It will never full scale penetrate like Java. If that is fine, then you consent to being an niche language. 

It will certainly slow adoption.  You can't predict the endpoint from this analysis because you're assuming "experienced senior java programmer" as the starting point.  But plenty of people aren't, and as time goes on the fraction will if anything decrease (if only because more people are coming in from JS and Python and such).
 
3. Major companies have dropped Scala because of point 2.

Indeed.  "Scala is not Java with better syntax" has caught some folks by surprise.  "Here, you can do things the old way, but we have this awesome other stuff that you have to think about in a whole new way" is, as you point out, not really compatible with short deadlines and exchangeable programmers.

But some companies seem okay with this.  I'm not in a position to know why, but you list some of the reasons yourself--maybe it's a longer-term project and they can afford to invest up front, or maybe they can get enough programmers who are experienced with Scala.  Or maybe they can scrupulously keep themselves to a "Java with better syntax" subset of the language.
 
4. Current companies that adopt Scala will hit point 2 and eventually have to make a decision of do they delay products and revenue or switch back. 

They may already have anticipated this, though.  If I had a project where the natural choice of technologies was some standard Java stack and I needed to have something done in three months, I'd probably try to hire Java developers and do it in Java unless I could hire already-trained talent.  (Actually, I'd probably quit and say "I don't like working on projects on that timescale."  But I digress.)  But if I had a year, I'd expect to do a lot of training up front (lots of pair coding and code reviews, plus plenty of time on tutorials and the Scala online courses and so on) and catch up in the remaining, I don't know, 8 months or so.  I would feel confident doing this *except* if I hired expert Java devs who weren't inclined to learn new ways of thinking.

But I haven't done it, so my impressions should be taken with appropriate levels of salt.

5. After years of being out there Scala has meagre penetration, and still bad tooling. 

Meteoric rises are fun to watch, but Scala is nonetheless gaining traction rather quickly compared to other languages that have been around for a while.  I'm not aware of any language that was adopted as widely and as quickly as Java, but that doesn't mean that Java is always going to be vastly dominant.  And Java tooling took a long time to get as good as it is now.  Really *nothing* is as good as Java tooling.  It's a competitive advantage that Java will keep for a good while (and I really mean this--it *is* a serious advantage that helps compensate for a variety of other flaws), but probably not forever.

  --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.
Reply | Threaded
Open this post in threaded view
|

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

Seth Tisue-3
In reply to this post by jez prime
On Thu, Feb 16, 2017 at 11:52 AM, jez prime <[hidden email]> wrote:
The people I've seen having most problems learning Scala (or the functional stuff in Java 8) are mainly the most experienced Java devs on the team. In other words it's their experience working in Java that holds them back most. The ones who took it on faster were more junior devs who hadn't already shaped a mental model based purely on OO and the Java language. So there is room for evolution in thinking. 

This! +1

--
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.
Reply | Threaded
Open this post in threaded view
|

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

Raoul Duke
Or, you know, those experienced devs who hatecwaiting for a bloody compiler to ever finish...

On Feb 16, 2017 1:39 PM, "Seth Tisue" <[hidden email]> wrote:
On Thu, Feb 16, 2017 at 11:52 AM, jez prime <[hidden email]> wrote:
The people I've seen having most problems learning Scala (or the functional stuff in Java 8) are mainly the most experienced Java devs on the team. In other words it's their experience working in Java that holds them back most. The ones who took it on faster were more junior devs who hadn't already shaped a mental model based purely on OO and the Java language. So there is room for evolution in thinking. 

This! +1

--
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.
Reply | Threaded
Open this post in threaded view
|

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

Dennis Haupt
i usually watch a short youtube video every time i do a clean compile. still getting paid the same. wouldn't call that a disadvantage :D

2017-02-16 23:24 GMT+01:00 Raoul Duke <[hidden email]>:
Or, you know, those experienced devs who hatecwaiting for a bloody compiler to ever finish...


On Feb 16, 2017 1:39 PM, "Seth Tisue" <[hidden email]> wrote:
On Thu, Feb 16, 2017 at 11:52 AM, jez prime <[hidden email]> wrote:
The people I've seen having most problems learning Scala (or the functional stuff in Java 8) are mainly the most experienced Java devs on the team. In other words it's their experience working in Java that holds them back most. The ones who took it on faster were more junior devs who hadn't already shaped a mental model based purely on OO and the Java language. So there is room for evolution in thinking. 

This! +1

--
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.
Reply | Threaded
Open this post in threaded view
|

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

Oliver Ruebenacker
https://xkcd.com/303/

On Thu, Feb 16, 2017 at 5:28 PM, Dennis Haupt <[hidden email]> wrote:
i usually watch a short youtube video every time i do a clean compile. still getting paid the same. wouldn't call that a disadvantage :D

2017-02-16 23:24 GMT+01:00 Raoul Duke <[hidden email]>:
Or, you know, those experienced devs who hatecwaiting for a bloody compiler to ever finish...


On Feb 16, 2017 1:39 PM, "Seth Tisue" <[hidden email]> wrote:
On Thu, Feb 16, 2017 at 11:52 AM, jez prime <[hidden email]> wrote:
The people I've seen having most problems learning Scala (or the functional stuff in Java 8) are mainly the most experienced Java devs on the team. In other words it's their experience working in Java that holds them back most. The ones who took it on faster were more junior devs who hadn't already shaped a mental model based purely on OO and the Java language. So there is room for evolution in thinking. 

This! +1

--
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.



--
Oliver Ruebenacker
Senior Software Engineer, Diabetes Portal, Broad Institute

--
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.
Reply | Threaded
Open this post in threaded view
|

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

Raoul Duke
In reply to this post by Dennis Haupt
i appreciate the humo(u)r but still prefer fluid trains of thought to making youtube earn ad revenue :-)

not that any other functional-supporting language ecosystem (haskell, ocaml, f#, flow, typescript, you name it) is overall better really.

also, i am old and so is my laptop cpu (tho does have ssd) so i am particularly hard to please.

and of course have no kegs to stand on sincrme I've never made any proframming language, outside of college, let alone one used by zillions of demanding industry folks!!!!

c'est la vie.

On Feb 16, 2017 2:28 PM, "Dennis Haupt" <[hidden email]> wrote:
i usually watch a short youtube video every time i do a clean compile. still getting paid the same. wouldn't call that a disadvantage :D

2017-02-16 23:24 GMT+01:00 Raoul Duke <[hidden email]>:
Or, you know, those experienced devs who hatecwaiting for a bloody compiler to ever finish...


On Feb 16, 2017 1:39 PM, "Seth Tisue" <[hidden email]> wrote:
On Thu, Feb 16, 2017 at 11:52 AM, jez prime <[hidden email]> wrote:
The people I've seen having most problems learning Scala (or the functional stuff in Java 8) are mainly the most experienced Java devs on the team. In other words it's their experience working in Java that holds them back most. The ones who took it on faster were more junior devs who hadn't already shaped a mental model based purely on OO and the Java language. So there is room for evolution in thinking. 

This! +1

--
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.
Reply | Threaded
Open this post in threaded view
|

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

Siddhartha Gadgil
In reply to this post by kraythe
In spite of (or because?) my experience is atypical, here it is regarding implicits. 

* I overused implicits all over the place at first but learnt - from the community and official documentation - that they come in different flavours, and what to use and what not.
* Implicit classes for extension methods are a nice syntactic convenience. Logically one can always just use functions, but these are safe, elegant and worth using.
* The deepest use of implicits is as functions from Types to Objects, using implicit resolutions. This is wonderful stuff, making scala having some elements of a dependently typed language, and I use this a lot both directly and indirectly. The only catch is that these are effectively modelling relations, not functions, and  the compiler has to figure that the particular relation is a function (at least for a specific argument).
* Implicit objects can also be used for configuration.
* What one can justify ranting against is _implicit conversions_, but as I mentioned I constantly get the message that one should avoid them - the latest being when switching to 2.12.1, the compiler suggested using extension methods for Java Conversions.
* The one case where I have seen very well justified use of implicit conversions (rather than classes) is when using _literals_, such as in Spire.
 
regards,
Siddhartha


On Sunday, February 12, 2017 at 10:46:49 PM UTC+5:30, kraythe wrote:
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.
Reply | Threaded
Open this post in threaded view
|

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

Seyed H. HAERI (Hossein)
Hi Siddhartha,

This is going to be a change of topic I guess. But, I'm too lazy to
spawn a new thread. So, I'm going to ask it here:

> * The deepest use of implicits is as functions from Types to Objects, using implicit resolutions. This is wonderful stuff, making scala having some elements of a dependently typed language,

Would you mind expanding on that a bit? My understanding has always
been that its in the other direction, i.e., dependently typed
programming gives objects individual type identities. For example, 1
has a different type (representation) than 2 -- at the same time that
they might still be regarded as integers. This way, it's from objects
to types.

> The only catch is that these are effectively modelling relations, not functions, and  the compiler has to figure that the particular relation is a function (at least for a specific argument).

I would also be interested in reading more about this one. (I do know
the difference between relations and functions.) Relations between
what and what?

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.
Reply | Threaded
Open this post in threaded view
|

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

Bardur Arantsson
On 2017-02-18 10:55, Seyed H. HAERI (Hossein) wrote:
> Hi Siddhartha,
>
> This is going to be a change of topic I guess. But, I'm too lazy to
> spawn a new thread. So, I'm going to ask it here:
>
>> * The deepest use of implicits is as functions from Types to Objects, using implicit resolutions.
>> This is wonderful stuff, making scala having some elements of a
dependently typed language,
>
> Would you mind expanding on that a bit? My understanding has always
> been that its in the other direction, i.e., dependently typed
> programming gives objects individual type identities. For example, 1
> has a different type (representation) than 2 -- at the same time that
> they might still be regarded as integers. This way, it's from objects
> to types.
>

Unless something changes drastically soon, the whole Dependent Types in
Scala is a red herring for all practical purposes. Encoding DTs in a
language not meant for it is an absolutely horrible experience -- Scala
and Haskell alike. Just a) look at the implementation of Shapeless and
b) try to use Shapeless for... anything[1]. Usability is, well, let's
just say "less than stellar". This is in large part due to the encodings
which rely on implicit conversions to fire all over the place... and
when they don't, you're left scratching your head as to with your
"simple" code doesn't compile like the examples do.

Don't get me wrong, Shapeless (and the like) are *engineering* marvels
that show that incredible things are possible, but it *really* shows
(ergonomically) that most of that power is accidental. Much like C++
templates.

(Hopefully Scala macros can be rescued to give us that much needed
metaprogramming power without the obtuseness of type-level programming
in Scala.)

[1] People have managed, but it's a *lot* of effort compared to what it
could be.

Regards,

--
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.
Reply | Threaded
Open this post in threaded view
|

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

Roland Kuhn

18 feb. 2017 kl. 11:15 skrev Bardur Arantsson <[hidden email]>:

On 2017-02-18 10:55, Seyed H. HAERI (Hossein) wrote:
Hi Siddhartha,

This is going to be a change of topic I guess. But, I'm too lazy to
spawn a new thread. So, I'm going to ask it here:

* The deepest use of implicits is as functions from Types to Objects, using implicit resolutions.
This is wonderful stuff, making scala having some elements of a
dependently typed language,

Would you mind expanding on that a bit? My understanding has always
been that its in the other direction, i.e., dependently typed
programming gives objects individual type identities. For example, 1
has a different type (representation) than 2 -- at the same time that
they might still be regarded as integers. This way, it's from objects
to types.


Unless something changes drastically soon, the whole Dependent Types in
Scala is a red herring for all practical purposes. Encoding DTs in a
language not meant for it is an absolutely horrible experience -- Scala
and Haskell alike. Just a) look at the implementation of Shapeless and
b) try to use Shapeless for... anything[1]. Usability is, well, let's
just say "less than stellar". This is in large part due to the encodings
which rely on implicit conversions

Please, everyone, be precise: this has nothing to do with implicit conversions, which are universally acknowledged as an anti-pattern. Shapeless’ implementation is almost exclusively based on implicit arguments, and it is a beautiful illustration of the Curry-Howard isomorphism—which thankfully the users of the library do not need to know or care about in order to use it.

to fire all over the place... and
when they don't, you're left scratching your head as to with your
"simple" code doesn't compile like the examples do.

This is indeed the main problem, I also recently ran into this while implementing session types for Akka Typed, with detailed effect tracking. My preliminary conclusion is that it will be necessary to write a macro whose sole purpose is to customise the error reporting in a domain-specific fashion (i.e. printing a nice message that you forgot to send that message of type A at step 3 in the protocol).

Don't get me wrong, Shapeless (and the like) are *engineering* marvels
that show that incredible things are possible, but it *really* shows
(ergonomically) that most of that power is accidental. Much like C++
templates.

(Hopefully Scala macros can be rescued to give us that much needed
metaprogramming power without the obtuseness of type-level programming
in Scala.)

Hmm, that may sound promising at first, but since types are propositions and only programs are proofs, I fear that such an approach would be wide open for the introduction of unsoundness in the usage of the type system. As you say, the proper solution is to add dependent types.

Regards,

Roland


[1] People have managed, but it's a *lot* of effort compared to what it
could be.

Regards,

-- 
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.
Reply | Threaded
Open this post in threaded view
|

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

Bardur Arantsson
On 2017-02-18 11:45, Roland Kuhn wrote:
>
> Hmm, that may sound promising at first, but since types are propositions
> and only programs are proofs, I fear that such an approach would be wide
> open for the introduction of unsoundness in the usage of the type
> system.

Oh, certainly, but luckily the JVM's (mostly) got our backs with
ClassCastException and similar. Granted, it'd be better to have full
compile-time verification of the soundness of macro implementations, but
as they say... "it's a highly non-trivial problem".

At least macros could hopefully be reasonably understandable
implementation-wise and debugged over time to become "good enough".

> As you say, the proper solution is to add dependent types.
>

I'm not sure "just add dependent types" is an answer that applies to
Scala. I think it mostly has to be *designed* into the language from the
start (e.g. Idris, Agda, etc.) or you might end up with a
Frankenlanguage. It's just not something you can necessarily add as an
afterthought.

(Though, actually, Haskell is undergoing the addition of full-on
Dependent Typing at the moment. AFAIUI it's a ~decade-long effort that
just gotten underway in the last couple of years or so. I guess we'll
see how that turns out. At least there's a lot less "friction" when
adding DTs to a Haskell-like language.)

Regards,

--
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.
Reply | Threaded
Open this post in threaded view
|

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

Roland Kuhn

> 18 feb. 2017 kl. 11:52 skrev Bardur Arantsson <[hidden email]>:
>
> On 2017-02-18 11:45, Roland Kuhn wrote:
>>
>> Hmm, that may sound promising at first, but since types are propositions
>> and only programs are proofs, I fear that such an approach would be wide
>> open for the introduction of unsoundness in the usage of the type
>> system.
>
> Oh, certainly, but luckily the JVM's (mostly) got our backs with
> ClassCastException and similar. Granted, it'd be better to have full
> compile-time verification of the soundness of macro implementations, but
> as they say... "it's a highly non-trivial problem".
>
> At least macros could hopefully be reasonably understandable
> implementation-wise and debugged over time to become "good enough".
>
>> As you say, the proper solution is to add dependent types.
>>
>
> I'm not sure "just add dependent types" is an answer that applies to
> Scala. I think it mostly has to be *designed* into the language from the
> start (e.g. Idris, Agda, etc.) or you might end up with a
> Frankenlanguage. It's just not something you can necessarily add as an
> afterthought.

Ah, yes, sorry for my sloppy language, we mean the same thing: if you want dependent typing, then the language needs to have first-class dependent types.

Regards,

Roland

> (Though, actually, Haskell is undergoing the addition of full-on
> Dependent Typing at the moment. AFAIUI it's a ~decade-long effort that
> just gotten underway in the last couple of years or so. I guess we'll
> see how that turns out. At least there's a lot less "friction" when
> adding DTs to a Haskell-like language.)
>
> Regards,
>
> --
> 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.
Reply | Threaded
Open this post in threaded view
|

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

Seyed H. HAERI (Hossein)
+1

Just because (admittedly accidental) dependent types of Scala are
powerful enough to make great tools like Shapeless, it doesn't mean
they are the right tool for the purpose. In fact, I too think that's a
misuse of power. :D Although, I'm not sure what the proper alternative
would be with what currently is in Scala. Macros are the first to come
to mind. Not sure how they'll end up though. They are taking the
Template Haskell flavour which gets runtime stuff into the game and I
just don't like that. I'd say metaprogramming is compile-time only for
its for instructing compilation after all. Furthermore, Generic
Haskell is known to cause incredible runtime overhead with the
compiler ingeniously leaving some of the metaprogramming resolution to
the runtime. Sorry I have nothing constructive to offer here...

On 18 February 2017 at 12:03, Roland Kuhn <[hidden email]> wrote:

>
>> 18 feb. 2017 kl. 11:52 skrev Bardur Arantsson <[hidden email]>:
>>
>> On 2017-02-18 11:45, Roland Kuhn wrote:
>>>
>>> Hmm, that may sound promising at first, but since types are propositions
>>> and only programs are proofs, I fear that such an approach would be wide
>>> open for the introduction of unsoundness in the usage of the type
>>> system.
>>
>> Oh, certainly, but luckily the JVM's (mostly) got our backs with
>> ClassCastException and similar. Granted, it'd be better to have full
>> compile-time verification of the soundness of macro implementations, but
>> as they say... "it's a highly non-trivial problem".
>>
>> At least macros could hopefully be reasonably understandable
>> implementation-wise and debugged over time to become "good enough".
>>
>>> As you say, the proper solution is to add dependent types.
>>>
>>
>> I'm not sure "just add dependent types" is an answer that applies to
>> Scala. I think it mostly has to be *designed* into the language from the
>> start (e.g. Idris, Agda, etc.) or you might end up with a
>> Frankenlanguage. It's just not something you can necessarily add as an
>> afterthought.
>
> Ah, yes, sorry for my sloppy language, we mean the same thing: if you want dependent typing, then the language needs to have first-class dependent types.
>
> Regards,
>
> Roland
>
>> (Though, actually, Haskell is undergoing the addition of full-on
>> Dependent Typing at the moment. AFAIUI it's a ~decade-long effort that
>> just gotten underway in the last couple of years or so. I guess we'll
>> see how that turns out. At least there's a lot less "friction" when
>> adding DTs to a Haskell-like language.)
>>
>> Regards,
>>
>> --
>> 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.



--
--------------------------------------------------------------------------------------------------------------

Seyed H. HAERI (Hossein), Dr.

Post-Doctoral Research Fellow
Department of Computing Science and Engineering
Catholic University of Louvain
Louvain-la-Neuve, Belgium

ACCU - Professionalism in programming - http://www.accu.org/
--------------------------------------------------------------------------------------------------------------

--
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.
Reply | Threaded
Open this post in threaded view
|

type-level programming, was: [scala-user] Why I and my company have moved away from Scala. An honest critique.

Roland Kuhn
Hi Seyed,

could you outline what makes you say that macros “get runtime stuff into the game”? Macros are fully evaluated at compile-time—if they choose to emit a computation to be evaluated at runtime is up to them.

Regards,

Roland

> 18 feb. 2017 kl. 12:58 skrev Seyed H. HAERI (Hossein) <[hidden email]>:
>
> +1
>
> Just because (admittedly accidental) dependent types of Scala are
> powerful enough to make great tools like Shapeless, it doesn't mean
> they are the right tool for the purpose. In fact, I too think that's a
> misuse of power. :D Although, I'm not sure what the proper alternative
> would be with what currently is in Scala. Macros are the first to come
> to mind. Not sure how they'll end up though. They are taking the
> Template Haskell flavour which gets runtime stuff into the game and I
> just don't like that. I'd say metaprogramming is compile-time only for
> its for instructing compilation after all. Furthermore, Generic
> Haskell is known to cause incredible runtime overhead with the
> compiler ingeniously leaving some of the metaprogramming resolution to
> the runtime. Sorry I have nothing constructive to offer here...
>
> On 18 February 2017 at 12:03, Roland Kuhn <[hidden email]> wrote:
>>
>>> 18 feb. 2017 kl. 11:52 skrev Bardur Arantsson <[hidden email]>:
>>>
>>> On 2017-02-18 11:45, Roland Kuhn wrote:
>>>>
>>>> Hmm, that may sound promising at first, but since types are propositions
>>>> and only programs are proofs, I fear that such an approach would be wide
>>>> open for the introduction of unsoundness in the usage of the type
>>>> system.
>>>
>>> Oh, certainly, but luckily the JVM's (mostly) got our backs with
>>> ClassCastException and similar. Granted, it'd be better to have full
>>> compile-time verification of the soundness of macro implementations, but
>>> as they say... "it's a highly non-trivial problem".
>>>
>>> At least macros could hopefully be reasonably understandable
>>> implementation-wise and debugged over time to become "good enough".
>>>
>>>> As you say, the proper solution is to add dependent types.
>>>>
>>>
>>> I'm not sure "just add dependent types" is an answer that applies to
>>> Scala. I think it mostly has to be *designed* into the language from the
>>> start (e.g. Idris, Agda, etc.) or you might end up with a
>>> Frankenlanguage. It's just not something you can necessarily add as an
>>> afterthought.
>>
>> Ah, yes, sorry for my sloppy language, we mean the same thing: if you want dependent typing, then the language needs to have first-class dependent types.
>>
>> Regards,
>>
>> Roland
>>
>>> (Though, actually, Haskell is undergoing the addition of full-on
>>> Dependent Typing at the moment. AFAIUI it's a ~decade-long effort that
>>> just gotten underway in the last couple of years or so. I guess we'll
>>> see how that turns out. At least there's a lot less "friction" when
>>> adding DTs to a Haskell-like language.)
>>>
>>> Regards,
>>>
>>> --
>>> 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.
>
>
>
> --
> --------------------------------------------------------------------------------------------------------------
>
> Seyed H. HAERI (Hossein), Dr.
>
> Post-Doctoral Research Fellow
> Department of Computing Science and Engineering
> Catholic University of Louvain
> Louvain-la-Neuve, Belgium
>
> ACCU - Professionalism in programming - http://www.accu.org/
> --------------------------------------------------------------------------------------------------------------
>
> --
> 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.
Reply | Threaded
Open this post in threaded view
|

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

Seyed H. HAERI (Hossein)
Hi Roland,

Sorry for being late on the response. Didn't mean to be impolite; I'm
a but unwell these days.

> could you outline what makes you say that macros “get runtime stuff into the game”? Macros are fully evaluated at compile-time—if they choose to emit a computation to be evaluated at runtime is up to them.

Of course, if they choose to do something at runtime, that's their
choice. But, that wasn't my point. I had two points:

Firstly, I don't have runtime figures for the consequences of using
Scala macros. Neither am I aware of any empirical study on that. Nor
have I taken a look into the macro engine of the Scala compilers. My
impression though is that the Scala macros are highly influenced by
the quasi-quoting culture of Template Haskell. (Please correct me if
I'm wrong.) There, the compiler is known not to be able to evade
certain sorts of splicing at runtime -- causing unpredictably high
runtime overhead. The Haskell 12 talk of Michael Adams [1] should be
your good starting point.

Secondly, with Scala choosing every object to be a reference, there
essentially is no clear cut between compile-time and runtime. This is
because every function call is then virtual and the programmer cannot
ever rely on the runtime cost being zero. I know the folklore in this
community is the other way around. But, I'm afraid that's pure
misconception. So, it bothers me that I need to come back to this from
time to time. Maybe exemplifying C++ here can help you get the point.
In C++, when the programmer needs late-binding, they use pointers or
references. Otherwise, no runtime action will take place and even
wrong call-by-value will cause slicing.

As a matter of fact, pure functional programming also has similar
drawbacks on runtime overheads. See the WGP12's closing discussion for
real-world Haskell users talking on the matter [2]. So, more into this
on the Template Haskell quasi-splicing culture penetrating into
Scala...

Having said all that, I am not advising Scala to take the
metaprogramming approach of C++. That's completely accidental and too
much of a pain. On the other hand, the Template Haskell semantics is
so well-defined. However, from what I have witnessed, the latter is
too much of an unleashed power that I am not sure about the real
usefulness of. I'm afraid I don't have an opinion on what the best bet
here might be.

HTH,
--Hossein

[1] http://www.youtube.com/watch?v=8bIBTxHgptQ

[2] https://www.youtube.com/watch?v=fqkf_T4PrmA

--
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.
Reply | Threaded
Open this post in threaded view
|

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

Roland Kuhn
Thanks for your answer, Seyed, and don’t worry about the delay: it will take me a few days to look into Template Haskell before I can formulate an informed response.

Regards,

Roland

> 22 feb. 2017 kl. 13:25 skrev Seyed H. HAERI (Hossein) <[hidden email]>:
>
> Hi Roland,
>
> Sorry for being late on the response. Didn't mean to be impolite; I'm
> a but unwell these days.
>
>> could you outline what makes you say that macros “get runtime stuff into the game”? Macros are fully evaluated at compile-time—if they choose to emit a computation to be evaluated at runtime is up to them.
>
> Of course, if they choose to do something at runtime, that's their
> choice. But, that wasn't my point. I had two points:
>
> Firstly, I don't have runtime figures for the consequences of using
> Scala macros. Neither am I aware of any empirical study on that. Nor
> have I taken a look into the macro engine of the Scala compilers. My
> impression though is that the Scala macros are highly influenced by
> the quasi-quoting culture of Template Haskell. (Please correct me if
> I'm wrong.) There, the compiler is known not to be able to evade
> certain sorts of splicing at runtime -- causing unpredictably high
> runtime overhead. The Haskell 12 talk of Michael Adams [1] should be
> your good starting point.
>
> Secondly, with Scala choosing every object to be a reference, there
> essentially is no clear cut between compile-time and runtime. This is
> because every function call is then virtual and the programmer cannot
> ever rely on the runtime cost being zero. I know the folklore in this
> community is the other way around. But, I'm afraid that's pure
> misconception. So, it bothers me that I need to come back to this from
> time to time. Maybe exemplifying C++ here can help you get the point.
> In C++, when the programmer needs late-binding, they use pointers or
> references. Otherwise, no runtime action will take place and even
> wrong call-by-value will cause slicing.
>
> As a matter of fact, pure functional programming also has similar
> drawbacks on runtime overheads. See the WGP12's closing discussion for
> real-world Haskell users talking on the matter [2]. So, more into this
> on the Template Haskell quasi-splicing culture penetrating into
> Scala...
>
> Having said all that, I am not advising Scala to take the
> metaprogramming approach of C++. That's completely accidental and too
> much of a pain. On the other hand, the Template Haskell semantics is
> so well-defined. However, from what I have witnessed, the latter is
> too much of an unleashed power that I am not sure about the real
> usefulness of. I'm afraid I don't have an opinion on what the best bet
> here might be.
>
> HTH,
> --Hossein
>
> [1] http://www.youtube.com/watch?v=8bIBTxHgptQ
>
> [2] https://www.youtube.com/watch?v=fqkf_T4PrmA
>
> --
> 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.
Reply | Threaded
Open this post in threaded view
|

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

oss.mlists
In reply to this post by kraythe
Why implicit conversions are not listed in ScalaDoc just like subtyping? They should be in a section just below subtyping. At least those defined directly in type companion object. But if some generic one applies it should be there as well. I have to look to Scala source code to find out that Option type can be used where Iterable is required.

Is it possible in any IDE to list all available implicit instances for a scope I have cursor in (or highlighted scope)?

One reason why nobody is confused by subtyping, outside of more a decade of familiarity and having only one option to consider, is easy discoverability. In a sense implicit conversions are similar to subtyping because they enable type substitution through a different mechanism.

Just compare:

class MyType extends Iterable { ??? }

object MyType {
  implicit def toIterable(x: MyType): Iterable = ???
}

As a side note, for those with PhDs, some call it coercive subtyping:

"The basic idea of coercive subtyping is that subtyping is modelled as an abbreviation mechanism: A is a subtype of B,
if there is a unique coercion c from A to B, written as A <c B. Then, if a hole in a context requires an object of type B, it
is legal to supply an object a of type A – it is equivalent to supplying the object c(a). This simple idea, when used with
the rich type structures in type theories with inductive types, provides a powerful and general subtyping mechanism. It
subsumes injective subtyping, projective subtyping and structural subtyping."

http://www.cs.rhul.ac.uk/~zhaohui/Subtyping12J.pdf
http://www.cs.rhul.ac.uk/~zhaohui/subtyping.html

And mad scientists may like this one:)
http://www.cs.cmu.edu/~neelk/cattheodesign.pdf

Petr

--
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.
123456