No, the content is all of William’s background, the lessons he has learned, the values he puts on various concepts, the needs he has etc.. For him, that code is ‘better’ because it addresses his needs. For others, with different needs, it might not be. And that is the point and why I injected my opinion, that talking in absolute terms isn’t entirely helpful.
William stated: "Justifying things is generally impossible.” which I thought was an interesting point given that is at the heart of this and many other discussions which take the form “I think this is better” and somebody else says “justify it” :-). I think it is possible if we share the rationale and context we are using to value these things. I certainly didn’t mean to detract from the conversation, rather I wanted to keep it flowing as I think it is a good thread, but I could see it stalling, hence my injection. > On 24 Nov 2015, at 09:42, Atamert Ölçgen <mu...@muhuk.com> wrote: > > > 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 > <mailto: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 >> <mailto: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 >>> <mailto:mu...@muhuk.com>> wrote: >>> >>> Hi William, >>> >>> How is this different than Yo-yo? >>> (https://groups.google.com/forum/#!topic/clojure/PvCc5sSeSRY >>> <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 >>> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>> <mailto:clojure%2bunsubscr...@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> <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 >>> <mailto:clojure+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <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 >>> <mailto: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 >>> <mailto:clojure%2bunsubscr...@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> <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 >>> <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 >>> <mailto:clojure+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <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 >>> <mailto: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 >>> <mailto:clojure%2bunsubscr...@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> <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 >>> <mailto:clojure+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <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 >>> <mailto: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 >>> <mailto:clojure%2bunsubscr...@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> <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 >>> <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 >>> <mailto:clojure+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <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 >>> <mailto: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 >>> <mailto:clojure%2bunsubscr...@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> <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 >>> <mailto:clojure+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <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 >>> <mailto: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 >>> <mailto:clojure%2bunsubscr...@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> <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 >>> <mailto:clojure+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >>> >>> >>> >>> -- >>> Kind Regards, >>> Atamert Ölçgen >>> >>> ◻◼◻ >>> ◻◻◼ >>> ◼◼◼ >>> >>> www.muhuk.com <http://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 >>> <mailto: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 >>> <mailto:clojure+unsubscr...@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> <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 >>> <mailto:clojure+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <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 >> <mailto: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 >> <mailto:clojure%2bunsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> <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 >> <mailto:clojure+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> ◻◼◻ >> ◻◻◼ >> ◼◼◼ >> >> www.muhuk.com <http://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 >> <mailto: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 >> <mailto:clojure+unsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> <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 >> <mailto:clojure+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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 > <mailto: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 > <mailto:clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > <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 > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > > -- > Kind Regards, > Atamert Ölçgen > > ◻◼◻ > ◻◻◼ > ◼◼◼ > > www.muhuk.com <http://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 > <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 > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
