We're building an (open-source) application which takes as input a data model described by RDF files, and puts out a generated schema of several possible types (Apache AVRO for example, but we want to expand to all sorts things such as SQL schemas). So it gets quite "meta", and we deal with generation of all sorts of data structures from whatever input set of files we may have. We left Java, and are currently trying a functional (FP) approach in Kotlin. It's not too bad, but I'm not happy about a lot of things. I gave Clojure a try in my spare time and I fell in love immediately. Now, I'm trying to make an objective case for why it is more useful for our purposes, and I would love to hear your thoughts. Both in response to what I'm thinking, as any ideas of your own. First of all, I think static typing isn't useful here, but gets in the way. Modeling highly abstract data using types is tricky. It isn't as flexible as a heterogenous map with a spec, and moreover it's hard (if not impossible) to generate classes from data at runtime, as we need to. Of course, you can choose not to model using types, but if that's the route you're taking, I feel you're basically choosing Clojure and maps. Especially since maps in Kotlin are not heterogenous. Furthermore, functional programming in Clojure feels great. You can express yourself very strongly, and there's no hassle with weird syntax, complicated casting of types and noisy syntax (this is my experience in Kotlin). Transforming data has never felt so powerful. Another reason for choosing Clojure is the helpful development workflow using the REPL. Especially when building out data, it can be very useful to check out intermediate results before moving on. With Kotlin, this feedback is not only much slower, but it also requires me to run some main/test function, and worst of all make sure my types are in order (since the intermediate result often has a different type). I've noticed myself being greatly productive in Clojure thanks to this, and I feel that especially if the data gets complex, this is very helpful. Finally, since it's runs on the JVM we can use all sorts of Semantic Web libraries built in Java (like Eclipse's RDF4j) without issues.

If anyone's stuck with me so far, thanks already :). I would love to know if you think my arguments make sense and are sufficiently objective with regards to the application we're building. Besides feedback on my points above, I would appreciate other input as well. Particularly with regards to the following remarks/questions I'm anticipating from my manager: 1. Sourcing people for Kotlin is doable, but Clojure is an esoteric niche. 2. Isn't Kotlin a good enough choice to warrant continuing to develop in it (note: this project is very much in its infancy) 3. Static types provide a better guarantee for mature software. I don't like the idea of dynamic typing, it feels unsafe.

Your comment on static typing stands out to me. I worked with RDF on Java for many years, and while static typing is fine for RDF itself (subjects can be IRIs, or blank nodes. Predicates must be IRIs. Objects can be IRIs, blank nodes, or literals. Then the language-coded literals for string, and all of the menagerie of data types associated with literals), it is horrible when it comes to modeling data that is expressed in RDF. Objects need to be flexible. Every system I've worked with which tried to define the structure so that it would conform to a statically typed language, it's caused pain. You can just use a map, but then you lose all the type information entirely.

Clojure uses maps naturally, and it's built into the syntax of the language. Even better: • Records can be defined to have a particular set of keys, but other keys can be added ad-hoc. This is ideal for both having a type description (complete with protocols), while staying flexible enough to accept any new data that is encountered. • Clojure Spec is optional, but if it's used it can give more type information, providing not only key/value structure, but also the ability to programmatically define the structure. • Other systems like Malli can also provide optional type information.

Addressing your concerns: 1. There are lots of people who can write Clojure, and it's constantly growing. There are also a legion of people out there who are not writing Clojure right now, but are trying to find that first opportunity to do so. Even so, Clojure is not a difficult language to learn (as you know) and a competent programmer can switch to it rapidly. Even better, if they've already learned an FP language on the JVM (I came from Scala). 2. Kotlin is fine. After all, anything can be written in any language. But using a language that removes obstacles can make the process faster and easier. This is where Clojure has demonstrated it's utility in general. My personal experience is that RDF is a domain that particularly benefits from it. 3. See Spec and Malli. They provide optional types, with most of the benefits you get from types in statically typed languages, but offer so much more. Full algebraic data types (e.g. Haskell, Scala) may also offer more than basic data types, but then you're stuck with a rigid system that makes open world data extremely difficult to work with. These optional type systems in Clojure have been the best I've worked with for handling open world data.

Thank you very much. I think there's a lot in there that I can use to state my case.

FWIW: We’ve been using clojure and RDF together for nearly 8 1/2 years. I still think they’re a good fit. Philosophically clojure and RDF are cut from the same cloth. RDF was a big inspiration to Rich in the design of clojure (and subsequently datomic), and there are many, many areas where this inspiration shows itself. Being open for extension, namespaced keywords, composing composites out of reified properties upon which you attach meaning/specification etc, having an accretive data model etc. I’m not against static types; but I agree with @U051N6TTC that their use in RDF derived data models can be awkward. The reason is that in RDF classes are composed from their properties (and aren’t containers for properties)… Indeed in RDFS/OWL classes are often inferred from their properties. Type systems tend to containerize your representations; where as in clojure you can naturally express the properties as compositions in maps, and tools like spec/malli will help specify it (in a property centric way). I actually gave a talk on the topic of reified properties last week…. I’ll share it here once the recording is available.

Thanks for weighing in @U06HHF230, that's definitely useful 🙂. Can't wait to see your talk!

Sorry I'm late to the party. If you're not already familiar with it "Uncle Bob" (of "Clean Code" fame) wrote a great piece of Clojure evangelism: https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html, which might be worth passing along to you colleagues.

That just blew my mind. Uncle Bob loves LISP? Wow. That definitely is a good source to attract the attention from colleagues, thanks @UB3R8UYA1! Enjoy your vacation 😉

I'm actually still a working stiff. More of a state of mind :-)

https://www.functionalgeekery.com/episode-1-robert-c-martin/ 9 years ago where he talked about how SICP changed his life. He also talked about Clojure in positive terms

Yes it seems he's really sold on Clojure. Ever since that blog @UB3R8UYA1 referred to, it seems he speaks positively about dynamic typing and particularly Clojure in many more blogs (and indeed podcasts) . I have to say I respect the open mind here. I mean, he was heavily invested in OOP advocacy and seems revered up to the point of a God-like figure at times. It takes character to then change your mind so drastically.

@U06HHF230 > I actually gave a talk on the topic of reified properties last week…. I’ll share it here once the recording is available. Did you manage to get hold of that recording? I would still be interested. This Thursday is going to be the first of (hopefully few) conversations with my technical manager to try and convince him of Clojure.

Ah thanks for reminding me… It was just a short talk, and was purposefully pitched at a high/conceptual level for a government audience of developers…. https://www.youtube.com/watch?v=HtYWAZZWiAs I wish the organisers would have titled the video properly too but 🤷

The talk’s title was: Unpopular ways to make better APIs; forgotten and emerging knowledge in API design.

Your talk confirms a lot of ideas that I've been forming myself in the last few months, and then some! Very informative, thanks for sharing. 🙂