Thoughts on Reactive programming course week 2...

[Ben Hutchison]

As in the earlier course, I find that Martin's lectures cover things that I presume I already know about, but somehow he tends to fill in the theory so that I come out with a stronger foundation. For example, the de-sugaring of for expressions, or his take on purity-vs-state.

I found the second weeks' homework challenging. Other's find similar? 

It makes me wonder whether anyone doing the course has got time to look,at ScalaJS next week. or if we'd prefer to concentrate on the course?

One thing I didn't like much was the EpidemySimulator code and especially its' unit tests. The use of 4 exposed state variables that the tests manipulate seems a good example of how *not* to write code. I actually had a correct implementation, but it was failing the test because of assumptions the tests made.

If the course is attempting to teach good 'Stateful' programming techniques, they should introduce finite state machines with actions that trigger on state transitions, IMHO. The epidemic model would be better modelled with an FSM than with 4 raw booleans, and would have been more testable.

-Ben

[Ken Scambler]

I suspect they deliberately designed it as a system where random things happen at different times to wean us into the async and actor stuff in later weeks.  If you were designing the system for it's own sake I can't you'd introduce these mutable shenanigans.

The course is going to keep me flat out in my hacking time...

--
You received this message because you are subscribed to the Google Groups "Melbourne Scala User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-melb+...@googlegroups.com.
To post to this group, send an email to scala...@googlegroups.com.
Visit this group at http://groups.google.com/group/scala-melb.
For more options, visit https://groups.google.com/groups/opt_out.

[Toby Corkindale]

On 18 November 2013 22:00, Ben Hutchison <brhut...@gmail.com> wrote:

> As in the earlier course, I find that Martin's lectures cover things that I
> presume I already know about, but somehow he tends to fill in the theory so
> that I come out with a stronger foundation. For example, the de-sugaring of
> for expressions, or his take on purity-vs-state.
>
> I found the second weeks' homework challenging. Other's find similar?

It took me a bit less than four hours to complete; I did have to check
the forums a couple of times before realising I had something
backwards in the circuit simulator's demux problem. I wish there was a
pre-existing unit test for that. Would have saved a lot of time
chasing down my logic (which was ultimately correct apart from that..)

> One thing I didn't like much was the EpidemySimulator code and especially
> its' unit tests. The use of 4 exposed state variables that the tests
> manipulate seems a good example of how *not* to write code. I actually had a
> correct implementation, but it was failing the test because of assumptions
> the tests made.

Likewise, that stuff screwed up my otherwise fine simulator. I guess I
designed it a bit differently to how they imagined? But it would have
otherwise been impossible to end up with a person in that state whilst
still have events queued that were incompatible.
I suppose it's good programming to check all your conditions just in
case though.

Otherwise, I enjoyed the epidemy simulator more than the other problems so far.
TC

[Ben Hutchison]

With actors, they receive a message, which lets them respond to it. Fair enough. What I specifically have a problem with is stuff like:

    val chosenOne = es.persons.head

    chosenOne.infected = true

    chosenOne.sick = true

    chosenOne.dead = true

    chosenOne.immune = false

That code should be something like:

chosenOne.die()

That's still an "actor compatible" style..

-Ben

[Bryan Murphy]

I had the same thoughts.  It felt a little bit like amateur hour with some of the the provided code and tests.  I ended up changing some of my code to make sure they would pass the tests even though I thought the tests were dodgy.  I originally had the starting infected persons decided using a random technique but the tests wanted an exact number so it would fail some of the time (eg when there were 2 or 4 rather than 3 which is 0.01 of 300).  The test you highlighted below also seemed dodgy and required extra tests to check against conditions that would not occur if the simulator was run like it was supposed to.  Of course, the whole use of multiple publicly exposed booleans rather than encapsulated states was code you would only expect from a graduate if you saw it at work.  I wanted to change it  but thought the marking system would get confused

I am also expecting to revisit the simulator when we get to Actors where hopefully a more state transition based approach is able to be used .

I also thought the Demux exercise was not well specified with quite a bit of assumed knowledge of binary numbers and logic gates.  I found some references to circuit designs in the discussion forums which actually helped.  A couple of tests would have been helpful to ensure one interpreted the question correctly.

There was also an update to the assignment zip file, presumably to fix problems, which I saw references to on the forum but nothing official on the main pages.  I  updated mine before starting the Epidemy problem so I am not sure what they fixed and how big a problem it would have been to only have the original zip.

Still, they are only minor quibbles and I continue to enjoy doing the course.

The graphic display was pretty good.  It was odd that they didn't display dead people with a distinct color but I found it was fairly straight forward to modify the code to do that.

Bryan 

[Toby Corkindale]

On 19 November 2013 00:19, Bryan Murphy <br...@murphynet.id.au> wrote:
> I originally had the starting infected persons decided using a
> random technique but the tests wanted an exact number so it would fail some
> of the time (eg when there were 2 or 4 rather than 3 which is 0.01 of 300).

