Recently, I’ve been working on a project that gave me a chance to get back to JVM world and take a nice look into its current state. Having spend a lot more time in .NET world last decade, it was very refreshing to experience it again. Highlights for me are working with Groovy (very nice and easy, but powerful and fast) and vertx.io application platform.
So… I simply love and admire the design of vertx.io; although it provides powerful set of features, it uses asynchronous messaging and reactive programming principles, it makes most of required infrastructure glue code disappear, by providing right abstractions and lightweight APIs that never gets in your way.
Here is the more complete list of the features straight from the their website:
- Simple actor-like concurrency model. Vert.x allows you to write all your code as single threaded, freeing you from many of the pitfalls of multi-threaded programming. (No more
volatile or explicit locking).
- Vert.x takes advantage of the JVM and scales seamlessly over available cores without having to manually fork multiple servers and handle inter process communication between them.
- Vert.x provides real power and simplicity, without being simplistic. Configuration and boiler-plate is kept to a minimum.
- Vert.x includes a powerful module system and public module registry, so you can easily re-use and share Vert.x modules with others.
- Vert.x can be embedded in your existing Java applications.
Tagged with: API
Posted in Development
VisualStudio 2015 and C# 6.0 are out available for preview!!
I decided that a good way to do that would be to try implement a couple of monads in C#. Monads offer a very nice way to separate core logic from the boilerplate code. They are used quite a lot in many programming languages, and in C# they are foundation for Linq. So, I was wondering how easy/hard it would be to implement them in pure C# (not with Linq) and would they end up being practical to use in a OOP language like C#?
Disclaimer: this really is a simplified and incomplete attempt – for a complete and more through take, you should go ahead and read more detailed blog posts here or here:
First, a basic intuition about monads:
monad = data container + some computation + public interface (‘From’ and ‘Bind’)
- Data container – in C#, simply a class
- Computation – repetitive logic that can be extracted from the main/core operation
- ‘From’ – function that wraps a value inside the monad – in C#, constructor or static factory
- ‘Bind’ – function that applies main/core operation within the context of internal computation
Lets try to implement two simple monads: Maybe (Option) and Writer monad.
Maybe monad’s internal computation checks for ‘null’ values, making top level code path clear of null checks.
Writer monad’s internal computation allows to accumulate additional information as we progress through chain of operations, hiding away explicit logging statements from the top level code path.
and here is how it is used:
You can get full source code by going to this GitHub page. I may continue to play around with this, potentially add other monads and more complex examples of use…
Lots of programming problems can be modeled by pipe-lining data through series of sequential or parallel processing steps. This data flow allows us to separate computational tasks into meaningful modules and
get more focused code base that is easier to debug and reason about. For example, a pipeline with three steps that takes input ‘req’ and successfully process it, would look like this:
And if at any stage there is error during the processing, we would skip the rest and return error…
Now, there are many ways to implement error handling, but this can easily end up in a messy combination of conditional statements and/or throwing and catching exceptions to stop processing. This adds noise to the real code logic and makes composing tasks harder… I’ve recently started to use Either monad to help with this this problem and am very happy about the results:
Here, I’m using Either implementation from the nice functional library Falktale…
Till next time…