Re: [scala-user] In the long run, what kind of developers do you think will make most use of scala?
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: [scala-user] In the long run, what kind of developers do you think will make most use of scala?
by Dimitris Andreou
::
Rate this Message:
2009/10/23 Adriaan Moors <adriaan.moors@...>:
> [please move this discussion to debate] > > On Fri, Oct 23, 2009 at 4:48 PM, Jim Andreou <jim.andreou@...> wrote: >> >> Lets hear what Guy Steele has to say about programming using things >> like Scala's List (instead of arrays). >> >> >> http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf >> >> In short: "it's a fundamentally bad idea". > > whoa! that could use some nuance... > here's an actual quote from the slides: >> >> Inventing new combining operators is a very, very big deal. >> >> > Creative catamorphisms! >> >> > We need programming languages that encourage this. > > Sounds a lot like Scala to me -- in fact, work is under way on a parallel > collections library. > adriaan Sure, both thumbs up for that. I only meant scala.List. Cheers, Dimitris |
|
|
Re: [scala-user] In the long run, what kind of developers do you think will make most use of scala?
by Jesper Nordenberg
::
Rate this Message:
It's also interesting to note that Steele uses binary trees and calls
arrays suspicious as most fast persistent data structures use arrays and a much higher branching factor. /Jesper Nordenberg Adriaan Moors wrote: > [please move this discussion to debate] > > On Fri, Oct 23, 2009 at 4:48 PM, Jim Andreou <jim.andreou@... > <mailto:jim.andreou@...>> wrote: > > Lets hear what Guy Steele has to say about programming using things > like Scala's List (instead of arrays). > > http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf > > In short: "it's a fundamentally bad idea". > > whoa! that could use some nuance... > > here's an actual quote from the slides: > > Inventing new combining operators is a very, very big deal. > > > Creative catamorphisms! > > > We need programming languages that encourage this. > > > Sounds a lot like Scala to me -- in fact, work is under way on a > parallel collections library. |
|
|
|
|
|
Re: [scala-user] In the long run, what kind of developers do you think will make most use of scala?
by Daniel Sobral
::
Rate this Message:
Not if I wish so. Trees, which he proposes, are extensible, and easy to copy parts of. One can pass references to subtrees, use the same subtree in for different trees, and things like that, which are not possible with arrays. And, in particular, immutable trees are more efficient than immutable arrays, because of these properties.
Look, it's not that difficult. Yes, he is telling us Lists are not good for concurrency, and that's true. But what is he used instead of them? Arrays? No, trees.
And I'll even grant that using immutable arrays to compose trees is very effective, as Clojure has shown.
On Fri, Oct 23, 2009 at 2:09 PM, Jim Andreou <jim.andreou@...> wrote: Sure, if you wish so. It's easy though to get such trees using arrays. -- Daniel C. Sobral Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value. |
|
|
Re: [scala-user] In the long run, what kind of developers do you think will make most use of scala?
by Dimitris Andreou
::
Rate this Message:
The question of trees vs arrays is besides the point. Perhaps I should
have said "instead of some other representation _such as arrays_ (or trees or whatever, that's not the point) which can yield computations with minimal critical path" - still, all these are more appropriate than LISPy lists, which yield linear critical paths, in the era of multicores. This is a pretty basic point and we all agree on it as far as I can see - so this should be moved out from "debate" :) But I'm not sure where you see the difficulty in dividing an array in 2 parts, carry on recursively, and get a computation resembling a balanced tree with critical path logN. What's the problem with that? ParallelArray does it. Oh, scrap that. Even mergesort does it. It's trivial, unless you meant something I miss. Can you clarify? Regards, Dimitris 2009/10/23 Daniel Sobral <dcsobral@...>: > Not if I wish so. Trees, which he proposes, are extensible, and easy to copy > parts of. One can pass references to subtrees, use the same subtree in for > different trees, and things like that, which are not possible with arrays. > And, in particular, immutable trees are more efficient than immutable > arrays, because of these properties. > > Look, it's not that difficult. Yes, he is telling us Lists are not good for > concurrency, and that's true. But what is he used instead of them? Arrays? > No, trees. > And I'll even grant that using immutable arrays to compose trees is very > effective, as Clojure has shown. > On Fri, Oct 23, 2009 at 2:09 PM, Jim Andreou <jim.andreou@...> wrote: >> >> Sure, if you wish so. It's easy though to get such trees using arrays. >> See ParallelArray of Doug Lea. (Could someone implement something like >> that with scala.List? Allow me to have my reservations :) ) >> >> 2009/10/23 Daniel Sobral <dcsobral@...>: >> > Could you cut that "instead of arrays" out? He is not comparing lists to >> > arrays, but to TREES! >> > >> > On Fri, Oct 23, 2009 at 12:48 PM, Jim Andreou <jim.andreou@...> >> > wrote: >> >> >> >> Lets hear what Guy Steele has to say about programming using things >> >> like Scala's List (instead of arrays). >> >> >> >> >> >> >> >> http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf >> >> >> >> In short: "it's a fundamentally bad idea". >> >> >> >> Dimitris >> >> >> >> 2009/10/23 Ricky Clarkson <ricky.clarkson@...>: >> >> >>> That's ok. There are problems with Java and C# that really need >> >> >>> addressing, and Scala addresses some of those. >> >> >> >> >> >> I totally agree. I am so happy that Scala has finally fixed them. I >> >> >> wonder >> >> >> if the masses will accept the changes though and we'll see a shift. >> >> > >> >> > I regularly see C# developers in freenode's ##csharp idly wishing >> >> > their language supported immutability better, and wasn't verbose in >> >> > certain ways. LINQ certainly began a shift. >> >> > >> >> >>> Because most mainstream languages don't emphasise immutability, the >> >> >>> linked list isn't used that much there. >> >> >> >> >> >> I think immutability is part of it - recursion and link lists in >> >> >> general are >> >> >> not concepts that people use in everyday, mainstream programming. >> >> > >> >> > Immutability is why recursion and linked lists are important. The >> >> > x:xs is quite natural though, to many programmers. Just rephrase it >> >> > as InputStream.read() and they'll know what you're talking about. :) >> >> > >> >> >> Almost all >> >> >> the time people use ArrayList compared to a linked list. >> >> > >> >> > Because immutability is at best an afterthought, and at worst >> >> > considered undesirable, in most programmers' minds. To my mind, that >> >> > makes those programmers faulty. >> >> > >> >> >> Algorithms on >> >> >> linked lists were only ever discussed in my computer science >> >> >> courses. I >> >> >> can't say I've used a Linked List many times in the last decade of >> >> >> my >> >> >> programming career, so writing recursive algorithms on them is >> >> >> something >> >> >> that I am out of practice with. >> >> > >> >> > Technically you won't really need to do that in Scala either, thanks >> >> > to for-comprehensions and folds. >> >> > >> >> >>> That's two positives, doesn't sound like a weird match to me. >> >> >> >> >> >> Again, I think they are positives too. I can see some people not >> >> >> getting >> >> >> the intellectually challenging aspects though, and wanting to revert >> >> >> back to >> >> >> more conventional programming ideas. >> >> > >> >> > That's ok, and I hope the IDEs help if they need to do that. In >> >> > fact, >> >> > having the IDEs help in that might be enough to make some of them >> >> > understand the thing they were conventionalising. >> >> > >> >> >> Don't get me wrong, I think pattern matching is a wonderful addition >> >> >> and >> >> >> it's extremely powerful. At first though, it seems like "magic". >> >> > >> >> > That's ok, just make sure you give something at least two glances >> >> > before forming an opinion. The preceding sentence sounds more harsh >> >> > than I intend it to. >> >> > >> >> >> It feels >> >> >> like it's a second language within a language - something akin to a >> >> >> computer >> >> >> science textbook than actually writing a real program. >> >> >> I think it takes a solid understanding to see that it is naturally >> >> >> fits >> >> >> in >> >> >> scala, knowing how the partial functions are created and applied to >> >> >> each >> >> >> case, and viewing the world that way. Once I got this, patterns >> >> >> became >> >> >> a lot >> >> >> more natural for me to think and reason about. >> >> >> However, this is not apparent just by looking at it the first few >> >> >> times. I >> >> >> can see a lot of people getting bewildered by it, either trying to >> >> >> "memorize >> >> >> the magic" or just not using it. >> >> > >> >> > I think using it for a while will fix that. >> >> > >> >> >> I would argue that 97% (made up number) of Java developers don't >> >> >> care >> >> >> and >> >> >> have never heard of them. In Java, you can program and not care for >> >> >> the >> >> >> most >> >> >> part. In scala, I think one needs to learn these to use the language >> >> >> better. >> >> > >> >> > I'm sorry you rate our fellow Java programmers so poorly. Though I >> >> > must say, as I don't use subtyping very much in Scala, I rarely >> >> > actually touch covariance and contravariance. It's a solution to a >> >> > mainstream problem. >> >> > >> >> > -- >> >> > Ricky Clarkson >> >> > Java and Scala Programmer, AD Holdings >> >> > +44 1565 770804 >> >> > Skype: ricky_clarkson >> >> > Google Talk: ricky.clarkson@... >> >> > Google Wave: ricky.clarkson@... >> >> > >> > >> > >> > >> > -- >> > Daniel C. Sobral >> > >> > Something I learned in academia: there are three kinds of academic >> > reviews: >> > review by name, review by reference and review by value. >> > > > > > -- > Daniel C. Sobral > > Something I learned in academia: there are three kinds of academic reviews: > review by name, review by reference and review by value. > |
|
|
Re: [scala-user] In the long run, what kind of developers do you think will make most use of scala?
by Daniel Sobral
::
Rate this Message:
Sure. Let's take an array [abcdefghijk], and a tree
Node(f, Node(c, Leaf(a,b), Leaf(d, e)), Node(i, Leaf(g, h), Leaf(j, k)))
Sorry, I suck at ASCII art. :-)
If I decide to replace "g" with something else, I need to copy two nodes and one leaf. To make things easier, assume all these letters are objects, so each node contains 3 references and leaf contain, two references. Total, I need to copy 8 references. If I need to (immutably) change the array, I need to copy the whole array, or 11 references.
As the tree gets deeper, the advantage of the trees get wider, as you only need to copy one object at each level.
We can go about this problem the other way too. If I have two arrays, I can only join them by copying them whole. If I have two trees, I just need a new node.
On Fri, Oct 23, 2009 at 4:11 PM, Jim Andreou <jim.andreou@...> wrote: The question of trees vs arrays is besides the point. Perhaps I should -- Daniel C. Sobral Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value. |
|
|
Re: [scala-user] In the long run, what kind of developers do you think will make most use of scala?
by Dimitris Andreou
::
Rate this Message:
Oh, I see. Yes, I certainly agree with this. Persistent arrays that
don't suck are tough to achieve (I must have been the first to point this out to someone who recently asked here for such a structure in the scala library, thinking that in fact they are easy to have), while persistent trees are so much easier to have. I don't think I said anything about persistent structures or mutability or anything that relates this to the previous discussion, though. Is the link that I mentioned "arrays", so you responded that "yeah, but persistent arrays suck"? If this is the case, it's quite funny, I thought we were disagreeing on something while we were agreeing on both accounts. Anyway, all in all, I found that presentation very interesting when I first saw it, and it's nice that apparently more people got to check it out, even in as a controversial way as this :-) ps: I didn't even bother reading your ascii tree, sorry, but I trust I got your point! 2009/10/23 Daniel Sobral <dcsobral@...>: > Sure. Let's take an array [abcdefghijk], and a tree > > Node(f, Node(c, Leaf(a,b), Leaf(d, e)), Node(i, Leaf(g, h), Leaf(j, k))) > > Sorry, I suck at ASCII art. :-) > > If I decide to replace "g" with something else, I need to copy two nodes and > one leaf. To make things easier, assume all these letters are objects, so > each node contains 3 references and leaf contain, two references. Total, I > need to copy 8 references. If I need to (immutably) change the array, I need > to copy the whole array, or 11 references. > > As the tree gets deeper, the advantage of the trees get wider, as you only > need to copy one object at each level. > > We can go about this problem the other way too. If I have two arrays, I can > only join them by copying them whole. If I have two trees, I just need a new > node. > On Fri, Oct 23, 2009 at 4:11 PM, Jim Andreou <jim.andreou@...> wrote: >> >> The question of trees vs arrays is besides the point. Perhaps I should >> have said "instead of some other representation _such as arrays_ (or >> trees or whatever, that's not the point) which can yield computations >> with minimal critical path" - still, all these are more appropriate >> than LISPy lists, which yield linear critical paths, in the era of >> multicores. This is a pretty basic point and we all agree on it as far >> as I can see - so this should be moved out from "debate" :) >> >> But I'm not sure where you see the difficulty in dividing an array in >> 2 parts, carry on recursively, and get a computation resembling a >> balanced tree with critical path logN. What's the problem with that? >> ParallelArray does it. Oh, scrap that. Even mergesort does it. It's >> trivial, unless you meant something I miss. Can you clarify? >> >> Regards, >> Dimitris >> >> 2009/10/23 Daniel Sobral <dcsobral@...>: >> > Not if I wish so. Trees, which he proposes, are extensible, and easy to >> > copy >> > parts of. One can pass references to subtrees, use the same subtree in >> > for >> > different trees, and things like that, which are not possible with >> > arrays. >> > And, in particular, immutable trees are more efficient than immutable >> > arrays, because of these properties. >> > >> > Look, it's not that difficult. Yes, he is telling us Lists are not good >> > for >> > concurrency, and that's true. But what is he used instead of them? >> > Arrays? >> > No, trees. >> > And I'll even grant that using immutable arrays to compose trees is very >> > effective, as Clojure has shown. >> > On Fri, Oct 23, 2009 at 2:09 PM, Jim Andreou <jim.andreou@...> >> > wrote: >> >> >> >> Sure, if you wish so. It's easy though to get such trees using arrays. >> >> See ParallelArray of Doug Lea. (Could someone implement something like >> >> that with scala.List? Allow me to have my reservations :) ) >> >> >> >> 2009/10/23 Daniel Sobral <dcsobral@...>: >> >> > Could you cut that "instead of arrays" out? He is not comparing lists >> >> > to >> >> > arrays, but to TREES! >> >> > >> >> > On Fri, Oct 23, 2009 at 12:48 PM, Jim Andreou <jim.andreou@...> >> >> > wrote: >> >> >> >> >> >> Lets hear what Guy Steele has to say about programming using things >> >> >> like Scala's List (instead of arrays). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf >> >> >> >> >> >> In short: "it's a fundamentally bad idea". >> >> >> >> >> >> Dimitris >> >> >> >> >> >> 2009/10/23 Ricky Clarkson <ricky.clarkson@...>: >> >> >> >>> That's ok. There are problems with Java and C# that really need >> >> >> >>> addressing, and Scala addresses some of those. >> >> >> >> >> >> >> >> I totally agree. I am so happy that Scala has finally fixed them. >> >> >> >> I >> >> >> >> wonder >> >> >> >> if the masses will accept the changes though and we'll see a >> >> >> >> shift. >> >> >> > >> >> >> > I regularly see C# developers in freenode's ##csharp idly wishing >> >> >> > their language supported immutability better, and wasn't verbose >> >> >> > in >> >> >> > certain ways. LINQ certainly began a shift. >> >> >> > >> >> >> >>> Because most mainstream languages don't emphasise immutability, >> >> >> >>> the >> >> >> >>> linked list isn't used that much there. >> >> >> >> >> >> >> >> I think immutability is part of it - recursion and link lists in >> >> >> >> general are >> >> >> >> not concepts that people use in everyday, mainstream programming. >> >> >> > >> >> >> > Immutability is why recursion and linked lists are important. The >> >> >> > x:xs is quite natural though, to many programmers. Just rephrase >> >> >> > it >> >> >> > as InputStream.read() and they'll know what you're talking about. >> >> >> > :) >> >> >> > >> >> >> >> Almost all >> >> >> >> the time people use ArrayList compared to a linked list. >> >> >> > >> >> >> > Because immutability is at best an afterthought, and at worst >> >> >> > considered undesirable, in most programmers' minds. To my mind, >> >> >> > that >> >> >> > makes those programmers faulty. >> >> >> > >> >> >> >> Algorithms on >> >> >> >> linked lists were only ever discussed in my computer science >> >> >> >> courses. I >> >> >> >> can't say I've used a Linked List many times in the last decade >> >> >> >> of >> >> >> >> my >> >> >> >> programming career, so writing recursive algorithms on them is >> >> >> >> something >> >> >> >> that I am out of practice with. >> >> >> > >> >> >> > Technically you won't really need to do that in Scala either, >> >> >> > thanks >> >> >> > to for-comprehensions and folds. >> >> >> > >> >> >> >>> That's two positives, doesn't sound like a weird match to me. >> >> >> >> >> >> >> >> Again, I think they are positives too. I can see some people not >> >> >> >> getting >> >> >> >> the intellectually challenging aspects though, and wanting to >> >> >> >> revert >> >> >> >> back to >> >> >> >> more conventional programming ideas. >> >> >> > >> >> >> > That's ok, and I hope the IDEs help if they need to do that. In >> >> >> > fact, >> >> >> > having the IDEs help in that might be enough to make some of them >> >> >> > understand the thing they were conventionalising. >> >> >> > >> >> >> >> Don't get me wrong, I think pattern matching is a wonderful >> >> >> >> addition >> >> >> >> and >> >> >> >> it's extremely powerful. At first though, it seems like "magic". >> >> >> > >> >> >> > That's ok, just make sure you give something at least two glances >> >> >> > before forming an opinion. The preceding sentence sounds more >> >> >> > harsh >> >> >> > than I intend it to. >> >> >> > >> >> >> >> It feels >> >> >> >> like it's a second language within a language - something akin to >> >> >> >> a >> >> >> >> computer >> >> >> >> science textbook than actually writing a real program. >> >> >> >> I think it takes a solid understanding to see that it is >> >> >> >> naturally >> >> >> >> fits >> >> >> >> in >> >> >> >> scala, knowing how the partial functions are created and applied >> >> >> >> to >> >> >> >> each >> >> >> >> case, and viewing the world that way. Once I got this, patterns >> >> >> >> became >> >> >> >> a lot >> >> >> >> more natural for me to think and reason about. >> >> >> >> However, this is not apparent just by looking at it the first few >> >> >> >> times. I >> >> >> >> can see a lot of people getting bewildered by it, either trying >> >> >> >> to >> >> >> >> "memorize >> >> >> >> the magic" or just not using it. >> >> >> > >> >> >> > I think using it for a while will fix that. >> >> >> > >> >> >> >> I would argue that 97% (made up number) of Java developers don't >> >> >> >> care >> >> >> >> and >> >> >> >> have never heard of them. In Java, you can program and not care >> >> >> >> for >> >> >> >> the >> >> >> >> most >> >> >> >> part. In scala, I think one needs to learn these to use the >> >> >> >> language >> >> >> >> better. >> >> >> > >> >> >> > I'm sorry you rate our fellow Java programmers so poorly. Though >> >> >> > I >> >> >> > must say, as I don't use subtyping very much in Scala, I rarely >> >> >> > actually touch covariance and contravariance. It's a solution to >> >> >> > a >> >> >> > mainstream problem. >> >> >> > >> >> >> > -- >> >> >> > Ricky Clarkson >> >> >> > Java and Scala Programmer, AD Holdings >> >> >> > +44 1565 770804 >> >> >> > Skype: ricky_clarkson >> >> >> > Google Talk: ricky.clarkson@... >> >> >> > Google Wave: ricky.clarkson@... >> >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Daniel C. Sobral >> >> > >> >> > Something I learned in academia: there are three kinds of academic >> >> > reviews: >> >> > review by name, review by reference and review by value. >> >> > >> > >> > >> > >> > -- >> > Daniel C. Sobral >> > >> > Something I learned in academia: there are three kinds of academic >> > reviews: >> > review by name, review by reference and review by value. >> > > > > > -- > Daniel C. Sobral > > Something I learned in academia: there are three kinds of academic reviews: > review by name, review by reference and review by value. > |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
