On Jun 17, 2012, at 9:38 PM, Timothy Baldridge <tbaldri...@gmail.com> wrote:
>>> I have also found that clojure code lacks cohesion we hate objects so we >>> are just going to throw everything into one large namespace and say we have >>> none... In OO I might call this a god class? I don't know, I'm not sold >>> yet... but I'll keep watching. > > That depends. In OOP we might call it a "God Class" if it was 100 > functions on a single mutable class. However, that's not what we're > doing in Clojure. The analogy to OOP would would be a class with 100 > static public members, and no private variables. This exact > methodology is used in .NET for example: > http://msdn.microsoft.com/en-us/library/system.linq.enumerable.aspx > > >>> Now if you want to change a map so that :area which was previously an >>> precomputed value to a deferred computation you now need to override ILookup > > I hear this argument at work dealing with Stored Procs in the SQL > database. "If you don't let me do ad-hoc queries, then when you change > the sproc, you're going to break all our code!". But the correct > answer to this complaint is: "I won't". If you need to change area > from pre-computed to defered execution, then you are changing the > actual semantics of the code. In that case, yes, you will either need > to define a different data api, or update all your old code to agree > with the new computation method. Most of the time, if you have code in > production, sticking with the first is the better route. Generally agree > > During the day, I work on a fairly large C# codebase, and I see these > same problems, but they are simply ignored by most .NET programmers. > If I call Foo.getBar(). I haven't the foggiest clue where on earth > it's going to get the data I want. It could be computing the value, or > simply returning a private variable, or it could be going to Mars to > gather a soil sample and use that in its calculation (blocking me > until it returns). That's one of the benefits of the "everything is a > map" method. I know that calling (:bar data) is going to return almost > instantly. You can re-write your data server to involve Mars trips, > but once the data is in my program, my code will remain snappy, no > matter how long it took to compute that data. Forget about getters, OO should be event driven in which case you dont call getFoo(), foo is given to you when your method is invoked making getters unnecessary. The clojure problem is different because events imply side effects. Although, I have never seen a program that does not have side effcts. I tried to write one once but it had no output so im not sure if it actually worked :) > > So I guess what I'm saying is that if you're deciding to switch area > from pre-computed to lazy execution, that's such a major change > semantically that you better reevaluate your code before simply > abstracting it and calling it a day. True too. > > But then again, I'm biased. I deal with so many layers of abstraction > at my day job sometimes I just want to stand up from my desk and shout > "A hashmap! My kingdom for a hashmap!". > I programmed in C# for years but changed to JVM cause windows isnt a good platform for web apps. I turned to clojure for many of these same reasons, i love that clojure values are immutable, serializable, and implement meaningful equality with basicaly no code. Pojos/message types should have these things :) but i think services classes should be event driven and emit new events rather than return values and delegate much of the work to the domain. I guess i feel like clojure consists only of pojos and god classes... > Timothy Baldridge > > -- > 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 a > 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
