Clojure for Java (OOPS) programmers
‘legacy’ OOPS programmers vs ‘current’ functional programmers - people find it hard to go from one to the other
Intent is to explain the differences and make it easier for OOPS programmers to adopt Clojure. We’‘ll refrain from comparing which one is better.
Talk will be presented by Madhu (Clojure programmer) and Rashmi (OOPs turned Clojure programmer)
Discuss the paradigms - Encapsulation of data and methods vs immutable functions acting on input data and outputting new data.
(Examples of a simple java class vs a Clojure function)
Talk about how conditioned OOPs programmers are to classes and objects and at first glance it seems we are adopting a messy world of methods, procedures where there is no control over access to data.
Immutable functions are like mathematical functions unlike the methods, procedures of other programming languages.
For an OOPS programmer lack of classes meaning lack of structured code - namespaces in Clojure allow for structuring code.
OOPS requires management of references, their state change, it’s important to follow best practices to control the state change. References also lead to null objects.
Immutable functions get rid of references, explain persistent data structures for how copies of objects are avoided in Clojure.
Clojure - built on Java and uses the Lisp paradigm
All underlyng Java functionality is available. at the same time the Lisp paradigm enables immutability of code.
(Give examples of calling a String function the Java way and the Clojure way)
Seq vs Iterator - Seq follows the interface pattern, mostly all Clojure collections provide the ISeq interface. Stateless compared to Java.
Defprotocol, defmethod - Underlying OOPs polymorphism concept, how the lisp paradigm makes it immutable. (Give examples of Java and Clojure)
Clojure allows mutable state using a few data types -
Atoms - Based on underlying Java atomic variables. Explain.
Clojure - Ease of making changes by generating JAVA bytecode and testing.
Conclusion - Possible to have redundant code, not follow best practices in both Java and Clojure.
Rashmi has over 20 years of experience in product development in various verticals including 15 years in the Silicon Valley where she primarily worked at Adobe Systems on products like Adobe Illustrator, HTML5 animation and Video Publishing. She is currently the Vice President of Engineering at Quintype.