http://www.zengularity.com/item/1519646134/functional-web-functional-programing-for-web

For a long time, and due to the lack of main FP concepts in most mainstream languages, we missed opportunities to abstraction and code expressiveness and conciseness. With today’s democratization of FP, Computational Abstraction is what will enable us to be less dependent on specific programming language syntax offering; creating libraries of control structures and composition forms that help find concise and expresive solutions to enterprise programming challenges (null, lists treatment, error handling), capturing elegantly important business concepts in code, and programming at the right level of abstraction.For a long time, and due to the lack of main FP concepts in most mainstream languages, we missed opportunities to abstraction and code expressiveness and conciseness. With today’s democratization of FP, Computational Abstraction is what will enable us to be less dependent on specific programming language syntax offering; creating libraries of control structures and composition forms that help find concise and expresive solutions to enterprise programming challenges (null, lists treatment, error handling), capturing elegantly important business concepts in code, and programming at the right level of abstraction.

Slides:  http://sadekdrobi.com/wp-content/uploads/2009/12/Computation-Abstraction666iiioii6jjjjjjhjj-5.pdf

Google wave:  https://wave.google.com/wave/#restored:wave:googlewave.com!w%252BPgcakhgiA

Code included here is over simplified for clarity, I hosted a better implementation code on CodePlex. These modifications change strictly nothing for the client code and are only an implementation detail. I use a continuation rather than a delay, and I chose to design a custom continuation class rather than using a delegate because of a type system limitations.

Most GUI frameworks, including Silverlight and WPF, are shipped with a fundamental problem: long use of the main thread causes the Window to blackout, and using different threads requires you to get your hands dirty with the Dispatcher stuff and freezable objects. Worse, you wont learn the necessity to do so until you get a surprise of “The calling thread cannot access this object because a different thread owns it.” exception when all what you were doing is to use available methods on an object that seemed you have access to, at lease it seemed until runtime! This post illustrates a solution based on Monads abstraction and LinQ syntax.

This is a problem you get often when applying Model View Presenter pattern [MVP]. There, your view (which is a WPF control) implements a contract IView that the presenter in its turn will use to extract values and then make operations on the view.

interface ISayHello { string GetName(); Unit SayHello(string name); }

class MyLoginControl:Control,ISayHello {

//this interface gets implemented by the corresponding control as texboxes and a text area…

}

The problem appears when for doing any realistic responsive application, the presenter (representing business operations if you’d like) will have to run on a background thread to leave the main thread free for graphics rendering.

While working on a background thread, the presenter needs to access the view (having a reference to it through a contract) and there something wrong happen “The calling thread cannot access this object because a different thread owns it.” . 

The problem here is simply that the view is giving quite a promise that it simply can not satisfy which is implementing the IView contract.

The view cannot satisfy the ISayHello contract under all circumstances, and not even under a commonly desirable condition (the presenter or business code running on another thread). This fact is simply not communicated through the type.

The solution I suggest to this problem that I implemented and employed in a production real world project is based on the LinQ syntax added to C# last year. In the solution I use two things: an extension method and a special type.

The type that I use is the monadic type (thanks to Wesdyer for his enlightening posts): View<T>

So in my case my type will be View<IView> which means that what I am offering here is a a type that acts under some special circumstances as the Contract ISayHello . If I want for example to extract the name from the WPF control, I need to do something with the View<ISayHello>. 

Using the View<T> Monad:

And here comes the LinQ syntax for help. Having a reference to View<ISayHello>, the only way with which I can access the desired value or methods is using Linq:

Having the view contract:

I can extract a view monad that I can pass to the presenter as View<ISayHello> 

note the type View<ISayHello> which is somehow useless without the LinQ syntax:

and you can also use several contracts in the same expression:

Implementation of the View<T> Monad:

View<T> is not really special. It is just a Delay<T> which is a Func<T>. And the Select implementation is the same one for functions and is not special at all:

The fact that I am defining a new delegate type here (View<T>) is because we don’t have type synonyms is C#. And because of this I had to reimplement all the Select methods for this type. Of course all of that Monad plumping code is invisible and all the user needs to do is use the LinQ syntax.

