clojuredesign-podcast

Discussions around the Functional Design in Clojure podcast - https://clojuredesign.club/
2019-07-28T01:56:36.054200Z

@nate @neumann Just finished listening. You guys covered it well! In answer to your question as to why the other teams migrated to Kotlin, I don't know that there was any single answer to that. Seemed like a combination of chasing the next new thing, a sense that since Intellij (we are a Jetbrains shop) was promoting Kotlin, and a concern one of our senior administrators had over the future of hiring Kotlin programmers over Clojure programmers (being self-assured that Kotlin was going to be more successful than Clojure). A close friend of mine, and also a team lead that stayed with Clojure told me the reason they stayed is because, unlike any of the other languages, Clojure is data-driven. Being data-driven, the time to get a solution out to production is significantly faster. Being able to shape the language to the problem, rather than the other way around is what makes working with a Lisp like Clojure way better.

neumann 2019-07-28T03:37:25.055200Z

@lodin.johan Oh, that's a good insight. Thanks! That's a helpful thing for me to keep in mind.

neumann 2019-07-28T16:05:53.055300Z

@trhawes Thanks for listening and sharing! Yes, data-driven is such a huge thing. @nate and I should talk about that specifically. I think it has come up a bunch, but it probably deserves it's own episode.

2019-07-28T20:49:47.055700Z

@neumann I definitely think data-driven programming ought to be front and center when discussing Clojure. When a different programming problem comes up, people look for the best language for the job. You don't need to change languages, when you can rewrite the language for the job. Homoiconicity is key, and almost unique to Lisp dialects (Julia, Prolog, and Tcl probably being the most popular non-Lisp homoiconic languages).