Cool... Do you use kilns at Akamai, and to what extent? Another question: you set up coals and clays and eventually kilns are fired. When you're setting up the coals and clays in code, you're telling the system about dependencies. Are these dependencies laid out explicitly enough to be always unambiguous-in-execution?
(I'm comparing this to an architecture in the object-oriented world where we ditched static singletons since static things in Java are initialized at load time and we had no control over the sequence. In our architecture, we had explicit metadata lists for depends-upon and provides-interface and everything was registered with a master collection which would construct a valid sequence for set-up and tear-down according to those metadata lists. So the ambiguity was eliminated with the use of those lists. And the issue of passing around more and more arguments was addressed since now you pass around the single master collection. And each context could have its own master collection... etc.) What were the other ways of managing complexity that you considered and why did you decide that kilns would fit your needs better? On Sunday, May 6, 2012 6:28:59 PM UTC-4, Jeffrey Straszheim wrote: > > > I detail what I mean about "insanely complex" here: > > http://github.com/straszheimjeffrey/The-Kiln/wiki/Why > > And I would reject any description of the Kiln as "imperative", as such. > It does allow for side effects, but that is a matter of design and taste. > You could use it without side effects. > > Ultimately, it is a dataflow model, albeit one where each cell > is only be computed once. This makes it the opposite of a > "cells-alike" library, where you want to model statefull cells > changing. The Kiln is for when your cells do not change, at > least over the lifetime of a particular kiln. > > During a webapp request, the `current-user` is a fixed value, as > is `request-uri` and `response-main-body`, etc. . I find that managing > the dataflow between this stuff is an endless headache. > > And no, it is not a FSM. FSM's model things that change. Kilns > model things that do not (over the lifetime of a single kiln). > > > On Sunday, May 6, 2012 5:52:04 PM UTC-4, Paul deGrandis wrote: >> >> Can you give a better example of insanely complex functions? >> >> I actually think that FP is ideal at modeling, representing, and >> managing data-flow, stream-based, or request/response data. >> Kiln seems to encourage a sort of imperative style to these >> operations, where associative data (like hashmaps) would normally be >> used. >> What advantages and tradeoffs does Kiln offer? What problems does it >> solve for you where you've deployed it? >> Is Kiln's goal to create a uniform interface to a finite state machine >> -esque concept? >> >> Thanks! >> Paul >> >> >> >> On May 6, 2:08 pm, Jeffrey Straszheim <jstra...@akamai.com> wrote: >> > The Kiln is an evaluation strategy for insanely complex functions. It >> was >> > designed based on two things: my experience with managing several >> large, >> > complex, ever-changing web applications in Clojure, and my experience >> in >> > dataflow approaches to modelling. >> > >> > I have released version 1.0.0 on Clojars. Also, there is quite a bit of >> > documentation and explanation on the project Github page, including a >> full >> > sample application presented in a somewhat “literate” style. >> > >> > Please take a look. >> > >> > http://github.com/straszheimjeffrey/The-Kiln > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
