Talk:Scala

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Comment provided by Fabrizio.giudici - via ArticleComments extension)
(Comment provided by Alexander Temerev - via ArticleComments extension)
Line 28: Line 28:
--[http://weblogs.java.net/blog/fabriziogiudici Fabrizio.giudici] 13:22, 12 August 2009 (CEST)
--[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>
</div>

Revision as of 11:47, 7 September 2009

Comments on Scala <comments />

Landei said ...

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)

Thanks for your comment Landei.

  1. 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.
  2. 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?
  3. 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)

Retrieved from "http://wiki.apidesign.org/wiki/Talk:Scala"
Personal tools
buy