Abstract Clojure

Yes - sometimes you can go too far in the quest for abstraction. I've seen a ton of over-enterprisey people build gorgeous abstractions with perfect testability and dependency management, only for it to be used only ever in one context in one way. I lean towards WET first before extracting an abstraction, if that.

The argument for pure functions holds in a real system; these particular signatures will be familiar to anyone who's built a few Clojure web services. In reality, some of the functions listed (say, `get-article`) would disappear entirely into a system-specific convention. There's a balance to be had between the number of seams the team is managing directly and those which, by their creation, mean less cognitive overhead. The seams then exist only if they are required, as certain handlers might choose to diverge from the conventional functions used in a generic way.

It's of course not easy to see that next step from the article, since it doesn't eliminate any code by creating pure functions. But even in a toy example, there is value of creating pure functional abstractions. In some codebases, you might even see the team lead segregate pure functions by namespace: "Pure stuff over here, tainted stuff over there." In those situations, teams try to reduce impure surface area -- in this case, anything that touches the `db` namespace.

Yes Clojure is all about first-order functions working on simple, concrete data structures.

Pervasive use of protocols and custom, user-defined higher-order functions I would argue is unidiomatic Clojure and creates long-term pain as you end up with opaque functions being passed around that can't be inspected at the REPL and a lot of tricky "fitting functions together" that is made difficult without a static type system. You sometimes need them, but you should reach for them very judiciously.

There's a reason Clojure emphasizes data over functions (and both over macros).

Thank you for this rec, been thirsty for knowledge in this domain.

Great book. Great podcast by him as well: https://lispcast.com/category/podcast/

Are you sure about Java? http://titanium.cs.berkeley.edu/doc/java-langspec-1.0/ talked about interfaces in 1996 and I don’t remember any version that didn’t have them.

The same Java that took the interfaces idea out of Objective-C protocols on version 1.0?

Doesn’t it also make the stack traces more difficult to read as well?

That really sprung out at me too. I don't think the problem is well understood at all, let alone the answers to it.

Design is about tradeoffs, as I think something the submission addresses very well. Something I recognize about your implementation of get-article! is that it knows a number of implementation details:

* it handles http requests * it uses a jdbc data source * the result of the parsing function and the arguments of the database fetch function are coupled, * the result of the database fetch and the formation of the http response are coupled

This has implications both in testing and in application maintenance. What needs to change if you decide you want to add caching in front of the database? What if you want to pick up requests off of a Kafka stream instead of from a web server?

Like I said, there are tradeoffs. The entire premise of the article is about depending on abstractions rather than implementations. Depending on your particular context, where you want to end up on the continuum should reflect your particular context.

It's lisp on the jvm.

If you have an hour spare, probably the best way to understand Clojure's main selling points is to watch this talk: https://www.infoq.com/presentations/Simple-Made-Easy/

InfoQ list the Key Takeaways as:

- We should aim for simplicity because simplicity is a prerequisite for reliability.

- Simple is often erroneously mistaken for easy. "Easy" means "to be at hand", "to be approachable". "Simple" is the opposite of "complex" which means "being intertwined", "being tied together". Simple != easy.

- What matters in software is: does the software do what is supposed to do? Is it of high quality? Can we rely on it? Can problems be fixed along the way? Can requirements change over time? The answers to these questions is what matters in writing software not the look and feel of the experience writing the code or the cultural implications of it.

- The benefits of simplicity are: ease of understanding, ease of change, ease of debugging, flexibility.

- Complex constructs: State, Object, Methods, Syntax, Inheritance, Switch/matching, Vars, Imperative loops, Actors, ORM, Conditionals.

- Simple constructs: Values, Functions, Namespaces, Data, Polymorphism, Managed refs, Set functions, Queues, Declarative data manipulation, Rules, Consistency.

- Build simple systems by: Abstracting (design by answering questions related to what, who, when, where, why, and how); Choosing constructs that generate simple artifacts; Simplifying by encapsulation.

So Clojure is a language that embodies these principles in its design. It's a Lisp, which means that all code is constructed from a very regular expression syntax that has an inherent simplicity and can be quickly understood. It's a functional programming language that provides exceptional tools for minimising mutating state, and it favours working with a small set of data structures and provides a core api with many useful functions that operate on them.

I'd say the result is getting a lot done with a small amount of code, minimal ceremony, true reuse, and the ability to maintain simplicity even as your system's capabilities grow.

Not writing Java (although you do have to do lots of interop with Java).

Sibling provided a good overview of philosophy. Practically it offers Lisp goodness, jvm/js interop and a well-designed set of persistent collections everyone and their dog uses, part of the reason why clj libraries tend to compose very well. You get some stunning mileage out of the thing.

A really well thought out Lisp-1 that runs on the JVM, in the browser, in node as well as the CLR and BEAM.

It is hard to go back to other languages once you appreciate its simplicity.

It's very good and straight to the point about transforming data. The central data structures (maps, keywords, vectors) and excellent languge + standard library centered around those, combined with interactive iteration at the REPL, make for a rewarding development experience when you can just try stuff. Since most things are immutable and passed around as data, you can easily rerun things at the REPL with high confidence that objects in your data aren't being mutated.