> Not in any way, only that we explain the context in which we consider the approach ‘better’.
The context is the code William initially shared with the list. I will not write a long response as I think this is getting off-topic for this list. You are very welcome ping me at my email if you would like to continue off-list. On Tue, Nov 24, 2015 at 11:21 AM, Colin Yates <colin.ya...@gmail.com> wrote: > Hi Atamert, good challenge. > > TLDR: every choice is about weighing the pros and the cons and I am > suggesting that the criteria we use is very very subjective and context > sensitive > > waffly comments inline. > > > in this industry there are hardly any unambiguous and objective > statements > > Either you contradict yourself or the following is ambiguous and/or > subjective: > > > Or both :-) I know! Isn’t this industry great :-) > > I was too broad with my original statement - let me try again. I am > suggesting that we are continually forced with making decisions/reasoning > about things with very few objective and quantifiable metrics or tools to > use to reason with. This leads to claims being made around something being > ‘better’ or ‘worse’ without any agreed definition of the domain being > discussed. Without any ubiquitous language if you will. Thus, many > discussions lead to multiple inputs all claiming “this is right, that is > wrong” but those choosing different things to be ‘right’ or ‘wrong’ about. > And they are all right, and they are all wrong. They are all right for the > person making the claim as these claims have to be context dependant > because there are very few ‘global truths’ in this industry. They are > (almost always) all wrong because they assert what is useful for them is > useful for everybody. > > Often what happens in these discussions is that somebody agrees with a > principle (complecting is bad) and then proposes an approach which for them > reduces it _for them_. Others, with different contexts and perspectives > agree with the principle but see the proposed approach as either not > reducing it or actually increasing it. At which point, until people are > clear what their values are, the conversation ends at best with a "well > chaps, let’s agree to disagree” or worse, people get offended. If people > didn’t make such wide-ranging assertions then the discussion would be more > fruitful. > > > pragmatism throws it all out of the window > > > because "this is all well and good but I need to get on with stuff". I > suggest that most of us continually live the dilemma of ‘do it now’/‘do it > later’. A variation of which is ‘do it now with the tools I know > about’/‘learn better tools and do it better, later’. > > Almost everything we (or at least I) do is a compromise of some sort > because where the real world meets the computer is a mess of ambiguity, > time pressure etc. So a programmer’s life is full of decisions which are > trade-offs between choosing A and B. Static typing/dynamic typing, > protocols/fns, which of the gazillion frameworks and libraries to use, > kanban or sprint, unit testing? and so on and so on. > > > ----- > > > One man’s complexity is another man’s simplicity and so on. > > Can you please give an example? > > > Sure: > - a big ball of mud is a single coherent domain model > - micro services are nicely encapsulated and can introduce exponentially > increasingly fragile deployment plans > - design patterns are great and cause enormous bloat to a lot of code > bases > - dependency injection frameworks enable components to be ignorant and > break encapsulation > - static typing adds a whole level of safety and type signatures are > bewildering > - abstractions allow me to describe something I couldn’t before and add > layer and layer of noise > - lots of little namespaces keep things manageable and make navigation > painful > - lots of large namespaces keep things management and make navigation > painful > - DSLs bring capability to the user and add complexity to the code base > - OO - what can I say here :-) > > The point, the only point I am making is that all of the above is true > depending on your view point because yes, complecting is bad, complexity is > bad, and what makes something complex for me is different to what makes it > complex to you. Where you see a number of things complected together I > might see an example of encapsulation. > > ----- > > Are you suggesting we don't discuss merits and shortcomings of different > approaches to design software? > > > Not in any way, only that we explain the context in which we consider the > approach ‘better’. I also wish we did discuss the merits and shortcomings, > too frequently we don’t, we only discuss the merits. > > The reason I posted initially is because I have wasted so many months > arguing details with other developers and having a black and white view of > things and it almost always turned out that we were agreeing with the > general principle but the application of that principle meant different > things in each of our different contexts. We were ‘violently agreeing’ :-). > > TLDR(2): there is no ‘better’ only ‘better in this context' > > I hope that clarified my view point. > > > > > On Tue, Nov 24, 2015 at 10:11 AM, Colin Yates <colin.ya...@gmail.com> > wrote: > >> I think this discussion has run into the age-old problem of ‘subjective >> interpretation’, namely, multiple people all agreeing with a principle >> (i.e. complexity sucks) but then having _different_ interpretations of >> where that principle is challenged/upheld. Unfortunately in this industry >> there are hardly any unambiguous and objective statements because most of >> what we do is more artistic than engineering (zips up the flame suit now). >> >> And, as ever, pragmatism throws it all out of the window :-) >> >> One man’s complexity is another man’s simplicity and so on. >> >> >> >> On 24 Nov 2015, at 06:34, Atamert Ölçgen <mu...@muhuk.com> wrote: >> >> Hi William, >> >> How is this different than Yo-yo? ( >> https://groups.google.com/forum/#!topic/clojure/PvCc5sSeSRY) >> >> > Justifying things is generally impossible. >> >> Actually, no. It is possible, at least when you are dealing with >> reasonable people. And when you make claims like "lightweight" or >> "ultralight", people will naturally ask "oh, interesting, how so?" >> >> ----- >> >> Some functional programming folks are allergic to exceptions. They go out >> of their ways to prevent any and all exceptions and they end up >> unnecessarily complicating their types for little or no gain. >> >> It seems to me, you are trying to avoid using protocols like it's a >> plague. >> >> > I am tired of doing ongoing refactorings interrupted periodically by >> complete rewrites. Class hierarchies are the worst... >> >> When your ultralight function based components get out of hand, you will >> have a worse time refactoring. With component you only have two functions, >> your lightweight design will end up having (* n 2) functions. >> >> Also, looking at a component's code (it's defrecord form I mean) I can >> see what other components it depends on. Your design would bury them inside >> functions making it harder to read. >> >> >> On Tue, Nov 24, 2015 at 6:57 AM, James Reeves <ja...@booleanknot.com> >> wrote: >> >>> Have you watched Simple Made Easy >>> <http://www.infoq.com/presentations/Simple-Made-Easy>? >>> >>> I mention it because you remark about being tired of refactoring. It's >>> my opinion that's a symptom of complexity, in the Hickey definition of the >>> term. >>> >>> - James >>> >>> On 24 November 2015 at 03:31, William la Forge <laforg...@gmail.com> >>> wrote: >>> >>>> James, >>>> >>>> Being fun is important but not a justification. We should strive to >>>> keep things fun, but there are plenty of thing worth doing and our >>>> resources are always limited. And if it is not fun, you are not going to do >>>> your best work. >>>> >>>> Justifying things is generally impossible. If vanilla clojure meets >>>> your needs, then vanilla clojure it is. If macros solve the problems you >>>> have been dealt in the past, then three cheers for macros. If unifying >>>> client and server addresses your needs, then Om Next may well be a major >>>> blessing for you. >>>> >>>> For me, the winner is avoiding static structures. I am tired of doing >>>> ongoing refactorings interrupted periodically by complete rewrites. Class >>>> hierarchies are the worst--being the largest, they are the least stable. I >>>> like small files that I can put to bed as finished. And self-defining >>>> aggregation. Because these meet my very real needs. I constantly >>>> reconceptualize what I am working on while bringing projects to completion. >>>> So having a programming style which keeps code relevant in the face of such >>>> an onslaught is very helpful and also a genuine delight. >>>> >>>> --b >>>> >>>> On Mon, Nov 23, 2015 at 10:08 PM, James Reeves <ja...@booleanknot.com> >>>> wrote: >>>> >>>>> I feel you might be barking up the wrong tree with this approach, as >>>>> it seems to complicate things without providing any compelling advantages. >>>>> >>>>> That said, if it's fun then by all means continue to experiment. Maybe >>>>> I'm wrong :) >>>>> >>>>> - James >>>>> >>>>> On 24 November 2015 at 02:45, William la Forge <laforg...@gmail.com> >>>>> wrote: >>>>> >>>>>> I think you have read too deeply into my thoughts on reserving the >>>>>> first argument of a function. I haven't actually written any polymorphic >>>>>> functions relating to this. >>>>>> >>>>>> Really, the take off point for me is being able to operate on an >>>>>> object by implementing it as a map of functions and data. That is to say, >>>>>> making objects data. Implementing multiple inheritance becomes trivial >>>>>> and >>>>>> without having to define any classes or any interfaces. And with full >>>>>> support for circular references without needing to do declares. >>>>>> >>>>>> What I like about it is that I get separation of concerns and maximal >>>>>> reuse without, I suspect, the usual usage coupling. The small maps which >>>>>> define traits can even participate in the lifecycle of the aggregate, so >>>>>> they start taking on the characteristics of components. >>>>>> >>>>>> My biggest problem with writing code over the decades has been the >>>>>> constant desire to do rewrites--which are costly and devastating in their >>>>>> impact. That is *why *I am fascinated with this approach. >>>>>> >>>>>> A second *why *is that when I have clear separation of concerns and >>>>>> the pieces of code can be easily tested independently, documentation >>>>>> becomes clearer and more fun to write. And keeping code fun is a critical >>>>>> driver for open source. >>>>>> >>>>>> On Mon, Nov 23, 2015 at 9:24 PM, Timothy Baldridge < >>>>>> tbaldri...@gmail.com> wrote: >>>>>> >>>>>>> So I feel compelled at this point to ask..."why?". The whole point >>>>>>> of functional programming in Clojure is to de-couple state from data. >>>>>>> When >>>>>>> you need polymorphic dispatch on the contents of a map, you have access >>>>>>> to >>>>>>> multi methods. Sure this is a fun thought experiment, but I don't >>>>>>> understand the design goals. It's a fairly verbose way to write more >>>>>>> complex code to accomplish what we already have good tools for >>>>>>> (protocols/multimethods, etc). Maybe I'm missing something. >>>>>>> >>>>>>> Timothy >>>>>>> >>>>>>> On Mon, Nov 23, 2015 at 7:15 PM, William la Forge < >>>>>>> laforg...@gmail.com> wrote: >>>>>>> >>>>>>>> James, when I used the term mixin I was referring to a map that >>>>>>>> acts like a trait that gets merged into a larger map. You would define >>>>>>>> several such smaller maps that can then be used in various >>>>>>>> combinations to >>>>>>>> compose "objects". The identity of the composite object (this) is the >>>>>>>> map >>>>>>>> which holds the merged contents of the smaller maps. I.E. The entries >>>>>>>> in >>>>>>>> the smaller maps get copied into the larger map. >>>>>>>> >>>>>>>> When executing functions held by a map, the last parameter is >>>>>>>> always the map itself, i.e. the "this". On the other hand, when placing >>>>>>>> closures into the map, the self reference is no longer needed as it is >>>>>>>> implicit in the closure. But this means that a closure can only >>>>>>>> reference >>>>>>>> the contents of the map when the closure was created, while a function >>>>>>>> can >>>>>>>> reference any of the contents of the map passed as its last argument. >>>>>>>> >>>>>>>> Why did I make the map reference the last argument for functions >>>>>>>> held by the map? So that we can do type polymorphism on the first >>>>>>>> argument >>>>>>>> passed to the function. But we should make an exception to this. To >>>>>>>> facilitate threading, functions which return an updated map should take >>>>>>>> that map as the first argument. But that is an API change and needs to >>>>>>>> wait >>>>>>>> for release 0.6.0. >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Clojure" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to clojure+unsubscr...@googlegroups.com. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> “One of the main causes of the fall of the Roman Empire was >>>>>>> that–lacking zero–they had no way to indicate successful termination of >>>>>>> their C programs.” >>>>>>> (Robert Firth) >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> --- >>>>>>> You received this message because you are subscribed to a topic in >>>>>>> the Google Groups "Clojure" group. >>>>>>> To unsubscribe from this topic, visit >>>>>>> https://groups.google.com/d/topic/clojure/7Q7QvlSUGL4/unsubscribe. >>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>> clojure+unsubscr...@googlegroups.com. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Clojure" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to clojure+unsubscr...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> --- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "Clojure" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/clojure/7Q7QvlSUGL4/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> clojure+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> -- >>>> 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 >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to clojure+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> -- >>> 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 >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> ◻◼◻ >> ◻◻◼ >> ◼◼◼ >> >> www.muhuk.com >> >> -- >> 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 >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> 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 >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Kind Regards, > Atamert Ölçgen > > ◻◼◻ > ◻◻◼ > ◼◼◼ > > www.muhuk.com > > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
