Looks awesome.
I think we're going the same direction. Myself, I wanted clays to be
first-class items that can live in Clojure namespaces, and give you all of
that. The downside is this: if I particular clay is wrong for some
particular evaluation, you're stuck. The clay is the clay is the
Hi Jeff,
What do you think about a Map interface for this?
I recently implemented something similar in a project of mine, which I
called an 'evaluating-map'. It's not a Web project, but the pattern is a
general one. In my case, a DSL for specifying a job to run. I want the
DSL writer to have
Marc,
Nicely done! I've done something similar before as well.
This was basically my point earlier: Dispatch tables (and maps in
general), unification, and closures seem to solve the same problem,
are composable, don't introduce nouns/types/metaphors, are open for
extension and closed for
On Tuesday, May 8, 2012 11:18:42 AM UTC-4, Andrew wrote:
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.
Well, I’m not sure what you mean. It does nothing specific with the “data
types” as such, so I would say, no, that isn’t it.
On Monday, May 7, 2012 10:59:22 AM UTC-4, cperkins wrote:
I like it. Kiln looks like it is automatically composing the request
handler based mostly on a description
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
I like it. Kiln looks like it is automatically composing the request
handler based mostly on a description of data types (*) provided and
needed. Is that correct, more or less?
It looks very useful. Using Common Lisp (not Clojure yet) I end up
using a lot of macros when handling HTTP requests
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
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)
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.
10 matches
Mail list logo
