And one more thing to say about polymorphism. In functional programing protocols are OO polymorphism inside out. It is possible because FP doesn't care of state, its operates only on its input and gives outputs (it is by definition - functional). We are taught from very beginning how to function in a poly way. For example on math classes we are taught how to operate on numbers depending on its classification.
And other story about being simple and Monads. I want to learn Monads, because I want to solve problems in declarative way. Unfortunately all tutorials on Monads in Clojure gives me a fish instead of fishing rod. Because of that now I'm learning Haskell. I believe that they are made there right. The funny thing is that after 5 days of reading of "Learn Haskell for Great Good" (for 45 mins. a day) and not programming at all (especially in Clojure), I wanted to implement some concepts from book in Clojure and guess what. I found my self saying "man it is so wordy when doing it in Clojure" - destructions, functions composition, lambda calculus, pattern matching done via library, imperative let statement, partials. But I think that one thing justifies it - homoiconicity and as a result its macros. Learn by that experience I believe that the source of inability to learn monads is that they are made hard in Clojure in terms of Rich speech. Funny thing is that I believe that I already know the purpose of monads and use cases where I could use them - I have even wrote code in Clojure which is missing monads as glue for my declarative specified statements in a algorithm - and believe that monads already should glue them, but they are missing in Clojure - they are made there via libraries and obscured by homoiconicity law. The sad story for me is that I have waste so much time of my life in doing some higher level concepts with wrong tools. I waste a lot of time on bugs; documenting; and learning cutting-edge, super hyped, students life cycle driven frameworks. The good side of this story is that I already knew what Rich is talking about, because learning about higher level concepts and expressing them with right tools, gives you ability to judge other solutions. Well, Rich don't leave us, you have such bright look on technology that you would easily support for example SAP with good tools to theirs domain problems, so its matter of time when you will get proposition to not reject. Or you could participate in such firm on your own, all you need to do is to make PRINCE2, ITIL; find CEO; decide what business problems you want to solve; get some sponsors; remodel your personal life to not neglect your family and you are another shark of the IT, of course hire me for Great Good in your company, I can work for you on eastern Europe. On 21 Paź, 23:10, Michael Jaaka <michael.ja...@googlemail.com> wrote: > Bravo, bravo! Great speech, I'm already looking for such esseys. I'm > already learning haskell and erlang for great good, because all things > told about lisp has been already read. > > I'm also designing system. Because it has some well defined > functionality, my first tought was, hey man I will use obect oriented > approach to creat model of that system. It is easy to document in UML > since I only concerned on fundamental operations. Complexity of > diffrent configurations I wanted to hide in poliformism of java oo > programing. But i have found it corrupted, nevertheless i will still > document it in terms of objects. OO is broken because it require from > me to build tree structure of impl. objects depending on types of > processing, I would make it simpler by message dispatching but, I have > choosed protocols. Still don't know if it will work, because never > used them before, but from read materials that is its purpose. I don't > need state of obj. because it is about processing input and spitting > output. > > Btw. from built-in data structures I'm missing trees. > > On 21 Paź, 22:25, daly <d...@axiom-developer.org> wrote: > > > > > > > > > On Fri, 2011-10-21 at 15:41 -0400, David Nolen wrote: > > > Just because we have dynamic types does not give us the freedom to not > > > consider them. > > > If all of these dynamics types and all of the tests "respected nil" > > in its many meanings then > > (when s ..., > > (when (seq s)..., > > (when (empty? s)..., > > would not be an issue. (when s...) would "just work". > > > > Clearly express a consideration about the types at play. > > > Clojure was supposed to transparently substitute things like sequences > > and vectors everywhere that lisp used lists. That would be true if nil > > was respected but is not true now and this complicates the code without > > apparent benefit, in my opinion. > > > In lisp you can ask what the type is (e.g. by calling consp, vectorp, > > etc) but these type-specific predicates are relatively rarely used. > > In fact, when they are used then you are struggling with data-level > > issue that could probably be abstracted away (e.g. a code smell). > > > Clojure is a great language but the nil handling is, in my opinion, > > a design flaw. It forces the introduction of (empty?...) and an > > awareness of the data types into view unnecessarily. > > > Tim Daly > > Literate Software -- 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
