2011/1/3 Jozef Wagner <jozef.wag...@gmail.com> > Our team works on big EU projects, where there are many technical partners > from different countries cooperating. Most of our work is about choosing a > good technology and then about customizing and integrating it into our > system. Usually SOA, Enterprise Java and semantic web technologies are in > place. > > Many people argue (and my colleagues are among them) that LISP is not > suitable for such environments (many coders, tests and use cases, have > to produce explicit designs and specifications e.g. because other team who > builds on your work is in different country). They say LISP is a hacker > language for lone warriors, not suited for big teams, where code must be > understood by many. > > See also http://c2.com/cgi/wiki?LispIsTooPowerful , > http://c2.com/cgi/wiki?SocialProblemsOfLisp and > http://c2.com/cgi/wiki?HackerLanguage > > They are IMO right if by LISP a Common Lisp is meant. But I have a feeling > (and I want to believe) that Clojure has largely fixed this social problem > of LISP, just like it has fixed the other big social problems of LISP, > namely http://c2.com/cgi/wiki?LispUsersAreArrogant :) > > My colleagues all know and have been using LISP (in academics), we are an > AI department after all. How can I explain them that Clojure is also useful > for enterprise projects and big teams? Or is it not? > > Some of my arguments are: > - Clojure has no custom reader macros, makes it easier to read others code > - Protocols and the way clojure handles data helps to explicitly formulate > specifications and designs > - Fresh syntax which improves readability > - Easy integration with familiar technologies thanks to JVM > - Modern collection types, not just lists > > What are your thoughts? How would you argue? > > Some more arguments for you: - More opinionated, which has the interesting side effect that some "idiomatic" clojure can emerge (using immutable as the default, managed ways to get into the mutable world). "Common Lisp" in this area is more open to different "styles of programming". Clojure makes one style be easier than the others. - It's not just about modern collection types (after all, common lisp has these built-ins too, hash maps, etc.), it's more the way that Rich placed the focus on abstractions first. In a nutshell "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures." - Alan J. Perlis" versus "It is better to have 100 functions operate on one data abstraction than 10 functions on 10 data structures." (generally attributed to Rich Hickey).
> -- > 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<clojure%2bunsubscr...@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 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
