2016-02-08 Tweets

Is the Lisp Curse Lifting?

One question about Lisp is if it is as wonderful as its advocates say, why isn’t is used more?

One hypothesis is the Lisp Curse (see here, here, here, here, here). In essence, it comes down to “Not Invented Here” on steroids. Once you get proficient with Lisp, one person can do things more quickly with Lisp than entire teams using other languages. So one result is that there are very few commonly used libraries in Lisp (Common Lisp, Scheme, etc).

You might find a library that does 80% of what you want, but its creator won’t help you, so you just make your own custom library. And now there are two libraries that do almost the same thing. Repeat this for a few decades.

I first heard about this from Neal Ford at a talk on Clojure or general functional programming either at a No Fluff Just Stuff conference or a Ruby/Rails conference. He said that Clojure might be the Lisp that gains traction because it is on the JVM, and can thus use Java libraries.

Then I found out about Quicklisp, a “library manager for Common Lisp” that lists 1,200 libraries for every major implementation of Common Lisp. (Also, see this page on the Common Lisp wiki.)

Recently, I read about Roswell, a launcher for Common Lisp. What sdkman does for the Groovy ecosystem and rvm does for Ruby, it looks like Roswell does the same for Common Lisp. It can manage multiple installations of two implementations of Common Lisp, Steel Bank Common Lisp and Clozure Common Lisp. (Now that sound has three meanings in programming. Are you saying “closure“, “Clojure”, or “Clozure”? We need some closure on this issue.)

One things that Roswell does that sdkman and rvm do not is that it runs on Windows as well as Linux and other Unix-based systems.

I am still just getting started with Clojure and Lisp, but it looks like I showed up at an interesting time.

You’re welcome.

Testing Groovy Actors

One thing I did not quite get when I was looking at multithreading technologies was how to unit test them.

I have not looked at Akka for a while, but a few years ago it seemed like the consensus was to use a logger like Log4J, and then parse the logging messages. That is kind of unwieldy and feels wrong. (Akka seems to have more ways to test now.)

I emailed the GPars list about putting private fields in an actor, changing them in the onMessage method, and then checking them afterwards; something like this:

class BadActor extends DynamicDispatchActor {
    private def someField
    private def someOtherField
    void onMessage( ObjectType message ) {
        someField = message.doStuff()
        someOtherField = message.doOtherStuff()

You could do that. There is nothing wrong with having private fields in an actor. You might want to keep some data between requests (like an encryption key). But making a field just for testing seems wrong.

Then I had an idea: Have your actor call another class that does the actual work, and unit test the worker class:

class BetterActor extends DynamicDispatchActor {
    void onMessage( BetterObjectType message ) {
        def worker = new WorkerClass( message )
        def result = worker.doWork()

I suppose that will not help with functional testing. It might violate some SOLID principle, or DRY, or GRASP or the Law of Demeter or Principle of Least Astonishment or Poe’s Law,
but it seems like a pretty good idea to me.

You’re welcome.

2016-01-18 Tweets

2016-01-11 Tweets

2016-01-04 Tweets

2015-12-21 Tweets