Re: Protocols considered harmful?

2018-05-22 Thread Piyush Katariya
https://www.braveclojure.com/multimethods-records-protocols/

https://stackoverflow.com/questions/8070368/clojure-multimethods-vs-protocols

-- 
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.


Re: Protocols considered harmful?

2018-05-22 Thread Piyush Katariya
This article also explains it nicely.

https://8thlight.com/blog/myles-megyesi/2012/04/26/polymorphism-in-clojure.html 

-- 
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.


Re: Protocols considered harmful?

2018-05-22 Thread Mark Engelberg
There are two schools of thought:
1. Multimethods are the most versatile and work better at the REPL.  Use
protocols only where necessary for performance (and doing so early is
premature optimization).
2. Protocols are the most performant and handle the most common
polymorphism need - single dispatch based on type.  So use protocols unless
you are doing something that can't be done with protocols.

I tend to agree with your coworkers and fall into camp 1, but we are
probably a minority.  Either philosophy is ok if you're working on your
own, but at work you probably need to standardize on whatever the more
experienced coworkers prefer.

On Mon, May 21, 2018 at 10:25 PM, Sam Bartolucci 
wrote:

> Hi,
>
> I've been an enthusiastic Clojure tinkerer for a few years now--it's a
> great language!--but only recently began using it professionally, where
> I've stumbled into a strong disagreement over the use of protocols vs.
> multimethods for single dispatch polymorphism. I had always assumed that
> protocols were a normal part of Clojure when polymorphism was called for,
> but a few of my coworkers (often, it seems, those who have experience with
> Lisp prior to Clojure) swear up and down that protocols are only to be used
> as a last resort because they "break the REPL". Apparently they're frowned
> upon because, due to the JVM interop, they don't reload as well as other
> constructs. It has even been suggested a few times that all uses of
> protocols should be refactored to use a multimethod with a "type" as the
> dispatch function. Protocols, in other words, should be considered harmful.
> This seems strange to me considering how many successful and mainstream
> Clojure projects use protocols, but maybe I am missing something, so I
> thought I would ask the list. So what is it? Is there any consensus around
> the assertion that "good, idiomatic Clojure will use multimethods rather
> than protocols for single-dispatch polymorphism"?
>
> Thanks,
> Sam
>
> --
> 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.


Re: Protocols considered harmful?

2018-05-22 Thread Erik Assum
As Mark Engelberg writes, if you work in a team, you need to figure this out 
with the team.

One point to add to the discussion is that if you find yourself implementing 
“several” multi methods per type, it might be worth creating
a protocol, just to make it easier for the consumer to understand the coupling:

Instead of 

(defmulti foo :type)

(defmulti bar :type)

you could consider 

(defprotocol MyProto
  (foo [thing …])
  (bar [thing …]))

if both foo and bar need to be implemented for stuff to work. But then you need 
to start using defrecord instead of plain old maps, which may or may not be a 
benefit.

Erik.

> On 22 May 2018, at 07:25, Sam Bartolucci  wrote:
> 
> Hi,
> 
> I've been an enthusiastic Clojure tinkerer for a few years now--it's a great 
> language!--but only recently began using it professionally, where I've 
> stumbled into a strong disagreement over the use of protocols vs. 
> multimethods for single dispatch polymorphism. I had always assumed that 
> protocols were a normal part of Clojure when polymorphism was called for, but 
> a few of my coworkers (often, it seems, those who have experience with Lisp 
> prior to Clojure) swear up and down that protocols are only to be used as a 
> last resort because they "break the REPL". Apparently they're frowned upon 
> because, due to the JVM interop, they don't reload as well as other 
> constructs. It has even been suggested a few times that all uses of protocols 
> should be refactored to use a multimethod with a "type" as the dispatch 
> function. Protocols, in other words, should be considered harmful. This seems 
> strange to me considering how many successful and mainstream Clojure projects 
> use protocols, but maybe I am missing something, so I thought I would ask the 
> list. So what is it? Is there any consensus around the assertion that "good, 
> idiomatic Clojure will use multimethods rather than protocols for 
> single-dispatch polymorphism"?
> 
> Thanks,
> Sam
> 
> -- 
> 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.


Re: Protocols considered harmful?

2018-05-22 Thread Shantanu Kumar
Hi Sam,

In my experience, protocols are a great mechanism for extensibility. Let's 
say you build an abstraction with a default implementation. If your 
abstraction is based on protocols, somebody can extend the abstraction to 
build a different implementation (that possibly integrates with another 
system). I think the sweet spot of protocols lies in (1) protocols being an 
implementation detail rather than public API, (2) protocols being used for 
extensibility.


Shantanu

