Quantcast

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

Next Topic
 
classic Classic list List threaded Threaded
79 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dennis Haupt-2
implicits are statically typed - this was already mentioned. 
 
Gesendet: Dienstag, 14. Februar 2017 um 16:35 Uhr
Von: "Seyed H. HAERI (Hossein)" <[hidden email]>
An: Kein Empfänger
Cc: scala-user <[hidden email]>
Betreff: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.
Dear Robert,

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

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

Seyed H. HAERI (Hossein)
In reply to this post by Dennis Haupt-2
Maybe you're right Dennis and I simply haven't still understood
implicits. :p But, did you ever had to simulate lightweight family
polymorphism in Scala? I suspect not. Because, me personally aside,
doing that is known in the PL community to be next-to-impossible for a
language supporting only family polymorphism. See the nice work of
Madsen and Ernst [1], for example.

Cheers,
--Hossein

[1] A. B. Madsen and E. Ernst, Revisiting Parametric Types and Virtual
Classes, Obj., Models, Components, Patterns, 48th Int. Conf. Proc. (J.
Vitek, ed.), Lect. Notes in Comp. Sci., vol. 6141, Springer, June
2010, pp. 233--252.

On 14 February 2017 at 16:51, Dennis Haupt <[hidden email]> wrote:

> i do not share this opinion. i never had a problem with understanding
> implicits once i understood the concept (unless it was a code puzzle
> intended to confuse)
>
> Gesendet: Dienstag, 14. Februar 2017 um 16:35 Uhr
> Von: "Seyed H. HAERI (Hossein)" <[hidden email]>
> An: Kein Empfänger
> Cc: scala-user <[hidden email]>
> Betreff: Re: [scala-user] Why I and my company have moved away from Scala.
> An honest critique.
> Dear Robert,
>
> 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.



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

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
|  
Report Content as Inappropriate

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

Seyed H. HAERI (Hossein)
In reply to this post by Dennis Haupt-2
Late-binding and static typing can be orthogonal. My hunch is that
Robert meant the former and he simply didn't have the terminology. (No
offence meant Robert.)

On 14 February 2017 at 16:58, Dennis Haupt <[hidden email]> wrote:

> implicits are statically typed - this was already mentioned.
>
> Gesendet: Dienstag, 14. Februar 2017 um 16:35 Uhr
> Von: "Seyed H. HAERI (Hossein)" <[hidden email]>
> An: Kein Empfänger
> Cc: scala-user <[hidden email]>
> Betreff: Re: [scala-user] Why I and my company have moved away from Scala.
> An honest critique.
> Dear Robert,
>
> 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.



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

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
|  
Report Content as Inappropriate

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

Jasper-M
In reply to this post by Seyed H. HAERI (Hossein)
Hossein,

I'm sorry but you are very much mistaken. Implicits are 100% compile time statically checked concepts.
The point being made by Robert, for quite a few years now, is that "Scala will never penetrate the business world" like Java, because of the magical things that happen with implicits. The irony here is that in basically all popular Java frameworks a lot of the magical stuff happens completely at runtime with reflection. In Scala every magical thing happens at compile time and is statically checked by the compiler, unless you are using runtime reflection but almost nobody does that in Scala.

I can agree that if implicit conversions are used excessively things can get out of hand. That's why there already has been an effort to make it more difficult to define implicit conversions without knowing the consequences. Perhaps it should be made even more difficult.

Stating that Scala would be a great language, if only it did not have this, this, and this concept, but would have this, this and this new keyword, is like saying "ice cream is the best dessert in the whole world, but as long as it's sweet and cold it will be a niche dessert for all eternity".

Robert's communication has always been pretty aggressive on this mailing list. That might not have been his intention, but it is the case either way. And in spite of that most community members have always gone to great lengths to help him out and go into discussions and have tried their best to be polite. Yet every counter-argument seems be received as a personal attack or flame against him. It's hard not to flame a person and at the same time help him or have a healthy discussion if that means not disagreeing at all.


Kind regards,
Jasper

Op dinsdag 14 februari 2017 16:35:55 UTC+1 schreef Hossein:
Dear Robert,

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

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

