Application Development Meanderings

As you may have noticed, I have published a few blogs on using the scalaz library.  As I have worked through some examples, I had a growing feeling that scalaz was hard to use. For someone new to scala, this is true (let's ignore the lack of documentation issue for now). Why is this so? After thinking about, I realized that scalaz is designed to implement solutions to a variety of functional problems. These typically involve monoids and other structures. Monoids operate at a small scale. In other words, they are each designed to do a very small job. Because each part of the library is designed to do a very small job, they are ideal for implementing software using small, concise layers. Since monoids encode the programmer's intent into the type system (e.g. State, Reader, Writer), scalaz has many types of class that all perform small, monoidal jobs. The scalaz library is not designed to be a full dependency injection library, say like spring or guice. spring implements a

As I was working through some content on the Reader monoid, I realized I wanted to lift a function to use it. If you read the Scala In Depth book, which as a really great book, you know that lifting a function to be monoidal could be useful. The classic example is to lift the function so that the arguments as well as the return value are all Option types. Then, if any of the parameters to the new lifted function are None, the function returns None. Otherwise it would return Some. The key thought is that you do not have to write your own, scalaz already supports lift. It turns out that scalaz has support for lifting functions using your monoid of choice. Below is a transcript using scala REPL  with a -cp set to the scalaz core library: See the entire post on  github .

Someone asked how you run the code examples on my blog. I have started using gisthub to store the entire blog, including code. To run the code, simple go to the gisthub. Cut and paste the code into a file. Then run it through the scala REPL. I do scala -cp ./scalaz-core_2.10-7.1.0-M2.jar  yourFile.scala Where yourFile.scala is the file that you save the cut and paste into.

I just put together a short blog on the Reader monad in scala, its similarities to State and some mentions about comparisons to spring dependency injection. You can find the article on  github.

As a follow up to my last post about no free lunch I wanted to show more state monad usage and recognize that you can change function return types in the middle of a for-comprehension. This allows each function to return different types of values from the computation along the way. In the code below, you compose a function by using the for-comprehension. The yield part of the for-comprehension is a State object. When that state object is called, it returns a tuple of (state, value). You can use ._1 or ._2 to obtain the value of interest. The last composed function shows an example of changing the state type (instead of changing the returned value type mentioned above)  in the middle of the for-comprehension using scalaz IndexedState's iPut and iModify. This allows you to change the type of state as you go to adapt to different function's API needs. The entire article is at  gisthub .

I was working on using the State monad in my cake example, but needed to fiddle with some simple examples first. The code below can run in the scale REPL. The main thought is that if your system is already setup to handle the state type already, say by sharing a cache, then you modify your code to return states and the State monad can help you sequence and ensure that the state information is available for each function call. However, if you are accessing resources that do not return state information structurally aligned with your state value, you still have to use some ugly code to convert a function's return value to the structure needed by your state. When using the state monad, you can pull that code out of the functions you are calling which is good, but you still have that code and its still messy--no surprise here. It's clear though that the components you are using must be designed to use the same state structure. This last point effectively makes this design patte

It has taken me awhile to understand monoids and their use. Once you get the hang of it, they make a lot of sense as a design pattern for structuring your code. Either, Option, Try are all monoids that can help structure your code and adapt existing code without changing the existing code or they help in structuring new code. It also took a while to understand for-comprehensions as well. It turns out that switching monoids types in the middle of a for-comprehension is not impossible but difficult. Its best if each statement in the for-comprehension has the same monoid return type. On gisthub: https://gist.github.com/aappddeevv/6530787 in case it does not display below correctly. 1: 2: // Define functions that return an Option 3: def f1(x: Int): Option[Int] = Some(x*30) 4: def f2(x: Int): Option[Int] = Some(x+3) 5: def f3(x: Int): Option[Int] = Some(x*2) 6: 7: // Sequence the computation, it will be successful 8: var answer = for { 9: x <- f1(30) 1

I realized I need to be able to explain the differences between the cake pattern in scala and spring dependency injection. As in my last post, I wanted to understand how to compose objects to build applications. I've become a scala fan because alot of things make sense, although it takes a long time (at least for me) to learn a more functional style. The reason I want to compare the cake pattern to spring dependency injection is because each approach has trade-offs. I'll try to call those out more carefully than I have seen written elsewhere. There are a number of blogs you can find on the cake pattern and it is a pattern often covered in functional programming books. Here we go... Composing Using Plain Old Java Lets ignore all dependency injection for the moment and just think about plain java. We want to compose objects. For example, we have a software component that is dependent on other components. In java, we have two ways to handle this. Inheritance and Bean Prop