Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Melbourne Scala User Group
Home
+ new post
About this group
Join this group
Coursera Functional Programming Principles in Scala
Options
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
   Messages 1 - 25 of 38 - Collapse all  -  Translate all to Translated (View all originals)   Newer >
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Toby Corkindale  
View profile  
 More options Sep 27 2012, 7:20 pm
From: Toby Corkindale <t...@dryft.net>
Date: Fri, 28 Sep 2012 09:17:29 +1000
Local: Thurs, Sep 27 2012 7:17 pm
Subject: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
Hi,
I've been following the Coursera.org course by Odersky, Functional
Programming Principles in Scala.
It's been interesting enough so far.. I don't feel like it's
introduced anything I didn't already know so far (week 2) but it's
been giving me a better understanding of some functional concepts.

Actually, I did learn something new, the arrow symbol here: def fn(x: => int)
Which means, substitute the variable into the body, rather than
calculating it and substituting the result, which is useful for cases
where that variable may not end up being evaluated inside the
function.

If you're following it too, I'm curious to know what you are thinking
of the course so far?

cheers,
Toby

--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Toby Corkindale  
View profile  
 More options Sep 27 2012, 8:20 pm
From: Toby Corkindale <t...@dryft.net>
Date: Fri, 28 Sep 2012 10:11:17 +1000
Local: Thurs, Sep 27 2012 8:11 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
On 28 September 2012 10:01, Ishaaq Chandy <ish...@gmail.com> wrote:

> Am doing it too. It's been interesting, though am hoping that something more
> challenging comes up in upcoming weeks.

> Did you manage to come up with a tail-recursive implementation of the
> money-change problem?

No, but I was rushing for time on that one. Took me ages to get the
basic algorithm for money changing correct; I went off chasing down
the wrong path for a while, then yesterday I caved and googled around
for the right algo, then it was trivial to write a Scala
implementation.

> I've always though of x:=>Int as syntax sugar for the anonymous function:
> x:()=>Int (or x:Unit=>Int) - passing in a function as a parameter has
> similar call-by-name repercussions.

Agreed, but it does result in neater looking code.

--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Travis Dixon  
View profile  
 More options Sep 27 2012, 8:22 pm
From: Travis Dixon <the.t...@gmail.com>
Date: Fri, 28 Sep 2012 10:22:54 +1000
Local: Thurs, Sep 27 2012 8:22 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

I'm doing it and finding similar things.
Mostly stuff I know, well presented and reinforces some good concepts.
Didn't know about the call-by-name feature.

I found the calculate change problem really fun, found a paper on it:
https://subjoin.net/misc/m496pres1.nb.pdf and quite liked how the formula
at the bottom of page one translates almost 1:1 into a scala program.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Jem  
View profile  
 More options Sep 27 2012, 8:29 pm
From: Jem <jem.maw...@gmail.com>
Date: Fri, 28 Sep 2012 10:29:36 +1000
Local: Thurs, Sep 27 2012 8:29 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

I loved the week two work - declaring Set as Int => Boolean and then
implementing various set operations using hofs. Super good fun.
On Sep 28, 2012 10:22 AM, "Travis Dixon" <the.t...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Lachlan O'Dea  
View profile  
 More options Sep 27 2012, 8:37 pm
From: Lachlan O'Dea <lo...@me.com>
Date: Fri, 28 Sep 2012 10:36:58 +1000
Local: Thurs, Sep 27 2012 8:36 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

I found the change problem quite challenging. I managed to nut out a pure functional recursive solution, but did not manage to make it tail recursive. I also had to cheat a bit by sorting the list of available coins up front. The grading robot still gave me 10/10 though, so I gave in to laziness and stopped working on it.

Lachlan.

On 28/09/2012, at 10:22 AM, Travis Dixon <the.t...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ishaaq Chandy  
View profile  
 More options Sep 27 2012, 8:01 pm
From: Ishaaq Chandy <ish...@gmail.com>
Date: Fri, 28 Sep 2012 10:01:31 +1000
Local: Thurs, Sep 27 2012 8:01 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

Am doing it too. It's been interesting, though am hoping that something
more challenging comes up in upcoming weeks.

Did you manage to come up with a tail-recursive implementation of the
money-change problem?

I've always though of x:=>Int as syntax sugar for the anonymous function:
x:()=>Int (or x:Unit=>Int) - passing in a function as a parameter has
similar call-by-name repercussions.

Ishaaq

On 28 September 2012 09:17, Toby Corkindale <t...@dryft.net> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ken Scambler  
View profile  
 More options Sep 27 2012, 8:54 pm
From: Ken Scambler <ken.scamb...@gmail.com>
Date: Fri, 28 Sep 2012 08:54:54 +0800
Local: Thurs, Sep 27 2012 8:54 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

I feel kinda reassured you guys had as much trouble as I did with that damn
money change problem, it took me hours!   It was fun though.

I don't think it had to be tail-recursive did, it?  I managed to eventually
get it working purely with no sorting, non-tail recursive.

The lesson I learnt from it was that the correctness of a recursive
algorithm depends entirely on the degenerate case to unravel it all at the
right point; the first algorithm I thought of was correct, but because I
didn't focus on the degenerate cases up front, it produced rubbish
results.  After cycling through a few different algorithms, it all fell
into place once I put in the right behaviour for trivial inputs.

On 28 September 2012 08:36, Lachlan O'Dea <lo...@me.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Tony Morris  
View profile  
 More options Sep 27 2012, 8:58 pm
From: Tony Morris <tonymor...@gmail.com>
Date: Fri, 28 Sep 2012 10:58:34 +1000
Local: Thurs, Sep 27 2012 8:58 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
I didn't sign up for the course, but I helped a lot of people asking
about the "balanced parentheses?" problem. To me, it is clearly a
problem that is best solved using forallM on the State monad, where the
state value denotes the number of opened left-parentheses. So I went
ahead and solved it that way.

The forallM function is the same as forall, except there is an
"environment" on each type in return position. Here is regular forall:

def forall[A](x: List[A], p: A => Boolean): Boolean

Here is forallM:

def forallM[M[_], A](x: List[A], p: A => M[Boolean]): M[Boolean]

We can denote "the number of opened parentheses" with a natural number
type, which is just List[Unit]. That is, we cons a Unit value each time
we see ( and we tail each time we see ). This is quite similar to many
solutions that I saw, except they used Int instead of List[Unit]. I like
especially-safe type-safety :)

type Nat = List[Unit]

Now we can define state over this thing like so:

case class State[S, +A](run: S => (A, S)) {
  // todo: def map, flatMap, etc.

}

type NatState[+A] = State[Nat, A]

Now the problem is as easy as using forallM on the input data, while
carrying a Nat state to decide on our current position with regard to
opened parentheses. In the event that we find unbalanced, we break out
(forall/forallM do this for us!).

Some protest against this solution in that it is "too complex." However,
it is simply taking existing solutions and abstracting out the common
recursion patterns and code repetition.

Since I don't know the exact rules for the problem, I expect this
solution is not completely within the guidelines. I just chose to
demonstrate how library support and abstraction looks and works in the
context of the problem.

https://gist.github.com/3768490

I don't know the details of the other problems ("coin counting"), but I
am curious.

On 28/09/12 10:11, Toby Corkindale wrote:

--
Tony Morris
http://tmorris.net/

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ken Scambler  
View profile  
 More options Sep 27 2012, 9:20 pm
From: Ken Scambler <ken.scamb...@gmail.com>
Date: Fri, 28 Sep 2012 09:20:22 +0800
Local: Thurs, Sep 27 2012 9:20 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

On 28 September 2012 08:58, Tony Morris <tonymor...@gmail.com> wrote:

> I didn't sign up for the course, but I helped a lot of people asking
> about the "balanced parentheses?" problem. To me, it is clearly a
> problem that is best solved using forallM on the State monad, where the
> state value denotes the number of opened left-parentheses. So I went
> ahead and solved it that way.