Kris Nuttycombe-3
Among long-time users of Scala, you'll find something interesting with respect to their use of implicits - that is, that long-time users barely remember that implicit conversions exist, except insofar as implicit classes are used as a mechanism to provide extension methods, frequently in combination with the "implicit typeclass" pattern. We forget that in the broader Scala world, people still use direct implicit type conversions to "magically" transform a value of an unrelated source type to a target type that is used directly. We've forgotten about the fact that some people use *stateful* implicit values to control how their program functions. We've forgotten these antipatterns because we learned that they're catastrophically bad ideas nearly a decade ago, and have abandoned their use ever since. 

The problem is that for many, these inappropriate uses of implicits are their first introduction to the concept, and consequently they properly react in horror at the whole feature, without realizing the power of their principled use. If one was able to go back in time, I think one might choose to make implicit classes a language feature, and promote the use of (stateless) implicit parameters, but would otherwise eliminate implicit conversions from the language.

All that being said, many of Robert's complaints seem somewhat disingenuous to me. He's clearly upset about Scala, but at the same time I have to wonder whether he's ever taken the opportunity to look at any Scala codebase other than his own. The (purely) functional Scala way of doing things can certainly appear alien, but I have yet to find anyone who, after having the power of real compositionality demonstrated to them, wouldn't concede that this approach is really the correct one for at least some people.

Kris



On Tue, Feb 14, 2017 at 9:08 AM, Jasper-M <[hidden email]> wrote:
Hossein,

I'm sorry but you are very much mistaken. Implicits are 100% compile time statically checked concepts.
The point being made by Robert, for quite a few years now, is that "Scala will never penetrate the business world" like Java, because of the magical things that happen with implicits. The irony here is that in basically all popular Java frameworks a lot of the magical stuff happens completely at runtime with reflection. In Scala every magical thing happens at compile time and is statically checked by the compiler, unless you are using runtime reflection but almost nobody does that in Scala.

I can agree that if implicit conversions are used excessively things can get out of hand. That's why there already has been an effort to make it more difficult to define implicit conversions without knowing the consequences. Perhaps it should be made even more difficult.

Stating that Scala would be a great language, if only it did not have this, this, and this concept, but would have this, this and this new keyword, is like saying "ice cream is the best dessert in the whole world, but as long as it's sweet and cold it will be a niche dessert for all eternity".

Robert's communication has always been pretty aggressive on this mailing list. That might not have been his intention, but it is the case either way. And in spite of that most community members have always gone to great lengths to help him out and go into discussions and have tried their best to be polite. Yet every counter-argument seems be received as a personal attack or flame against him. It's hard not to flame a person and at the same time help him or have a healthy discussion if that means not disagreeing at all.


Kind regards,
Jasper

Op dinsdag 14 februari 2017 16:35:55 UTC+1 schreef Hossein:
Dear Robert,

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

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

Adriaan Moors-7
Thanks, Kris, and everyone else for sharing your thoughtful feedback.

The point about antipatterns is an important one. All languages have those, and all language communities acquire cultural knowledge about how to avoid them. It's up to us (the creators and the community together) to document them and share the wisdom with new members of the community. As the creators, we are also always looking for ways to have the language itself guide you away from the antipatterns, where possible. 

I believe Scala does a good job at shielding you from many existing antipatterns, but implicits (and their interaction with type inference, which may look like magic, even though it is deterministic) are a harder nut to crack in terms of finding a good balance in the (new) user experience and expressive power.

I also would like to reiterate that we value everyone's opinion (that includes criticism, obviously), and we take all feedback to heart. I prefer the actionable kind of feedback, though (I'm not about to give up being a mad scientist ;-)). We care deeply about the productivity of all Scala programmers out there, and are dedicated to improving your experience with Scala in every release.

cheers
adriaan

Scala team lead at Lightbend


On Tue, Feb 14, 2017 at 9:01 AM Kris Nuttycombe <[hidden email]> wrote:
Among long-time users of Scala, you'll find something interesting with respect to their use of implicits - that is, that long-time users barely remember that implicit conversions exist, except insofar as implicit classes are used as a mechanism to provide extension methods, frequently in combination with the "implicit typeclass" pattern. We forget that in the broader Scala world, people still use direct implicit type conversions to "magically" transform a value of an unrelated source type to a target type that is used directly. We've forgotten about the fact that some people use *stateful* implicit values to control how their program functions. We've forgotten these antipatterns because we learned that they're catastrophically bad ideas nearly a decade ago, and have abandoned their use ever since. 

