4 ms·
That's a bit much to resort to when AFAIK caching hasn't been pursued aggressively as it could be.
by alnayyir 16y ago
That's a bit much to resort to when AFAIK caching hasn't been pursued aggressively as it could be.
- jacquesm 16y agoTypically if you start the work when you need it you're actually too late, if this is a direction that is viable the work could get underway long before there was an immediate need and it would probably be done that much better for that reason. Again, I have no idea if this is even feasible, the differences between the various dialects of lisp seem to me (as an outsider) to be considerable.
- alnayyir 16y agoIgnoring myriad other differences, Clojure's syntactic improvements on Lisp/Scheme alone would create far more work than would be worthwhile. It's simply unnecessary and excessively painful in the face of much better alternatives. Like cutting the bloody limb off when you haven't even tried a penicillin derivative yet, a common "first step".
- pmjordan 16y agoTo my knowledge, Arc, like Scheme, uses mutable conses as its main data structure; Clojure doesn't use conses in the sense that the cdr-equivalent element of a list cell can't be just anything. Clojure's data structures are also immutable. You'd have to do a lot to re-engineer the basic data structures just for that; I doubt Arc would be the same language at the end of it. I'm sure Mz/Arc can be made to run workers in other threads or processes in some way, even if it's not trivial. I also get the impression the caching is implemented in Arc code rather than as a HTTP proxy. The latter could run across multiple cores or even servers. Finally, it may be possible to decouple the user-specific data from the generated pages themselves and cache that information on the HTTP level. I admittedly haven't given it a lot of thought, and I also haven't read through the public HN source yet.