On Tuesday, 22 May 2018 11:19:35 UTC+5:30, Sam Bartolucci wrote:
>
> Hi,
>
> I've been an enthusiastic Clojure tinkerer for a few years now--it's a 
> great language!--but only recently began using it professionally, where 
> I've stumbled into a strong disagreement over the use of protocols vs. 
> multimethods for single dispatch polymorphism. I had always assumed that 
> protocols were a normal part of Clojure when polymorphism was called for, 
> but a few of my coworkers (often, it seems, those who have experience with 
> Lisp prior to Clojure) swear up and down that protocols are only to be used 
> as a last resort because they "break the REPL". Apparently they're frowned 
> upon because, due to the JVM interop, they don't reload as well as other 
> constructs. It has even been suggested a few times that all uses of 
> protocols should be refactored to use a multimethod with a "type" as the 
> dispatch function. Protocols, in other words, should be considered harmful. 
> This seems strange to me considering how many successful and mainstream 
> Clojure projects use protocols, but maybe I am missing something, so I 
> thought I would ask the list. So what is it? Is there any consensus around 
> the assertion that "good, idiomatic Clojure will use multimethods rather 
> than protocols for single-dispatch polymorphism"?
>
> Thanks,
> Sam
>

-- 
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.


Re: New idea & POC for a Kubernetes/Clojure interface

2018-05-22 Thread Punit Naik
Is there any documentation around spinning up K8s cluster on Amazon EC2 
instances?

On Tuesday, November 7, 2017 at 8:34:35 AM UTC+5:30, Blake Miller wrote:
>
> Here's a little something I cooked up this weekend, to interact with a 
> Kubernetes cluster from Clojure:
>
> https://github.com/blak3mill3r/keenest-rube
>
> It abstracts away the K8s API calls completely. Instead, you get the state 
> of the cluster as a value in an atom. Changes to the state of the cluster 
> are streamed to the Clojure client, which keeps the value in the atom 
> current, and attempts to mutate the atom will cause one cluster resource 
> (one at a time) to be modified/created/destroyed appropriately. So far I'm 
> finding it to be a real pleasure to use compared to `kubectl` (giving it 
> hand-edited json or yaml files) or worse: the Dashboard (poking around at a 
> web app with a mouse).
>
> I guess I could've just tried the Python library, but where's the fun in 
> that?
>
> I feel like this could turn into a pretty powerful tool for ops work, or 
> even adding abstractions to manage resources automatically. I've been 
> wanting to use Clojure (more) for infrastructure-automation/dev-ops ... but 
> this is one area where the tooling available is a bit lacking, IMO.
>
> I've been successfully toying around with this project and a real 
> Kubernetes cluster in an AWS VPC.
>
> I'd be glad to get hear any thoughts on this idea. If you're into k8s, 
> please give it a whirl.
>
> This is total toy-status right now, by the way, it's just a 
> proof-of-concept. Oh, and it mixes nicely with `cider-enlighten-mode`, if 
> you're into that sort of thing. I went ahead and published it to Clojars.
>

-- 
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.


Re: New idea & POC for a Kubernetes/Clojure interface

2018-05-22 Thread Blake Miller
Yes, kops has a tutorial that walks you through it:

https://github.com/kubernetes/kops/blob/master/docs/aws.md

You just need an AWS account to start.

HTH

On Tue, May 22, 2018 at 1:20 PM, Punit Naik  wrote:

> Is there any documentation around spinning up K8s cluster on Amazon EC2
> instances?
>
>
> On Tuesday, November 7, 2017 at 8:34:35 AM UTC+5:30, Blake Miller wrote:
>>
>> Here's a little something I cooked up this weekend, to interact with a
>> Kubernetes cluster from Clojure:
>>
>> https://github.com/blak3mill3r/keenest-rube
>>
>> It abstracts away the K8s API calls completely. Instead, you get the
>> state of the cluster as a value in an atom. Changes to the state of the
>> cluster are streamed to the Clojure client, which keeps the value in the
>> atom current, and attempts to mutate the atom will cause one cluster
>> resource (one at a time) to be modified/created/destroyed appropriately. So
>> far I'm finding it to be a real pleasure to use compared to `kubectl`
>> (giving it hand-edited json or yaml files) or worse: the Dashboard (poking
>> around at a web app with a mouse).
>>
>> I guess I could've just tried the Python library, but where's the fun in
>> that?
>>
>> I feel like this could turn into a pretty powerful tool for ops work, or
>> even adding abstractions to manage resources automatically. I've been
>> wanting to use Clojure (more) for infrastructure-automation/dev-ops ...
>> but this is one area where the tooling available is a bit lacking, IMO.
>>
>> I've been successfully toying around with this project and a real
>> Kubernetes cluster in an AWS VPC.
>>
>> I'd be glad to get hear any thoughts on this idea. If you're into k8s,
>> please give it a whirl.
>>
>> This is total toy-status right now, by the way, it's just a
>> proof-of-concept. Oh, and it mixes nicely with `cider-enlighten-mode`, if
>> you're into that sort of thing. I went ahead and published it to Clojars.
>>
> --
> 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/GqZ04diilkM/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.