Application Development Meanderings

While I'm not a lisp (common lisp, scheme'ish) programming guru, I occasionally use lisp/scheme to write programs for analysis or data management tasks. Since I am data mining/data scientist person, I write many smaller programs to build out analysis workflows. I use many different tools although I would prefer just one, or at the very least, fewer. Sometimes I need to write some web code, and for those tasks, javscript is the dominant language. Javascript has a history similar to lisp but a future that is probably different given the attention and focus it has. I was recently updating my skills in some of the "web" programming toolkits, e.g. moving from grunt to webpack, and I had a thought. I'll admit that I had this thought even though I once again felt that the javascript ecosystem has too many pieces to it--a great source of innovation *and* irritation. Javascript was stuck with the same, rather poor, language standard for a decade until recent committee

Transducers Transducers were introduced into clojure many years ago. The term transducers is not unique to clojure. The type signature provided on the clojure page is reducer -> reducer where reducer is {state, value} -> state . Using functional language terminology, a transducer is a reducer combinator--you can create new reducers from other reducers. A reducer can be thought of as a functional fold. Hence, a transducer is just a transformational pass over an input sequence with a final reduce operation e.g. sum. If implemented correctly, transducers can reduce the number of passes and the amount of intermediate results compared to naive implementations--improving memory usage and in theory, processing performance. There are other functional concepts involved in transducers as well including currying. A good read, using javascript, is included here: https://hackernoon.com/partial-application-of-functions-dbe7d9b80760#.v84qwq432 . Transducers are also related to

A few notes on exception handling in common lisp. It is different than just plain old termination-based models of exception handling. Does that make it better? Perhaps in some situations, yes. In many situations, perhaps. You can also build your own exception handling protocols using the general   signal   capabilities in common lisp. While using   handle-bind   may make your code less referentially transparent, does that matter in all situations? Clearly, you should avoid using exceptions for flow control in your program, which python and java seem to almost support, but what's the best model for any specific application? If one were to use a function approach to providing "handlers", you would be adding alot of arguments and syntax to your function calls over time and that makes it harder as well. No clear, one-size-fits-all answer. ; ;; Demonstration of simply try-catch logic in CL ; ;; as well as restart logic. ; Define exception objects,