Comments for Casual Miracles

Comment on A Small Example of the Scalaz IO Monad by channing

channing — Fri, 06 Jan 2012 20:50:08 +0000

No worries, thanks for pondering it.

Comment on A Small Example of the Scalaz IO Monad by missingfaktor

missingfaktor — Fri, 06 Jan 2012 13:07:45 +0000

I am sorry I am unable to think of an example to support my point. When I come across one, I will let you know.

Comment on A Small Example of the Scalaz IO Monad by missingfaktor

missingfaktor — Fri, 06 Jan 2012 13:06:32 +0000

Welcome. In this case, none. The effects are easy to visualize for the small examples. Even though `printNamesInIo` uses an impure function, its type signature still tells the truth. So it’s perfectly fine. In more complex cases though, you may end up with functions whose type signatures lie (e.g. `IO[A]` instead of `IO[IO[A]]`, and thus lead to early execution of effects, and perhaps incorrect interleaving with other effects etc.

Comment on A Small Example of the Scalaz IO Monad by channing

channing — Wed, 04 Jan 2012 21:23:21 +0000

Thanks What sort of trouble is likely to arise?

Comment on A Small Example of the Scalaz IO Monad by missingfaktor

missingfaktor — Wed, 04 Jan 2012 21:07:31 +0000

Mixing regular impure functions (such as println) with the effectful functions using IO monad is asking for trouble. You should wrap usage of impure functions with io or use their monadic counterparts.

For example: http://paste.pocoo.org/show/530040/.

Comment on Type Names From An Earlier Age by Channing Walton

Channing Walton — Tue, 28 Sep 2010 06:45:39 +0000

> From the point of view of a class that must make use of the OrderBook, all that matters is that the OrderBook is sent something like write(…), delete(…) or find(…) messages with the appropriate arguments. How it writes, deletes or finds is irrelevant,

It should be said that the only rule here is that only domain level concepts should be passed to those methods. There should be no persistence-specific information like an ID or some such.

Comment on Rank, Authority and Power by Ben Fuchs

Ben Fuchs — Thu, 09 Sep 2010 06:30:14 +0000

Subtle (and not so subtle) rank dynamics organise much of how we behave at work. This is especially true when there is conflict or the pressure is on. Recent developments in neuroscience confirm that changes in status (or threats of change) in a social system, trigger limbic brain responses.

It is easier to see how others’ rank and power impacts upon us, rather than how our own rank impacts upon them. In many protracted conflict situations, each side sees itself as the victim or underdog.

By raising awareness of our own rank, we can empower ourselves to make the changes we wish to see. We can recognise the (unintended) impact we may be having on others.

Comment on TDD from a Control Theory Point of View by channing

channing — Tue, 18 May 2010 15:02:30 +0000

Hi Benson!

I think it depends where you are. Where I am now there is widespread acceptance. In my experience, those that believe that they are capable of writing perfect software without tests have a different definition of working software to me

Channing

Comment on TDD from a Control Theory Point of View by Benson Hoi

Benson Hoi — Tue, 18 May 2010 13:24:03 +0000

Interesting article! What do you think is the main reason that there is no widespread acceptance of the TDD methodology?

Comment on Writing Maintainable Acceptance Tests by David Kemp

David Kemp — Tue, 09 Mar 2010 02:56:39 +0000

Nice blog. I often find that acceptance tests catch serious regressions missed by unit tests. It is too easy to change a class and its tests to satisfy a change of requirements and then find that your change breaks some assumptions made elsewhere. I find unit tests good for driving the code (and design), but acceptance tests good for catching regressions. As for randomness, I used to scoff at code that used the current date for everything until some tests started breaking one leap year! Yes it would be better if we had tests that covered leap years etc, but the guy who wrote the tests didn’t think of doing it at the time. Randomly generated dates may have picked the problem up sooner!