On Dec 26, 2013, at 9:32 AM, Massimiliano Tomassoli <kiuhn...@gmail.com> wrote:
> Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a > little bit worried about the absence of support for OOP in Clojure. How do > you decompose large systems in Clojure? That seems like a very intelligent question. I didn't see that anyone in the thread mentioned Brian Marick's book, Functional Programming for the Object-Oriented Programmer. In the book, Marick emulates object-oriented programming in Clojure, which not only helps you see the greater flexibility you get with Clojure, but also helps you be a better OOP programmer when dealing with OOP languages. I'd definitely recommend the book. Another book worth checking out is Dmitri Sotnikov's Web Development with Clojure, which is a good survey of Clojure web development using Ring and Compojure. It illustrates well the idea of selecting the components you need for your web application and pulling them together, as opposed to the idea of a single overarching framework. I am a professional Rails developer and I like Rails. But I think the criticisms leveled against the single-framework model are very legitimate. If you want to do something the framework is not built for, you can spend a lot of time trying to work around the framework instead of using it. The easy things are really magically easy, but the hard things are pretty hard. Having said all that, here's what I really love about Clojure. Like Ruby and Rails, you can start off with an amorphous, ill-defined idea that you are prototyping. You can put it together, realize you had a lot of misconceptions (about the problem, the product, what people want, etc), and easily shift your assumptions. But Clojure shifts from Ruby and Rails when your idea matures and the invariants of your application settle. Clojure's tools give you more assurance of correctness when your app increasingly takes shape. Functional programming and immutability save you from whole classes of really fun state problems. Pure functions give you testability and transparency that are rarely seen in Rails apps. You can gradually add types to your arguments and return values (https://github.com/clojure/core.typed), thereby gaining much of the safety of statically-typed languages. You can use contracts (https://github.com/clojure/core.contracts) to ensure that your assumptions are always met, both regarding parameters and results of your functions. You can elegantly address all the possible cases of a set of parameters using matching (e.g. matchjure, https://github.com/dcolthorp/matchure/). Argument pattern-matching and destructuring is a fabulous tool and you really have to use it a little to realize how handy it is. In short, Clojure gives you all you need for prototyping, and when your idea jells out, you can tighten it down tremendously and expect fewer late-night phone calls where the app is breaking. Your software is simply more stable and correct, with less effort. Yet, you didn't have to pay the static-typing toll up front, when you needed the freedom and flexibility to try different things. I don't know if Clojure is ultimately right for you. But I can say with no doubt that learning Clojure will grow you as a software developer, and you won't be sorry you spent the time to get to know the language and the Clojure way of thinking. Good luck, steven -- -- 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/groups/opt_out.
