Scala
From APIDesign
(→Scala Libraries Rant) |
|||
| (3 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| - | [[wikipedia::Scala_(programming_language)|Scala]] is a language capable to run on the [[Java]] virtual machine. It merges various functional languages concepts with object | + | [[wikipedia::Scala_(programming_language)|Scala]] is a language capable to run on the [[Java]] [[HotSpot|virtual machine]]. It merges various functional languages concepts with object orietentation quite nicely (like [[trait]]s) and cooperates well with existing [[Java]] libraries. |
=== [[Scala]] Libraries Rant === | === [[Scala]] Libraries Rant === | ||
| - | After being part of the first [[Scala]] unconference just after JavaOne 2008 and publishing a recipe how to write [[NetBeans]] module extensions in [[Scala]], I had given up on [[Scala]] for a longer time. | + | After being part of the first [[Scala]] unconference just after [[JavaOne]] 2008 and publishing a recipe how to write [[NetBeans]] module extensions in [[Scala]], I had given up on [[Scala]] for a longer time. |
| - | But as the activity of [http://www.artima.com/scalazine/articles/origins_of_scala.html Artima.com guys] is increasing with | + | But as the activity of [http://www.artima.com/scalazine/articles/origins_of_scala.html Artima.com guys] is increasing with forthcoming [[JavaOne]] 2009, I dediced to give [[Scala]] one more try in early May 2009. I think I will be able to like it (as soon as I really learn it more). However I am still far more productive in [[Java]] than in [[Scala]], so I rewrote my early May project back to [[Java]]. |
One reason for that also was my uncertainty. I am still unsure what promises some [[API]] construct in [[Scala]] mean for [[BackwardCompatibility]]. Martin Odersky seems to care more about the language design, than its libraries. Thus it will take time and a lot of trial and error for the other to find out how to write shared libraties that support easy [[upgradability]]. Someone will have to document all the [[evolution]] gotchas. So far I know I cannot backward compatibly add methods to traits (which sort of beats all their purpose, imho), but there is going to be more, much more hidden catches. | One reason for that also was my uncertainty. I am still unsure what promises some [[API]] construct in [[Scala]] mean for [[BackwardCompatibility]]. Martin Odersky seems to care more about the language design, than its libraries. Thus it will take time and a lot of trial and error for the other to find out how to write shared libraties that support easy [[upgradability]]. Someone will have to document all the [[evolution]] gotchas. So far I know I cannot backward compatibly add methods to traits (which sort of beats all their purpose, imho), but there is going to be more, much more hidden catches. | ||
| Line 19: | Line 19: | ||
<comments/> | <comments/> | ||
| + | |||
| + | {{:Talk:Scala}} | ||
Current revision
Scala is a language capable to run on the Java virtual machine. It merges various functional languages concepts with object orietentation quite nicely (like traits) and cooperates well with existing Java libraries.
Contents |
Scala Libraries Rant
After being part of the first Scala unconference just after JavaOne 2008 and publishing a recipe how to write NetBeans module extensions in Scala, I had given up on Scala for a longer time.
But as the activity of Artima.com guys is increasing with forthcoming JavaOne 2009, I dediced to give Scala one more try in early May 2009. I think I will be able to like it (as soon as I really learn it more). However I am still far more productive in Java than in Scala, so I rewrote my early May project back to Java.
One reason for that also was my uncertainty. I am still unsure what promises some API construct in Scala mean for BackwardCompatibility. Martin Odersky seems to care more about the language design, than its libraries. Thus it will take time and a lot of trial and error for the other to find out how to write shared libraties that support easy upgradability. Someone will have to document all the evolution gotchas. So far I know I cannot backward compatibly add methods to traits (which sort of beats all their purpose, imho), but there is going to be more, much more hidden catches.
I am not sure how much you like the language, but I, as libraries API designer, feel disgusted looking at core Scala APIs. Have you seen the scaladoc and for example series of Product1, 2, 3, 4, ..., Product13, ... Product20? Why has the so called language of future pollute its core libraries with trash like this? All the beauty one could potentially feel when looking at the language has to be in vain as soon as one see its libraries.
APIs are like stars, you can hardly make them disappear. Does that mean Scala programmers will have to live with this API madness until the end of their days?
--JaroslavTulach 14:52, 28 May 2009 (UTC)
<comments/>
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)