One of the few things that lack seriously, IMO, in C# is the power of Java checked exceptions. In Java world? things happen weirdly. Maybe it is a result of crowd intelligence and a bad side effect of open source. Often, people in J2EE world tend to believe the opposite. Anyway you see the effect in most preferred frameworks (such as today’s popular ORMs and Containers) of wrapping checked Java exceptions and rethrowing them as runtime ones.

I guess offering runtime exceptions together with compile time ones did a hole in the Java type system, but this hole was left to discipline, in a way of giving the tools and letting smart enterprise programmers decide for the right tool for the job. Things turned to happen differently in the enterprise world.  Programmers abused of this freedom of choice and mainstream frameworks designers decided to dismiss and bury one of the most interesting features of the Java type system.

Why do I like Java checked exceptions? Well simply because it saves me from surprises. And I tend not to like surprises much!

The funny thing is that, in my experience, it is mostly architects that dismiss Java checked exceptions whereas Compile time exceptions are a very good asset for cleaner and bug free architecture.

I just take a look at a “standard” DAO method that gets an entity

Customer getCustomer(CustomerId id);

This method lies! what if there is no connection? what if the Id is incorrect? The signature of the methods gives quite a promise that under all circumstances it will returns a Customer. Now for any architecture this is bad. It used to be better before some popular frameworks decided to completely omit it! Before? well I used to control my architecture better!

Before these “good practices” become mainstream, imposed in mainstream frameworks, It used to be often more predictable the return type a method has. For my example, the signature would tell me that the method will either return a customer OR throws a “Dao Exception”.

Customer getCustomer(CustomerId id) throws DaoException;

No surprise. Now when I use this method, I will certainly need to handle the case when the method will return something else than a Customer. Now of course, a Java “enterprise developer” could do one of to things:

1- Out of laziness or incompetence, keep rethrowing data access exceptions up until you’ll have to deal with it up in the GUI logic (where handling an infrastructure error does not often belong)

This often sounds for me the main argument for dismissing Java Compile Time Exceptions claiming that it is a “code boilerplate”. The thing is that you’ll have to deal with these exceptions once even when you turn them into runtime. The fact of wrapping them into runtime does not eliminate them (even if I wish it did). But having them as compile time will make easy to spot where a “bad” developer did not handle the exception correctly simply by following the signature and type system. Then the solution will be to wrap them into more business friendly, context meaningful Compile Time Exceptions that need to be handled. This way the contract communicated better the result of executing a piece of logic.

This turns to be as useful for “void” return type methods. With Compile Time Exception a method can simply communicate the fact that it will either return “void” or will throw an exception to be handled.

2- Out of laziness or incompetence, frustrated developers will start “catch”ing checked exception without rethrowing them.

This one is a result of the hole in the type system that is left intentionally to leave some place for flexibility relying on discipline. Nevertheless, and before the big favor of generous frameworks I mentioned earlier, this turned out to be an easy problem to spot. Most IDEs and code analyses tools can find easily empty catch clauses and warn me about them.

I often get surprised of the limited use of Java language wealth in enterprise J2EE applications!

Good thing: C# and .Net are introducing checked exceptions together with other DbC stuff (like non null objects) in the next release. Sad thing: Java has Compile Time Exceptions since version 1, open source chose to unvalue them!

In my trip through Haskell programming I keep discovering how clean and enjoyable the language is. By the end I am someone that loves doing abstractions and I guess I’ve found my world.

I discussed with some colleagues lately how a programming language creates a whole culture around it. This culture inherits from language properties and shapes the language programming style.

Take for example Java; there are a lot of different ways to program in java. The java syntax does not force you to program OOP. It is just more convenient to do so. Same thing goes with other programming languages. However it is not only about paradigm, it is really about a whole mindset.

While programming a web site with Haskell, I was searching for a function that parses a string to return me an int. As I’ve been for a long time a C#/Java programmer I expected to find a simple function like what I used to use in these language. A function that simply takes a string and produces and int. After a fair search I didn’t find such a “simple” function. I’ve rather found a function with slightly more complicated/richer signature (type). This function takes a string and returns a list of int-string pairs. This got me thinking, there should be a reason for not offering the simple function I was searching for…