The problem is that for many, these inappropriate uses of implicits are their first introduction to the concept, and consequently they properly react in horror at the whole feature, without realizing the power of their principled use. If one was able to go back in time, I think one might choose to make implicit classes a language feature, and promote the use of (stateless) implicit parameters, but would otherwise eliminate implicit conversions from the language.

All that being said, many of Robert's complaints seem somewhat disingenuous to me. He's clearly upset about Scala, but at the same time I have to wonder whether he's ever taken the opportunity to look at any Scala codebase other than his own. The (purely) functional Scala way of doing things can certainly appear alien, but I have yet to find anyone who, after having the power of real compositionality demonstrated to them, wouldn't concede that this approach is really the correct one for at least some people.

Kris



On Tue, Feb 14, 2017 at 9:08 AM, Jasper-M <[hidden email]> wrote:
Hossein,

I'm sorry but you are very much mistaken. Implicits are 100% compile time statically checked concepts.
The point being made by Robert, for quite a few years now, is that "Scala will never penetrate the business world" like Java, because of the magical things that happen with implicits. The irony here is that in basically all popular Java frameworks a lot of the magical stuff happens completely at runtime with reflection. In Scala every magical thing happens at compile time and is statically checked by the compiler, unless you are using runtime reflection but almost nobody does that in Scala.

I can agree that if implicit conversions are used excessively things can get out of hand. That's why there already has been an effort to make it more difficult to define implicit conversions without knowing the consequences. Perhaps it should be made even more difficult.

Stating that Scala would be a great language, if only it did not have this, this, and this concept, but would have this, this and this new keyword, is like saying "ice cream is the best dessert in the whole world, but as long as it's sweet and cold it will be a niche dessert for all eternity".

Robert's communication has always been pretty aggressive on this mailing list. That might not have been his intention, but it is the case either way. And in spite of that most community members have always gone to great lengths to help him out and go into discussions and have tried their best to be polite. Yet every counter-argument seems be received as a personal attack or flame against him. It's hard not to flame a person and at the same time help him or have a healthy discussion if that means not disagreeing at all.


Kind regards,
Jasper

Op dinsdag 14 februari 2017 16:35:55 UTC+1 schreef Hossein:
Dear Robert,

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.

--
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
|  
Report Content as Inappropriate

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

Eduardo Cavalcanti
In reply to this post by kraythe
I can agree that if implicit conversions are used excessively things can get out of hand. That's why there already has been an effort to make it more difficult to define implicit conversions without knowing the consequences. Perhaps it should be made even more difficult.
 
Hi, I´ve been getting along with implicits very well. No big deal. Please do not restrict them. Scala evolution has been in very good track.
 
Cheers!
 

--
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
|  
Report Content as Inappropriate

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

Dennis Haupt-2
make it difficult: no, that would defeat the purpose
make the developer sign a contract where he states that he will to be blamed for misuse: yes
 
Gesendet: Dienstag, 14. Februar 2017 um 19:12 Uhr
Von: "Eduardo M. Cavalcanti" <[hidden email]>
An: scala-user <[hidden email]>
Betreff: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.
I can agree that if implicit conversions are used excessively things can get out of hand. That's why there already has been an effort to make it more difficult to define implicit conversions without knowing the consequences. Perhaps it should be made even more difficult.
 
Hi, I´ve been getting along with implicits very well. No big deal. Please do not restrict them. Scala evolution has been in very good track.
 
Cheers!
 

 

--
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
|  
Report Content as Inappropriate

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

Eduardo Cavalcanti
In reply to this post by Eduardo Cavalcanti
Agreed. That is how it already is. Isn´t it?
 
import language.implicitConversions
 
 




De: [hidden email]
Enviada: Terça-feira, 14 de Fevereiro de 2017 19:34
Para: [hidden email]
Assunto: Aw: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.

make it difficult: no, that would defeat the purpose
make the developer sign a contract where he states that he will to be blamed for misuse: yes
 
