How we all going with the Coursera Scala course?

[Ben Hutchison]

Fellow Course-takers,

I've been a while since we last swapped opinions and reactions on Martin's Scala FP course. Well, the lectures are done, and the final assignment due next.Who's still following along and doing the homework? How are you finding it?

Myself, I have a few opinions to air:

- I am learning heaps from doing the assignments. Something about the way they are structured just forces me to learn. My use of monads got alot more fluent after the anagram assignment too.

* The unit test failure notifications in the assignment code suck!

This: assert(solve(solution) == Block(goal, goal))

results in: org.scalatest.exceptions.TestFailedException

Doh! 

Just for contrast, in my preferred Specs2 style using "eg", this:

 {URLOps.extension(new URL("http://domain/MyPhoto.jpg")).mustEqual(Some("jpg"))}.eg

results in: 

URLOps.extension[new URL["http://domain/MyPhoto.jp"]].mustEqual[Some["jpg"]](11)

java.lang.Exception: 'Some(jp)' is not equal to 'Some(jpg)'

Its a bit flaky at times, but basically it extracts the source code of the example into the test output.

-Ben

[Jem]

The last assignment almost broke me. Because the provided test coverage was so low and I got lazy and didn't write my own. I spent yonks debugging. Finally I realised that I had mixed around my x and y vals way back in the find Block function. Iirc there was a test for this to find the start Block(1, 1). So that passed. : )

Martin has a great way of delivering the material. I really loved the course and hope for a follow-on.

--
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...@googlegroups.com.
To unsubscribe from this group, send email to scala-melb+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scala-melb?hl=en-GB.

[Kamal Advani]

My (n00b) observations, keeping in mind that practically all my
knowledge of Scala has come from this course and any "digressions"
while attempting to solve the assignments, additionally I have not
done the last assignment yet (grrrr so little time, so much to do), so
this set of observations is missing any insight from those:

* It has altered my view of the language -- I still think that it is
BIG. But, certainly a lot of thought seems to have been put in to make
the features work together -- and I think, I can accept the idea of a
scalable language. In a way, it reminds of Perl which I used very
briefly at my first job -- the idea that it was not trying to be
C-like with a small core, but it wanted to scale as you learnt more
idioms, etc.

* Operators as essentially functions, leading to requiring conventions
in function names to determine precedence, associativity, operand
count -- wow. Crazy cool.

* I have had a blast rewiring my brain to think recursively, and more
importantly without mutation, no vars.

* Corollary to the last point, Persistent Data Structures -- neat
stuff, answers my questions on whether functional programming a lot of
copying around to return immutables.

* Until I did the assignments, it never really sunk into me just how
bottom-up FP (at least as portrayed in the course can be), and in many
ways it makes sense -- it's too complicated (again, for a noob like
me) to think of the entire solution while worrying about immutability
-- but breaking it down into chunks, suddenly it's an easier problem
to deal with. I know it sounds obvious, but the functional
decomposition is almost a must.

* Everything returning values is something I am getting used to, e.g.
in an imperative for loop, the body can easily execute "void"
functions (I know that is probably an oxymoron).

* For-Comprehensions and their translation into "standard" map/filter
is neat. This was easy to grasp, because in Python, Guido's rationale
for the similar/equivalent List Comprehensions was as a nicer view on
map/filter.

* I do find the types a little difficult, while learning the IDE
tooltips on what is returned to (inferred by the IDE) some val has
been er... invaluable (pun really not intended, but things do work
out!), but that's mainly, I hope, because I am not yet familiar with
the common type hierarchies.

* The IDE, at least on Linux... is flaky, it crashes every now and
then... hopefully it will improve, I don't wish to compare it to the
JDT, because they are different beasts, but still... annoying when you
want quick feedback and it locks up.

* I don't have any off the top of my head -- but I found several
expressions that sbt console happily accepted, but in Eclipse I had to
group by brackets. Any light shed on this (if valid) much appreciated.

* I am fairly impressed at the brevity most of the time, closure
expressions certainly help, but type inferencing I think is key in a
statically-typed language.


Personal notes:

* It sucked big time that I could not figure out the last bit of
sentenceAnagrams -- the part on using the third generator and yielding
the generated word against the sentence, recursively. It was a mental
block that was hard to eradicate -- I kept thinking of merging 2 lists
separately imperatively; sigh. So sad and unl33t.