I quickly started understanding why libraries implementers chose to offer this function with this signature and I did so simply by imagining its use. Imagine that I pass a string that is not the expected type (in our case int) to this reads (stands for read string) function, what would happen? Well in the simple version of C# and Java, the parsing function well throw an exception when passed a string that can not be parsed. In some way, the signature of the function promises me to get always the expected type (in our case an int) as a return of using it but it actually lies! Throwing an unexpected exception comes as a surprise as the signature (the function type) looked extremely kind but behaved irresponsibly unexpectedly when I trusted it. But what about the Haskell version?

Well the type of the Haskell function tells me “I will try to parse the string passed, and each time I find a fit with your expected type I will return a pair with the value in the expected type and a remaining string that represents what remains”. So here the function type tells me that it will try to parse and that it will might face several possibilities. There is no lie here, no magic, no false promise, parsing strings can produce several possibilities depending on the parsing method, and that what the function tells me.

I like the no surprise / safe  programming culture in Haskell. I guess there are a lot of lessons to be learnt from this style of programming.

PS: Some might call this safe style “defensive programming” to make it look rigid, I guess there is no point in calling it so, and I would rather call it communicative programming, no surprise programming, or intention revealing programming. I like DbC!

In QCon London 2008, I had the opportunity to have an interview with one of my heros: Simon Peyton Jones. Simon has an enormous capacity of making the answer to almost any question precise and clear no matter how abstract the subject is. I Strongly recommend that you have a look at this interview if you are interested in programming languages in general. Following Simon’s talks and interviews requires almost no prior knowledge about functional programming or Haskell.

In this interview, computer scientist and researcher Simon Peyton Jones discusses properties of functional programming languages, and particularly Haskell, that have inspired some features in mainstream languages. He gives his opinion on the issues of syntax and language complexity and talks about some research work on subjects such as Data parallelism and transactional memory.

Bio
Honorary Professor of Computer Science at the University of Glasgow, Simon Peyton Jones currently works at Microsoft Research in Cambridge. He has led several research projects focused on the implementation and applications of functional programming languages. He has greatly contributed to the design of the Haskell language, and is the lead designer of the Glasgow Haskell Compiler.

Access this exclusive interview published at InfoQ.com

Everyday we hear about languages implementations on the JVM or the CLR. Every language has its own taste and semantics. All of these implementations try the best to satisfy an important second promise which is leveraging the preexisting platform libraries and giving an easy access to them from within that language. So on the CLR you get a promise of an easy access to all the .NET framework, and from Java, well, to the J2EE enormous libraries.

Well designed .Net libraries might be bad designed F# libraries

Some days ago I was trying to solve a small problem using F# (a new member to the .Net family). The reason I chose F# for this problem is the functional paradigm, my specific problem was easier to model using functional paradigm than any other paradigm. What I noticed while using F# is how easy it was to access the large .Net libraries, but I also noticed how can that potentially affect my way of programming. As I already mentioned the reason I chose F# was its semantics, I realized that .Net don’t talk F# and to access it I had to program with its semantics: imperatively, with a command like style almost dropping the expression oriented style that was one of the reasons I chose the language for!

Worse, this drew my attention to how this promise of 100% integrity with the preexisting libraries can affect the language design and implementation. Looking at implementations of popular languages like Ruby and Python on the JVM/CLR one can notice concepts that have almost forced in the languages (like attributes and signatures) . I guess these additions add noise to the language and to the code written with them, but that leads to an important question: How languages should communicate in a multilingual project? And what and where should be the seams when communicating between them?

Some libraries and frameworks are not even necessary for other languages, some just don’t fit, and some need to be wrapped and adapted for the new language

Before trying to think how to communicate between languages, I need to think about what is the kind of libraries I need for the new language. I mean of course it might be technically possible to use Spring and Hibernate when programming JRuby. But in case it is your first choice then, I guess you might be missing the point. There are a lot of frameworks and libraries that have been constructed because of limitations of the language. That is why you need to think twice before just accessing a foreign library because it might be supported natively by your language of choice or its supporting libraries.

Nonetheless , there are some necessary libraries that just don’t exist in your language of choice, and it would be kind of nice to have the painless access to them. But on the other hand, and as stated previously, these libraries don’t talk your language. It is somehow senseless, for instance, to specify type parameters while accessing strongly typed APIs from a dynamic language like Ruby, or say implementing strategies or writing 10 lines of imperative code for configuring a mutable object from a functional programming language like F#.