Gesendet: Dienstag, 14. Februar 2017 um 19:12 Uhr
Von: "Eduardo M. Cavalcanti" <[hidden email]>
An: scala-user <[hidden email]>
Betreff: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.
I can agree that if implicit conversions are used excessively things can get out of hand. That's why there already has been an effort to make it more difficult to define implicit conversions without knowing the consequences. Perhaps it should be made even more difficult.
 
Hi, I´ve been getting along with implicits very well. No big deal. Please do not restrict them. Scala evolution has been in very good track.
 
Cheers!
 

 

--
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+unsubscribe@....
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
|  
Report Content as Inappropriate

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

Kris Nuttycombe-3
In reply to this post by Dennis Haupt-2
I disagree, to a point. What we choose to make difficult in a language is as important as what we choose to make easy - what we choose to make difficult tends to shape the entire ecosystem of a language. Rust chooses to make concurrent nonlocal modification of memory difficult, and this has an effect upon their whole ecosystem; Haskell chooses to make uncontrolled IO difficult, and this has a profound effect. In both cases, the ecosystem of libraries is significantly better for these choices.

The feature-flag-based disabling of implicit conversions was one of the few parts of SIP-18 that I supported. I guess though that this thread is evidence that the SIP-18 changes to feature visibility didn't have that great of an effect. In retrospect that's predictable; when desirable features like higher-kinded types get lumped in with unsafe features like implicit conversions, it's hard for users to use this modularization as a guideline for which features to use and which not. I know that I face the same confusion when exploring the myriad of Haskell extensions; I always have to go read blog posts to find out whether an extension I'm considering using is widely considered desirable or not.

Kris

On Tue, Feb 14, 2017 at 11:34 AM, Dennis Haupt <[hidden email]> wrote:
make it difficult: no, that would defeat the purpose
make the developer sign a contract where he states that he will to be blamed for misuse: yes
 
Gesendet: Dienstag, 14. Februar 2017 um 19:12 Uhr
Von: "Eduardo M. Cavalcanti" <[hidden email]>
An: scala-user <[hidden email]>
Betreff: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.
I can agree that if implicit conversions are used excessively things can get out of hand. That's why there already has been an effort to make it more difficult to define implicit conversions without knowing the consequences. Perhaps it should be made even more difficult.
 
Hi, I´ve been getting along with implicits very well. No big deal. Please do not restrict them. Scala evolution has been in very good track.
 
Cheers!
 

 

--
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
|  
Report Content as Inappropriate

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

Seyed H. HAERI (Hossein)
In reply to this post by Jasper-M
Hi Jasper,

> I'm sorry but you are very much mistaken. Implicits are 100% compile time
> statically checked concepts.

Is an implicit not just like an ordinary object in that it enjoys late
binding? It is. Then, I'm afraid, they are not 100% compile-time. They
might have been if Scala had chosen to take a classes-as-families [1]
approach to family polymorphism. Right now, it's objects-as-families
-- like the original family polymorphism crafted by Ernst and all
those beautiful following works...

Cheers,
--Hossein

[1] P. Jolly, S. Drossopoulou, C. Anderson, and K. Ostermann, Simple
Dependent Types: Concord, Proc. 6th W. Formal Tech. Java-like Prog.,
June 2004, Tech. Rep. nr. NIII-R0426, Uni. Nijmegen.

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

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
|  
Report Content as Inappropriate

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

Seyed H. HAERI (Hossein)
In reply to this post by Kris Nuttycombe-3
Hi Kris,

I liked your response for collecting some of the anti-patterns related
to implicits. Has anyone ever done a comprehensive list of such
anti-patterns?

Cheers,
--Hossein

On 14 February 2017 at 18:01, Kris Nuttycombe <[hidden email]> wrote:

