and simple :) case in point, consider the sum method, as available on lists. This is about as trivial as you can possibly get to use:
List(1,2,3).sum even the use case signature is laughable: def sum: Int but that's just the use-case for a List<Int>, for a List<Double>, it's: def sum: Double actually, it works for ALL numeric types. How about if you want to define your own type, we'll call it `Complex`, and you want it to also be summable in a list? We scale it up to the next level, this is now intermediate Scala. lets look at the full definition of that sum method: def sum[B >: A](implicit num: Numeric[B]): B that `implicit Numeric[B]` is a type class, it's what allows the sum method to work (and be type-safe) so long as there's some Numeric[T] implicit object defined. By default, the library already supplies Numeric[Int], Numeric[Double], etc. for you, so you really don't need to worry about this stuff. You can also define your own Numeric[Complex] if you wish, and that's enough to make complex numbers summable in lists, plus a host of other standard library functionality that's built around implicit Numeric objects. What if you're you're the author of the collections library? Now we move into advanced territory. The sum method is actually defined on TraversableOnce, this trait is a subclass of almost everything else in the collections hierarchy, so by defining it here you're able to sum almost any collection available, not just lists. I'm not going into the design of the collections library now, I don't have enough time and it's heavily OO-based code (unlike the functional stuff I've described so far), which actually makes it more complex to explain briefly. But all of this complexity, it's just the flip-side of flexibility, really it's just there so that library authors can make life easier for you, as a library consumer. Never forget that the true goal of these features is to allow you to write: List(1,2,3).sum and to allow that expression to be type-safe and checked by the compiler. 2010/8/29 Cédric Beust ♔ <[email protected]> > My turn to surprise you then, because I agree with pretty much everything > you say below. > > Yes, Scala is versatile and scalable. It covers functional and OO > programming. It has pattern matching, implicits, support for DSL's and a > powerful type system. > > Now, can you see how all these features combined in one language can make > such a language complicated? > > -- > Cédric > > > > On Sun, Aug 29, 2010 at 12:29 PM, Kevin Wright > <[email protected]>wrote: > >> I'm goin to surprise you now, and come out in total whole-hearted >> agreement. >> You have rather elegantly captured one of Scala's core philosophies. >> >> >> The subset of Scala to which you refer is, in fact Scala itself. The name >> of the language is a reduction of "Scalable", which applies on a number of >> levels. One such is that it can be used for programming "in the small" >> (Kojo, scripts, etc.) as well as programming "in the large" (polymorphism, >> dependency injection, etc.). >> >> Another interpretation of being "scalable" is that Scala can be used for >> conceptually simple work, possibly aided by a DSL (as with Kojo), or it can >> be used for building a large, rich, and arguably complex framework such as >> lift, or scalaz. >> >> >> What most Scala developers have now come to appreciate is that using a >> library or DSL is often a trivial matter, and that the more advanced you >> make it, the easier it becomes to use. When programming in Scala, you >> really do tend to work in one of two distinct modes: producer and consumer. >> >> >> One of Scala's biggest problems now is that most examples online are >> written by people wanting to demonstrate their competence, and this is often >> done by leveraging the full power of the language. What we need now are far >> more examples of Scala in normal use :) >> >> >> On 29 August 2010 20:10, Fabrizio Giudici >> <[email protected]>wrote: >> >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 8/29/10 20:32 , Kevin Wright wrote: >>> > >>> > >>> > ... bottom line is that using Kojo and reading the Kojo doc teaches >>> > you nothing about Scala. >>> > >>> > >>> > >>> > and this is the fundamental point of disagreement. >>> > >>> > Actually, it not only teaches you some Scala, but also come of the >>> > Java API as well: >>> > >>> http://wiki.kogics.net/forum/t-229555/another-example-with-sq-and-dist-methods >>> > >>> I >>> > >>> must say I'm pretty much with Cedric. But indeed it's not that >>> Cedric and others are right and Kevin and others are wrong. You're >>> mostly discussing on different things. I've read the pdf about Kojo. >>> Pretty neat. Indeed the DSL capabilities of Scala are a great thing, >>> pretty neat and powerful, and I regret that Java can't do that much >>> more than closures. >>> >>> Given that, I think that the only correct statements that can be done >>> are: >>> >>> 1. Students using Kojo are learning a subset of Scala. So it's not >>> wrong that they are not learning Scala. But it's a subset. For >>> instance, I don't see any trace of "pattern matching" in the whole PDF >>> document. >>> 2. I think we can assume they are enjoying Kojo >>> 3. Surely, since they are using a subset of Scala they could be pushed >>> to learn more of Scala. Kojo is a pretty smart idea to evangelize >>> Scala, indeed. >>> >>> I think that we can all agree on these three points. >>> >>> Now, there's some implicit inferencing by Kevin: that those students >>> that will go on expanding their knowledge of Scala will keep on liking >>> it as they expand their knowledge of it. Consider this example: >>> playing chess. I'm able to play chess in the sense that as I child I >>> learned the basic rules (how the different pieces move). This is a >>> subset of the game domain. Further parts of the game domain are >>> strategies to win. Indeed "playing chess" does include at least some >>> level of strategy - serious players will poo poo at you if you only >>> can move pieces (and indeed, I don't think that I can really say "I >>> can play chess"). I was saying that I can't deal with chess >>> strategies: It's not the kind of thing that I've fun with: too >>> cerebral. I really can't improve there. Thus, the fact that I found >>> easy and even amusing to learn the basics of a thing did not imply >>> that I liked the whole of it. >>> >>> Of course, I'm not asserting that all students will _not_ enjoy Scala >>> as they learn more of it. That's why I'm not saying that Kevin is >>> wrong. Give me a proof of that, and I'll believe that. If I understand >>> well, nobody has got yet enough statistics to figure out, right? We'll >>> wait and see. Personally, I think that only a minority of students >>> will still enjoy keep on learning Scala - perhaps even Kevin, in his >>> subconscious, as in his previous post he wrote "the more advanced >>> students". :-) >>> >>> This objection of mine is perfectly coherent with my judgment of Scala >>> being "powerful" and "complex". This means that if you only use a >>> subset of Scala, you might be satisfied by the reduced power that you >>> get, and you're not facing with all the complexity. In fact, I seem to >>> have said in the past that I'd be curious to see a stripped down >>> version of Scala. >>> >>> >>> - -- >>> Fabrizio Giudici - Java Architect, Project Manager >>> Tidalwave s.a.s. - "We make Java work. Everywhere." >>> java.net/blog/fabriziogiudici - www.tidalwave.it/people >>> [email protected] >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.14 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAkx6sMMACgkQeDweFqgUGxfUQQCgkDD/qvES9PFzT67+/S5OStbE >>> TkkAn0UVeaYLiE64HxPXIC4ilKy5w93f >>> =H/1M >>> -----END PGP SIGNATURE----- >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<javaposse%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >>> >> >> >> -- >> Kevin Wright >> >> mail/google talk: [email protected] >> wave: [email protected] >> skype: kev.lee.wright >> twitter: @thecoda >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<javaposse%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > > > -- > Cédric > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
