tag:blogger.com,1999:blog-22587889.post4192709327590596880..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Domain Models - Thinking differently in Scala & ClojureAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-22587889.post-40322384103250896582011-07-05T23:58:53.492+05:302011-07-05T23:58:53.492+05:30It's not clear to me why those vals are lazy. ...It's not clear to me why those vals are lazy. Could you elaborate?<br /><br />Cheers.Stevenoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-20409466053397061632010-09-29T01:43:22.221+05:302010-09-29T01:43:22.221+05:30Posted my thoughts about the subject on my blog: h...Posted my thoughts about the subject on my blog: http://sbtourist.blogspot.com/2010/09/dynamic-mixins-in-clojure-experiment.html ... your feedback would be greatly appreciated :)Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-22598371201064257992010-09-28T08:07:20.527+05:302010-09-28T08:07:20.527+05:30thanks for a very good blog on a subject of these ...thanks for a very good blog on a subject of these two languages, Scala and Clojure.<br /><br />I started reading your entries to figure out which of these two language to select and the more I read I find that inevitably both languages offer different ways to think and implement solutions.<br /><br />Reading about Clojure and experiment a bit with it I very much like its elegance but soon I find material on Scala and same effect often for different reasons and it appears that you and others master both quite well.<br /><br />Thanks again for your work re subject languages and look forward to reading your bookAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-14324482662372685922010-09-28T03:59:00.988+05:302010-09-28T03:59:00.988+05:30Great post, really.
I admit I am far more comfor...Great post, really. <br /><br />I admit I am far more comfortable with Scala than with Clojure so probably my judgment could be a bit biased. Anyway I find the Scala solution far more readable and easy to understand. I guess also syntax issues also play a role in that. I am afraid completely functional languages are not a good playgroud for creating DSLs. <br /><br />In my experience, if I design well my DSL in Scala, I am often able to allow business people to read, understand and validate my business logic even if they never wrote a line of code. A few months ago one of them (one of the smartest I met in my life to be honest) was so fascinated that he asked me a short dictionary of the keywords I used in my DSL and by looking at my examples he was almost able to write the entire business logic he needed in pure Scala making only a few trivial and basically syntactical mistakes.<br /><br />Provided that the biggest part of problems in our job come from the frequent misunderstandings between men-with-tie and geeks, shouldn't be fantastic if business men were able to write (and modify) their business logic by their own? Do you think you could achieve a similar result in Clojure? I am very skeptical of that.Mario Fuscohttps://www.blogger.com/profile/05495580929866102756noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-8435438628344623992010-09-28T01:49:11.104+05:302010-09-28T01:49:11.104+05:30(sorry but i use twitter almost automatically, i r...(sorry but i use twitter almost automatically, i rewrite here my twitter comments to continue the thread):<br />You're right with defrecord,i've changed my code to use extend,a little closer to scala -but not the same-. However i think it would be idiomatic clojure too,<br />i agree with the main point: clojure shines more in one facet (abstracting syntactically) and scala in the other (abstracting semantically).Anonymoushttps://www.blogger.com/profile/03081252416288495482noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-33741038906045512152010-09-28T00:28:10.261+05:302010-09-28T00:28:10.261+05:30Hi Javier -
You Clojure implementation almost mim...Hi Javier -<br /><br />You Clojure implementation almost mimics the Scala one. However when u define a defrecord for Trade along with a composition of TradeTax and Commission protocols, you have hardwired them as part of Trade. Note that u cannot have any other type of tax-fees as part of Trade abstraction. This was not the case with the Scala implementation where we used a mixin based approach that gives me the flexibility to compose abstractions while creating the object.<br /><br />In my Clojure implementation also it was dynamic - not the with-values function and how the thrush threads the subject with all the decorators during runtime.<br /><br />In fact this is one the underlying thoughts of the post. We should not try to mimic an implementation in one language into another. We should use what's idiomatic in every language.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-42266005614560793832010-09-28T00:08:56.498+05:302010-09-28T00:08:56.498+05:30definitely i think i have catched the main point (...definitely i think i have catched the main point (describe two ways of thinking encouraged for the two langs)<br />The compojure redefine in "read time" and the macro sintactic way to abstract decoration is nice but i agree with Sergio Bossa that maybe for domain modelling the semantic way fits better.<br />For curiosity i have tried to mimic your scala impl in clojure, although my knowledge of scala is very basic (clojure one is no too advanced :-P )<br />http://gist.github.com/599553Anonymoushttps://www.blogger.com/profile/03081252416288495482noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-622376296956181942010-09-28T00:05:45.577+05:302010-09-28T00:05:45.577+05:30definitely i think i have catched the main point (...definitely i think i have catched the main point (describe two ways of thinking encouraged for the two langs)<br />The compojure redefine in "read time" and the macro sintactic way to abstract decoration is nice but i agree with Sergio Bossa that maybe for domain modelling the semantic way fits better.<br />For curiosity i have tried to mimic your scala impl in clojure, although my knowledge of scala is very basic (but clojure one is not too advanced :-P )<br />http://gist.github.com/599553Anonymoushttps://www.blogger.com/profile/03081252416288495482noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-64222785121299071312010-09-27T23:25:47.227+05:302010-09-27T23:25:47.227+05:30Hi Sergio -
Thanks for visiting my blog.
The mai...Hi Sergio -<br /><br />Thanks for visiting my blog.<br /><br />The main focus of this post is to demonstrate how implementing even the same architectural pattern like *behavior extension* makes you think differently in two languages espousing two different paradigms.<br /><br />I have modeled the Trade abstraction as a Map. I mentioned this in the article that I could have modeled it as a Clojure protocol also. In that case I would have a defrecord implementing the protocol. But ultimately a defrecord provides an implementation of a persistent map only and offers the same keyword accessors for fields. The final composition of the functions would have been the same and there would not have been any change in the thrush based decorator implementation. Hence I thought to keep the implementation simpler with a bare bone Map as the Trade abstraction. <br /><br />And the macro was just for spicing up a nice DSL that abstracts the thrush application.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-17326757853131298482010-09-27T22:16:06.907+05:302010-09-27T22:16:06.907+05:30Why didn't you use clojure protocols rather th...Why didn't you use clojure protocols rather than macros? <br />I think the former is better suited for domain modeling, while the latter is better suited for higher-level composition, such as expressing a whole use case logic (and using clojure protocols/records under the hood). Think at it like "domain layer" vs "service layer" :)<br /><br />Cheers,<br /><br />Sergio B.Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-87198066304109711282010-09-27T17:14:09.322+05:302010-09-27T17:14:09.322+05:30i'm interested in how you learned those langua...i'm interested in how you learned those languages if you don't mind. you provided a comparison in two languages and i'm curious how did you go about learning these:<br /><br />1) how long did it take you ?<br />2) what is your level of expertise ?<br />3) did you walk this path alone ?<br /><br />4) did some one help with the code for this article ?<br /><br />thanks,<br />alexBelunhttps://www.blogger.com/profile/13466388943244709429noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-69829481428320913852010-09-27T15:54:04.328+05:302010-09-27T15:54:04.328+05:30Hi Javier -
As I mentioned in the post, the Scala...Hi Javier -<br /><br />As I mentioned in the post, the Scala approach is to focus towards composition of classes/objects. While the Clojure approach is to compose functions. Irrespective of how you model the underlying trade (Map, Record, struct-map etc.), I think the idiomatic way to decorate an abstraction is to use the Thrush (the -> macro) to thread through the subject function and the decorators. In fact I mentioned it in the post as well that we could have modeled the underlying trade structure using defrecord. And yet implement the dynamic addition of behaviors through function composition.<br /><br />Thanks.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-56551529976030069052010-09-27T15:47:45.968+05:302010-09-27T15:47:45.968+05:30Have you considered use clojure features like stru...Have you considered use clojure features like structs, records (with protocols or not) to implement in clojure somewhat more similar to scala approx?<br />i guess you have chosen the diff approx in clojure for the purpose of demonstrating the point but imo a impl closer to scala is possible in idiomatic clojureAnonymoushttps://www.blogger.com/profile/03081252416288495482noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-50429777160089832010-09-27T15:25:10.619+05:302010-09-27T15:25:10.619+05:30Hi Stephan -
Thanks for visiting.
Type classes a...Hi Stephan -<br /><br />Thanks for visiting.<br /><br />Type classes are definitely a way to handle variabilities in your abstraction. In the current example, it makes sense to use type classes if we are going to have a number of variations in computing tradeTax or commission. However, the moot point of the current post is to demonstrate that in languages like Scala that offer the hybrid approach of OO and functional programming, we use OO for modeling coarse grained abstractions and use functional approach for modeling fine grained behaviors and control flow. Hence I thought simple higher order functions can also make this point clear. Implementing type classes would have made the post longer and possibly could have shifted the focus of discussion as well. And I have discussed enough of type classes in my blog :)<br /><br />Thanks.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-43902697120389526832010-09-27T15:16:25.226+05:302010-09-27T15:16:25.226+05:30My problem with this:
lazy val tradeTax = t.trade...My problem with this:<br /><br />lazy val tradeTax = t.tradeTax { p => p * 0.05 }<br />lazy val commission = t.commission { (p, q) => if (q > 100) p * 0.05 else p * 0.07 }<br /><br />is reusability and maintanence. I have the feeling this will lead to many undocumented, nameless functions scattered around the code base - or you need a lot of discipline. I'd prefer your approach with type classes for this. Type classes have names, can easily be reused etc.<br /><br />Best<br />Stephan<br />http://codemonkeyism.comStephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.com