Some of these necessary APIs can be adapted for the target language. So in this case our issue is solvable by wrapping these well thought mature APIs to make them fit better in the target language paradigm. This can be done using abstractions while leaving other unnecessary details behind like state or type casting. This makes them less intrusive on your paradigm or language. Some libraries’s paradigm, however, is impossible to hide, and in this case you either need an equivalent library for your language, or you need to think carefully about your modules and boundaries to be able to use different libraries with different paradigms without one module being intrusive on another.

Understanding properties and semantics of each used language is the key to a better integration and communication

Each programming language is built and designed based on some theories, principles and concepts. Understanding these does not only help you in your decision of language choice, but this also helps you identifying where and how languages should be communicating. So for example modules written with functional programming languages can be imagined as stateless services that take an input and yield an output, modules written using OOP as holding the state, and modules written with configuration languages place some global, most probably immutable, variables into the environment. This thinking also helps defining barriers between modules to identify when the scope of one language ends for the starting edge of another.

Finally

In this post I tried to draw attention to a hairy, in my view, promise we get from language specification implementers of a seamless integration with existing libraries and frameworks. I guess in the no-fit case, the seam will be in your code and it will obscure it and add noise to your language rather than nicely being abstracted behind a foreign API wrapper. Proper design is instrumental for a non intrusive integration. Properties of each of the used language and frameworks should be considered.

The first time I got introduced to mutation, I had a bad feeling. How can x:=x+1 be logical at all?

It felt so unnatural, scary, or maybe like a hack. Then, because of society constrains, I got to forget the bad feeling about that. Well, my mind started to tolerate with counter-logic logic. And that is how I became an enterprise developer. I am not sure how proud I am with this title anyway. I feel that tolerating and accepting the counter-logic logic is one, and most important one, of the prerequisite to this title.

Nowadays, I am working on a project that has to process a huge number of data to do calculations on it and produce results that make sense to the user. Performance is a constraint. And I decided this time to do it the right way, the way that I believe is right. The logical way.

I decided to the calculations with no mutable state. I wanted immutability to be my guarantee to safety. Mutability breaks logic, and so produces bugs. But I couldn’t imagine how hard this choice can be. You tend all the time to feel that it is easier to introduce a mutable object, mutable flags, temporary mutable containers inside loops. Imperative programming is so tempting. Just like drugs. It feels so strange and weird in the first time, but then, it becomes a habit, a bad one, and you can’t help but to break into it. Mutation and imperative programming is the simplest thing that work in some way.

Today, I am happy I almost finished the whole calculation logic I had to model ( and it is quite a complex one). And I am proud that I could resist introducing mutability in the algorithm. Yet, I did some experiments along the way to introduce just a bit of state, kind of just what I need to introduce faster one kind of calculation. This very small mutation just breaks it all. It just breaks the whole modularity of the algorithm, and just makes the whole calculation much less generic, and more importantly less maintainable and evolutive. Such a small mutation, like introducing a mutable flag, or a global variable, just breaks the whole logic of my calculation, and drives me far away from a good modular calculation, with a good design based on plain old principles of separation of concerns. It just makes impossible to go further with the implementation! It is like a cancer of code…

Now, after the discipline and the resistance to a mutable state, we are so happy with the resulting code that yet needs polishing, makes it very easy to parameter more calculations and so add more desired functionality to the program. And just for fun, we compared it to the same calculation done with imperative programming. It is much more concise, intention concealing, and as a result, surprisingly we paid no performance cost for a much more declarative code.

I owe a lot to Erik Meijer, Paul Hudak, Linq, and Haskell :)

It has been a long time since the last time I committed posts here. I’ve been submitting quite frequently posts on the Architecture section on InfoQ community and sharing them here too. Actually I tend to like what I am doing with InfoQ. Often I think about an idea or a subject and then go to find arguments of different people about that subject. For me this is very richening and I hope that it has been informative to readers of both InfoQ and this Blog. However, sometimes I don’t succeed to find a loud argument about a subject that seems important to me. I open my blog writer to try to talk about it, mostly I fail because of lack of time. I’ve started working a couple of months ago on a very interesting project. And I can’t help but to keep thinking about lambdas and calculations.

Aside from all that personal stuff, I’ve decided this time to finish this post, to try to represent some ideas and my own opinion about an important topic that I find not sufficiently treated in communities.

When we talk about design in software development we talk about modularity, the fact of partitioning a problem into modules that interact to produce the expected result. Mostly this modules are partitioned through separation of concerns principles. Modules can be Objects, Functions, Namespaces, Modules or any other modeling tools that exit in the programing language of choice. Interaction of these components needs to be defined by combining and composing these components and designing their interactions in a certain way. Examples of interaction definitions tools are workflows ,orcherstration tools, and even Dependency Injection frameworks.

