I am only a teacher to the extent that I have done teaching. I remember
believing that hiding terminology from students was a good idea. I was
partly influenced by students themselves. Some students still insist. We
were all wrong and not just a bit. I must remember to dismiss their
demands, for everyone's benefit.
On Oct 1, 2012 9:10 AM, "Toby Corkindale" <t...@dryft.net> wrote:
> On 30 September 2012 17:23, Tony Morris <tonymor...@gmail.com> wrote:
> > I agree e.g.
> > https://github.com/tonymorris/course/blob/master/src/L04/Misty.hs > > However, it is of extremely limited use. Almost always it is better to
> > tell the student what they are really doing.
> I'm not convinced, but then, I haven't studied teaching. A couple of
> friends are teachers. I could ask them?
> --
> You received this message because you are subscribed to the Google Groups
> "Melbourne Scala User Group" group.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
(Un)fortunately I've been reading *Structure and Interpretation of Computer Programs* in parallel with the course (*highly recommended!*) and saw (and analysed) the algorithm before I saw the problem in the course :(
The Scala Course is pretty much a mirror of the book. I find it very valuable. My problem is now juggling two new languages in my head.
On Friday, September 28, 2012 11:38:12 AM UTC+10, Branko Juric wrote:
> The money challenge was a real gem. Took me ages but I was determined to > do no googling to nut it out on my own. It felt so good when I finally got > it :) I will remember that one forever.
Just to say I've been following the course too and it's been
interesting to have to think purely recursively and forego mutable
values.
As a personal exercise, I've also been trying out the assignments
before watching the videos to see how much I already know - both Scala
syntax and data structures / algorithms - so far so good, though not
sure how long this will last :-)
On 2 October 2012 08:57, Dean Budd <dean.b...@gmail.com> wrote:
> (Un)fortunately I've been reading Structure and Interpretation of Computer
> Programs in parallel with the course (highly recommended!) and saw (and
> analysed) the algorithm before I saw the problem in the course :(
> The Scala Course is pretty much a mirror of the book. I find it very
> valuable. My problem is now juggling two new languages in my head.
Could be interesting to try out the exercises in Scala, and use the
book just for the generic concepts.
> On Friday, September 28, 2012 11:38:12 AM UTC+10, Branko Juric wrote:
>> The money challenge was a real gem. Took me ages but I was determined to
>> do no googling to nut it out on my own. It felt so good when I finally got
>> it :) I will remember that one forever.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
Speaking of the course, I feel that last week and this week have drifted
towards "Object-oriented Programming Principles in Scala".
For example, last week's Rational example demonstrated a textbook OO
implementation. You could just use a tuple containing a Numerator and a
Denominator field to model a rational, alias it as Rational, and write a
bunch of functions that worked over Rationals. That would be simpler, in
the sense that you wouldn't need to invent/understand classes or OO at all.
My impressions is that the course is more about teaching Scala than
teaching functional programming, which is a slight surprise because I'd
been expecting the opposite emphasis. But for a lot of people this could be
ideal.
-Ben
On Wed, Oct 10, 2012 at 6:43 PM, King Lung Chiu <kinglung.c...@gmail.com>wrote:
> Just to say I've been following the course too and it's been
> interesting to have to think purely recursively and forego mutable
> values.
> As a personal exercise, I've also been trying out the assignments
> before watching the videos to see how much I already know - both Scala
> syntax and data structures / algorithms - so far so good, though not
> sure how long this will last :-)
> On 2 October 2012 08:57, Dean Budd <dean.b...@gmail.com> wrote:
> > (Un)fortunately I've been reading Structure and Interpretation of
> Computer
> > Programs in parallel with the course (highly recommended!) and saw (and
> > analysed) the algorithm before I saw the problem in the course :(
> > The Scala Course is pretty much a mirror of the book. I find it very
> > valuable. My problem is now juggling two new languages in my head.
> Could be interesting to try out the exercises in Scala, and use the
> book just for the generic concepts.
> cheers,
> King
> > On Friday, September 28, 2012 11:38:12 AM UTC+10, Branko Juric wrote:
> >> The money challenge was a real gem. Took me ages but I was determined
> to
> >> do no googling to nut it out on my own. It felt so good when I finally
> got
> >> it :) I will remember that one forever.
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Melbourne Scala User Group" group.
> > To view this discussion on the web, visit
> > https://groups.google.com/d/msg/scala-melb/-/FWovFQP4-kMJ.
> > To post to this group, send an email to scala-melb@googlegroups.com.
> > To unsubscribe from this group, send email to
> > scala-melb+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/scala-melb?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Melbourne Scala User Group" group.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
I got the impression that Martin was going with the line that OO is not
mutually exclusive with FP
Didn't he use the first lecture to describe FP as being primarily about
immutable variables and contrasted with imperative style, which is a
sequence of machine instructions that update state?
On Wed, Oct 10, 2012 at 11:37 PM, Ben Hutchison <brhutchi...@gmail.com>wrote:
> Speaking of the course, I feel that last week and this week have drifted
> towards "Object-oriented Programming Principles in Scala".
> For example, last week's Rational example demonstrated a textbook OO
> implementation. You could just use a tuple containing a Numerator and a
> Denominator field to model a rational, alias it as Rational, and write a
> bunch of functions that worked over Rationals. That would be simpler, in
> the sense that you wouldn't need to invent/understand classes or OO at all.
> My impressions is that the course is more about teaching Scala than
> teaching functional programming, which is a slight surprise because I'd
> been expecting the opposite emphasis. But for a lot of people this could be
> ideal.
> -Ben
> On Wed, Oct 10, 2012 at 6:43 PM, King Lung Chiu <kinglung.c...@gmail.com>wrote:
>> Just to say I've been following the course too and it's been
>> interesting to have to think purely recursively and forego mutable
>> values.
>> As a personal exercise, I've also been trying out the assignments
>> before watching the videos to see how much I already know - both Scala
>> syntax and data structures / algorithms - so far so good, though not
>> sure how long this will last :-)
>> On 2 October 2012 08:57, Dean Budd <dean.b...@gmail.com> wrote:
>> > (Un)fortunately I've been reading Structure and Interpretation of
>> Computer
>> > Programs in parallel with the course (highly recommended!) and saw (and
>> > analysed) the algorithm before I saw the problem in the course :(
>> > The Scala Course is pretty much a mirror of the book. I find it very
>> > valuable. My problem is now juggling two new languages in my head.
>> Could be interesting to try out the exercises in Scala, and use the
>> book just for the generic concepts.
>> cheers,
>> King
>> > On Friday, September 28, 2012 11:38:12 AM UTC+10, Branko Juric wrote:
>> >> The money challenge was a real gem. Took me ages but I was determined
>> to
>> >> do no googling to nut it out on my own. It felt so good when I
>> finally got
>> >> it :) I will remember that one forever.
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Melbourne Scala User Group" group.
>> > To view this discussion on the web, visit
>> > https://groups.google.com/d/msg/scala-melb/-/FWovFQP4-kMJ.
>> > To post to this group, send an email to scala-melb@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > scala-melb+unsubscribe@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/scala-melb?hl=en-GB.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Melbourne Scala User Group" group.
>> To post to this group, send an email to scala-melb@googlegroups.com.
>> To unsubscribe from this group, send email to
>> scala-melb+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/scala-melb?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Melbourne Scala User Group" group.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
On Thu, Oct 11, 2012 at 6:39 AM, Travis Dixon <the.t...@gmail.com> wrote:
> I got the impression that Martin was going with the line that OO is not
> mutually exclusive with FP
> Didn't he use the first lecture to describe FP as being primarily about
> immutable variables and contrasted with imperative style, which is a
> sequence of machine instructions that update state?
> On Wed, Oct 10, 2012 at 11:37 PM, Ben Hutchison <brhutchi...@gmail.com>wrote:
>> Speaking of the course, I feel that last week and this week have drifted
>> towards "Object-oriented Programming Principles in Scala".
>> For example, last week's Rational example demonstrated a textbook OO
>> implementation. You could just use a tuple containing a Numerator and a
>> Denominator field to model a rational, alias it as Rational, and write a
>> bunch of functions that worked over Rationals. That would be simpler, in
>> the sense that you wouldn't need to invent/understand classes or OO at all.
>> My impressions is that the course is more about teaching Scala than
>> teaching functional programming, which is a slight surprise because I'd
>> been expecting the opposite emphasis. But for a lot of people this could be
>> ideal.
>> -Ben
>> On Wed, Oct 10, 2012 at 6:43 PM, King Lung Chiu <kinglung.c...@gmail.com>wrote:
>>> Just to say I've been following the course too and it's been
>>> interesting to have to think purely recursively and forego mutable
>>> values.
>>> As a personal exercise, I've also been trying out the assignments
>>> before watching the videos to see how much I already know - both Scala
>>> syntax and data structures / algorithms - so far so good, though not
>>> sure how long this will last :-)
>>> On 2 October 2012 08:57, Dean Budd <dean.b...@gmail.com> wrote:
>>> > (Un)fortunately I've been reading Structure and Interpretation of
>>> Computer
>>> > Programs in parallel with the course (highly recommended!) and saw (and
>>> > analysed) the algorithm before I saw the problem in the course :(
>>> > The Scala Course is pretty much a mirror of the book. I find it very
>>> > valuable. My problem is now juggling two new languages in my head.
>>> Could be interesting to try out the exercises in Scala, and use the
>>> book just for the generic concepts.
>>> cheers,
>>> King
>>> > On Friday, September 28, 2012 11:38:12 AM UTC+10, Branko Juric wrote:
>>> >> The money challenge was a real gem. Took me ages but I was
>>> determined to
>>> >> do no googling to nut it out on my own. It felt so good when I
>>> finally got
>>> >> it :) I will remember that one forever.
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "Melbourne Scala User Group" group.
>>> > To view this discussion on the web, visit
>>> > https://groups.google.com/d/msg/scala-melb/-/FWovFQP4-kMJ.
>>> > To post to this group, send an email to scala-melb@googlegroups.com.
>>> > To unsubscribe from this group, send email to
>>> > scala-melb+unsubscribe@googlegroups.com.
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/scala-melb?hl=en-GB.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Melbourne Scala User Group" group.
>>> To post to this group, send an email to scala-melb@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> scala-melb+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/scala-melb?hl=en-GB.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Melbourne Scala User Group" group.
>> To post to this group, send an email to scala-melb@googlegroups.com.
>> To unsubscribe from this group, send email to
>> scala-melb+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/scala-melb?hl=en-GB.
Yeah, you remind me that there are 2 different spectrums or axes where the
word "Functional" is used. They are often mixed up, because it *is*
confusing to have one word mean at least two different things
One is the mutable <-> immutable axis (aka imperative<-> declarative) axis,
and this is probably the one where Martin uses the word Functional to
describe the immutable/declarative direction. Fair enough.
A somewhat orthogonal axis is the Object-oriented <-> uh, "Functional"
(maybe "Type Class"?) spectrum. At the OO end, the data is tightly bound to
related behavior and polymoprhic dispatch is implemented by heap pointers
to method vtables, associated with the first special "self" parameter to
each function.
At the , er "functional" end, data and behavior are kept separate.
Polymoprhic dispatch is implemented via type-classes, which use the
compile-time type system to invoke the appropriate type-class instance for
the data types in context. Obviously, this paradigm requires a static type
system to get past Go.
Support for the typeclass model is not "native" to scala, the way OO is. It
was kind of engineered post-hoc, as people (a) understood
the capabilities of implicits, (b) ported Haskell code over and
(c) recognized how powerful it was.
The big "wins" of the typeclass model vs the OO model are:
- It doesn't require the asymmetry of dispatching purely on the first
"self" parameter to the method. This asymmetry looks to me like an
artificial implementation-artefact when critically examined, and has lots
of negative consequences, eg implementing Object.equals(other) [
http://www.artima.com/lejava/articles/equality.html].
- It allows the behavior to vary in different contexts. Look at
java.util.Comparable as example of why you need this; you just cannot just
weld one ordering onto a piece of data and expect this to suffice for all
clients. Hence, java.util.Comparator came into being, which
is essentially a type class, except in Java you must do the dispatch
manually by hand.
On Thu, Oct 11, 2012 at 6:39 AM, Travis Dixon <the.t...@gmail.com> wrote:
> I got the impression that Martin was going with the line that OO is not
> mutually exclusive with FP
> Didn't he use the first lecture to describe FP as being primarily about
> immutable variables and contrasted with imperative style, which is a
> sequence of machine instructions that update state?
> On Wed, Oct 10, 2012 at 11:37 PM, Ben Hutchison <brhutchi...@gmail.com>wrote:
>> Speaking of the course, I feel that last week and this week have drifted
>> towards "Object-oriented Programming Principles in Scala".
>> For example, last week's Rational example demonstrated a textbook OO
>> implementation. You could just use a tuple containing a Numerator and a
>> Denominator field to model a rational, alias it as Rational, and write a
>> bunch of functions that worked over Rationals. That would be simpler, in
>> the sense that you wouldn't need to invent/understand classes or OO at all.
>> My impressions is that the course is more about teaching Scala than
>> teaching functional programming, which is a slight surprise because I'd
>> been expecting the opposite emphasis. But for a lot of people this could be
>> ideal.
>> -Ben
>> On Wed, Oct 10, 2012 at 6:43 PM, King Lung Chiu <kinglung.c...@gmail.com>wrote:
>>> Just to say I've been following the course too and it's been
>>> interesting to have to think purely recursively and forego mutable
>>> values.
>>> As a personal exercise, I've also been trying out the assignments
>>> before watching the videos to see how much I already know - both Scala
>>> syntax and data structures / algorithms - so far so good, though not
>>> sure how long this will last :-)
>>> On 2 October 2012 08:57, Dean Budd <dean.b...@gmail.com> wrote:
>>> > (Un)fortunately I've been reading Structure and Interpretation of
>>> Computer
>>> > Programs in parallel with the course (highly recommended!) and saw (and
>>> > analysed) the algorithm before I saw the problem in the course :(
>>> > The Scala Course is pretty much a mirror of the book. I find it very
>>> > valuable. My problem is now juggling two new languages in my head.
>>> Could be interesting to try out the exercises in Scala, and use the
>>> book just for the generic concepts.
>>> cheers,
>>> King
>>> > On Friday, September 28, 2012 11:38:12 AM UTC+10, Branko Juric wrote:
>>> >> The money challenge was a real gem. Took me ages but I was
>>> determined to
>>> >> do no googling to nut it out on my own. It felt so good when I
>>> finally got
>>> >> it :) I will remember that one forever.
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "Melbourne Scala User Group" group.
>>> > To view this discussion on the web, visit
>>> > https://groups.google.com/d/msg/scala-melb/-/FWovFQP4-kMJ.
>>> > To post to this group, send an email to scala-melb@googlegroups.com.
>>> > To unsubscribe from this group, send email to
>>> > scala-melb+unsubscribe@googlegroups.com.
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/scala-melb?hl=en-GB.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Melbourne Scala User Group" group.
>>> To post to this group, send an email to scala-melb@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> scala-melb+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/scala-melb?hl=en-GB.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Melbourne Scala User Group" group.
>> To post to this group, send an email to scala-melb@googlegroups.com.
>> To unsubscribe from this group, send email to
>> scala-melb+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/scala-melb?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Melbourne Scala User Group" group.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
At the risk of getting into a debate about the meaning of words...
When one talks about a "pure" functional language, it means (to me) referential transparency.
So I think of the mutable/immutable axis you were talking about as the functional style, especially in Scala where you have options. To me, OO and type class dispatch are "merely" convenient ways of doing various things in the mutable / immutable styles.
well, without proper value data types in the JVM if you lived solely on
Ben's non-OO orthogonal axis you'd be relegated to resorting to use tuples
for everything - which would feel clunky IMO. I guess you could still
declare classes as purely data structures and not give them any methods at
all - I guess you throw away traits then as well?
Ishaaq
On 11 October 2012 10:42, Andrew Conway <agoo...@greatcactus.org> wrote:
> At the risk of getting into a debate about the meaning of words...
> When one talks about a "pure" functional language, it means (to me)
> referential transparency.
> So I think of the mutable/immutable axis you were talking about as the
> functional style, especially in Scala where you have options. To me, OO and
> type class dispatch are "merely" convenient ways of doing various things in
> the mutable / immutable styles.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
Immutable variables are common. Many people, especially logicians, use
the term variable to mean "free variable." It has been argued that using
the term variable to imply an updating register should be discouraged.
http://existentialtype.wordpress.com/2012/02/01/words-matter/
I have no idea what OO is (and as an aside, I argue, nobody does), but
imperative programming is not in conflict with functional programming.
Indeed, Haskell is a purely functional language that does imperative
programming extremely well.
http://apocalisp.wordpress.com/2011/05/30/imperative-vs-functional-pr...
> it just occurred to me that immutable variable is a total oxymoron,
> but I think you get what I mean :P
> On Thu, Oct 11, 2012 at 6:39 AM, Travis Dixon <the.t...@gmail.com
> <mailto:the.t...@gmail.com>> wrote:
> I got the impression that Martin was going with the line that OO
> is not mutually exclusive with FP
> Didn't he use the first lecture to describe FP as being primarily
> about immutable variables and contrasted with imperative style,
> which is a sequence of machine instructions that update state?
> On Wed, Oct 10, 2012 at 11:37 PM, Ben Hutchison
> <brhutchi...@gmail.com <mailto:brhutchi...@gmail.com>> wrote:
> Speaking of the course, I feel that last week and this week
> have drifted towards "Object-oriented Programming Principles
> in Scala".
> For example, last week's Rational example demonstrated a
> textbook OO implementation. You could just use a tuple
> containing a Numerator and a Denominator field to model a
> rational, alias it as Rational, and write a bunch of functions
> that worked over Rationals. That would be simpler, in the
> sense that you wouldn't need to invent/understand classes or
> OO at all.
> My impressions is that the course is more about teaching Scala
> than teaching functional programming, which is a slight
> surprise because I'd been expecting the opposite emphasis. But
> for a lot of people this could be ideal.
> -Ben
> On Wed, Oct 10, 2012 at 6:43 PM, King Lung Chiu
> <kinglung.c...@gmail.com <mailto:kinglung.c...@gmail.com>> wrote:
> Just to say I've been following the course too and it's been
> interesting to have to think purely recursively and forego
> mutable
> values.
> As a personal exercise, I've also been trying out the
> assignments
> before watching the videos to see how much I already know
> - both Scala
> syntax and data structures / algorithms - so far so good,
> though not
> sure how long this will last :-)
> On 2 October 2012 08:57, Dean Budd <dean.b...@gmail.com
> <mailto:dean.b...@gmail.com>> wrote:
> > (Un)fortunately I've been reading Structure and
> Interpretation of Computer
> > Programs in parallel with the course (highly
> recommended!) and saw (and
> > analysed) the algorithm before I saw the problem in the
> course :(
> > The Scala Course is pretty much a mirror of the book. I
> find it very
> > valuable. My problem is now juggling two new languages
> in my head.
> Could be interesting to try out the exercises in Scala,
> and use the
> book just for the generic concepts.
> cheers,
> King
> > On Friday, September 28, 2012 11:38:12 AM UTC+10, Branko
> Juric wrote:
> >> The money challenge was a real gem. Took me ages but I
> was determined to
> >> do no googling to nut it out on my own. It felt so
> good when I finally got
> >> it :) I will remember that one forever.
> > --
> > You received this message because you are subscribed to
> the Google Groups
> > "Melbourne Scala User Group" group.
> > To view this discussion on the web, visit
> > https://groups.google.com/d/msg/scala-melb/-/FWovFQP4-kMJ.
> > To post to this group, send an email to
> scala-melb@googlegroups.com
> <mailto:scala-melb@googlegroups.com>.
> > To unsubscribe from this group, send email to
> > scala-melb+unsubscribe@googlegroups.com
> <mailto:scala-melb%2Bunsubscribe@googlegroups.com>.
> > For more options, visit this group at
> > http://groups.google.com/group/scala-melb?hl=en-GB.
> --
> You received this message because you are subscribed to
> the Google Groups "Melbourne Scala User Group" group.
> To post to this group, send an email to
> scala-melb@googlegroups.com
> <mailto:scala-melb@googlegroups.com>.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com
> <mailto:scala-melb%2Bunsubscribe@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
> -- > You received this message because you are subscribed to the
> Google Groups "Melbourne Scala User Group" group.
> To post to this group, send an email to
> scala-melb@googlegroups.com <mailto:scala-melb@googlegroups.com>.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com
> <mailto:scala-melb%2Bunsubscribe@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
> -- > You received this message because you are subscribed to the Google
> Groups "Melbourne Scala User Group" group.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
On Thu, Oct 11, 2012 at 1:14 PM, Ishaaq Chandy <ish...@gmail.com> wrote:
> well, without proper value data types in the JVM if you lived solely on
> Ben's non-OO orthogonal axis you'd be relegated to resorting to use tuples
> for everything - which would feel clunky IMO. I guess you could still
> declare classes as purely data structures and not give them any methods at
> all
I think you answered your own concern here :) - yes, use case classes
without methods for data, which are relatives of tuple in that they share a
common superclass Product.
But to put it another way: ignoring inheritance, any class def can be
mechanically transformed into 2 classes: one pure data, one
pure behaviour that operates over the data class, with any significant
performance impacts.
> - I guess you throw away traits then as well?
I don't think type-class style amount to a deprecation of traits. They can
still be used to compose either the behaviour classes ("modules") or less
commonly the data classes. Unless it's changed radically in 7, type-class
library Scalaz uses traits extensively.
Finally, I don't think the typeclass style can address all the use-cases
for OO-style dispatch, and hence some kind of OO-like mechanism will always
be needed. In Haskell, a similar effect is achieved with Existential Types,
which are the underpinnings for OO.
For example: Imagine I have a TrafficLight type with Red and Green
subtypes, and I want to dispatch to different methods per color,
light.speedOfACarAt perhaps. If I throw a heterogeneous collection of light
colors together in a List[TrafficLight], I've lost the specific type
information I'll need to dispatch typeclass-style over the elements.
You can do this, trivially, using OO. But you can also do this by pairing
Existential Types + Typeclasses. I'll try to express the idea in english,
since my Scala existential syntax is too rusty: a List of pairs, each
containing a value of some hidden (existential) type, paired with a
CanFindSpeedOf instance for that same hidden type.
I asked Simon Peyton-Jones about this topic at YOW last year. His reply was
that this encoding was essentially objects, but that "you only pay for
objects when you need them", rather than being on-by-default. Makes sense
to me...
> I asked Simon Peyton-Jones about this topic at YOW last year. His reply was that this encoding was essentially objects, but that "you only pay for objects when you need them", rather than being on-by-default. Makes sense to me...
This relates to my biggest complaint about OOP is that it conflates too many semantic features (each potentially useful in their own right) into one conglomeration.