The only specific part about the View monad, is the way you extract it. For Wpf for example the .AsView implementation looks like:

Which merely tells about how to execute the delay when applied.

This is the code responsible for calling on WPF windows using dispatcher and other plumping details. Again code here is simplified for clarity. In the same way one can implement an AsView extension method for Silverlight with no need to change the Select implementation. View<T> is a generic monad and contain nothing specific to GUI technology.

Conclusion

The Monad generalization provides a good solution for WPF/Silverlight thread problem. The solution is barely about communicating through the type system the fact that WPF/Silverlight controls are special, and using LinQ expression to operate on them leaving the plumping (Dispatcher.Invoke, Freezable) to the monad library implementers. Also this frees the caller from thread logic that is specific to the implementation technology.

In my project I didn’t work much on the freezing/unfreezing of Wpf controls (copy them and extract them to other threads) as it actually wasn’t necessary for my project. However, I think that a proper implementation of .AsView for WPF/Silverlight that manages Freezable and nested Freezable objects copying would be very interesting and would complete the API.

PS: I decided to finish this draft quickly as I am not having enough time to finish properly. Please tolerate typos and don’t hesitate to ask questions.

We did put abstraction after abstraction onto our distributed system infrastructure and you know what: it hasn’t worked out that well for us. Some of the largest and most sophisticated distributed systems on the planet haven’t been all that large or sophisticated and then this kind of crappy protocol comes along that insists on being synchronous, and insists on being text-driven and it scales globally. That’s shocking and does not make sense to us as engineers. That’s the web paradox – it’s the rubbishest thing on the planet, but it scaled and for me that is what’s hit the reset button because I was totally up for XML-based protocols that do all sorts of funky stuff.

Recently, I’ve been working on a Web Api system where, thanks to support of @jeanlaurent http://morlhon.net/blog/, I used Scala applying DCI architecture in a real world project. This post is about reporting benefits of using this approach. Other posts will follow that will be more focused on the use of Scala and Functional Programming in that project. Code included is a bit simplified and parts of the system that are not of interest are omitted.

The concerned part of the system is an API for logging a Web API usage and using it for showing interesting statistics to users and for implementing a Web 2.0 business model authorization.

The story starts with an API key passed as a parameter in the requested URI something like product/1234?api_key=AFFSEFFVFE2344

I create an object that represents the API user containing the key: (did I tell I like one liners?)

This is a class of an object that holds the apiKey, now I need a method that I will call to log the use of product/123 for user represented by the apiKey AFFSEFFVFE2344. What could be quite convenient and OOP-iesh is to call a record method on the apiKey instance, something like apiUser.record(…) . The problem with this, as explained in the original DCI article, is that adding these methods to the domain objects adds noise in other contexts for which recording is not relevant such as authorization and statistics, as we will see later. I would rather use here the DCI’s role concept (or context). Doing so I would say (apiUser in recording role).record(…) . This pseudo code tends to be very close to mixins implemented in Scala language and will look like following in real world Scala code:

Here the ApiUser object doesn’t contain a record method by default and so it can be shared in different contexts. In other words we kept our domain objects pure yet not scarifying OOP convenience. Now the Recorder is a trait that minds only business in the context of recording. The definition looks like the following:

Another view of the system is the end user’s statistics. Statistics should be represented in a meaningful way to the user and the user can’t care less about how the recording is done. So, it is quite desirable not to have the noise of recording when talking about the statistics view context. Here is how the call looks like in our example in Scala:

Again what we are doing here looks merely like saying: I want to use the ApiUser in a statistics context and I choose to call method getRequestsPerMonthForLast12Months. I guess the convenience brought by using this approach is obvious. This is how the Statistics trait looks like:

Note that as in the Recording trait, the ApiUser object is not passed as an explicit parameter but rather as an implicit receiver parameter (something like this for an object). To access it we use Self that refers to it.

The third view of the system is what allows us to provide an authorization mechanism based on user’s activities for a business plan they choose (be it a quota per day, per month or other interesting combinations). It could be quite convenient to have the call looking like apiUser.isAuthorized . We get pretty close with DCI without polluting our domain object with a specific context logic:

