Scala school(twitter.github.com)
twitter.github.com
Scala school
http://twitter.github.com/scala_school/
6 comments
Hmmm, lots of REPL input/output, nearly no informative descriptions. Besides that some descriptions are wrong or inaccurate, three randomly picked examples (and I am not a Scala programmer):
* "compose calls the second function and then the first function."
* "Maps - It can hold basic datatypes."
* "foldRight Is the same as foldLeft except it runs in the opposite direction."
I'd recommend friends to buy a good, well-edited book.
* "compose calls the second function and then the first function."
* "Maps - It can hold basic datatypes."
* "foldRight Is the same as foldLeft except it runs in the opposite direction."
I'd recommend friends to buy a good, well-edited book.
hi, i'm one of the authors.
the scala school is mostly intended to be used in conjunction with a course we teach.
we're working on moving it towards being more self-contained, independent from the accompanying lectures.
the scala school is mostly intended to be used in conjunction with a course we teach.
we're working on moving it towards being more self-contained, independent from the accompanying lectures.
ignore the trolls, I appreciate you putting this out there, looks like some good reading material for the day :)
What trolls? The starter of this subthread raised a legitimate point.
For the sake of the ignorant, could you expound on why these examples are wrong or inaccurate?
1. 'compose f g' doesn't call g and then f, but it constructs a new function of the form \x -> f (g x).
2. Maps store mappings between keys and values.
3. Left and right folds both process a list recursively from start to end. However, left folds apply the given function first and then recurse. Right folds recurse first and then apply. As a result, in right folds the given function is applied to the last element first.
2. Maps store mappings between keys and values.
3. Left and right folds both process a list recursively from start to end. However, left folds apply the given function first and then recurse. Right folds recurse first and then apply. As a result, in right folds the given function is applied to the last element first.
Also, right folds preserve the structure of the datatype folded over. If you fold right over a list with the empty list as the start value and cons (or (_::_) in scala) as the operation, you get the original list back (i.e. same value, not same object). A left fold on the other hand is just some arbitrary looping constuct.
I am no master myself but I will take a stab at it.
* "compose calls the second function and then the first function."
I would not call that wrong or inaccurate just very empty and not clear. What is the first function the left or right? Whatever the definition, it may as well be a tautology. If I was explaining composition I would explain it in a way that pulls from prior knowledge but also does not hamstring the learner.
In particular composition need not follow any particular direction. What matters in composition is in the ordering of the types, the outputs must fit the inputs. That is you can have f : B <- A and g : C <- B then h = f o g is a function from C <- A that is identical to a function formed by first applying f to its argument and piping that to g. Composition is a way of making new functions from old ones, kind of like multiplication for functions.
* "Maps - It can hold basic datatypes."
I don't know what that is supposed to mean. But Maps in functional languages tend to be immutable tree based key value data structures.
* "foldRight Is the same as foldLeft except it runs in the opposite direction."
This one is dangerous because it is true in a sense they are dual to each other. But applied indiscrimnately you could end up with different results unless operation with respect to the values is commutative and associative. remember the associative rule from school? Is 5 - (8 - 5) = (5 - 8) - 5? You can think of foldLeft as an accumulating a value and foldright as reducing to a value. foldRight is also less space efficient although you can write it in terms of foldl. However in a lazy language foldr has the additional distinction of being able to work with infinite lists since it works straight from the front of the list, it doesn't have to recurse to the end of the list first like foldl.
* "compose calls the second function and then the first function."
I would not call that wrong or inaccurate just very empty and not clear. What is the first function the left or right? Whatever the definition, it may as well be a tautology. If I was explaining composition I would explain it in a way that pulls from prior knowledge but also does not hamstring the learner.
In particular composition need not follow any particular direction. What matters in composition is in the ordering of the types, the outputs must fit the inputs. That is you can have f : B <- A and g : C <- B then h = f o g is a function from C <- A that is identical to a function formed by first applying f to its argument and piping that to g. Composition is a way of making new functions from old ones, kind of like multiplication for functions.
* "Maps - It can hold basic datatypes."
I don't know what that is supposed to mean. But Maps in functional languages tend to be immutable tree based key value data structures.
* "foldRight Is the same as foldLeft except it runs in the opposite direction."
This one is dangerous because it is true in a sense they are dual to each other. But applied indiscrimnately you could end up with different results unless operation with respect to the values is commutative and associative. remember the associative rule from school? Is 5 - (8 - 5) = (5 - 8) - 5? You can think of foldLeft as an accumulating a value and foldright as reducing to a value. foldRight is also less space efficient although you can write it in terms of foldl. However in a lazy language foldr has the additional distinction of being able to work with infinite lists since it works straight from the front of the list, it doesn't have to recurse to the end of the list first like foldl.
The first error I noticed in 'Basics':
scala> val timesTwo = multiply(2)(_)
This should just be multiply(2). Using an underscore misses the point of a curried function. f(_)==f..
scala> val timesTwo = multiply(2)(_)
This should just be multiply(2). Using an underscore misses the point of a curried function. f(_)==f..
[deleted]
Good stuff, really useful to see what Twitter considers to be 'Scala: the Good Parts'.
But no mention of Actors or Akka in the concurrency section? Why not, out of curiosity? Actor model doesn't fit your use cases?
But no mention of Actors or Akka in the concurrency section? Why not, out of curiosity? Actor model doesn't fit your use cases?
Actors had a memory leak when a lot of the formative Twitter Scala stuff happened. This lead to more usage of java concurrency primitives, which snowballed within the culture.
There's some people at Twitter who truly love and grok Scala and Scala idioms inside out, and there's some people who look at Scala as a more functional, less verbose Java.
There's some people at Twitter who truly love and grok Scala and Scala idioms inside out, and there's some people who look at Scala as a more functional, less verbose Java.
Interesting form of technical debt. I hear Akka is replacing Scala's actors lib in 3.1 or thereabouts. Any talk about adopting it?
>There's some people at Twitter who truly love and grok Scala and Scala idioms inside out, and there's some people who look at Scala as a more functional, less verbose Java.
I'm a full card-carrying member of exactly both groups, but if all Scala does is succeed b/c of the latter, it will have served a wonderful purpose in displacing Java.
>There's some people at Twitter who truly love and grok Scala and Scala idioms inside out, and there's some people who look at Scala as a more functional, less verbose Java.
I'm a full card-carrying member of exactly both groups, but if all Scala does is succeed b/c of the latter, it will have served a wonderful purpose in displacing Java.
You attempt to explain partial function application and currying on page 1. Using opaque examples.
This makes no sense; people who have experience with FP concepts don't need to know that, and those who don't won't be able to understand what you're talking about. Saying things like "I promise, this will get easier over time" isn't actually helpful.
Also, the text is low-contrast and difficult to read.
This makes no sense; people who have experience with FP concepts don't need to know that, and those who don't won't be able to understand what you're talking about. Saying things like "I promise, this will get easier over time" isn't actually helpful.
Also, the text is low-contrast and difficult to read.
Fwiw, best explanation I've found of currying and partial functions is in Learn You a Haskell (Chp. 5) by Miran Lipovaca. He's one of those writers that is exceptionally good at explaining technical concepts.
for those looking for free reference, this is the best I have found: http://ofps.oreilly.com/titles/9780596155957/index.html
not a great book but if complemented with blog posts here and there and the exercises from http://aperiodic.net/phil/scala/s-99/ you can get started.
Horstmann's draft tutorial book is shaping up to be a great (non-reference) book
http://blog.typesafe.com/free-pdf-from-typesafe-scala-for-th...
http://blog.typesafe.com/free-pdf-from-typesafe-scala-for-th...
“Scala for the Impatient” is indeed probably the best of the current generation of books for getting into Scala.
Unfortunately it's not for the actually impatient since only the first 9(?) chapters are released and the more interesting ones probably won't be available until late this or early next year, so you'll need to augment it with another book for now.
Unfortunately it's not for the actually impatient since only the first 9(?) chapters are released and the more interesting ones probably won't be available until late this or early next year, so you'll need to augment it with another book for now.
What I really want is a book dedicated to type-level wankery in Scala. That's the part of the language that's not easy and requires a lot of trial and error to figure out on your own.
This is EXACTLY how I feel. I don't need a lot of introductory chapters dedicated to first-class functions, closures, and higher order functions like map/fold & friends. So much Scala material is clearly targeted at Java programmers and leads with something like "look no semicolons!" I want something like "Scala for Lispers". (or even "Scala for Ruby programmers")
I've found "Scala in Depth" to be really good for learning more about the type system http://www.manning.com/suereth/
I don't think there's a "Scala for Haskellers or ML'ers". Try Tony Morris' blog, or maybe this draft book
https://github.com/leithaus/XTrace/tree/8498f3294c8e8e52fe52...
I haven't seen this book, the review war is unfortunate, but the one 4-star review seems credible
http://www.amazon.com/Steps-Scala-Introduction-Object-Functi...
https://github.com/leithaus/XTrace/tree/8498f3294c8e8e52fe52...
I haven't seen this book, the review war is unfortunate, but the one 4-star review seems credible
http://www.amazon.com/Steps-Scala-Introduction-Object-Functi...
I'm finding the light gray on white text pretty hard to read.
EDIT: Not to mention there are places that could use some copy editing...
EDIT: Not to mention there are places that could use some copy editing...
Also, the sbt they use in the tutorial is an old version; the community is going through a big shift to sbt 0.10 now, which is a totally different system. Very different, and often outright weird to the uninitiated, but worth learning if you're starting new projects.
This tutorial is for Scala 1.8.1, and 1.9.1 is available now and considered stable. Use it!