> Among long-time users of Scala, you'll find something interesting with
> respect to their use of implicits - that is, that long-time users barely
> remember that implicit conversions exist, except insofar as implicit classes
> are used as a mechanism to provide extension methods, frequently in
> combination with the "implicit typeclass" pattern. We forget that in the
> broader Scala world, people still use direct implicit type conversions to
> "magically" transform a value of an unrelated source type to a target type
> that is used directly. We've forgotten about the fact that some people use
> *stateful* implicit values to control how their program functions. We've
> forgotten these antipatterns because we learned that they're
> catastrophically bad ideas nearly a decade ago, and have abandoned their use
> ever since.
>
> The problem is that for many, these inappropriate uses of implicits are
> their first introduction to the concept, and consequently they properly
> react in horror at the whole feature, without realizing the power of their
> principled use. If one was able to go back in time, I think one might choose
> to make implicit classes a language feature, and promote the use of
> (stateless) implicit parameters, but would otherwise eliminate implicit
> conversions from the language.
>
> All that being said, many of Robert's complaints seem somewhat disingenuous
> to me. He's clearly upset about Scala, but at the same time I have to wonder
> whether he's ever taken the opportunity to look at any Scala codebase other
> than his own. The (purely) functional Scala way of doing things can
> certainly appear alien, but I have yet to find anyone who, after having the
> power of real compositionality demonstrated to them, wouldn't concede that
> this approach is really the correct one for at least some people.
>
> Kris
>
>
>
> On Tue, Feb 14, 2017 at 9:08 AM, Jasper-M <[hidden email]> wrote:
>>
>> Hossein,
>>
>> I'm sorry but you are very much mistaken. Implicits are 100% compile time
>> statically checked concepts.
>> The point being made by Robert, for quite a few years now, is that "Scala
>> will never penetrate the business world" like Java, because of the magical
>> things that happen with implicits. The irony here is that in basically all
>> popular Java frameworks a lot of the magical stuff happens completely at
>> runtime with reflection. In Scala every magical thing happens at compile
>> time and is statically checked by the compiler, unless you are using runtime
>> reflection but almost nobody does that in Scala.
>>
>> I can agree that if implicit conversions are used excessively things can
>> get out of hand. That's why there already has been an effort to make it more
>> difficult to define implicit conversions without knowing the consequences.
>> Perhaps it should be made even more difficult.
>>
>> Stating that Scala would be a great language, if only it did not have
>> this, this, and this concept, but would have this, this and this new
>> keyword, is like saying "ice cream is the best dessert in the whole world,
>> but as long as it's sweet and cold it will be a niche dessert for all
>> eternity".
>>
>> Robert's communication has always been pretty aggressive on this mailing
>> list. That might not have been his intention, but it is the case either way.
>> And in spite of that most community members have always gone to great
>> lengths to help him out and go into discussions and have tried their best to
>> be polite. Yet every counter-argument seems be received as a personal attack
>> or flame against him. It's hard not to flame a person and at the same time
>> help him or have a healthy discussion if that means not disagreeing at all.
>>
>>
>> Kind regards,
>> Jasper
>>
>> Op dinsdag 14 februari 2017 16:35:55 UTC+1 schreef Hossein:
>>>
>>> Dear Robert,
>>>
>>> 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.



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

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
|  
Report Content as Inappropriate

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

Adriaan Moors-7
In reply to this post by Seyed H. HAERI (Hossein)
I think what Jasper meant was that implicit resolution happens at compile time, and that the static type of the required implicit value directly determines the expression that will be evaluated to produce a value of that type (of course during run-time evaluation there's late binding, but that's orthogonal to implicit search). 

Implicit resolution provides the same kind of ad-hoc polymorphism as method overloading, where the static types of the arguments determine which method overload is chosen, or Haskell's type classes, where the instance is directly defined by the type class. Here's a paper we wrote on the equivalence between type classes and implicits: https://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf

cheers
adriaan



On Tue, Feb 14, 2017 at 2:58 PM Seyed H. HAERI (Hossein) <[hidden email]> wrote:
Hi Jasper,

> I'm sorry but you are very much mistaken. Implicits are 100% compile time
> statically checked concepts.

Is an implicit not just like an ordinary object in that it enjoys late
binding? It is. Then, I'm afraid, they are not 100% compile-time. They
might have been if Scala had chosen to take a classes-as-families [1]
approach to family polymorphism. Right now, it's objects-as-families
-- like the original family polymorphism crafted by Ernst and all
those beautiful following works...

Cheers,
--Hossein

[1] P. Jolly, S. Drossopoulou, C. Anderson, and K. Ostermann, Simple
Dependent Types: Concord, Proc. 6th W. Formal Tech. Java-like Prog.,
June 2004, Tech. Rep. nr. NIII-R0426, Uni. Nijmegen.

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

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
|  
Report Content as Inappropriate

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