Interaction, composition and combining, all of that means coupling. And we know damn well that any coupling should be loose and well mastered. That is why actually we use interfaces, abstract classes, and a whole toolbox of patterns,  to control the coupling that we have to face in our software design and architecture. One very important point one should not forget, is that these patterns do NOT remove coupling. Dependency still exists after using these patterns and tools, the difference is that coupling becomes more loose, in a way that components wont depend statically on particular implementations, but rather on a contract that should be satisfied by an implementation that is bound later on (at runtime or preprocessor time). Notice my use of “static dependency” in this context. We can imagine these patterns and tools’ role is to turn the static coupling between components’ implementation into a dynamic one (late binding, strategies, overloading, polymorphism…).

Dynamic (runtime) coupling is inevitable,  at least when we want to do a modular code. I guess it is still ok to have runtime coupling until we fall into behavior coupling. Behavior coupling is one of the most annoying bug generators I cross everyday. Behavior coupling is a kind of runtime coupling. It is when two components are dependent on some state. And component B can’t succeed if component A doesn’t do its job on some shared state with B before. Taken into such a small context, behavior coupling might not seem that harmful, but the problem rises when several components are coupled behaviorally.

Behavior coupling problem might seem obvious, and easily evitable.  But not when, with a little observation, we notice that it is everywhere!

An example of an unsafe behavior coupling, is stateful event-based GUIs. In general, they have a special lifecycle. Complexity goes wild when several components need to manipulate the view. And ask these components all manipulate a shared state, they become all behaviorally coupled. I’ve seen a lot of projects where producing the expected behavior on the interface becomes a nightmare.

This kind of problem is not exclusive to GUIs. Actually all stateful components make candidates of a runtime coupling generator. The problem with behavior coupling becomes serious when it shows as ad-hock mutation of a shared state. Meaning that there is no well defined diagram or component that described the interaction of the several components with that state. It is indeed possible to have some kind of tools that can trace this interaction to draw a diagram that represents the behavioral dependency. However I think it is a good practice to explicitly define dynamic dependency, coupling and interaction in some formal way. This can be workflows (through xmls or other technology) that describe explicitly in a visual (or at least visualizable) manner , the runtime interaction. Yet a workflow is just a technology, and one needs a lot of discipline and modeling efforts to master the state of the view, and so the behavior dependency between several components.

A better solution to this problem is not to have state, no mutation. When there is no mutation and no shared state, then there is no behavior coupling. The question that is raised right away is how can one do real world applications without mutation and without state. Isn’t programming without state contradicts object oriented programming? Isn’t the world stateful? Databases, GUIs, how can we ever interact with that yet not having mutable state?

First of all, OOP is about having a state, but not absolutely a mutable state. Immutable object brings isolation to the logic of components which has its good side effects on modularity (removes behavior coupling) and performance (especially when talk about concurrence and multi-threading).

But what about GUI frameworks, and databases?

Databases, GUIs, File System these are just some kinds of IO sources that somehow indispensable for a useful enterprise application. By the end most of the value of an enterprise application comes from its interaction with the outside world. And the outside world does have a mutable state. But this doesn’t mean that enterprise software should have mutable state internally. One can push out the mutation and keep it in the outside world. This keeps the software safe and uncoupled behaviorally. That is merely what functional programming solution to IO is about. Keep your software clean from mutable state.

Keeping mutable state out turns your software into a function, a side effect free function; which given the same input produces the same return value (evaluates to the same value). The input when in the case of a database are data from the database ( and maybe inputs from the UI) and the output is a list of commands, different kinds of commands: Some UI command that when executed by the UI (outside world) will mutate the state of the interface. And other database commands (also outside world) that when executed by the database driver will mutate its state. However, in this case the software given the same input will produce the same list of commands. This keeps your software out of mutation and side effects. Which means out of behavioral dependency and coupling, and so safe with much less bugs.

This technique is based on Monads, something Haskell programmers are quite familiar and comfortable working with. In Haskell by the way, you do not have a choice but to isolate IO inside a monad (IO monad), that is one of the reasons why Haskell is viewed to be the only pure functional programming language.

I am not a functional programming geek. I have a very heavy imperative programming culture. And that is exactly why I write this post. I am a C# programmer. And I felt to share what Haskell taught me about good practices of programming.