rymndhng

I've had a lot of success (and fun) getting Claude to write a MacOS userland driver for a pointing device (ZSA Navigator).

See https://git.sr.ht/~rymndhng/teach-touch

I started with Clojure but ultimately ended up using scheme. Clojure has built in solutions to some of the things that you’re asked in exercises which I think takes away from the experience.

I’d suggest going with a scheme such as racket.

If we take away the `thing` that defines garment works (despite how unfulfilling we see the work), I hope that society does not leave these people behind to fend for themselves (and use the new efficiencies for earning money to re-train & re-tool these individuals.

Please check out datomic!

http://www.datomic.com/

Interesting. Another place where I've seen something similiarly done is for the Canadian Gov't.

See https://github.com/wet-boew/wet-boew

I wish the website would link to this talk which gives some background on how they got to falcor.

https://www.youtube.com/watch?v=hOE6nVVr14c

Some of my personal opinions is that the tooling is still kinda esoteric. For a regular Javascript project, there's nothing like including a script tag and hacking on the Developer Console.

With ClojureScript, I found it is fulfilling after spending time getting used to using Emacs, setting up interactive compilation properly (and tweaking settings). Tweaking leiningen settings is a pain when the feedback cycle isn't instant. Oh, and occasionally esoteric error messages.

But really, once you get past that, and if you still have the gumption to press forward, it becomes pretty magical. I've been hacking on Clojure/Script in my free time and I find it very satisfying to make use of the abstractions that are already provided.

Immutability doesn't have to be a discipline. It is the default when working with ClojureScript!

That's what I wonder as well. We've been inundated with mobile interaction for the last 7 sevens that maybe it's ok to start peeling off some of the layers.

If you started with the flat iOS UI from the beginning it would have been very difficult to get accustomed to. Nowadays, we don't rely on those skeuomorphic affordances because we assume touch interfaces are the defacto.

That said though, I do agree that we should think critically about seasoned vs beginner interfaces. We should strive to accommodate both without causing detriment to one group or another.

If your library is written in pure Clojure (no reliance on Java) it's fairly trivial with Clojure 1.7's Conditional Readers.

Here's an example of a repository that I've repurposed to compile both Clojure + Clojurescript.

https://github.com/rymndhng/clj-diff/commits/add-cljc-redo

I'm still waiting for stable tooling support. With Clojure 1.7, the introduction of Reader Conditionals via `.cljc` is a step in the right direction.

The tooling still isn't quite ready yet. I've tried porting some `.cljx` code over, but it's not quite working for me yet with leiningen.

Totally agree with the point of pen/paper.

Something that compliments that approach is in-code annotation. Recently, I've recently been trying out https://github.com/bastibe/annotate.el which is pretty sweet. Check it out!

Sweet! I've been learning cljs/om and one problem I had while going through tutorials is understanding where to put your state, where and why. This answer on Stackoverflow helped me grasp the bigger picture of Om.

http://stackoverflow.com/questions/22883759/what-is-the-diff...

It depends. One thing that I thought is an interesting feature of Spring, is that it allows the framework to inject code between your dependencies like decorators. This allows them to do aspect-oriented-programming transparently. And I think there's some interesting ideas here. For example, you can mark the interface of a class as @Transactional, and all your implementations will get the behavior.

My thoughts the same. Frontend dev is too forgiving as an interactive playground that I tend to iterate on the solution by getting some feedback from feeling things out rather than straight up knowledge.