Refactoring Clojure
orsolabs.com
orsolabs.com
The sentence generator in my Markov text generator CL package looked like this:
(defun generate-random-sentence (mtab &key (first (random-elt (first-words mtab))))
(with-slots (prob-table) mtab
(format nil "~{~a~^ ~}"
(loop
:for next-word = first
:then (pick-random-word (gethash next-word prob-table))
:while next-word
:collecting next-word
:until (ends-with-end-sentence-punctuation-p next-word)))))Have you scrolled to the end, or you're judging by the initial examples in the code, because author did use more sensible names in the refactored example.
But if I'd have to re-write your CL snippet in Clojure, perhaps it would look something like this (I don't know if that actually works, haven't tested it):
(defn generate-random-sentence
([mtab] (generate-random-sentence mtab (rand-nth (:first-words mtab))))
([mtab first-word]
(->> (iterate #(pick-random-word (get (:prob-table mtab) %)) first-word)
(take-while some?)
(partition-by ends-with-end-sentence-punctuation?)
(take 2)
(apply concat)
(clojure.string/join " "))))
Clojure had a chance to do better because they were starting a new thing.
It's not necessarily a flaw with the language, in any case, just something I've noticed in Clojure articles.
I suppose I'm agreeing with the author - refactoring Clojure to make it more readable is a good idea.
And it did. The seq abstraction is way more practical than the old-school list obsession in other Lisps. You get to treat collections uniformly while keeping the performance benefits of each implementation. Pretty smart move, honestly.
While Common Lisp does have sequence functions, Clojure's seq abstraction is fundamentally different and more comprehensive: Clojure's seqs work uniformly across all data structures (vectors, maps, sets, strings, etc.), not just sequences; Clojure seqs are lazy by default; The seq abstraction is built around immutable data structures from the ground up; In Clojure, everything implements the seq interface - it's the primary abstraction, not just a library feature.
Common Lisp's sequences are more limited - they work on lists, vectors, and strings, but the interface isn't as pervasive or as foundational to the language design. Clojure made the seq abstraction central to how you work with any collection.
No it's not. There's no style-guide rule, or PEPx, or core team recommendation to use short or long names. Clojurists are pragmatists to the core — they use whatever makes sense in the context. If `m` and `f` feels like a reasonable choice instead of `map` and `function` — that's how they'd name the vars, but it's not a universal rule.
Clojure's syntax (and Lisp's in general) is very flexible, you may encounter names like `bar->foo` — for transforming, or `bar+foo` — for data combining functions. For uninitiated these kind of names may look cryptic — when you encounter a function name like that for the first time, you'd think it's some kind of special language construct. Matter of fact, because Lisp syntax is so minimal, the overhead of learning mental parsing of the code is also (relatively) small. No one after a few months of writing Clojure conceives it as a atypically "cryptic language", but of course, there are programmers capable of writing cryptic code in any language, no matter how generally terse or verbose it is.
Yes! After a few years of using Clojure for work; Fennel for configuring anything that requires Lua; Lisp-based editor, nbb and babashka for scripting — now I just can't deal with non-lispy languages without getting mentally and emotionally exhausted. It feels so taxing to have to deal with all the syntax elements, indentation, etc. So many times my thoughts got derailed due to a missing comma in some json or slightly misindented shit in yaml.
I just don't understand how I used to happily write programs before, and I did it for over a decade. Without ever being able to "transpose these two things around", "lift this structure and move it over here", "slurp this thing inside", "raise this expression", "wrap this piece into its own block", etc. And then the actual REPL — OMG, that's a song of its own accord.
Programmers with shallow understanding and lacking experience of Lisp (or straight bias against it) are missing out so much, it really is sad.
Most people I know of that tried Lisp and didn't like it did so by writing Lisp without structural editing, into a text file, starting a REPL, loading the entire file into the REPL and calling the main function from the REPL.
It's difficult to explain just how absurdly slow and cumbersome that is, as its the primary way developers work in other languages to the point that what you're saying sounds like hyperbole.
For those that haven't experienced that difference:
Structural editing when you have a homoiconic language that only has expressions is like combining expert level vim skills with vim macros and expert level IDE snippets/refactor shortcuts but with a fraction of the expertise as the tooling is simply less complicated.
REPL driven development is state retaining hot reload as a first class citizen, which makes regular compile cycles and the shenanigans you need to do to isolate your current code and make it run (eg. flags, rewriting main, writing tests) appear absurd in comparison.
By the time you add the features of Lisp systems on top (like condition restarts, runtime compilation, ASM inspection etc), most other languages feel like a big step back.
I know, right? The hardest part is that no amount of explaining and convincing anyone who never tried truly grokking this aspect of the homoiconic nature of Lisps really moves the needle. It's like living in ancient Greece, trying to convince people that riding a bike is enormously fun. No matter how verbally you explain, no matter how many blueprints and drawings you produce — until you build one and teach someone to ride it, nothing would change — people will not believe you.
Same is true with Lisp; until you get to experience the structural editing and REPL-driven workflow yourself, you wouldn't even know what you're missing.
1) replacing a func with a simpler recursive func may or may not be ideal.
2) this fills me with no joy when I read it:
> It seems easier to start from scratch as opposed to refactor it. The characterization tests above will help ensuring that the returned hash map stays the same.
Its enormously hmm… what word to use. Ambitous? Foolish? Brave?
Anyway, taking code, writing some tests for it and then rewriting the entire thing so it passes the tests you wrote only barely falls into “refactoring”.
If anyone refactored my code base by simply rewriting from scratch the parts they dont like, I would be upset.
Rewriting things is hard, and its … brave… to think you can just write a few tests and then if they all pass its all good!
That only works in very trivial examples, and really, doesnt show case the strengths of clojure at all.
Explicit dynamic bindings are better if you need something like this since those are thread local.
Lots of little, simple functions, composed... You can still use the threading at a higher function, but instead of doing the actual work at each step in the pipeline, you call a well-named function which does what that step was doing. Yes, it may feel redundant, but it absolutely improves human comprehension because it reads like clear human instructions.
Tests become much simpler too.
The only two challenges I face with this approach is 1 - naming things, and 2 - organizing. The function names tend to become quite long, since they ideally describe what the function does.
I haven't done this lately, now that the AI tools have become pretty great; I can imagine that an AI tool would be an excellent knowledge base for these many functions, and it would probably be very successful in providing additions or modifications given the clean, clear function names and brief contents.
That should always be how code is written, including inside of functions, which is the real problem here. Something absent from the original code that is needed in a case like this isn't more functions, it's comments and good names.
Pulling something out into a function that is purely individual application logic without intent for reuse is not the right way to use a function, whose purpose is to be called, ideally somewhere else and not just once. As Ousterhout points out in his book, proper abstractions hide information and implementation, they aren't just scaffolding that increase the surface of an interface without doing anything.
A nice middle way is using let bindings for whatever you want to give clearer names. You get the name you want while reducing the reader's scope to the literal let binding.
I do agree that big functions can be unwieldy, but I think that if it's mostly core clojure fns, and you're experienced, much bigger sized fns are acceptable than name-everything advocates generally prefer.
But it's individual and an artful balance even if the only reader is yourself. There's no silver bullet.
Annoying because I study new languages mostly on the phone, but the brackets/parenthesis make a mess on the phone
Anyone else finding some irony in the fact that the provided code is unreadable not because of its structure but because of the highlight colors?
Holy cow. That is difficult.
Jokes aside, I feel so raddled every single time I see some Lisp-mentioning post here on HN or Reddit, where inevitably someone comes to complain how "unreadable this Lisp thing is". Not you guys, this color scheme really is some "Christmas Night in a nuthouse"; I'm just unpacking my emotional shit all over, without addressing anyone specifically.
"Lisp is unreadable"... pffft. Geez, what the fuck does that even supposed to mean? Are they programmers or fucking toddlers dealing with an alphabet soup? It's as if linguists complained about semitic languages being "unpronounceable" on some specialized forums. Seriously, can you imagine, someone logs onto a professional forum of linguists and starts berating Arabic or Hebrew, saying shit like "I've been interpreting professionally since I was nine; I am fluent in twelve different languages, but this Arabic stuff, I gotta tell you... is pure bullshit. No money in the world would make me learn or even try using it..."
How can anyone still identify as a programmer with a stance "this programming language is unreadable"? I can understand if that's been said about a PL that someone just made or some ancient thing that very few still use, but how can anyone just dismiss a 65-year-old idea that is still being actively used and for which there's no good replacement?
You failed. Between the unreadable text colors and the word wrap, the code is incomprehensible. I cut and pasted it into a plaintext notes app and it was way easier to understand