Dennis Haupt-2
In reply to this post by Seyed H. HAERI (Hossein)
i don't know what late binding is, but i know all the magic happens at compile time. 
also: one of the criticisms was that scala is "too phd", but now i see the anti scala side argue using fancy expressions that i do not understand. just wanted to point that out because... contradiction :D
 
Gesendet: Dienstag, 14. Februar 2017 um 23:58 Uhr
Von: "Seyed H. HAERI (Hossein)" <[hidden email]>
An: Kein Empfänger
Cc: scala-user <[hidden email]>
Betreff: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.
Hi Jasper,

> I'm sorry but you are very much mistaken. Implicits are 100% compile time
> statically checked concepts.

Is an implicit not just like an ordinary object in that it enjoys late
binding? It is. Then, I'm afraid, they are not 100% compile-time. They
might have been if Scala had chosen to take a classes-as-families [1]
approach to family polymorphism. Right now, it's objects-as-families
-- like the original family polymorphism crafted by Ernst and all
those beautiful following works...

Cheers,
--Hossein

[1] P. Jolly, S. Drossopoulou, C. Anderson, and K. Ostermann, Simple
Dependent Types: Concord, Proc. 6th W. Formal Tech. Java-like Prog.,
June 2004, Tech. Rep. nr. NIII-R0426, Uni. Nijmegen.

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

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
|  
Report Content as Inappropriate

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

Adriaan Moors-7
Late binding is also called virtual dispatch. When you call a method, you don't know which subclass implementation of the method you'll get. All you know is that it's there (thanks to static typing ;-)).

I think of the type system as an approximation of what your program could do when it runs. Late binding introduces the needed slack between the type checker's rigor and the run-time environment's "open-endedness".

On Tue, Feb 14, 2017 at 3:09 PM Dennis Haupt <[hidden email]> wrote:
i don't know what late binding is, but i know all the magic happens at compile time. 
also: one of the criticisms was that scala is "too phd", but now i see the anti scala side argue using fancy expressions that i do not understand. just wanted to point that out because... contradiction :D
 
Gesendet: Dienstag, 14. Februar 2017 um 23:58 Uhr
Von: "Seyed H. HAERI (Hossein)" <[hidden email]>
An: Kein Empfänger
Cc: scala-user <[hidden email]>

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

> I'm sorry but you are very much mistaken. Implicits are 100% compile time
> statically checked concepts.

Is an implicit not just like an ordinary object in that it enjoys late
binding? It is. Then, I'm afraid, they are not 100% compile-time. They
might have been if Scala had chosen to take a classes-as-families [1]
approach to family polymorphism. Right now, it's objects-as-families
-- like the original family polymorphism crafted by Ernst and all
those beautiful following works...

Cheers,
--Hossein

[1] P. Jolly, S. Drossopoulou, C. Anderson, and K. Ostermann, Simple
Dependent Types: Concord, Proc. 6th W. Formal Tech. Java-like Prog.,
June 2004, Tech. Rep. nr. NIII-R0426, Uni. Nijmegen.

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

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.

--
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
|  
Report Content as Inappropriate

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

Dennis Haupt-2
In reply to this post by Seyed H. HAERI (Hossein)
i don't think it really makes sense to collect a full list of possible antipatterns regarding implicits. it would be like asking a master chef to write down things like "do not use too much salt" and then try to cook an awesome cake
it's the wrong level
 
the opposite should be done: "how should i use implicits? what are they good for?"
my answer to that is "they should do what i otherwise would do manually every time"
 
Gesendet: Mittwoch, 15. Februar 2017 um 00:05 Uhr
Von: "Seyed H. HAERI (Hossein)" <[hidden email]>
An: Kein Empfänger
Cc: scala-user <[hidden email]>
Betreff: Re: [scala-user] Why I and my company have moved away from Scala. An honest critique.
Hi Kris,

I liked your response for collecting some of the anti-patterns related
to implicits. Has anyone ever done a comprehensive list of such
anti-patterns?

Cheers,
--Hossein

