anyone here writen raw postscript by hand before ?

I'm fasicnated about how it differes from forth and how it supposedly has multiple stacks (beyond just instr and data)

Only for fun, made my school's printer do fractals once...

@akiroz: what are your thoughts on postscript vs svg ?

I'm building a little gfx library in cljs, and am tempted to write a mini postscript interpreter

hard to compare... SVG is not a programming language

I'd hate to use PS for any real work TBH, drawing instructions are not fun to read.

isn't the theory that in a forh like languatge you build up 'primitive words' that act as functions

so you build a 'vocab' dsl for the type of figures ou want to draw

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

That's the idea, qqq

@noisesmith: the problem with that argument is that one can replace PS with ASM and the statements would still hold

Have you had experience teaching clojure to very novice programmers?

Were they better to pick it up than experienced ones used to other paradigms?

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.

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.