Clojurians Log v2

To be fair, you can see it in even in Clojure itself.

Jazz is for everyone, man

The other one I’ve seen is klass, which lends it a distinctly germanic feel

In terms of informal strength, I would classify it like this: clazz < class < klass

user=> (def сlass nil)
#'user/сlass
;; No warnings

That’s great, for when you want to informally encourage a more exotic class type

If you don't want to hide anymore:

void hi(Class<T> jazz);

çlass if you've got it on your keyboard (and you hate your colleagues who don't)

If on a mac, your colleagues need to learn how to hold down c for a second. I don’t have it on my keyboard, but I çan čompletely get around this ĉonundrum.

In another universe, browsers render EDN / hiccup natively.

I’ve given up hope that the browser will ever improve much. I’m continually surprised how most of the principles from https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey/ have yet to be applied to UI development. @p-himik thanks for sharing! I initially passed over this link, but revisited it based on your suggestion. 👍

> In another universe, browsers render EDN / hiccup natively. Hiccup is helpful for representing DOM nodes, but the DOM is a no good, terrible object oriented representation for user interfaces. We can do much better!

Well, in that universe, the DOM is just a Value; an HAMT.

Hiccup solves a problem that shouldn’t exist. One of the problems with "the DOM" is that the meaning of the DOM is ill defined, varies substantially from person to person, and is often unrelated to its plain meaning (Document Object Model). It's hard for me to provide a better example of something that is most definitely not a value than the DOM. I think one of the reasons there isn't much progress solving the problems mentioned in "Are We There Yet?" in the context of user interfaces is that the DOM has been dominant for so long that folks have forgotten what it might be like to do it any other way.

@smith.adriane by DOM do you mean specifically like HTML, with string types and divs everywhere? Or would you also have problems with a different type of DOM like Flutter, where you still have nested components that have a lifecycle, and layout considerations flow both down and up?

Oh, I think I remember your position on this now - you wanted a focus on just functions and drawing primitives.

That is interesting, haven't tried an app with that approach yet

> Or would you also have problems with a different type of DOM like Flutter Does Flutter have a DOM? All the problems with Flutter's API are essentially the same problems you encounter when comparing OO with functional programming. > Oh, I think I remember your position on this now - you wanted a focus on just functions and drawing primitives. The key idea is to directly represent whatever information is important for your user interface. If it's an interface with 2d graphics, that will most likely be something like shapes, text, and images. If it's a UI with 3d graphics, it might be meshes, textures, and cameras. If it's a UI with a guitar hero guitar as input and sound as output, then you represent that. The DOM API provided by the browser has all of the problems you find with OO approaches, but also provides a very unnatural, indirect representation for 2d graphics even if you do try to treat it as data (there's also a lot of state only available in the DOM API that isn't represented in HTML). > That is interesting, haven't tried an app with that approach yet You probably do want something higher level than a graphics API can provide. It does take some design effort to apply functional programming principles to user interfaces and there aren't a whole lot of examples. I think this is why it's an uncommon approach, but I wish more people would try!