> Racket is not a good example. People learn it as non-interactive. The project now also switches to a conventional syntax without s-expressions. I can underst

> Racket is not a good example. People learn it as non-interactive. The project now also switches to a conventional syntax without s-expressions. I can understand that people that have achieved "lisp enlightenment" will view Racket this way. With respect to replacing s-expressions, I am hopeful that the original s-expression-based Racket retains prominence even when the Rhombus language is fleshed out. I know I will continue to use s-expressions. > a) interactive use (much of Lisp usage is 'interactivity first') To me, having used Clojure (which hopefully counts as an interactive Lisp) and worked in environments like A+ (in the family of APL/J/K), this is an amazing feature and I struggle to see this being such a "fundamental difference ... that is difficult or impossible to 'teach'" (paraphrasing OP). > b) the code as data thing and lack of static feedback (type checks, ...). With many people programming in Javascript, Python, and Ruby, the lack of static feedback seems less compelling to me. With "code as data" thing, as a Racket programmer, I rarely if ever think about macros or readers or code transformers. I am sure that can be understood as missing the whole point of lisp, but I have been productive in an environment whose underlying bits can make use of all of that and I can just write code as code and treat data as data in a manner similar to many other languages. Maybe I'm weird, but programming in a manner similar to Java but having code written with s-expressions feels better to me.