* Generally, I have struggled with time and personal commitments, but
this is understandable, I am thankful that the assignment length was
extended to 10 days, otherwise it would have been difficult. I already
got zero marks for the assignment prior to anagrams, for late
submission from a remote part of Java (the island in Indonesia, not
the language, but things work out) when on holiday -- at least my
answers were all correct :-P.

* I am much more keen on actually learning the language better, I
could not bring myself to invest in it before.

Have fun all.





--
Out beyond ideas of wrongdoing and rightdoing, there is a field. I
will meet you there.
-- Rumi

[Kamal Advani]

On Thu, Nov 8, 2012 at 10:54 PM, Kamal Advani <ka...@namingcrisis.net> wrote:
> extended to 10 days, otherwise it would have been difficult. I already
> got zero marks for the assignment prior to anagrams, for late
> submission from a remote part of Java (the island in Indonesia, not

<defensive>
Actually, that was Huffman, thankfully I managed that one, it was an
awesome assignment - I failed Week 3, OO Sets.
</defensive>

[Kamal Advani]

On Thu, Nov 8, 2012 at 10:18 PM, Jem <jem.m...@gmail.com> wrote:
> Martin has a great way of delivering the material. I really loved the course
> and hope for a follow-on.
>

His sincerity in teaching really shows I think. Digressing a bit, for
some reason Martin kept reminding me of Niklaus Wirth, that too from
reading a compiler book by Wirth -- so it was cool to find out that
Mr. Odersky spent his grad years with the famed langs creator. :-)

[King Lung Chiu]

--

[King Lung Chiu]

> I've been a while since we last swapped opinions and reactions on Martin's
> Scala FP course. Well, the lectures are done, and the final assignment due
> next.Who's still following along and doing the homework? How are you finding
> it?

It's been great. I've really enjoyed the course.

In terms of the assignments:

I found the 2-week long Huffman coding assignment relatively straight
forward and finished it in 2 hours (plus another hour reviewing what
I'd done).

Whereas the shorter, week-long Anagrams assignment was actually way
harder for me and took me 2 solid days to work out the correct
algorithms. Then another day to nut out the optimisations. Well worth
the time though; learned a lot.

I've found that the key to these exercises have been to get the
algorithms right. Once you have that, implementation was actually
pretty quick and straight forward.

Or, looked another way, I find the Scala (FP) syntax clean enough to
use as a thinking aid / pseudo code without cluttering up my thoughts.

Being forced to avoid mutable variables also had a nice side effect of
forcing you to think more recursively - the call parameters are now
your variables - and the algorithms that result are often quite clean
and succinct.

And yes, I look forward to part 2 if/when they decide to run it.

cheers,

King

>
> Myself, I have a few opinions to air:
>
> - I am learning heaps from doing the assignments. Something about the way
> they are structured just forces me to learn. My use of monads got alot more
> fluent after the anagram assignment too.
>
>
> * The unit test failure notifications in the assignment code suck!
>
> This: assert(solve(solution) == Block(goal, goal))
>
> results in: org.scalatest.exceptions.TestFailedException
>
> Doh!
>
> Just for contrast, in my preferred Specs2 style using "eg", this:
>
> {URLOps.extension(new
> URL("http://domain/MyPhoto.jpg")).mustEqual(Some("jpg"))}.eg
>
> results in:
>
> URLOps.extension[new
> URL["http://domain/MyPhoto.jp"]].mustEqual[Some["jpg"]](11)
> java.lang.Exception: 'Some(jp)' is not equal to 'Some(jpg)'
>
> Its a bit flaky at times, but basically it extracts the source code of the
> example into the test output.
>
> -Ben
>

[Tony Morris]

I didn't do how the course. However, I am curious of how you used a monad to solve anagrams.

--

[Travis Dixon]

I've been a while since we last swapped opinions and reactions on Martin's Scala FP course. Well, the lectures are done, and the final assignment due next.Who's still following along and doing the homework? How are you finding it?

Loving it, just started going through the final set of lectures this morning, looking forward to the assignment.

Agree with other comments on MO's teaching style, the presentation is extremely clear and logically organised.

Having spent a fair bit of time with scala, but still not calling myself an expert, I found I knew a lot of the content already, however I went in without knowing anything about the substitution model, which is in my mind the most valuable feature of this course.

I also found I had tons of gaps that going through the lectures and assignments filled in (assuming I retain it)

Interestingly enough, I found the deadline extensions demotivating, I was far more on top of things when it was a bit of a push to fit it in.

The mathematical proof lectures were interesting, and I'm glad that such a solid backing exists for this form of coding, however I can't see it being something I use in most of my daily work.

I didn't do how the course. However, I am curious of how you used a monad to solve anagrams.

What's a monad ;)

I used that rose tree structure I was bugging you in IRC about

[Ben Hutchison]

If it helps, I totally missed the x/y switch myself, until your email last night! Extremely unusual to put y before x; deliberate trap perhaps? My solution didn't ever refer to the fields explicitly however, so wasn't affected.

And I had the same laziness with unit tests, preferring println debug hackery.

Ben

[Ben Hutchison]

Oh, I pipelined through the Anagram Monad using the flapMat operator ;)

