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.
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.
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.
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.
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.
I’d suggest going with a scheme such as racket.