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
