Will do!

The best description of what I mean by data is https://www.infoq.com/presentations/Value-Values/.

> why existing IDEs miss the mark? There are definitely lots of IDEs that do cool things, but are missing one or more items from my wish list.

With respect to data orientation, most IDEs don't represent information as immutable data. If all internal state uses immutable data, it's much easier and safer to share. If everything is mutable, then sharing data is hard, which why most IDEs don't have pervasive sharing. As an example of an IDE that does provide access to data pervasively, but makes very different trade-offs than Easel, see https://gtoolkit.com/.

Using an IDE where all the tools take data and share data has dramatically changed my workflow. You can sort of get this feeling when you pipe together a bunch of shell commands `find ... | grep ... | tee ... | nc ... | etc...`. However, I think 1) sharing data rather than strings and 2) having a 2D graphical user interface is a big upgrade from piping shell commands.

I did consider that. I think it's possible, but there are a few challenges:

- It's much harder for components in separate processes to share data efficiently

- Window managers tend to be OS dependent. I want something that is cross-platform

- Coordinating components in separate, asynchronous processes is hard

- Working with OS window APIs is more annoying than writing a layout library

> although I'll note that there are plenty of ways (most of them via Java interop) to introduce mutability of some kind into a Clojure program besides the first-class reference types (atoms/refs/agents/volatiles.)

Fair point, I tried to word that statistic accurately without being too verbose.

> I'd be interested in an analysis in what percentage of Clojure functions are truly referentially transparent, but that's difficult (if not impossible) to determine statically.

Absolutely, I'm not sure it's possible or even practical to measure functional purity in an absolute sense, but there's definitely room for improvement:

- measure Java Interop

- measure usage of mutation functions (eg. swap!, set!, binding, send, vswap!, alter, etc)

- measure (def ^:dynamic *my-var*) usages

My intuition is that the numbers wouldn't change that much, but I'd rather have the data than guess.

Every software architecture promises to make your software better and easier so the subheading is mostly buzzword "noise". It's unclear what makes polylith different other than it claims it's more functional. I've tried to click through to understand what Polylith means in practice.

Is it?

- read through our book and you'll become better at designing great code

- read through our book and learn how to refactor your current codebase into a better codebase

- use our tools and you'll build better systems in less time

- use our libraries and you'll build better systems in less time

- buy into our ecosystem and get lots of pluggable components

- something else?

Conceptually, I get that better design can improve development workflows, but it's hard to tell where the rubber meets the road when it comes to polylith. When I read the transitioning to polylith, it sounds like I have to download some new tool, "import" all my code, and then I rewrite all the code? That sounds like a lot of work and I still don't know what the that means in practical terms.

Polylith is, first and foremost, an opinionated file structure for codebases (similar to how a framework forces you to structure your code in a particular way). Polylith's structure gives a host of benefits for the modularity, composability, testability, and "growability" of the codebase, and for giving a near friction-free development experience when working with your code in an editor/IDE.

One of the key benefits is how it separates development from deployment, giving you the freedom to work with your code as though it's a monolith, but choose to deploy it as any number of services.

To make the development experience even more delightful, we've also built a tool (currently only supporting Clojure, but with nothing stopping the development of tools for other languages) which gives instant creation of new components and bases, incremental tests (only test the code that's impacted by the last change), build support, and project visualisation.

So to answer your question, there's definitely some code rewriting involved to convert to Polylith from an existing codebase, but usually the steps involved are quite clear, and the outcome will be a codebase that we predict you'll be delighted to work with!

If you're interested in desktop alternatives for clojure, check out https://github.com/phronmophobic/membrane. It's different from javafx in that all the event handling code is pure clojure. For graphics, it uses skia, https://skia.org/.

Love the example with the spacer, guess we're back to building UIs with tables soon as well!

  (defn counter [num]
    (horizontal-layout
     (on :mouse-down (fn [[mouse-x mouse-y]]
                       (swap! counter-state inc)
                       nil)
         (button "more!"))
     (spacer 5 0)
     (label num (ui/font nil 19))))

Otherwise, haven't heard about Skia before, so thanks for sharing that, looks really nifty.

Thanks! More complicated layout strategies are easy to integrate, but spacer works really well for examples since most people can intuit what the result will look like.

Skia has worked well so far. Since it's used by Chrome, Android, and Firefox under the hood, it means that I can reach a lot of platforms "for free".

All of the core.async operations having blocking versions (eg. >!! vs. >!) which means you can use your own threads/thread pools for any work, if needed. Basically, you create your own threads instead of using go blocks and then use the blocking operations, >!!, <!!, alts!!, alt!!, etc.

I've found that maxing out the key repeat rate makes life better. System Preferences > Keyboard. Select the keyboard tab then move the Key Repeat slider all the way to the right.