I hit that as well. I was a bit annoyed, but on the other hand, I can
see that there could be merit in ensuring your initial data always has
an exact amount.
Eg. With my original method (which had a 1% chance per person of being
infected) there could potentially be a run that had zero infected.

[Jem]

I had no problem with the Epidemy exercise, thanks to the visualiser. But I found the demux troublesome. Eventually I realised I shouldn't fold the output wires with the control wire, but create intermediate output wires instead.

The code quality of Epidemy was poor, I agree. But it was nowhere near as mind-bendingly convoluted as the stuff Martin wrote in week 1 (and also in the previous course) where methods would ignore the callee and use the parameter. For example `emptyHeap.isEmpty(nonEmptyHeap) == false`.

[Xuefeng Wu]

Yes, if there are demux unit test would help much. I mistake the high-low order for controller and output, wast much time to find how to reverse the controller. Only high position controller could select half part of output.

And the epidemy simulator is interesting, but I hard to understand rule 1 at first. Sorry my English Reading...

It's very funning to do exercise and expand programming thinking model. 

--
You received this message because you are subscribed to the Google Groups "Melbourne Scala User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-melb+...@googlegroups.com.
To post to this group, send an email to scala...@googlegroups.com.
Visit this group at http://groups.google.com/group/scala-melb.
For more options, visit https://groups.google.com/groups/opt_out.

--

~Yours, Xuefeng Wu/吴雪峰  敬上

[Branko Juric]

Assignments are definitely fun and challenging. A nice change actually from the mundane Java enterprise application programming I currently have to contend with in my day job. It is much more clunky and infested with side effects. As someone once said, you have to juggle eggs in your head.

--

[Bernard Leach]

