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
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.
