Hi Claus,
thanks a lot for your feedback, I highly appreciate it. Find my comments
below.
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 http://learnyouahaskell.com/chapters). 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<[email protected]> 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] https://github.com/krasserm/scalaz-camel
[2] https://github.com/krasserm/scalaz-camel/wiki#getting-started
[3] http://code.google.com/p/scalaz/
[4] https://github.com/krasserm/scalaz-camel/wiki
--
Martin Krasser
blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz
--
Martin Krasser
blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz
