Simulations in Clojure/Clojurescript

[Michael Nardell]

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

[Christopher Small]

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

[Michael Nardell]

On Wednesday, January 10, 2018 at 4:56:24 PM UTC-8, Christopher Small wrote:

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. 

Chris :: Thanks, I am hoping that you are foretelling the path I will end up following. That I start with an object approach, because that is what I am familiar with and have used in the past. Then find new ways of thinking about the problem through through functional and Clojure programming. I think a good starting point, is as you recommend, substitute maps for objects in my thinking in the problem domain. I can see that I could actually set-up the simulation just so, and I will have completely captured the model, frozen at time t=0. Then my challenge is to write a set of functions that will transition the model to time t+1. At that point I am done. 

Mike

[Bobby Eickhoff]

I don't have any examples to provide, but I would highly recommend reading through Rich's essay on Identity and State: https://clojure.org/about/state

Bobby

[Michael Nardell]

Bobby :: Thanks for the recommended reading, I am finding it useful for pointing me in a new direction in my thinking. Also, finding Chapter 9 in The Joy of Clojure, where it discusses Records and Protocols, helpful guidance. In particular, it seems like I could start by using 'plain-old'  maps and functions, and easily 'slot-in' Records/ Protocols when/if  design or performance considerations warrant their introduction. 

Mike

[Christopher Small]

Joy of Clojure is a wonderful book.

Sounds like you have the right idea.

Enoy!

On Fri, Jan 12, 2018 at 9:55 AM, Michael Nardell <nar...@ucsc.edu> wrote:

Bobby :: Thanks for the recommended reading, I am finding it useful for pointing me in a new direction in my thinking. Also, finding Chapter 9 in The Joy of Clojure, where it discusses Records and Protocols, helpful guidance. In particular, it seems like I could start by using 'plain-old'  maps and functions, and easily 'slot-in' Records/ Protocols when/if  design or performance considerations warrant their introduction. 

Mike

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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 a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xHAoFwEZ-aA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tiago Antão]

My $0.02,

I was a very early Clojure adopter, but I stopped using it when Oracle bought Sun (I left the JVM completely at that time). I am currently using ClojureScript a lot - for the last 6 months or so, thus not the most experienced programmer.

Most of my usage is doing scientific simulations (genetics and epidemiology in my case). I published one simulator in Scala and Java. Done quite a few in Python+C and currently working in JavaScript + ClojureScript.

My observations here come mostly from my Scala work and my current work in JS+CLJS.

First observation is that a lot of scientific simulation code is highly imperative (not saying if that is good or bad), so lots of the mentality in the field is geared towards that. Still lots of Fortran floating around, for example.

In many cases performance is really really important. This tends to be CPU bound, rarely disk or network. Sometimes memory might be a consideration.

My general strategy is to do the computationally expensive core in a lower level language. For example, my Scala simulator had the core written in Java. My ClojureScript stuff has a JS core (and in the future will have parts in C). The Python stuff had C/C++ code.

The higher level language (Scala or ClojureScript) provided the interfaces to manipulate the lower level code in a declarative, elegant and functional way (actually DSLish way).

Tiago

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Tiago Antao

Scientific and HPC programmer

http://tiago.org

https://github.com/tiagoantao/

[Michael Nardell]

Tiago ::Thanks, for your input. Worth more considerably more than $00.02 for me right now. Since the last week or so, I have been diving into ClojureScript. In particular I am loving exploring D3.js, with an interactive, live coding experience. I am not sure if I should admit this in public.. but I actually really miss Macromedia Director + Lingo. Offered an interactive environment for building highly visual simulations and then distributing on the web. I am seeing ClojureScript + FigWheel + D3.js (and/or other viz libraries) as a way to get that experience back. 

MIke

[Tiago Antão]

Hi,

Have a look at Vega and Vega lite for visualization... Amazing chart library

On Jan 27, 2018 11:48 AM, "Michael Nardell" <nar...@ucsc.edu> wrote:

Tiago ::Thanks, for your input. Worth more considerably more than $00.02 for me right now. Since the last week or so, I have been diving into ClojureScript. In particular I am loving exploring D3.js, with an interactive, live coding experience. I am not sure if I should admit this in public.. but I actually really miss Macromedia Director + Lingo. Offered an interactive environment for building highly visual simulations and then distributing on the web. I am seeing ClojureScript + FigWheel + D3.js (and/or other viz libraries) as a way to get that experience back. 

MIke

--

[Christopher Small]

I'll second looking at Vega and Vega-lite. Grammar of graphics is wonderful.

With regards to simulation on Cljs, keep in mind that JS is limited in numerical precision relative to the JVM, and this can be important in some simulation contexts. Just make sure you are aware of the probabilistic implications for your application.

Chris

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xHAoFwEZ-aA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+unsubscribe@googlegroups.com.

[John Newman]

You might want to look into Chris Granger's work on component entity systems in clojurescript: http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/

Light Table went on to have a similar component-entity layout internally.

[Michael Nardell]

On Saturday, January 27, 2018 at 6:11:59 PM UTC-8, John Newman wrote:

You might want to look into Chris Granger's work on component entity systems in clojurescript: http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/

Right! Thanks for reminding me about that. I think I watched his talk a while back, and saw it as a natural way of modeling some of the systems I am interested in. 

Mike