On 14 February 2017 at 18:01, Kris Nuttycombe <[hidden email]> wrote:
> Among long-time users of Scala, you'll find something interesting with
> respect to their use of implicits - that is, that long-time users barely
> remember that implicit conversions exist, except insofar as implicit classes
> are used as a mechanism to provide extension methods, frequently in
> combination with the "implicit typeclass" pattern. We forget that in the
> broader Scala world, people still use direct implicit type conversions to
> "magically" transform a value of an unrelated source type to a target type
> that is used directly. We've forgotten about the fact that some people use
> *stateful* implicit values to control how their program functions. We've
> forgotten these antipatterns because we learned that they're
> catastrophically bad ideas nearly a decade ago, and have abandoned their use
> ever since.
>
> The problem is that for many, these inappropriate uses of implicits are
> their first introduction to the concept, and consequently they properly
> react in horror at the whole feature, without realizing the power of their
> principled use. If one was able to go back in time, I think one might choose
> to make implicit classes a language feature, and promote the use of
> (stateless) implicit parameters, but would otherwise eliminate implicit
> conversions from the language.
>
> All that being said, many of Robert's complaints seem somewhat disingenuous
> to me. He's clearly upset about Scala, but at the same time I have to wonder
> whether he's ever taken the opportunity to look at any Scala codebase other
> than his own. The (purely) functional Scala way of doing things can
> certainly appear alien, but I have yet to find anyone who, after having the
> power of real compositionality demonstrated to them, wouldn't concede that
> this approach is really the correct one for at least some people.
>
> Kris
>
>
>
> On Tue, Feb 14, 2017 at 9:08 AM, Jasper-M <[hidden email]> wrote:
>>
>> Hossein,
>>
>> I'm sorry but you are very much mistaken. Implicits are 100% compile time
>> statically checked concepts.
>> The point being made by Robert, for quite a few years now, is that "Scala
>> will never penetrate the business world" like Java, because of the magical
>> things that happen with implicits. The irony here is that in basically all
>> popular Java frameworks a lot of the magical stuff happens completely at
>> runtime with reflection. In Scala every magical thing happens at compile
>> time and is statically checked by the compiler, unless you are using runtime
>> reflection but almost nobody does that in Scala.
>>
>> I can agree that if implicit conversions are used excessively things can
>> get out of hand. That's why there already has been an effort to make it more
>> difficult to define implicit conversions without knowing the consequences.
>> Perhaps it should be made even more difficult.
>>
>> Stating that Scala would be a great language, if only it did not have
>> this, this, and this concept, but would have this, this and this new
>> keyword, is like saying "ice cream is the best dessert in the whole world,
>> but as long as it's sweet and cold it will be a niche dessert for all
>> eternity".
>>
>> Robert's communication has always been pretty aggressive on this mailing
>> list. That might not have been his intention, but it is the case either way.
>> And in spite of that most community members have always gone to great
>> lengths to help him out and go into discussions and have tried their best to
>> be polite. Yet every counter-argument seems be received as a personal attack
>> or flame against him. It's hard not to flame a person and at the same time
>> help him or have a healthy discussion if that means not disagreeing at all.
>>
>>
>> Kind regards,
>> Jasper
>>
>> Op dinsdag 14 februari 2017 16:35:55 UTC+1 schreef Hossein:
>>>
>>> Dear Robert,
>>>
>>> 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.



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

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
|  
Report Content as Inappropriate

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

Seyed H. HAERI (Hossein)
In reply to this post by Adriaan Moors-7
Evening Adriaan,

> I think what Jasper meant was that implicit resolution happens at compile
> time, and that the static type of the required implicit value directly
> determines the expression that will be evaluated to produce a value of that
> type (of course during run-time evaluation there's late binding, but that's
> orthogonal to implicit search).

Good point. I'm afraid though path-dependant types can kick in. Do I
not get it correctly that path-dependant types are also considered
static in Scala? If they are, then, the late-binding can indeed play a
significant role.

> Implicit resolution provides the same kind of ad-hoc polymorphism as method
> overloading, where the static types of the arguments determine which method
> overload is chosen, or Haskell's type classes, where the instance is
> directly defined by the type class. Here's a paper we wrote on the
> equivalence between type classes and implicits:
> https://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf

Yes, I read that work in the exact same year of its publication.
Splendid work! :)

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
|  
Report Content as Inappropriate

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