Like the previous, the Authorizer trait looks straightforward :

Now that we looked at the three views of our system introducing three examples of “Context” from DCI pattern we can go beyond that to discover how we use nested contexts (or roles).

Looking at the Authorizer trait, the ApiUser referred to by Self, doesn’t tell us much about how many requests the user did today or this month. And for authorizing user one needs a richer ApiUser that can give the necessary information that live themselves in a file or a database. But once again, we don’t want to pollute our domain object with Data Access code that varies on a different axis than the domain object itself.  Introducing a nested context/role that adds the Data Access logic would pretty convenient here:

Here Self is a richer ApiUser that carries Requests Data Access logic defined in the RequestsDataAccessor trait:

And the implementation of the Authorizer trait defined in terms of ApiUser with RequestsDataAccessor:

In the same way we implement the Statistics and Recorder traits using ApiUser with RequestsDataAccessor:

If you are not familiar with generics ( getRequestsPer[Day] ) you can ignore them since they are not central to the subject of this post and simply use their readability to understand the purpose of the method. The use of generics in this project will be the subject of a future post.

Encapsulation Test!

Now in the first version of the system, the ApiKey was passed in clear in the service URI. This is not very secured as it is quite easy to get the key and use it for using the API. We might prefer to encrypt the key in some way. This fortunately changes nothing for any of our traits implementations since the decryption of the key is the responsiblity of the ApiUSer object and all what our traits need is to get the concerned ApiKey from that object which can be easily done with pattern matching. Same thing if we want to replace database logging with file system in RequestsDataAccessor. Modularity and separation of concerns are apparent in this DCI architecture implementation.

Conclusion

This is a refreshing approach to OOP. The Domain Context Interaction pattern allowed us to restore interesting properties of real OOP approach yet not sacrificing modularity and separation of concerns. This simple view of “an object in several contexts” helps quite much in thinking explicitly about and understanding context boundaries. Note that an object(instance) is not defined by a single class but each instance curries the necessary context. This is essential to OOP which is NOT COP (for Class Oriented Programming ;) )

Feel free to ask questions and/or comment about this implementation. Refer to original papers for more in-depth explanation of the pattern.

Thanks to JetBrains’ IDEA and the Scala plug-in that helped me programming in Scala.

http://www.infoq.com/news/2009/05/dci-coplien-reenskau

In the generics design, there were a lot of very, very hard constraints. The strongest constraint, the most difficult to cope with, was that it had to be fully backwards compatible with ungenerified Java. The story was the collections library had just shipped with 1.2, and Sun was not prepared to ship a completely new collections library just because generics came about. So instead it had to just work completely transparently.

That’s why there were a number of fairly ugly things. You always had to have ungenerified types with generified types, the so called raw types. Also you couldn’t change what arrays were doing so you had unchecked warnings. Most importantly you couldn’t do a lot of the things you wanted to do with arrays, like generate an array with a type parameter T, an array of something where you didn’t know the type. [..]

When Java first shipped, Bill Joy and James Gosling and the other members of the Java team thought that Java should have generics, only they didn’t have the time to do a good job designing it in. So because there would be no generics in Java, at least initially, they felt that arrays had to be covariant. That means an array of String is a subtype of array of Object, for example. The reason for that was they wanted to be able to write, say, a “generic” sort method that took an array of Object and a comparator and that would sort this array of Object. And then let you pass an array of String to it. It turns out that this thing is type unsound in general. That’s why you can get an array store exception in Java. And it actually also turns out that this very same thing blocks a decent implementation of generics for arrays. That’s why arrays in Java generics don’t work at all. You can’t have an array of list of string, it’s impossible. You’re forced to do the ugly raw type, just an array of list, forever. So it was sort of like an original sin. They did something very quickly and thought it was a quick hack. But it actually ruined every design decision later on.

Programming with a Mainstream Language

Track: Functional and Concurrent Programming Languages Applied

Time: Thursday 17:15 – 18:15

Location: Abbey Room

Abstract:

