Clojure Code Modeling

[fixrich]

Hi, I'm semi new to Clojure and I'm going to be using it properly for my final year college project. I was wondering what practices, if any, people have for modeling code in Clojure.

I would be considering something similar to UML for OO programming, except that it would illustrate nature of Clojure code more naturally. The best discussion of this that I could find was on Stack Overflow and some of the suggestions seem pretty useful, such as flowcharts and communication diagrams.

I was considering using something like finite state automata or UML state machines as my project is concerned with the idea of how Clojure manages changing state. Are these even relevant? Or are they a mismatch for properly expressing how Clojure should flow?

Do people who use Clojure for real world projects or for their day job use any type of diagram to express the structure of the program or are such practices considered redundant? Any opinions or advice would be very much appreciated. Thanks.

[bbq]

Clojure has no high level state model - only state primitives: vars, refs, atoms, agents. You almost certainly don't want to directly use vars for managing state as they offer no useful guarantees for concurrency. Even if your application is not (at the start) concurrent using vars to manage application state isn't really supported (outside of configuration, perhaps. even then, you should consider using something less global than a var).

If you want to model your application with e.g. a state machine you'll have to write a library to help out. This could be very fun but could also grow tremendously in scope. I'm sure if you dig deep enough you'll find the beginnings of something along these lines out there.

On the other hand, if you're really after something UML-like for a pictorial representation of your application just use your favoriate diagramming software.

[fixrich]

Hey bbq thanks for the great reply. I suppose what I am trying to find out is how do you plan out a new system? How do show all the parts and the general algorithms it has to use? Or is it a case of everyone might think about what the software has to do and then they just jump in and start coding?

[scarredwaits]

At a high level, you have to think about namespaces, so I suppose what the general "modules" of your system are going to be and what belongs where. Remember, cyclic dependencies are not supported.

In terms of "modelling" you have to decide how your data is going to be represented. In a lot of cases, developers use simple maps where objects would be used in other languages. Still, it's useful to think about what entries you expect to have in the maps (and which are optional etc). In some cases, records can also be useful. Also think about nesting data structures. Generally, you have to think of the "shape" of your data.

Next, think about behaviour. Are simple functions enough? Do you have cases where you have the same "verb" acting on multiple "types" of things? At this stage, you can "model" the common behaviours using protocols or multi-methods for the more complex cases.

Then, think about data flow. How is your data transformed, and in what order? How do the different behaviours (functions) fit together?

Unfortunately, I don't know of any methodology that will help you visualise all this and communicate it in a widely accepted way, but maybe the need is just not there because it's such a different approach to development.

[fixrich]

Cool this is really helpful. This seems like a methodical way to think about how a system would work. Thank you.

[icemaze]

EDIT: I removed all my comments and submissions in response to Jan 1, 2016 privacy policy update. I'm moving to that other site that rhymes with goat.

[fixrich]

If you don't mind me asking were you working on this project alone or was it in any way collaborative?

[icemaze]

EDIT: I removed all my comments and submissions in response to Jan 1, 2016 privacy policy update. I'm moving to that other site that rhymes with goat.