Application Development Meanderings

Ok, I admit it, after struggling through monads, I know understand them at a basic level and their value.  There are may blogs out there that are really good but I will call out the haskell blog being especially helpful. There seems to be alot of noise, at least 2-3 years ago, around the IO monad in particular. According to the haskell blog, the IO monad helps mark computations that perform IO. Since haskell is a pure functional language, which means no side effects in functions, the IO monad helps delimit the scope of where impure operations are performed. In this use, it is like a marker. However, in scala, which is an impure functional language, functions can have side effects. So is there value in the IO monad? Maybe, but it may be awhile before I see where that value is. Since I can contain side effects and mark them using types e.g. a DAO object for database access, I'm okay for the moment not using the IO monad but I can see where the general concept may be useful for n...

Based on some recent scala work and coming from imperative programming background, reading functional programming code is hard for me. Why? First, the code is rather terse and dense. The terseness derives from the ability to use operator-like characters as  function names. Java does not allow this so its usually easier to read the methods. Java's method name conventions generally make the code easy to read. This comes at the expense of verbosity. Scala can use normal function names as well and most libraries provide both the function name as well as a terse equivalent. Second, its not always clear what design pattern is being implemented. Java has a few generally accepted approaches to writing code. Iterating over a list can only take a few forms. Creating some IO classes generally takes on only a few forms as well. The singleton pattern is implemented only in a few ways. If you are unfamiliar with functional programming, it takes awhile to recognize these types of patte...