xforms VS malli

Maybe https://github.com/cgrand/xforms The for transducer might help, just as the for comprehension helps unpack and map/filter nested stuff.

cgrand/xforms is a very useful hidden gem, if you like transducers/eager evaluation/solving map-vals without meander/specter.

* It's fast enough for 99% of apps out of the box. It's fast enough for 99.99% of the apps with minimal tuning.

* Yes, if your project is very big and macro heavy, it can take some time, but startup times have improved. In any case, I BARELY need to restart my development JVM. I have one currently running that I haven't restarted for 1 week+.

* Depending on what's your cup of tea, there's emacs/CIDER or IntelliJ/Cursive. They both work well. IntelliJ/Cursive is an excellent IDE combination. I use it every day.

* Java interop is very straightforward, not sure what you mean. Sure your code might not be all pure anymore, but that's the price for solving actual problems.

* Good java libraries have wrappers. A ton of original Clojure libraries as well. https://github.com/cgrand/xforms for example allows you to easily do things that I can't even imagine doing in an imperative language.

* Static vs dynamic typing: don't want to get into that.

* "Clojurescript isn't the same language". I use both Clojure and ClojureScript every day and as far as Clojure-only code is concerned, it works in both languages 99.99% of the time. One case you can encounter issues is if you do something host-specific, like dealing with numbers. That's by design. Clojure embraces each host, does not try to reinvent it. When you just use pure Clojure data structure manipulation, it works the same across both languages and works like magic.

Clojure's lazy sequences by default are wonderful ergonomically, but it provides many ways to use strict evaluation if you want to. They aren't really a hassle either. I've been doing Clojure for the last few years and have a few grievances, but overall it's the most coherent, well thought out language I've used and I can't recommend it enough.

There is the issue of startup time with the JVM, but you can also do AOT compilation now so that really isn't a problem. Here are some other cool projects to look at if you're interested:

Malli: https://github.com/metosin/malli

Babashka: https://github.com/babashka/babashka

Clerk: https://github.com/nextjournal/clerk

BREAKING: walking a :schema passes children instead of [id] to the walker function #884

When you get to larger, more complex validations, I'd recommend checking out Malli or Spec.

for specs, you can try malli - feels pretty well supported and full featured: https://github.com/metosin/malli (i'm not 100% sure how popular it is for others, but I use it on my personal projects)

Have you tried malli: Data-driven Schemas for Clojure/Script?

All that being said, I particularly use malli and I don't find anything to complain about. There is a very nice and sound ecosystem being built around it (malli-ts is one of my contributions to it, but still in early development stages). I highly recommend reading its README, very informative stuff.

Any large codebase can be broken up into small isolated components that can be reasoned about independently. This is how you structure Clojure projects if you want them to be maintainable. Clojure inherently encourages doing this by defaulting to immutability. The contract between components is the data being passed to the component and returned by it. Using Malli schemas at the edges of the components is a typical approach to documenting their APIs https://github.com/metosin/malli

I see the fact that people often end up creating large and tightly coupled monolithic codebases in static languages as a negative aspect of static typing. Such codebases are difficult to reason about even if you have guarantees that the types align. Ultimately, you need to understand the relationships in code, and how they relate to business logic. The more coupling an application has the harder it becomes to reason about it as a whole.

Ideally, I think applications should be structured as a bunch of Lego blocks that can be composed together. Each component should encapsulate some functionality, and then the flow of the business logic should bubble up to the top and expressed in how these components are chained together.

Uhhh spec has existed for a long time and before that, schema Nowadays we also have the excellent malli. If his codebase is full of functions where the shape of the data isn’t obvious, isn’t documented and isn’t specified in a specific/schema, that’s on him and his bad coding practices and really no different from passing data in other dynamic languages. A class by itself (without additional effort) only gives you field names.