The problem I had with the EpidemySimulator is that I found it enabled me to write poor code.  I found my self slipping into the bad practices that the first course worked hard to eradicate.  I have no problem with state/mutability but this solution seemed more the advertisement of how to write an application that was difficult to reason and debug (and perhaps that was the intent - 'and hey here's a great solution to that problem - actors!').

[Tony Morris]

Snake oil.

> --
> You received this message because you are subscribed to the Google
> Groups "Melbourne Scala User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scala-melb+...@googlegroups.com.
> To post to this group, send an email to scala...@googlegroups.com.
> Visit this group at http://groups.google.com/group/scala-melb.
> For more options, visit https://groups.google.com/groups/opt_out.

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

[Ken Scambler]

Hey Tony,

Could you elaborate for our benefit?  Is it just the way they've modelled the assignments, the whole thrust of the course, the reactive buzzwordy stuff, all of the above, or....?

Cheers,
Ken

[Ben Hutchison]

On Tue, Nov 19, 2013 at 12:48 AM, Jem <jem.m...@gmail.com> wrote:

The code quality of Epidemy was poor, I agree. But it was nowhere near as mind-bendingly convoluted as the stuff Martin wrote in week 1 (and also in the previous course) where methods would ignore the callee and use the parameter. For example `emptyHeap.isEmpty(nonEmptyHeap) == false`.

Yes, Week 1 used a distinctly non-OO style based around "Modules of functions". I actually like that style, it gets elegant when you use those modules as typeclasses and can write the functions in infix position. But I was interested that Martin, who has been a consistent advocate for object-orientation generally, should choose this style in his own exercises.

-Ben

[Travis Dixon]

I found the fact that the compiler allowed you to use heaps in a fundamentally incorrect way to be extremely poor.

Importing object members would seem far more appropriate

--

[Tony Morris]

I highly recommend reading up on process calculi and CCS (Milner). The best I can do for now is to promise many laughs at this recent explosion of "reactive programming."

Perhaps a recommended first step is to recognise the difference between "event-based programming" and "reactive programming." A difference that could not be any more disparate between any two other arbitrary nouns.

[Ken Scambler]

One of the things that annoys me about Scala is the confusion between the different ways of saying "this is what I can do for you" and "this is what I need to be given to do my job".     To me, the former belongs in public interfaces, and the latter in private constructor arguments.   When the two coincide, fine, use the in-place val syntax in constructors, or use a case class.   

However when the required input for a task gets arbitrarily divided between constructor arguments and abstract members, a whole lot of pointless confusion arises.   For one, you satisfy the dependency with a "new" call, and values.  With the other,  you design a trait, and statically mix it in; they are totally incompatible.  If the value happens to be a function, it gets even more confusing because of the difference with methods, and the nicer syntax for declaring methods. And of course, if you are mixing in traits to satisfy internal requirements, you take on a type that advertises menial implementation details; Logger, StampLicker, ShoeLaceTier, etc.   

My conclusion is that constructors are the only appropriate way to take required input to a class; Cake pattern be damned.    This means that until traits get constructor parameters, I seem to use abstract classes more than others do.   Mixins are still useful, just for connecting implementations to interfaces in a reusable way.

[King Lung Chiu]

And of course, if you are mixing in traits to satisfy internal requirements, you take on a type that advertises menial implementation details; Logger, StampLicker, ShoeLaceTier, etc.   

My conclusion is that constructors are the only appropriate way to take required input to a class; Cake pattern be damned.

That's actually the main issue I have when cake patterns / mixins are recommended as a way to get dependency injection in Scala: the whole thing just doesn't look right as you're exposing internal dependencies and polluting your public interface.

[Ken Scambler]

I can't believe I hadn't heard of that, it sounds really useful.  Can you recommend any entry-level tutorials?  Is there any part of the Scalaz library that exposes the core concepts?

[Ben Hutchison]

I dont understand what you are meaning here by "incorrect way". Can you give an example of misuse?

Ben

[Travis Dixon]

Jem already did:

emptyHeap.isEmpty(nonEmptyHeap) == false

[Travis Dixon]

maybe it's my bias from working almost exclusively with callee style systems, 

but having publicly accessible functions attached to instances, that have no implementation connection to that instance, 

it seems to make it very easy to write programs that look like they match your intent, and still compile, but in fact are not at all what you intend

[Ben Hutchison]

Actually, "emptyHeap.isEmpty(nonEmptyHeap)" does not typecheck. Here's the Heap trait:

trait Heap {

  type H // type of a heap

  type A // type of an element

  def ord: Ordering[A] // ordering on elements

  def empty: H // the empty heap

  def isEmpty(h: H): Boolean // whether the given heap h is empty

  def insert(x: A, h: H): H // the heap resulting from inserting x into h

  def meld(h1: H, h2: H): H // the heap resulting from merging h1 and h2

  def findMin(h: H): A // a minimum of the heap h

  def deleteMin(h: H): H // a heap resulting from deleting a minimum of h

}

The empty heap is of type H, the hidden type of the data representation for a Heap implementation. H has no isEmpty method.

I suspect there's a logical isomorphism between Martin's Heap module and a typical object-oriented representation, although the syntax appears quite different.

-Ben

[Jem]

Ha! That put me in it. Yes, I was making stuff up.

But this is lifted directly from Heap.scala:

trait Heap {

  type H // type of a heap

  ...

  def empty: H // the empty heap

  def isEmpty(h: H): Boolean // whether the given heap h is empty

}

As I read it, any Heap can call `isEmpty` with an H which the comments insist (at least 7 times) is a "heap", but in its implementation (BinomialHeap) it is actually a List[Node]. Node itself is a roll-your-own linked-list of List[Node]. I don't find this intuitive.

[Ben Hutchison]

This is the "de-sugaring" of object-orientation. 

What's going on when we define a class and create an instance of it, in the actual computer, is that a bunch of subroutines are stored in one bit of memory, and the data for that instance (eg List[Node]) is stored somewhere else, along with a "class" pointer referencing the associated subroutines.

Metaphors about objects sending and responding to messages are appealing and maybe have intuitive appeal, but Martin's code is much closer to how OO code executes on a machine.

-Ben

[Ishaaq Chandy]

On 19 November 2013 21:47, Ben Hutchison <brhut...@gmail.com> wrote:

Metaphors about objects sending and responding to messages are appealing and maybe have intuitive appeal, but Martin's code is much closer to how OO code executes on a machine.

Regardless of whether or not this code-style has merits, am not sure that this particular argument is a good one in favour of it. If it were, one could argue that machine-language supersedes any other language out there, followed by assembly language. The whole point of moving away from those languages is that humans find it hard to think about and construct large, complex programs in terms of how code actually runs on machines.

[Jem]

I wonder why the creator of the language would insist on writing in a de-sugared style. Doesn't he like his own language's features? :)

I'm currently viewing week 3 videos. I don't think I'll ever get used to Erik Meijer's sense of humour. And he even manages to get that awful shirt of his into the slides!

--

[Travis Dixon]

No love for Meijer?  Jem you have no heart!  

After his super enthusiastic Yow keynote on nosql == cosql I still can't think of him without grinning :P

[Toby Corkindale]

On 20 November 2013 16:22, Jem <jem.m...@gmail.com> wrote:
> I'm currently viewing week 3 videos. I don't think I'll ever get used to
> Erik Meijer's sense of humour. And he even manages to get that awful shirt
> of his into the slides!

I was going quite well with the week three lectures, until the last
two. I think partly it was just my attention wandering by then, and
partly still taking in concepts from earlier.. but I didn't get much
sense out of them.

I mean I picked up on the main concepts, but wasn't actually that
convinced that the non-recursive methods were actually as superior to
recursive solutions as Erik seemed to think. Certainly were less
clear.