Seriously though, just used lots of garden-variety list and option flat mapping..

Ben

[Gary Khominsky]

I had a very pleasant experience. This Wednesday night was so “empty” for me after having seven weeks of fun with Scala/FP.

I believe, it is a very good course. It has been well structured and presented.

Each week lecture materials prompt you to look deeper inside of both Scala and programming as general. Assignments were well created as well. They had an extra “theory” material [link between theory to practical field] as well as a practical exercise. Some of them were harder then others. However each of them has some challenge. I kept assignments without submitting for a few days after getting all my tests passed. I used this time to address a problem again, re-factor and improve both logic and performance. I forced myself to read/view lecture materials first [before attending an assignment] even if I knew the assignment’s domain well before hand. Doing this way was more enjoyable and productive for me.

However it is over. The last assignment was submitted last week.

Having said that I’d like to keep a momentum and do more Scala/FP programming.

Call me if you need a hand. ;-)

Cheers,

 -- Gary K

-Ben

--

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...@googlegroups.com.
To unsubscribe from this group, send email to scala-melb+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scala-melb?hl=en-GB.

--
      -- Gary

A = X + Y + Z
      “If A is success in life, then A equals x plus y plus z.
       Work is x; y is play; and z is keeping your mouth shut.” - Albert Einstein
   
 

[Toby Corkindale]

Hi,
I've been enjoying the course and the assignments. My understanding of
Scala has FP has certainly improved.

I have struggled with the assignments at times, not because of my
Scala comprehension, but because I didn't know the relevant algorithms
to achieve a result. For both the making-change and anagrams
assignments, I went a long way down the wrong path before researching
the "right" way to do it, and then being able to implement it in Scala
without a huge amount of trouble.

I guess it's been a long time since I did that kind of thing at uni;
maybe some people still remembered the right way to attack the
problems, when I was having to figure it out again from first
principles. (Or, maybe not? But I felt like that aspect of the course
was harder and outside the topic being taught)

-Toby

[Branko Juric]

Enjoyed the course a lot and am missing the lectures and assignments already.  All assignments were fun.  The most challenging one for me was Anagrams, but Huffman and Bloxorz were the most fun.  Did spend more than 5-7 hours of learning a week (about double that) but it was well worth it and very rewarding. 

The biggest learnings for me were:

- recursion (and mastery of accumulator functions)

- the substitution model (reinforcement of pass by name and value)

- streams (only do what is necessary)

- currying (for reuse and elimination of redundancy)

Regarding Anagrams, the recursive combinations solution was elegant but extremely inefficient. Writing a memo version eliminated redundant recursions but not without rewriting sentenceAnagrams as sentenceAnagramsMemo.  Would be good if references to other solutions that do not require rewriting were published (I suspect this could be possible through traits or some other functional pattern perhaps).

Regarding Bloxorz, in addition to the provided unit tests, Bloxorz.scala can also be run as a standalone scala app.  It runs the solver over the infinite terrain which the unit tests do not.  I discovered that the grader does not test the infinite terrain scenario.  I think this is very pertinent to testing stream based solutions and should be graded.  As a result you can submit a solution that fails on the infinite terrain and still gives you full marks.  

On Thu, Nov 8, 2012 at 10:11 PM, Ben Hutchison <brhut...@gmail.com> wrote:

-Ben

--

[Xuefeng Wu]

+1

The assignments are challenging me and help to improve understand what learned from video.

I'm eager for next course!

--
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...@googlegroups.com.
To unsubscribe from this group, send email to scala-melb+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scala-melb?hl=en-GB.

--

