Hi Martin I agree to differentiate the point of view between - Camel end user - Framework developer
And we can even categorized the levels of Camel end users - green horn - experienced - expert On Fri, Jan 21, 2011 at 8:22 PM, Martin Krasser <[email protected]> wrote: > 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. > Yes my thought for that was for the Camel end user perspective. I think the issue you would have is to strike a balance making it both fairly easy to pickup and get started with for the green-horn and average developer. And keeping the temptation in bay for not adding to advanced features and examples; "just because its possible" - to impress not yourself and the experts in the scala community. Obviously spending some time writing "beginning with" user guides and examples would be a solution to let users get started with scalaz. That said I agree that "richer" DSL is the future for not only Camel but for many domains. > 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 ... > Yeah I agree. Writing documentation from the very start is IMHO very important for the project. In todays internet world, the competitor is just one google search away and people tend to be impatient and if they can't understand and get started within some hours they are likely to look for something else. I would suggest adding some basic and simple examples, such as the "Hello World" example of copying a file from an inbox to an outbox directory. And then add to that with the filter EIP, and then an Content Based Router based on .xml and .txt files. And so forth. I even think we can do better there at Apache. > 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. > Yeah I agree. Now we are talking from the framework developer perspective. We have taken Apache Camel to the extreme what is currently possible with the plain Java language (JDK 1.5). It's definitely not too well suited for tomorrows concurrent challenges. It does takes a fair bit of code to handle concurrency, continuations and asynchronous in the Camel routing engines and the advanced EIPs which support those concepts. The main parts are however not scattered but mainly confined in the MulticastProcessor and Pipeline (which extends the former). That said if James Strachan today would create Camel I am sure camel-core would be developed in Scala. Now suppose the core over time could have parts of it replaced with an enhanced Scala based core? And we could keep all the existing components and whatnot in pure Java language. Then I think we would have a great model. Having components in plain Java foster any engineer to help contribute to those and its very easy to contribute new components. And the core could take advantage of the richer language of Scala, and all the cool research being done on parallelsim for tomorrows challenges. I am sure the routing engine, EIP patterns, (a)synchronous processing could be done leaner and at a better abstraction in Scala than possible with Java. However we must ensure that the we dont abuse and make the core code to complex and un-understandable for the framework developer. We want to let people who want to dig deeper into Camel be able to get into the core and be able to become a valuable committer and maintainer of the project. >> 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 > > -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