> Thanks for that Tony.  It's interesting to see how problems can be

expressed using these kind of abstractions.

I understand, though, that a (the?) use-case for State is to avoid the
repetition of manually threading lots of parameters through recursive
functions without the horror of mutable globals.   In this case there are
only two parameters to thread through the function, so does using the State
monad really pay for itself here?  Your solution looks less clear than a
straight recursive function call to me, although I concede this might just
be a symptom of unfamiliarity on my part.

We can denote "the number of opened parentheses" with a natural number

> type, which is just List[Unit]. That is, we cons a Unit value each time
> we see ( and we tail each time we see ). This is quite similar to many
> solutions that I saw, except they used Int instead of List[Unit]. I like
> especially-safe type-safety :)

> type Nat = List[Unit]

...except that knowing what value the number is will take effort
proportional to the size of the number, at least for List.  Which is fine
if we're just checking for empty/non-empty, but the trivial step of knowing
how many excess parentheses there are becomes unacceptably expensive.  So
I'm not sure the extra type-safety pays for itself here either.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Branko Juric  
View profile  
 More options Sep 27 2012, 9:38 pm
From: Branko Juric <branko.ju...@gmail.com>
Date: Fri, 28 Sep 2012 11:38:05 +1000
Local: Thurs, Sep 27 2012 9:38 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

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.

On 28/09/2012, at 10:54 AM, Ken Scambler <ken.scamb...@gmail.com> wrote:

I feel kinda reassured you guys had as much trouble as I did with that damn
money change problem, it took me hours!   It was fun though.

I don't think it had to be tail-recursive did, it?  I managed to eventually
get it working purely with no sorting, non-tail recursive.

The lesson I learnt from it was that the correctness of a recursive
algorithm depends entirely on the degenerate case to unravel it all at the
right point; the first algorithm I thought of was correct, but because I
didn't focus on the degenerate cases up front, it produced rubbish
results.  After cycling through a few different algorithms, it all fell
into place once I put in the right behaviour for trivial inputs.

On 28 September 2012 08:36, Lachlan O'Dea <lo...@me.com> wrote:

 --
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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Tony Morris  
View profile  
 More options Sep 27 2012, 9:48 pm
From: Tony Morris <tonymor...@gmail.com>
Date: Fri, 28 Sep 2012 11:48:48 +1000
Local: Thurs, Sep 27 2012 9:48 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
On 28/09/12 11:20, Ken Scambler wrote:
> ...except that knowing what value the number is will take effort
> proportional to the size of the number, at least for List.  Which is
> fine if we're just checking for empty/non-empty, but the trivial step
> of knowing how many excess parentheses there are becomes unacceptably
> expensive.  So I'm not sure the extra type-safety pays for itself here
> either.

This is not required to solve the problem. Only cons/tail is required.

--
Tony Morris
http://tmorris.net/


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Tony Morris  
View profile  
 More options Sep 27 2012, 9:56 pm
From: Tony Morris <tonymor...@gmail.com>
Date: Fri, 28 Sep 2012 11:56:03 +1000
Local: Thurs, Sep 27 2012 9:56 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
On 28/09/12 11:20, Ken Scambler wrote:

> ...except that knowing what value the number is will take effort
> proportional to the size of the number, at least for List.  Which is
> fine if we're just checking for empty/non-empty, but the trivial step
> of knowing how many excess parentheses there are becomes unacceptably
> expensive.  So I'm not sure the extra type-safety pays for itself here
> either.

On second thought, perhaps I should point out that List[Unit] is (of same form as) a
church-encoded natural number.

What would it mean to "check the size" of such a thing?

http://en.wikipedia.org/wiki/Church_encoding#Computation_with_Church_...

As far as poor efficiency goes, compared to a machine integer,
operations such as addition run in time proportional to the first
operand. Multiplication builds on addition and exponentiation on that.

If the only operations you are doing are:
* isEmpty: Nat => Bool
* +1: Nat => Nat
* -1: Nat => Nat (invariant: not compose isEmpty)

...then where is the problem?

