A Wize One once said > Closures are the poor man's objects
It's easy to build "object-like" things in clojure. Just create a map pointing to whatever you like, including stateful things, like atoms. Then write functions which take that map and do stuff with it. Clojure's Records and Protocols are more formal ways of doing this, with added performance optimization and bidirectional polymophism, so they may be worth looking into. You may also want to take a look at spec. You may be right about an object-oriented approach being the most natural here. But, I'd encourage you to keep an open mind. Clojure has this particular way of encouraging you to and rewarding you for describing your problem domain in terms of pain data, and writing program logic as (mostly) pure functions around that data. When statefulness is required, we're often careful about how we introduce it, and find ways to isolate it as much as possible from the non-stateful bits, thereby maximizing how much of the code we can keep pure. If you're already familiar with other functional languages, I may be saying nothing too new here. But Clojure still has a pretty unique take on the data-driven paradigm, so you may find yourself thinking about things in new ways. Even if you end up doing something pretty object-oriented, think about how you can steer things in this general direction, and other ways you might tackle the problem. Good luck Chris On Wednesday, January 10, 2018 at 3:13:00 PM UTC-8, Michael Nardell wrote: > > Greetings :: I am new to Clojure and have not really gotten my feet wet > with Clojurescript yet. The advice I always give someone when leaning > programming or a new language is to pick a project that they are interested > in and dive in. For me, that project would be creating educational > simulations that model complex systems. > > Part of my challenge with this as a project is that it is leading me > towards programming (at least partially) with objects to model the discrete > components in these systems. Arguably simulations are one of the domains > where objects are the right paradigm. The question I pose to the group is > how to work with objects in Clojure, in a manner that "goes with the grain" > of the language. Perhaps best to ground my question in a concrete example: > > I had created simulations / visualizations of Hubel and Wiesel's model of > the center-surround receptive fields in the retina. My past simulations I > used a collection of objects to model photo receptors (i.e. rods/cones), > horizontal, bi-polar cells, connected together to represent the behavior of > either on-center or off-center receptive fields. Kind of a simple neural > network. Would like to preserve the object nature of nodes in the network, > since the nodes have state and should be represented by graphics in a gui. > Ultimately I would like to move toward a "constructor kit" approach that > would allow students and teachers to model and simulate a whole variety of > various systems that can be represented as a network of processes with > feed-forward and feed-back connections. > > Interested to know of any useful examples and guidance for doing objects > the Clojure/Clojurescript way. Certainly one of the examples I want to look > at closely is the Ant Hill that Rich Hickey demonstrated. > > As is the case with a neophyte - any advice is well appreciated. > > Mike > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
