Talk:Scala
From APIDesign
(Comment provided by Jslarochelle - via ArticleComments extension) |
|||
| (4 intermediate revisions not shown.) | |||
| Line 17: | Line 17: | ||
Thanks for your comment Landei. | Thanks for your comment Landei. | ||
| - | # Re.: ''some [[API]]s are ugly'' - all I want is to point out that core language [[API]]s are as important the language itself. [[Scala]]'s core [[API]] really lack the slickness of the syntax and semantics of the language. [[Martin Odersky]] and friends shall realize that soon, before it is too late. | + | # Re.: ''some [[API]]s are ugly'' - all I want is to point out that core language [[API]]s are as important as the language itself. [[Scala]]'s core [[API]] really lack the slickness of the syntax and semantics of the language. [[Martin Odersky]] and friends shall realize that soon, before it is too late. |
| - | # Re.: ''fetish'' - so who will decide what is an acceptable change - [[Martin Odersky|Martin]]? If the language (and its libraries) was treated as lightly as suggested above (e.g. if [[evolution]] is necessary, let's ignore all existing investments made by all users all around the world), then the right question is: Is [[scala]] ready for production environment? Or is it still just a university project? | + | # Re.: ''fetish'' - so who will decide what is an acceptable change - [[Martin Odersky|Martin]]? If the language (and its libraries) was treated as lightly as suggested above (e.g. if [[evolution]] is necessary, let's ignore all existing investments made by all the unknown users all around the world), then the right question is: Is [[scala]] ready for production environment? Or is it still just a university project? |
| - | # Re.: ''need to be [[JVM]] compatible'' - this is always trade off. Either you design whole system yourself (technically easy, hard to promote) and then you have as much freedom as you want. Or your try to piggy back on success of another technology ([[API]] or [[JVM]], etc.). In the later case you need to make sacrifices, but you share the momentum behind the already existing system (aka [[Java]]). | + | # Re.: ''need to be [[JVM]] compatible'' - this is always a trade off. Either you design whole system yourself (technically easy, hard to promote) and then you have as much freedom as you want. Or your try to piggy back on success of another technology ([[API]] or [[JVM]], etc.). In the later case you need to make sacrifices, but you share the momentum behind the already existing system (aka [[Java]]). |
--[[User:JaroslavTulach|JaroslavTulach]] 08:16, 12 August 2009 (UTC) | --[[User:JaroslavTulach|JaroslavTulach]] 08:16, 12 August 2009 (UTC) | ||
| + | == Fabrizio.giudici said ... == | ||
| + | |||
| + | <div class='commentBlock'> | ||
| + | Re: backward compatibility, I'm with Jaroslav. People should realize that the success of a technology is given by mainstream adopters. And mainstream adopters *need* backward compatibility. The world is not so fast forwarding, leading egde and agile as it appears in many blogs... | ||
| + | |||
| + | --[http://weblogs.java.net/blog/fabriziogiudici Fabrizio.giudici] 13:22, 12 August 2009 (CEST) | ||
| + | </div> | ||
| + | == Alexander Temerev said ... == | ||
| + | |||
| + | <div class='commentBlock'> | ||
| + | Product1..ProductN series (like its Tuple... and Function... cousins) are actually a clever trick allowing to map functional programming concepts to JVM API. Unfortunately, there is no way to define vararg-generics in JVM, so Scala API designers had to cheat. This particular cheat actually works very nice, and when I see, say, Function3[String,Int,String] datatype, I know exactly what it is. | ||
| + | |||
| + | Unfortunately, Scala language designers don't have a luxury of defining everything from scratch. They have to rely on underlying JVM mechanisms. And JVM compatibility is _the_ major selling point of Scala. | ||
| + | |||
| + | --[http://www.temerev.com Alexander Temerev] 13:47, 7 September 2009 (CEST) | ||
| + | </div> | ||
| + | == Jslarochelle said ... == | ||
| + | |||
| + | <div class='commentBlock'> | ||
| + | I also have my reservations towards Scala libraries. The use of operators worries me. I have seen a number of cases where operators were used where method names would have been better. I hope it does not get out of control. | ||
| + | |||
| + | --[[User:Jslarochelle|Jslarochelle]] 19:16, 14 September 2009 (CEST) | ||
| + | </div> | ||
Current revision
Comments on Scala <comments />
Contents |
Landei said ...
Thanks for your comment Landei.
- Re.: some APIs are ugly - all I want is to point out that core language APIs are as important as the language itself. Scala's core API really lack the slickness of the syntax and semantics of the language. Martin Odersky and friends shall realize that soon, before it is too late.
- Re.: fetish - so who will decide what is an acceptable change - Martin? If the language (and its libraries) was treated as lightly as suggested above (e.g. if evolution is necessary, let's ignore all existing investments made by all the unknown users all around the world), then the right question is: Is scala ready for production environment? Or is it still just a university project?
- Re.: need to be JVM compatible - this is always a trade off. Either you design whole system yourself (technically easy, hard to promote) and then you have as much freedom as you want. Or your try to piggy back on success of another technology (API or JVM, etc.). In the later case you need to make sacrifices, but you share the momentum behind the already existing system (aka Java).
--JaroslavTulach 08:16, 12 August 2009 (UTC)
Fabrizio.giudici said ...
Re: backward compatibility, I'm with Jaroslav. People should realize that the success of a technology is given by mainstream adopters. And mainstream adopters *need* backward compatibility. The world is not so fast forwarding, leading egde and agile as it appears in many blogs...
--Fabrizio.giudici 13:22, 12 August 2009 (CEST)
Alexander Temerev said ...
Product1..ProductN series (like its Tuple... and Function... cousins) are actually a clever trick allowing to map functional programming concepts to JVM API. Unfortunately, there is no way to define vararg-generics in JVM, so Scala API designers had to cheat. This particular cheat actually works very nice, and when I see, say, Function3[String,Int,String] datatype, I know exactly what it is.
Unfortunately, Scala language designers don't have a luxury of defining everything from scratch. They have to rely on underlying JVM mechanisms. And JVM compatibility is _the_ major selling point of Scala.
--Alexander Temerev 13:47, 7 September 2009 (CEST)
Jslarochelle said ...
I also have my reservations towards Scala libraries. The use of operators worries me. I have seen a number of cases where operators were used where method names would have been better. I hope it does not get out of control.
--Jslarochelle 19:16, 14 September 2009 (CEST)
Follow
Yes, some of the current Scala-APIs are ugly, but I can't agree with your generalization. - Scala is still in flow, and the community is willing to accept incompatibilities if there is a real improvement. BackwardCompatibility isn't the fetish it became in Javaland - it's important, but only as long as it doesn't block the evolution of the language - Some design decisions are driven by the need to be JVM compatible. A "Standalone-Scala" would certainly look cleaner - You have much more possibilities to work around API shortcomings in Scala than in Java
--Landei 09:38, 10 August 2009 (CEST)