+1 for Odersky's presentation style. He does a really excellent job.
I think the lecture content was too superficial though. For comparison,
years ago, as a Mech Eng student, I took a first-year Melbourne Uni subject
which used the Miranda language. Perhaps my memory is faulty, but I
remember it as a more in-depth introduction to the functional approach than
this present course. It certainly involved much more homework. I expected
more from a course which required at least a year of previous programming
experience.
I thought that the assignments were great. If anything, they seemed to be
pitched at a level somewhat above that of the lectures. It often seemed to
me that a person who could complete the assignments without significant
problems would learn rather little from the accompanying lectures. Again,
maybe that's just me. :-)
Finally, I found it somewhat frustrating that Coursera chose to run the
course within a fixed time period. Personally, it would have been nice to
be able to put it on hiatus for three or four weeks to cope with activity
spikes elsewhere.
On Tue, Nov 13, 2012 at 1:15 PM, Jonathan Merritt <j.s.merr...@gmail.com>wrote:
> It often seemed to me that a person who could complete the assignments
> without significant problems would learn rather little from the
> accompanying lectures.
Agree. After the second week I skipped most of the lectures and just did
the assignments.
> Finally, I found it somewhat frustrating that Coursera chose to run the
> course within a fixed time period. Personally, it would have been nice to
> be able to put it on hiatus for three or four weeks to cope with activity
> spikes elsewhere.
(a) a habit from "real-people" courses where the lecturers cannot be
bottled,
(b) real people must be scheduled to manage forums and handle assessment
anomalies,
(c) concerns about solution-sharing,
(d) a perception (probably true) that people will be more motivated by
studying together. Certainly, this thread would be less likely to exist if
we'd all taken the course at different times.
Some of the oldest (ie 2 years!), most established courses, like
https://www.coursera.org/course/db, offer a self-study mode, and I reckon
it will become widespread once the courses can basically "run themselves"
> --
> 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.
From the exercises I have seen (people posting questions mostly), I
think there is something to be learned by solving them with he
assumption of significantly better library support. The result being a
very different means by which to view the problem and subsequent solution.
> On Tue, Nov 13, 2012 at 1:15 PM, Jonathan Merritt
> <j.s.merr...@gmail.com <mailto:j.s.merr...@gmail.com>> wrote:
> It often seemed to me that a person who could complete the
> assignments without significant problems would learn rather little
> from the accompanying lectures.
> Agree. After the second week I skipped most of the lectures and just
> did the assignments.
> Finally, I found it somewhat frustrating that Coursera chose to
> run the course within a fixed time period. Personally, it would
> have been nice to be able to put it on hiatus for three or four
> weeks to cope with activity spikes elsewhere.
> (a) a habit from "real-people" courses where the lecturers cannot be
> bottled,
> (b) real people must be scheduled to manage forums and handle
> assessment anomalies,
> (c) concerns about solution-sharing,
> (d) a perception (probably true) that people will be more motivated by
> studying together. Certainly, this thread would be less likely to
> exist if we'd all taken the course at different times.
> Some of the oldest (ie 2 years!), most established courses, like
> https://www.coursera.org/course/db, offer a self-study mode, and I
> reckon it will become widespread once the courses can basically "run
> themselves"
> -Ben
> Jonathan Merritt.
> -- > 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.
It's a pretty minor complaint, but the sound levels on the lectures
were terribly quiet.
I had the volume up to max everywhere, and still struggled to hear
them through my laptop speakers.
(Of course it was fine on powered speakers or headphones, but
sometimes I can't be bothered..)
Not just you, I found the sound quality to be fairly poor, and also could
use some normalisation as there were dramatic changes in volume at a few
points.
On Tue, Nov 13, 2012 at 2:05 PM, Toby Corkindale <t...@dryft.net> wrote:
> It's a pretty minor complaint, but the sound levels on the lectures
> were terribly quiet.
> I had the volume up to max everywhere, and still struggled to hear
> them through my laptop speakers.
> (Of course it was fine on powered speakers or headphones, but
> sometimes I can't be bothered..)
On 13 November 2012 13:58, Tony Morris <tonymor...@gmail.com> wrote:
> **
> From the exercises I have seen (people posting questions mostly), I think
> there is something to be learned by solving them with he assumption of
> significantly better library support. The result being a very different
> means by which to view the problem and subsequent solution.
If you're referring to the higher-level abstractions in Scalaz and Haskell,
I think there's something to be said for learning to solve problems by hand
on one level before moving on the next. For instance, the State monad
makes a whole lot more sense if you've solved a bunch of problems manually
threading half the world through function arguments. Do you prefer to
see these concepts introduced up front?
> From the exercises I have seen (people posting questions mostly), I think
> there is something to be learned by solving them with he assumption of
> significantly better library support. The result being a very different
> means by which to view the problem and subsequent solution.
I think it'd be useful to cover both approaches.
First, solve the problem through first principles using existing API.
Then identify the pain points and show what a better library can do,
and how it changes the way you can solve the problem.
Ideally, at the second stage, you also go deeper and go through how
the better library is actually designed to avoid the pain points from
the first solution.
Solving through first principles, and then identifying the pain
points, gives you motivation and better understanding & appreciation
for the better library.
You can of course skip the first step and go straight to the better
library, if the problem is trivial enough to understand. But whether a
problem is trivial is often subjective and depends on the individual.
> On Tue, Nov 13, 2012 at 1:15 PM, Jonathan Merritt <j.s.merr...@gmail.com>
> wrote:
>> It often seemed to me that a person who could complete the assignments
>> without significant problems would learn rather little from the accompanying
>> lectures.
> Agree. After the second week I skipped most of the lectures and just did
> the assignments.
>> Finally, I found it somewhat frustrating that Coursera chose to run the
>> course within a fixed time period. Personally, it would have been nice to
>> be able to put it on hiatus for three or four weeks to cope with activity
>> spikes elsewhere.
> Fixed time frame's are the norm for MOOCs right now, perhaps because
> (a) a habit from "real-people" courses where the lecturers cannot be
> bottled,
> (b) real people must be scheduled to manage forums and handle assessment
> anomalies,
> (c) concerns about solution-sharing,
> (d) a perception (probably true) that people will be more motivated by
> studying together. Certainly, this thread would be less likely to exist if
> we'd all taken the course at different times.
> Some of the oldest (ie 2 years!), most established courses, like
> https://www.coursera.org/course/db, offer a self-study mode, and I reckon it
> will become widespread once the courses can basically "run themselves"
> -Ben
>> Jonathan Merritt.
>> --
>> 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.
> On 13 November 2012 13:58, Tony Morris <tonymor...@gmail.com> wrote:
>> From the exercises I have seen (people posting questions mostly), I think
>> there is something to be learned by solving them with he assumption of
>> significantly better library support. The result being a very different
>> means by which to view the problem and subsequent solution.
> If you're referring to the higher-level abstractions in Scalaz and Haskell,
> I think there's something to be said for learning to solve problems by hand
> on one level before moving on the next. For instance, the State monad makes
> a whole lot more sense if you've solved a bunch of problems manually
> threading half the world through function arguments. Do you prefer to see
> these concepts introduced up front?
> --
> 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.
> Do you prefer to see these concepts introduced up front?
Yes. I used to be of a different opinion -- that it was "advanced" and
so introduction should be "delayed." In fact, it is just less clumsy,
simpler and more obvious, particularly if you abandon previously held
conceptions. It is this that I like to encourage in a learning setting
and I have since come to the opinion that appeasing that clumsiness is
more a hindrance than anything -- rather, I'd prefer to develop
techniques to swiftly overcome that hurdle.
> Yes. I used to be of a different opinion -- that it was "advanced" and
> so introduction should be "delayed." In fact, it is just less clumsy,
> simpler and more obvious, particularly if you abandon previously held
> conceptions. It is this that I like to encourage in a learning setting
> and I have since come to the opinion that appeasing that clumsiness is
> more a hindrance than anything -- rather, I'd prefer to develop
> techniques to swiftly overcome that hurdle.
It's certainly a big time saver to go directly to the better solution,
you just need to make sure it's clear to the student what problem it's
trying to solve.
My maths teacher used to tell us that it's OK to look at answers if
you're stuck, as long as you don't skip the derivations afterwards.
> --
> 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.
> Agree. After the second week I skipped most of the lectures and just did the
> assignments.
I think the only downside here is not knowing which api / technique
you're meant to exercise in the assignment.
While doing the Huffman coding problem (before watching the lecture),
I kept wondering "Am I doing this wrong? How come it's so simple? Am I
meant to avoid using maps etc and build my algorithms with simpler
constructs?".
Then I had a quick scan of the lectures and found out that I was on
the right track.
... then there was a slight disappointment that yes, it was that simple ... :-)
>> Finally, I found it somewhat frustrating that Coursera chose to run the
>> course within a fixed time period. Personally, it would have been nice to
>> be able to put it on hiatus for three or four weeks to cope with activity
>> spikes elsewhere.
> Fixed time frame's are the norm for MOOCs right now, perhaps because
> (a) a habit from "real-people" courses where the lecturers cannot be
> bottled,
> (b) real people must be scheduled to manage forums and handle assessment
> anomalies,
> (c) concerns about solution-sharing,
> (d) a perception (probably true) that people will be more motivated by
> studying together. Certainly, this thread would be less likely to exist if
> we'd all taken the course at different times.
> Some of the oldest (ie 2 years!), most established courses, like
> https://www.coursera.org/course/db, offer a self-study mode, and I reckon it
> will become widespread once the courses can basically "run themselves"
> -Ben
>> Jonathan Merritt.
>> --
>> 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.
>> Yes. I used to be of a different opinion -- that it was "advanced" and
>> so introduction should be "delayed." In fact, it is just less clumsy,
>> simpler and more obvious, particularly if you abandon previously held
>> conceptions. It is this that I like to encourage in a learning setting
>> and I have since come to the opinion that appeasing that clumsiness is
>> more a hindrance than anything -- rather, I'd prefer to develop
>> techniques to swiftly overcome that hurdle.
> It's certainly a big time saver to go directly to the better solution,
> you just need to make sure it's clear to the student what problem it's
> trying to solve.
> My maths teacher used to tell us that it's OK to look at answers if
> you're stuck, as long as you don't skip the derivations afterwards.
No skipping.
I'd prefer to inadvertently manipulate a student into constructing a
less degenerate solution on their own (completely on their own), so that
when they try to argue (and often they will!) that it is too
complicated, I can point out that it is, in fact, *their* solution.
Watching someone come to terms with this dilemma is quite entertaining
as well as insightful. The dumbstruck look of someone trying to unify
the fact that it is their own, simple solution along with their deeply
held belief that "but it is too complicated and obtuse and crazy!" is
often followed by euphoria and abandonment of the contradiction (the one
fails to fit observation).
