This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-07
Channels
- # announcements (35)
- # beginners (80)
- # boot (1)
- # calva (4)
- # cider (33)
- # cljdoc (40)
- # clojars (3)
- # clojure (95)
- # clojure-berlin (2)
- # clojure-europe (4)
- # clojure-italy (28)
- # clojure-nl (2)
- # clojure-seattle (1)
- # clojure-serbia (1)
- # clojure-spec (74)
- # clojure-uk (71)
- # clojurescript (29)
- # core-async (1)
- # cursive (80)
- # data-science (4)
- # datomic (17)
- # duct (75)
- # emacs (4)
- # figwheel-main (5)
- # fulcro (3)
- # jackdaw (1)
- # java (1)
- # jobs-discuss (20)
- # off-topic (32)
- # parinfer (2)
- # pathom (23)
- # re-frame (26)
- # reagent (25)
- # rum (6)
- # shadow-cljs (122)
- # speculative (4)
- # sql (17)
- # testing (7)
- # yada (8)
the other day we were talking about Tim Baldridge's video that put forth an argument against Higher Order Functions. The gist is that multiple functions as arguments define an ad-hoc protocol. He prefers to name that set of functions as a protocol and pass something that implements them. Argues that it makes codebase much more tractable when initially reading and clarify what these functions are supposed to do. @borkdude i think we were talking about it recently
https://tbaldridge.pivotshare.com/media/design-thoughts-ep-3-why-not-to-use-hof/76801/feature
yes. And he has an excellent presentation style. Really enjoy the $4 that i spend there a month
Does that suggest ring middleware would be better off as a protocol then?
pedestal interceptors (which are kind of like middleware taken apart) are defined with protocols
Curious if this isn’t, in the general sense, saying that types makes sense for understandability? I haven’t really wrapped my head around the “no types” thing of thinking that all kinds of types are always only bad and that no one should ever know what is expected... so, curious about this take as well 🙂
What is great in Clojure is spec
, it allows you to say what the shape of your data is
I think types makes a lot of sense but in a typed languages it gives problems because they are so rigid. If you have a 'Employee' types in java, and it has a field 'E-mail' you run into problems when you don't know the e-mail always, and often at some point that is the case. Or you can have an 'Employer' which also has an 'E-mail' field, but without some tricks, you can't use the same method only needing the email both on the 'Employee' and the 'Employer'. And in my current java project there are often several type definitions for the same thing, making the whole puzzle much more complex then needed.
^ that depends a bit on the type system in place right, this sounds like something that a categorial type system is better at
(ala Haskell)
I think in this case protocols are probably most useful for exploiting the speed of Java's type system for dispatch. But they could just as easily be maps and the method names could just be keys into the map. And I personally would find that no less understandable.
If we're using compile time errors as our method of understanding, then sure types can help. But spec can provide that fail fast feedback, if desired.
And there's really no such thing as "no types." It's just whether you have to annotate the world with "Any" or if that annotation is implied.
And I don't think the ethic is "no one should ever know what is expected." It's moreso like, "no one can always know what is expected in all places, at all times, for all purposes."
So do you really want to have to annotate everything with "Any" everywhere, just so you can start exploring how functions behave for any given purpose?
It’s a fascinating discussion. I have seen at least a couple of Richs talks, and I have done a fair amount of JS, Python and... things. It’s still not clear to me what the one truth is. 😅
there are never any truths in programming
Don’t want to push everyone’s patience, but... one more thing; do you, in your day to day work, typically put type information anywhere at all? External documentation, docstrings, comments, anything?
Personally I tend to use clojure spec to document args/ret for most functions
Ie, is the “no types” thing a matter of degrees and the information is still useful at some point, or is type information by way or working actually never interesting.
Cool, haven’t started on spec but tried to digest some of the reasoning behind it. Looking forward to it.
not really... But sometimes I'll put extra type-like info in the fn name, like num->str
or what have you.
does slack always reply with pong when anyone says ping?
yep. odd