I couldn't find a book that exactly matches Clojure. Still, I prioritize Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# by Scott Wlaschin. However, many concepts, such as algebraic data types, wrapper types, and monads, may need to be adapted or even ignored.

Thank you for your explanation?

What is your recommendation?

Is it to understand clean architecture and mold it to my usage, and use imperative shell patterns with it?

I haven't applied clean architecture with Clojure, but I'm working on a Python codebase that uses dependency injection intensively. It works, but I personally feel the pain every time I create a mock.

Although the clean architecture book mentioned vertical-slice architecture and added a new chapter about packaging by technical layers versus by features, clean practitioners seem to prefer packaging by layers, which should be approached with caution. I don't remember if the book mentions pushing I/O to the edges, or the imperative shell pattern, which would allow pure functions to cover more logic instead of having a service layer that interleaves I/O and logic.

I ask because it seems pretty popular in the Clojure community and I'm mostly developing with Clojure.

What?

I love babashka and the clojure ecosystem so much. Truly amazing.

I also love cli and tuis! So this might be heaven!

Yesss. wasm clojure is really a missing piece.

I didn't quite understand, so the react native app was 6x slower than the native app?

I didn't, but a linter or some other tool like that is much better suited for catching errors like that.

Did you spot the error with return?

And the theme the author used was a bit disingenuous. Like, why was audio two different colors? One for the declaration and one as the call member? Like of course it’s useless like that. I think there’s a happy medium between the two but I’m like you. If I’m coding and I need to find a variable I look at what color it is and then search for that color. If I need to find function defs I do the same. Same for everything.

I can see the point that too many program elements get too much color, but:

Suggesting to not color keywords and use a single color for the names of top-level elements at the same time simply doesn't mesh well.

I'm coloring keywords exactly because I do not want to invent a new color for each individual top-level element name or require backtracking from the (in his proposal) highlighted name to the (in his proposal) non-highlighted keyword preceding it.

Looking at the code example here I'd be open to have less things highlighted, but where to start? I guess parameter names, but apart from that?

Strongly disagree with the author on this. Syntax highlighting for me is to be able to differentiate discrete parts of code rather than being able to quickly identify what is what. I don't rely on syntax highlighting for catching errors since linters/compilers are a much more appropriate tool for that. Their color scheme is far too bare bones that it feels like one step above writing code in notepad. I have to do more thinking to see what the code is doing in the "improved" color scheme where the "inferior" version I can mentally see each part is distinctly different from the other parts. Maybe if they didn't use such a clickbait title I would be less harsh.

Wow I'm a big Clojure fan and work with Cesium daily, never thought I'd see them combined!

This looks like ai generated slop

I'm not sure if I understand why. I like snapshot testing, but I'm not sure what you gain from using this dsl approach instead of a snapshot library and a more typical test framework, but there are some notable downsides:

• you have to write typical tests in a different place from your snapshot tests. some things are more complex than "this value never changes", you might just care about a property holding, it produces the same value for several different inputs, etc. properly capturing a big for a regression test is more than a snapshot
• you lose editor tooling, I can't just send tests to the repl from my editor, I don't have autocomplete, etc
• need edn serializers for all values you care about. seems easy enough to return a host language object without a proper representation
• may just be me but I'm not a fan of the added levels of nesting

I partially agree, but this language intentionally doesn't try to change the way the user interacts with the language. Just unlocks another target for running on. A native target even. That's just great, right?

Hot Take, we need to stop inventing new languages and learn to use what we got, programming inherently has infinite complexity and so it can gain infinite entropy and infinite chaos, a good developer can work with anything a bad developer will turn anything into chaos.

I personally possess all of the musical acumen commonly found in gravel, and I'm just learning Clojure as a language, but I wanted to comment and say this looks like an incredibly interesting project and takes me back to when I downloaded a midi editor on my family computer many decades ago! Thanks for posting it here!