rymndhng

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.

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.

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.

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.