Hi Colin,

> in this industry there are hardly any unambiguous and objective statements

Either you contradict yourself or the following is ambiguous and/or
subjective:

> pragmatism throws it all out of the window

-----

> One man’s complexity is another man’s simplicity and so on.

Can you please give an example?

-----

Are you suggesting we don't discuss merits and shortcomings of different
approaches to design software?



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.

Reply via email to