Adriaan Moors-7
You can absolutely statically remove all implicit "magic" in the IDE before compiling without changing the behavior of your program. This is what we mean when we say implicit resolution is static. IntelliJ offers a refactoring that does this (and much more!). The same idea applies to method overloading. You could avoid overloading by name mangling yourself, instead of having the compiler do it based on the static types of the arguments used in an overloaded method call. It would just be tedious.

I think this is getting a bit too technical for this forum, but path equivalence is decided statically, so, there's no uncertainty there either. Of course, every time you select a member on a path, you don't statically know the run-time value of the target. This is where late binding kicks in for value members. For type members, this is not the case, however: there is no notion of late-bound types in Scala, as opposed to Beta, Ernst's language (which leads to some interesting language design to maintain soundness).

Glad to hear you liked the paper!

cheers
adriaan

On Tue, Feb 14, 2017 at 3:17 PM Seyed H. HAERI (Hossein) <[hidden email]> wrote:
Evening Adriaan,

> I think what Jasper meant was that implicit resolution happens at compile
> time, and that the static type of the required implicit value directly
> determines the expression that will be evaluated to produce a value of that
> type (of course during run-time evaluation there's late binding, but that's
> orthogonal to implicit search).

Good point. I'm afraid though path-dependant types can kick in. Do I
not get it correctly that path-dependant types are also considered
static in Scala? If they are, then, the late-binding can indeed play a
significant role.

> Implicit resolution provides the same kind of ad-hoc polymorphism as method
> overloading, where the static types of the arguments determine which method
> overload is chosen, or Haskell's type classes, where the instance is
> directly defined by the type class. Here's a paper we wrote on the
> equivalence between type classes and implicits:
> https://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf

Yes, I read that work in the exact same year of its publication.
Splendid work! :)

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

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

Seyed H. HAERI (Hossein)
In reply to this post by Dennis Haupt-2
Sorry Dennis for throwing too much jargon at the list. This is, after
all, a language design issue and it takes its own terminology I'm
afraid.

OTOH, for me as a C++ person, Scala is indeed only a research
language. I publish my research papers in it! :D

On 15 February 2017 at 00:08, Dennis Haupt <[hidden email]> wrote:

> i don't know what late binding is, but i know all the magic happens at
> compile time.
> also: one of the criticisms was that scala is "too phd", but now i see the
> anti scala side argue using fancy expressions that i do not understand. just
> wanted to point that out because... contradiction :D
>
> Gesendet: Dienstag, 14. Februar 2017 um 23:58 Uhr
> Von: "Seyed H. HAERI (Hossein)" <[hidden email]>
> An: Kein Empfänger
> Cc: scala-user <[hidden email]>
> Betreff: Re: [scala-user] Why I and my company have moved away from Scala.
> An honest critique.
> Hi Jasper,
>
>> I'm sorry but you are very much mistaken. Implicits are 100% compile time
>> statically checked concepts.
>
> Is an implicit not just like an ordinary object in that it enjoys late
> binding? It is. Then, I'm afraid, they are not 100% compile-time. They
> might have been if Scala had chosen to take a classes-as-families [1]
> approach to family polymorphism. Right now, it's objects-as-families
> -- like the original family polymorphism crafted by Ernst and all
> those beautiful following works...
>
> Cheers,
> --Hossein
>
> [1] P. Jolly, S. Drossopoulou, C. Anderson, and K. Ostermann, Simple
> Dependent Types: Concord, Proc. 6th W. Formal Tech. Java-like Prog.,
> June 2004, Tech. Rep. nr. NIII-R0426, Uni. Nijmegen.
>
> --------------------------------------------------------------------------------------------------------------
>
> 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.



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

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
|  
Report Content as Inappropriate

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

Seyed H. HAERI (Hossein)
In reply to this post by Adriaan Moors-7
Hi Adriaan,

> I think this is getting a bit too technical for this forum,

Agree. But, I think it needs to be taken up once at least -- just for
the record.

> but path
> equivalence is decided statically, so, there's no uncertainty there either.
> Of course, every time you select a member on a path, you don't statically
> know the run-time value of the target. This is where late binding kicks in
> for value members.

And, that's one of the few places where things get out of my hands
wanting to simulate lightweight family polymorphism in Scala.

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