This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-15
Channels
- # admin-announcements (3)
- # aws (1)
- # beginners (1)
- # boot (73)
- # cider (1)
- # clojure (146)
- # clojure-japan (4)
- # clojure-nl (3)
- # clojure-russia (90)
- # clojurescript (72)
- # community-development (17)
- # core-async (10)
- # cursive (60)
- # datomic (15)
- # devcards (7)
- # emacs (5)
- # events (5)
- # hoplon (3)
- # instaparse (3)
- # ldnclj (48)
- # leiningen (5)
- # off-topic (27)
- # om (120)
- # onyx (31)
- # re-frame (7)
- # reagent (7)
- # ring-swagger (17)
- # yada (3)
I went from a clojure project to Java today. I'm totally getting what Rich means with working with data vs objects. Immutable data + functions is so much simpler than a mutable domain model with mixed annotations from several libraries to serialize and store/retrieve
My past experience with Scala and its community suggests two different worlds: the "better Java" crowd, using OOP with some FP mixed in, gathered around the more "enterprise" end of the market; the ScalaZ crowd, using as much pure FP as they can but having some of the same issues as the Haskell community does at times (too much dogma, too much academia, too condescending).
But that was back in 2009/2010 primarily. Things may have improved by now.
@seancorfield: maybe I should look at some typical Scala applications for comparison
i think in general programs/langs that are oriented towards OOP you'll see code being emphasized as the API rather than data
Even in clojure, it's not always 100% rosy. people have history with other models, and it comes across in API design IMHO
There's another Rich talk where he ponders if data is good enough for communicating between systems over the wire, why isn't it good enough within a system?
And: > When we drop down to the algorithm level, I think OO can seriously thwart reuse. In particular, the use of objects to represent simple informational data is almost criminal in its generation of per-piece-of-information micro-languages, i.e. the class methods, versus far more powerful, declarative, and generic methods like relational algebra. Inventing a class with its own interface to hold a piece of information is like inventing a new language to write every short story. This is anti-reuse, and, I think, results in an explosion of code in typical OO applications.
which is from this old interview http://www.codequarterly.com/2011/rich-hickey/
@ghadi: for me, it was important to realize that every time I create a new class in Java, I am creating a brand new interface that no one knows how to use. there are conventions (setters) but there is no generic interface to the actual data trapped in the fields of the object (other than reflection, which is in practice too cumbersome and slow to actually use for this purpose).
Java has means of abstraction, like interfaces. but applying abstraction via interfaces (for example, creating an Emailable interface to be able generically use getEmail on both Company and Person) means a) ADDING code (a new interface) and b) CHANGING existing code (Company and Person). Thus the act of abstraction both makes your code base bigger and is invasive.
Clojure provides a single generic data interface (the collections, most importantly maps) - every map (or record) works with the exact same set of functions. You do have to know the keywords to access individual elements and it's kind of interesting to really meditate on that and how that compares to setters in terms of knowledge and maintenance. I'm not suggesting that Clojure's approach solves every problem, but imo it's vastly better than Java's approach.
And abstraction tools like multimethods or protocols do not require you to modify existing data - they let you extend behaviors to data from the outside. The combination of the generic data interface and open extensions means that most acts of abstraction in Clojure reduce code size and make it easier to understand. That's crucial in the long term.
And then beyond that, there's immutable values with known semantics vs mutable objects with broken concurrency and equality semantics
I just saw an example of a domain modelled with case classes in Scala. When you wanted to 'update' an existing instance, that looked cumbersome too
@alexmiller: thanks for the elaboration, very insightful
similar ramblings in longer form here: http://chariotsolutions.com/screencast/phillyete-screencast-6-alex-miller-clojure-enemy-of-the-state/