This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (73)
- # capetown (1)
- # cider (13)
- # cljsrn (4)
- # clojure (56)
- # clojure-russia (2)
- # clojure-uk (1)
- # clojurescript (50)
- # community-development (3)
- # cursive (1)
- # datomic (80)
- # defnpodcast (2)
- # emacs (2)
- # fulcro (16)
- # graphql (8)
- # hoplon (206)
- # immutant (43)
- # keechma (4)
- # lumo (4)
- # off-topic (26)
- # perun (2)
- # re-frame (2)
- # reagent (4)
- # remote-jobs (2)
- # rum (4)
- # shadow-cljs (82)
- # spacemacs (5)
- # vim (6)
I'm fasicnated about how it differes from forth and how it supposedly has multiple stacks (beyond just instr and data)
I'm building a little gfx library in cljs, and am tempted to write a mini postscript interpreter
isn't the theory that in a forh like languatge you build up 'primitive words' that act as functions
postscript has functions, but I think most ps in the world is terrible machine generated stuff not suitable for human consumption http://rigaux.org/language-study/syntax-across-languages-per-language/PostScript.html
@noisesmith: the problem with that argument is that one can replace PS with ASM and the statements would still hold
I found that the person's experience wasnt a problem, time and stress were. Someone doesn't want to spend energy on a new way to do the same thing
People that don't know any method, obviously don't have that issue
@matan I have, as part of ClojureBridge -- http://clojurebridge.org -- and for the basics of Clojure, it doesn't really matter whether they have programming experience or not. Beyond the basics, I've seen folks with a purely OOP background have a harder time "getting" FP and immutability etc...
Question that remains is whether people without OOP background or much programming background are able to get up to speed. E.g. take the average data scientist who only knows some python.
I once read a book about "intelligence" and knowledge and stuff like that. I dont remember much, but the main takeaway was that in general, people that are able to compare problems to other problems they already solved before (independent of domain) and are able to find similarities in these problems in general perform better and faster in solving new problems that have been unknown to them.
I've experienced this regularly. It affects how we internally model the problems and solutions. There's a flipside to this, though, in that this approach can also lead us to miss areas where problems differ from our experience; we can reach too easily for the known, and not discover the unknown. In general, when you see a solution model that just doesn't seem to 'fit' the problem you're working with (a la DDD), chances are you picked a problem model that wasn't as similar as you'd thought.
So I would say you cannot divide people in to "know OOP" vs "dont know programming" but something else, whatever the name for this kind of adoption is.
People do come with biases, and I've found that in general the less biases they have in conflicting views of programming the easier it is. So teaching junior devs who learned about OOP last year is much easier than a intermediate dev who perhaps has been immersed in hard-core OOP for the past decade.
Same goes for types, and a lot of other things
But even that depends on how sold the person is on these concepts. Teaching someone FP when they don't have any problems with OOP isn't easy, because you'll have to constantly justify why something is "different" or "harder" than OOP.
In my case I listened to "Are We There Yet" and my head hit the desk because every problem Rich identitifed was something my employer was doing at that exact moment.
So FP was an easy sell to me.