吴雪峰/ Alan  敬上

[Jem]

I'm curious. How can you write a test of an infinite domain that passes in a finite time?

[Branko Juric]

Here is a very minimal test based on the code in Bloxorz.scala.  The solver should return with one solution.

test("inifinite terrain") {

  object InfiniteLevel extends Solver with InfiniteTerrain {

    val startPos = Pos(1,3)

    val goal = Pos(5,8)

  }

  val result = InfiniteLevel.solution

  assert(false === result.isEmpty)

[King Lung Chiu]

On 9 November 2012 12:16, Branko Juric <branko...@gmail.com> wrote:

...

> Regarding Anagrams, the recursive combinations solution was elegant but
> extremely inefficient. Writing a memo version eliminated redundant
> recursions but not without rewriting sentenceAnagrams as
> sentenceAnagramsMemo. Would be good if references to other solutions that

Perhaps we can discuss this offline, but I'm curious how much change
you needed to make to rewrite it as sentenceAnagramsMemo.

For me, (after quite a bit of thinking) the main algorithm ended up
remaining largely the same, including the recursions.

The only (minor) difference is that the memoised version has the
smarts to skip the recursive calls for previously calculated subsets.

> do not require rewriting were published (I suspect this could be possible
> through traits or some other functional pattern perhaps).

Maybe there's a Scalaz monad for that! :-)

But in terms of my own implementation, after looking at it again, I
see that my two functions can actually be merged into a curried
version and then simply specialised with a different inner loop - one
using the original and the other using the memoised version, and then
with implicits sprinkled at a couple strategic places ...

[Jem]

Thank you. I read "infinite terrain" as there being an infinite space between the start and finish cells.

[Tony Morris]

A quick way of doing this is passing a memo table around in the state monad.

e.g. case class MemoState[A](run: Memo => F[(A, Memo)])  {// where F is your existing monad.
  def map, flatMap, etc.
}

PS: why discuss offline?

[King Lung Chiu]

On Nov 10, 2012 9:16 AM, "Tony Morris" <tmo...@tmorris.net> wrote:
>
> A quick way of doing this is passing a memo table around in the state monad.
>
> e.g. case class MemoState[A](run: Memo => F[(A, Memo)])  {// where F is your existing monad.
>   def map, flatMap, etc.
> }

Thanks Tony.

>
> PS: why discuss offline?

In case our discussions reveal too much about potential assignment solutions.

From their email several weeks ago:

---
We are saddened to report that some students have been uploading the solutions of the weekly exercises to public spaces. As you might have guessed, this is a clear violation of Coursera honor code article 3 ( https://www.coursera.org/maestro/auth/normal/tos.php#honorcode).
...

Thus, as a bottom-line: If you have uploaded solutions to any public space, including github, please remove them ASAP or face immediate expulsion.
---

Cheers,

King

[Tony Morris]

I guess we better not discuss it then, for the purposes of excellent
learning of course :)

I've never been one who takes kindly to being told how to talk. YMMV.

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

[Ken Scambler]

Alrighty!  Last minute Bloxorz submission is go.  I had some good fun thinking through the algorithm, and was almost disappointed to realize that the solution was almost identical to the Water Pouring problem in the lecture and didn't require nearly so much ingenuity. :)

I really enjoyed the course.   I knew most of the lecture content up until the later weeks, but the assignments with recursion had a way of tripping me up for hours (coin change, huffman, anagrams especially).  The one thing they all had in common is that the functional solution always ended up being really small and clear, and kinda obvious in hindsight.   I clearly need more practice!

[Jonathan Merritt]

+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.

Jonathan Merritt.

[Ben Hutchison]

On Tue, Nov 13, 2012 at 1:15 PM, Jonathan Merritt <j.s.m...@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.

[Tony Morris]

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.

[Toby Corkindale]

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..)

Was that just me?

[Travis Dixon]

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.

[Ken Scambler]

On 13 November 2012 13:58, Tony Morris <tonym...@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?

[King Lung Chiu]

> 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.

cheers,

King

[King Lung Chiu]

+1

(and our emails just crossed)

[Tony Morris]

On 13/11/12 13:11, Ken Scambler wrote:
> 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.

[King Lung Chiu]

> 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.

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

[King Lung Chiu]

> 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 ... :-)

[Tony Morris]

On 13/11/12 15:08, King Lung Chiu wrote:
>> 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).