--
Tony Morris
http://tmorris.net/


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ken Scambler  
View profile  
 More options Sep 27 2012, 10:08 pm
From: Ken Scambler <ken.scamb...@gmail.com>
Date: Fri, 28 Sep 2012 10:07:59 +0800
Local: Thurs, Sep 27 2012 10:07 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

On 28 September 2012 09:56, Tony Morris <tonymor...@gmail.com> wrote:

meant was that if I were writing it for any other purpose the
Church-Encoding wouldn't recommend itself because of its limitations.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ben Hutchison  
View profile  
 More options Sep 27 2012, 11:30 pm
From: Ben Hutchison <brhutchi...@gmail.com>
Date: Fri, 28 Sep 2012 13:30:41 +1000
Local: Thurs, Sep 27 2012 11:30 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
Ive been doing the course too - from the side of a pool in Noosa Heads :)

Pretty similar experience as everyone else, I found money change
tricky, and map() over a Set. Hoping it gets more advanced in later
weeks.

I don't think the money change _can_ be tail recursive in a simple
way, because it requires backtracking. You need to explore 2 lines of
enquiry (a) more of the same coin, and (b) using a different coin. If
one dries up, you go back and continue the other.

-Ben


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ishaaq Chandy  
View profile  
 More options Sep 27 2012, 11:45 pm
From: Ishaaq Chandy <ish...@gmail.com>
Date: Fri, 28 Sep 2012 13:45:14 +1000
Local: Thurs, Sep 27 2012 11:45 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

Yup, the coin-change problem was the most fun to work out, once the insight
finally dawned it was all blindingly obvious and elegant. Though with large
numbers it becomes quite sluggish.

No, I know it didn't have to be tail-recursive, I was just curious if
anyone worked out how to make it so. My best guess would be that it would
have to rely on some sort of memoisation technique, but then you'd be just
replicating having a stack so perhaps you don't gain that much other than
the guarantee that you won't blow the stack, you'll just trade that in for
memory blowouts (possibly).

Ishaaq

On 28 September 2012 10:54, Ken Scambler <ken.scamb...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Tony Morris  
View profile  
 More options Sep 27 2012, 11:48 pm
From: Tony Morris <tonymor...@gmail.com>
Date: Fri, 28 Sep 2012 13:48:36 +1000
Local: Thurs, Sep 27 2012 11:48 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
Ha! I will be up that way on the weekend, writing FP in Scala.

On 28/09/12 13:30, Ben Hutchison wrote:

--
Tony Morris
http://tmorris.net/

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ishaaq Chandy  
View profile  
 More options Sep 27 2012, 11:57 pm
From: Ishaaq Chandy <ish...@gmail.com>
Date: Fri, 28 Sep 2012 13:57:33 +1000
Local: Thurs, Sep 27 2012 11:57 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

Yeah, that's what I would have said too except that after I implemented it
I headed over and read up the relevant section in the SICP book [1] that
introduced the problem, where my pleasure at having coming with the exact
same solution independently was short-lived when I saw that the section
finishes off with an intriguing statement that a tail-recursive
implementation is non-obvious and they left it to the reader as a challenge
- that's what I've been mulling over in the background the past few days
with no good insight.

Ishaaq

[1] http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-11.html#%_idx_728

On 28 September 2012 13:30, Ben Hutchison <brhutchi...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
theGhost  
View profile  
 More options Sep 28 2012, 10:28 pm
From: theGhost <theghost...@gmail.com>
Date: Fri, 28 Sep 2012 19:28:18 -0700 (PDT)
Local: Fri, Sep 28 2012 10:28 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

Hi
I've been following along and so far so good. It seems a pretty slick
introduction to concepts of FP using Scala. What is most encouraging is
number of people who seem to be doing this course - a nice step in bringing
Scala in from the fringes one would hope.
John

p.s. I really sucked counting change. I did eventually get a solution,
though I'm sure not the most elegant. My aspirations of becoming a checkout
chick have been crushed.

