Thanks for the suggestion. I understand part of the joy (and pain) of learning a new language is to change the way of thinking. So I probably need to take on something no-trivial but also not overwhelming to understand the issue or benefit better.
But eventually, a language cannot meet everybody's needs/tastes. In my view, there are certain patterns that are just "natural" to most people (not simply because they were taught like that in school), and a language will be more productive for those people to have those patterns (maybe with extra enhancements and enlightenment). I am sure with maps and multimethods you have actually a superset of any OO systems, and certain people find it much productive, but lacking direct support of certain natural patterns will lose many capable but non-genius programmers (which is nothing wrong if that is not part of the language's objectives). Part of my learning here is to find out if the language is right for me. On May 20, 5:37 pm, Bill Caputo <logos...@gmail.com> wrote: > On May 20, 2012, at 4:23 PM, Warren Lynn wrote: > > >> defrecord, deftype, and defprotocol provide extensible low level > >> abstractions like the kind Clojure is built on. > > >> As a Clojure programmer you should only need them rarely. > > >> As a beginner you should never use them. > > Well, I don't want to be a beginner for too long, :-) > > I am not a clojure beginner (though far from feeling I know all there is to > learn about it). I have been using clojure for almost a year; my team has > rebuilt the central part of our system (which is relied on by just about > every other team where I work) out of clojure and have had it in production > for 6 months. > > I've yet to even learn *how* to use defrecord, deftype & defprotocol. > > IMO, If you're not doing a lot of java interop (i.e. where your clojure code > is being consumed by java clients) you might never need them. > > As someone who came from, C++, C# & Ruby (and a little Java) - i.e. OO - to > clojure & FP, I *strongly* recommend that you take a project (preferably one > that you aren't hanging your livelihood on, but trust me it's a real rush) > and try *really* hard to solve your design problems just with maps, vectors > and the other core data structures (I first tried this in ruby, btw - a great > learning experience and gave me a strong appreciation for the optimizations > that clojure provides to make such code practical). > > IOW: pretend for a project that OO doesn't exist. When you're done, you'll > have learned a lot, you'll still have what you know about OO, and when you're > done you'll have lost nothing except your time and your perspective. You'll > be doing yourself an enormous disservice if you simply try to map clojure > onto your current way of working/thinking. > > bill -- 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
