I still have to do my personal large scale project in Clojure, but I would like to share my thoughts so far. (10 years ago I implemented a 60k Common Lisp project; I never worked on more than 5k Clojure code so far; the C++ and Java projects I was involved in reached 800k to 1M lines of code).
I think one important ingredient for large scale Clojure projects would be the literate programming approach that Tim Daly described some time ago: https://groups.google.com/group/clojure/browse_thread/thread/460417fe45f314c3?hl=de In addition I think midje is a very good unit testing framework. I am currently working on a maven archetype that makes the construction of projects with literate programming and midje easy. The "toy project" that I am thinking of implementing in order to test the large scale characteristics of Clojure is the ERP like system described in "Java Modeling In Color With UML": http://www.amazon.com/Java-Modeling-Color-UML-Enterprise/dp/013011510X/ The biggest trouble in larger Clojure projects that deal with large data graphs that I have is with the lack of a "data schema" like a Java class definition or a SQL DDL schema definition or an xml schema. I just want to know how data structures have to look like even before instantiating the first instance of it. In addition a "reflection" like query mechanism and other meta data like validation rules would be helpful. I for myself came to the conclusion that Clojure is not made for large nested data structures on its own. I personally feel much better with a combined approach like the Functional Relational Programming approach recently mentioned here on the group: https://groups.google.com/group/clojure/browse_frm/thread/ba3da253f6358ac9?hl=de http://web.mac.com/ben_moseley/frp/frp.html I think one could use either SQL (e.g. an embedded h2sql database) or something like datalog: http://code.google.com/p/clojure-contrib/wiki/DatalogOverview to describe "entities" and their relations. Those entities would be maps in clojure with *few*! key value pairs. The nice characteristics of Clojure as a pure functional language that deals with immutable data structures and is easy to test would be kept. You could use SQL or datalog as a query language to link the smaller structures together, the entities, together. You could even write a runtime documentation feature that would display a graphical representation of an E/R like diagram. Clojure would be the pure functional aspect of the FRP approach and the data structures would be handled by the relational algebra part. I believe in what Alan Perlis said: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." That's the reason why I have my difficulties with Python. Nevertheless for large connected data graphs I think something like a data-schema is needed. Clojure would still follow its approach to only deal with maps, but there is a descriptive meta-data level in addition that explains the connection between those maps. I would agree to what was said elsewhere: the Clojure community has to come up with idioms on how to deal with large scale projects. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