p.s.s Go Hawks (relevance to Scala questionable)


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ben Hutchison  
View profile  
 More options Sep 29 2012, 7:45 pm
From: Ben Hutchison <brhutchi...@gmail.com>
Date: Sun, 30 Sep 2012 09:45:06 +1000
Local: Sat, Sep 29 2012 7:45 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

Actually, I have some further thoughts on this course:

One of the exercises in week 2 requires you to generalize Sum and Product
methods.

Then the week 2 problems highlighted the difference in capabilities of Sets
defined via a membership test ("intensionally") or via enumerating it's
members ("extensionally"). Especially in the problem where you have to
define a map() method across a Set.

All this is done without mention of Monoid or Functor. The course teaches
the concepts, but then omits the commonly recognised name for the concepts
that it introduces. Is this helpful?* *Is there a risk that student's do
the problems, but miss out on a deeper understanding of, and language for,
the patterns they encounter? Or is the important learning in the doing, and
the names of patterns a distraction?

-Ben

PS can an intensionally-defined Set be a Functor?

On Sep 28, 2012 9:17 AM, "Toby Corkindale" <t...@dryft.net> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Jem  
View profile  
 More options Sep 29 2012, 7:47 pm
From: Jem <jem.maw...@gmail.com>
Date: Sun, 30 Sep 2012 09:47:39 +1000
Local: Sat, Sep 29 2012 7:47 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

Interesting!

On one hand, sharing a common language provides a lot of leverage and lets
us communicate on a higher level. On the other hand, if the course
mentioned these terms many would groan from fatigue and write it off.
Perhaps Martin will retrospectively label these concepts.

On 30 September 2012 09:45, Ben Hutchison <brhutchi...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Tony Morris  
View profile  
 More options Sep 29 2012, 7:50 pm
From: Tony Morris <tonymor...@gmail.com>
Date: Sun, 30 Sep 2012 09:50:12 +1000
Local: Sat, Sep 29 2012 7:50 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
Hiding terminology is of limited use. Some beginners protest about this.
They are wrong and will probably stay beginners for a while longer.

On 30/09/12 09:45, Ben Hutchison wrote:

--
Tony Morris
http://tmorris.net/

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Branko Juric  
View profile  
 More options Sep 30 2012, 1:58 am
From: Branko Juric <branko.ju...@gmail.com>
Date: Sun, 30 Sep 2012 15:58:00 +1000
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
From a learning perspective I think it's important to first grasp the
core concepts and then discover the patterns and abstractions through
practice. Much more enlightening that way than to merely have someone
point them out.  Those who seek and discover will be so much better
for it when they have that 'aha, so that's what a Monoid is' moment.
Martin's style of teaching I think promotes this style of learning.

Loved week 2 btw.

On 30/09/2012, at 9:50 AM, Tony Morris <tonymor...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Tony Morris  
View profile  
 More options Sep 30 2012, 3:23 am
From: Tony Morris <tonymor...@gmail.com>
Date: Sun, 30 Sep 2012 17:23:06 +1000
Local: Sun, Sep 30 2012 3:23 am
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
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.

On 30/09/12 15:58, Branko Juric wrote:

--
Tony Morris
http://tmorris.net/

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Toby Corkindale  
View profile  
 More options Sep 30 2012, 7:10 pm
From: Toby Corkindale <t...@dryft.net>
Date: Mon, 1 Oct 2012 09:10:18 +1000
Local: Sun, Sep 30 2012 7:10 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author
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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Malcolm Gorman  
View profile  
 More options Sep 30 2012, 8:08 pm
From: Malcolm Gorman <malcolm.gor...@gmail.com>
Date: Mon, 1 Oct 2012 10:08:23 +1000
Local: Sun, Sep 30 2012 8:08 pm
Subject: Re: Coursera Functional Programming Principles in Scala
Print | Individual message | Show original | Report this message | Find messages by this author

Yes, context is very important. Even a cursory mention of the associated
concepts
and their pedigree. An example might be teaching logic without mentioning
truth
tables.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Messages 1 - 25 of 38   Newer >
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google