Hacker News Reader

Comment by alain94040 | Hacker News Reader

This thread may be as good as any to ask: the code I write has to deal with a huge amount of state. To summarize, my code receives millions of "change commands", which update state in memory. Data structures are hash tables, lists, etc. And some commands, once in a while, are queries like "how many of these are there now, of what does this element now point to?".

I guess I'm describing some kind of custom in-memory database engine.

Anyway, I'm confused as to how the purity of Lisp functions would or would not prevent me from writing this code? Is this a use case that is bad for Lisp, or am missing something?

View on HN

As far as FP langugages go, LISP is very much a free-for-all. It can be pure if you want it to be, or stateful and imperative if you prefer. Nothing is really enforced like for example in Haskell.

For your use-case a mutable reference behind some type of synchronized accessor would probably suffice. If you want to get fancy you could design the system in such a way that any point in time could be replayed or rewound to, since you have the commands and the initial state.

Some ideas to look into:

[1] https://github.com/acid-state/acid-state

[2] https://docs.datomic.com/pro/getting-started/brief-overview....

[3] https://www.martinfowler.com/bliki/CQRS.html

Lisp functions are generally not pure! Common lisp, the language this article is mostly talking about, is very comfortable with state. CL, like most lisps, often encourages a functional style- everything is an expression, and usually you'll return data structures even if you mutate them. But big hash tables and arrays are definately in common lisp's wheelhouse. Even Clojure, which is largely pure when dealing only with itself, has full support for diving into the messy practicalities of mutation on the JVM.

Lisp is not pure, in general. cons is "functional" because lists, if treated immutably, are functional. There's still setq (set! in Scheme), though, and operations on hash tables, arrays, and sets are typically mutating.

so Lisp is actually not a pure language, like, at all. Emacs is often written about as a big hairy ball of state and Lisp itself can be as imperative or statefule as you want. So while I don't know much about what you're designing, Lisp wouldn't be necessarily a bad choice.

Reply on news.ycombinator.com