Using functional programming (FP) in enterprise software development is often quite a challenge. In this presentation, Sadek Drobi will talk about his experience of applying functional programming principles on a real-world project in relation with existing non-functional frameworks.

In the year 2008 and just on the release of C# 3.0 and Linq, which is basically several FP concepts implemented on C# language, Sadek Drobi worked as a tech lead on a project where functional programming approach was used to meet performance requirements and to achieve desired response time. Facing similar issues, a mainstream architect would strive to instantiate less objects and to use mutation for optimization. Considering the big amount of data that had to be processed on each request, Sadek chose to do it otherwise: no mutation, used memorization, laziness, recursion, functions, curry, monads, list comprehensions and, then, parallelization to yield an almost purely functional core domain model.

Sadek Drobi will talk more about this experience and elaborate on the good and the bad of going almost extreme through a functional programming approach from different perspectives.

Participants don’t need to be functional programming experts even if having some knowledge about LinQ will spare you too much hard thinking during the session. Each new concept will be briefly introduced and the structure of the talk will be as non-sequential as possible so that its parts can be understood and analyzed separately.

In short, I do believe that Spring framework forced you for a long time to use a subset of Java, a subset of frameworks you use, and has been implicitly very intrusive on all the frameworks that support it. It constrains innovation and limit choices. And more!

Unfortunately I would not be able to list in this post all the arguments I have because of lack of time. I would rather provide few examples that shows why the Spring culture is unacceptable for me. Of course you can reply saying that Spring will support this, or is supporting this starting with version x. Well I am afraid I don’t care. Spring existed for a long time now, and my judgement is based on a long history. Besides what I am targeting is the culture of the framework.

First of all, if you want to use Spring Beans you need to believe in magic. Don’t agree?

class MyServiceClass {
  private IMyDao myDao;
  // Other stuff goes here.
}

this field "myDao" is never initialized, not by any constructor and it is private. But if you believe in magic, then you can use it. Because you know what? There is a wizard config file that you can find if you search enough in your project that will "inject" it. What?!!

First of all this solution violates member visibility rules in Java. But ignoring that, this results in a practice or a habit to ignore a never initialized field believing in magic! A framework that offers and advocates such a violating is not worth even trying IMHO!

Now the suggested solution is to write a setter for this field that then will be used by Spring, but this changes nothing as anyway you will either make it public (allowing any public user of your API to set you DAO!) or put it back private and back to the never initialized field! Did I mention "final" yet? :)

Spring claims that it is not intrusive. What? Now imagine that you remove Spring from your dependencies list, your application is no more useful and you suddenly get null pointer exception everywhere my friend! Who will inject the private field? or a private setter? This claim is ridiculous!

Now did it happen to you to forget to declare or mistype your beans in your config? What happens? Runtime exception! What? I thought Java applications are statically typed!

Now I can hear you, use annotations! Annotations solves your problem! Well I am afraid not. Annotations like @Required or @AutoWired is just like begging the user not delete the field or property, and it is not mandatory and not forced by any checker. Remember, I am talking culture here…

Now if you are a defender of injection using constructors, then I believe you got something right and most probably you reject most of the hacks I mentioned above (Including setters based injection, private field injection,  aspects based injection (in short 80% of what Spring Beans mainly offers and actually does)). But then, you turned anyway your architecture dependency into dynamic, never checked and its composition specified in desperate XML files! Think of code navigability, and software flow and dependencies that you can not trace without the help of a debugger using this approach.

Oh, what about JavaConfig. Well yeah, I do not need Spring to do that! "new", you remember the keyword "new"? yeah OOP, new, instances. That is Java programming. Trust me "new" is no evil, and guess what, you need no dependencies to any framework to resolve your dependencies in a statically checked, navigable, readable, simple, clear, elegant, concise, safe and beautiful way!

Last thing for now, you need to learn Spring-FU to use any, any framework that wasn’t designed specifically for use with Spring and yet you may not succeed (though framework designers are forced to be distracted by Spring design when defining their architecture, for examples see Restlet and Jersey) ! That reminds me of something…

YAGNI!