I constructed a subsystem in Clojure. We had a nice, compact problem to solve. The rest of our app talks to this Clojure bit through a small interface. The attraction of Clojure was that I could enjoy all the nimbleness of hacking Lisp interactively. Using such a powerful language, I could adapt to emerging requirements, experiment, twiddle, and workaround faster than using Java. And early on, that largely proved true.
But I am here to tell you: It is possible to write inflexible, unmaintainable, fragile code in Clojure.
As they say in bicycle racing, the riders make the race. I never said I was a good programmer.
It's my own fault. I dived into Clojure and learned key concepts on the run. And these key concepts are fundamental to how you should structure your program. FP has a learning curve. Managing shared state using Refs, Agents and STM -- better to understand these concepts up front. Even now, I'm unsure how I'd restructure my code to use them properly. I'm very glad not to have to worry about deadlocks. But there are parts of this code I still am unsure how to to test for consistency under multithread access.
Consequently, I'm slogging through this bowl of spaghetti of my own making, cursing the author.
[Edited to add "fragile" ... as I made one more change and my tests came tumbling down... ]
Hugh Winkler holding forth on computing and the Web
Subscribe to:
Post Comments (Atom)
2 comments:
Thank you for a refreshing mea culpa. Any details you can share?
Well, I will tell you that coordinating writes to the filesystem with changing the state of Clojure Refs and Agents is tricky. If you want synchronous changes to Refs, you need STM, but you can't do I/O within a Clojure 'dosync. Agents can do I/O, but the effects happen asynchronously (via send-off). This is a tricky issue using old fashioned locking as well -- but I have experience doing it the old-fashioned way. I haven't learned the patterns for the new-fangled Clojure ways, and sorta made some up.
Post a Comment