camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Krasser <>
Subject Re: [INFO] Project scalaz-camel
Date Fri, 21 Jan 2011 19:22:14 GMT
Hi Claus,

thanks a lot for your feedback, I highly appreciate it. Find my comments 

Am 21.01.11 14:02, schrieb Claus Ibsen:
> Hi Martin
> Its really exiting work and experiments you are doing.
> Wonder how you get the time? And have you left Groovy completely or is
> it still part of your IPF platform?

Of course, the Groovy DSL is still part of IPF and will be further 
developed/maintained. scalaz-camel is currently completely independent 
of IPF but it will play a role in IPF's future. scalaz-camel will also 
be used in akka-camel.

> I think the success of Camel is the simplicity, and that its plain
> Java, than any green-horn developer can get started with.
> That said, the FP and Kleisli composition and whatnot is out of the
> legue for that kind of developer. (myself would need to spend a bit
> time catching up on this as well)

IMHO simplicity is also about having the right abstractions, so that a 
framework or library is not only easy (and intuitive) to use but also 
easy to maintain and easy to extend in a non-intrusive way.

We both agree that ease of use is important so that 'green-horn 
developers' can start using a library without diving (too deeply) into 
the concepts/details of the abstractions used to implement this library. 
I hope I could demonstrate that *usage* of the scalaz-camel DSL is easy 
even without knowing anything about monads and Kleisli composition 
(although I mentioned these in the tutorial) (... also I'm sure there 
are many Scala developers out there who are using List or Option without 
knowing that these are monads) If you think that the scalaz-camel DSL is 
*not* easy to use, please let me know what parts of it are difficult to 
use (or understand). I fully agree that a complete and well written user 
guide/manual is essential - this is work in progress ...

On the other hand, I also agree that understanding the implementation 
details of scalaz-camel is not easy for a 'green-horn developer'. But 
understanding these is primariliy important for developing scalaz-camel 
i.e. for a framework/library developers but not necessarily for an 
application developer who only uses scalaz-camel. I know that 
understanding continuations, monads etc is mind-bending in the 
beginning. Continuation monads do not make it easier (maybe learning 
some Haskell basics helps to grasp these functional programming concepts 
- there's very good documentation around Haskell and FP; btw an 
excellent starting point is But 
once you got these concepts, you'll find that they make structuring your 
codebase much easier (provided you're using the right abstractions, of 
course). For example, using

- continuations for non-blocking routing
- monads for sequencing (a)synchronous computations and
- Responder (a Continuation monad) to support a direct-style DSL

just makes explicit what's currently scattered around numerous existing 
classes in Camel (which this leads to another kind of complexity). I 
think functional programming is a just a good fit for what Camel wants 
to achieve (sequential/monadic composition of (a)synchronous 
functions/processors). Given that the relevant FP concepts are known to 
a developer, I hope you can agree that the complexity of the 
scalaz-camel implementation is quite low. It's not about doing things 
with less lines of code - it's about making the right abstractions, and 
making these abstractions composable and extensible.

> However what you show here is a peak into the future and with promise
> of scala and what it brings to the platform would make take the DSL to
> the next level. But I think for it to be adopted by the general masses
> it has to be at a level they would be able to understand and use it.

Again, I fully agree that *only framework/library developers* should 
need to care about monads etc ... . Application developers should care 
about DSL usage and I hope that I found the right balance here i.e. that 
the DSL usage is easy enough for a beginning Scala developer. That's 
comparable with Scala library developers vs. Scala application developers.

> In the end its not above who can write code with the fewest codelines
> that does the most. Its about people can understand and maintain it,
> also after 6 months without glaring at the code.

Given a good explanation of the few FP concepts used by scalaz-camel 
(for which I owe appropriate documentation - I know) it should be pretty 
easy to grasp what's going on under the covers. This should go into a 
developer guide that explains the relevant abstractions far enough to 
make the scalaz-camel code easy to read. Additionally, a separate user 
guide should focus on DSL usage only, avoiding terms such as monads, 
Kleisli composition etc.

> I am sure its already doable, but then we should have documentation
> and samples at "the level" those people can understand.
> But I am sure as such a talented engineer as you, its more fun to take
> it to the highest level :)
> Okay I think I'm getting on a sidetrack here.
> In terms of donating your camel-scalaz to Apache. Currently I think
> its best hosted at github which fosters a higher degree of innovation.
> Then when the project is stabilized and you think its ready, then yeah
> we would love to distribute it at the Apache kit.

Was thinking in the same direction. Let's keep it there first and see if 
the interest further increases.

> I love what you are doing and now my sparetime is not occupied writing
> a book, I am sure to tend some time to looking more into the world of
> scalaz, akka and scala.

Would love to see you in the Scala world. It would be a big win for the 
Scala community having you to help promoting Camel there.

> We do have the simpler camel-scala module at Apache Camel. It could
> use a bit of love to make the DSL a bit more scalaish and also some of
> the EIPs lack some of  the latest additions which we have added to
> camel-core.
> So we could use your expertise to take a look and improve the areas
> which you feel would make the best improvements.
> There is raising interrest in Scala and thus also in camel-scala.
> On Thu, Jan 20, 2011 at 9:22 AM, Martin Krasser<>  wrote:
>> Hi,
>> I want to let you know of a new Camel-related project that I've been working
>> on over the last couple of weeks:
>> scalaz-camel - A Scalaz-based DSL for Apache Camel [1, 2]
>>  From the docu: " This project provides a domain-specific language (DSL) for
>> Apache Camel that is based on the Scala programming language and the Scalaz
>> [3] library. It supports the combination of message processors and endpoints
>> to complete message processing routes based on functional programming (FP)
>> concepts such as continuations, monads and Kleisli composition. The
>> scalaz-camel DSL is an alternative to Camel’s existing Java DSL and Scala
>> DSL (it does not depend on the org.apache.camel.model package) ... [and]was
>> re-designed from scratch with the goal of a better and more native
>> integration with the Scala programming language." (find more at [4])
>> Over the last year I've been involved in Scala projects that use Apache
>> Camel and was looking for a way to better utilize the power of Scala and
>> functional programming concepts when creating integration solutions with
>> Camel. The scalaz-camel project is a proposal how this could look like.
>> I'm posting this message because I'd like to hear your opinion about the
>> approach taken by scalaz-camel. I'm also interested in your opinion whether
>> you see a need for a stronger investment in supporting Scala and functional
>> programming in Camel.
>> The scalaz-camel project is still in an early stage, some features (for
>> production) are still missing (and documentation needs to be completed) but
>> I hope the general direction is clear from the latest release (version 0.2).
>> I'm also open for discussions about contributing scalaz-camel to Apache
>> Camel.
>> Thanks in advance for any feedback.
>> Regards,
>> Martin
>> [1]
>> [2]
>> [3]
>> [4]
>> --
>> Martin Krasser
>> blog:
>> code:
>> twitter:

Martin Krasser


View raw message