This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-19
Channels
- # aws-lambda (1)
- # bangalore-clj (4)
- # beginners (66)
- # boot (13)
- # cider (9)
- # cljs-dev (44)
- # cljsjs (3)
- # clojure (181)
- # clojure-austin (2)
- # clojure-greece (6)
- # clojure-italy (2)
- # clojure-russia (64)
- # clojure-sg (1)
- # clojure-spec (68)
- # clojure-uk (60)
- # clojurescript (66)
- # conf-proposals (12)
- # cryogen (1)
- # cursive (3)
- # datomic (44)
- # graphql (1)
- # hoplon (2)
- # jobs (2)
- # jobs-discuss (3)
- # keechma (2)
- # liberator (6)
- # luminus (2)
- # nyc (1)
- # off-topic (92)
- # om (10)
- # onyx (17)
- # parinfer (39)
- # pedestal (8)
- # proton (11)
- # re-frame (110)
- # reagent (2)
- # remote-jobs (11)
- # ring-swagger (9)
- # rum (2)
- # sql (2)
- # test-check (6)
- # untangled (138)
@gfredericks thanks, I guess thats the difference between runtime specs for cljs
@flyboarder the same applies to clj-jvm
makes sense
@alexmiller @seancorfield what's wrong with encapsulation, from the colujarians' world view? đ
Anyway I am very happy about spec, it is really a "missing piece" for robust programs that teams can collaborate on
@matan in OO (particularly thinking of Java / C++ here), encapsulation is used to hide or protect the data inside an object and access it via methods. Because this data is mutable, the accessor/mutator methods are also a place where you can apply a locking strategy to protect that mutable data in multi-threaded usage.
Clojure turns this inside out and says, data is actually the most important thing here - make it visible, introspectable, and directly manipulable via a generic data interface, rather than via a custom set of API methods that is different for every class.
alexmiller: #off-topic an alternative perspective, just for fun: "immutable datum" is just another way of saying "pure function". we could discard the notion of "data" altogether.
Immutable data structures allow you to do this while also being automatically thread-safe and avoiding the need for locking around access and manipulation of mutable data completely.
even more than thread-safety, you get independence of usage -- you can pass the same object to different pieces of code and not worry about what things they will each "change" that might affect the other which may or may not be what alex's last sentence meant
gfredericks: sorry for being late to return to the party đ I am not sure why I would not worry about different pieces collaborating on the raw data. Or how this is different than the claim of concurrency/thread-safety.
they're not collaborating, they're doing completely independent things
@alexmiller to make data explicit and visible is undoubtedly a good thing, but there is definitely situations where encapsulation is valuable https://github.com/clojure/clojure/blob/clojure-1.9.0-alpha14/src/clj/clojure/core.clj#L4939
Go blocks are about process, not data. Channels are about conveyance of values, not encapsulation
Agreed, but I didn't say that
Most encapsulation in OO is incidental, not useful
this is not quite the same topic but it just occurred to me that one of my biggest frustrations with legacy OO codebases that I haven't heard articulated before is that the classes I encounter have unclear lifecycles
the thing I want to understand about a class to help me understand the whole codebase is how/why the objects get instantiated, what you do with them while they're alive, how they get discarded, how that relates to the lifecycle of the program as a whole; and I've never seen an OO codebase where that's remotely clear
perhaps there's a similar question about how functions are used in a functional codebase, but it seems like less crucial of a question for some reason
âlifecycleâ implies some degree of statefulness to me. mutable state requires coordination. all of that is often a mess in OO.
although Iâd say that aspect is a distant second problem for me after the notion of not having a generic data interface and/or clear equality semantics in OO
alexmiller: that is an interesting thought. I am wondering, is there a consensus about âthis is not generic enoughâ. Currently I am working on a program were I need to squeeze every inch of performance that I can get so I ended up defining some custom interfaces to access the data. Nevertheless this puts the clear equality semantics
and generic data interface
a bit to the limit since the interface is no longer Clojure-like but rather case-specific.
Btw I used some of the current benchmarks as inspiration đ https://github.com/jafingerhut/clojure-benchmarks/blob/master/binarytrees/binarytrees.clojure-rh.clojure#L18
I have no problem with breaking every rule in the book in very narrow areas where you are seeking the ultimate performance :) hopefully that is about 0.1% of the code
Well that depends on how you define 0.1% of the code. The loc that use those custom interfaces are very short but the ones that consume it are probably very long and very different. Which is what got me thinking. I think it is a similar situation to what Clojure does i.e defining algorithms and interfaces in java yet using them in Clojure.
the "no generic data interface" complaint also applies to type-oriented functional programming (haskell etc.), right?
I havenât done enough of it to say
that feels like the biggest difference to me between clojure and most of the rest of FP, even more than static vs dynamic type system
though I'm sure the static vs dynamic dimension is highly correlated with generic vs typey
yeah not having equality, robust hashing and string representations built into your data structures is terrible
I had a giant dump of ruby data the other day and would have appreciated being able to read it into a repl and analyze it, but I just had to decide to not want to do that
so much #<...>
one of my complaints with clojure is actually that the default string representation isnât EDN â this decision confuses me. e.g.
(println {:foo "bar"})
{:foo bar}
=> nil
i guess not all clojure data can be represented as EDN because of nested Java objects, but why not quote âfooâ above?
because then (println "foo")
would be surprising
you'd need some other mechanism for printing a raw string
that would bother me even more
but that might be a personality thing; some people like things that are less complicated to describe, others like things that are more likely to do what you wanted
ironically, now that I think about it, I feel like gripes about clojure are pretty evenly split between people wanting the former and getting the latter, and vice versa
I suppose there are also gripes about situations where neither ideal is achieved
@alexmiller: Is there a place on the http://clojure.org site that would make sense for compiling links to blog posts, videos, and other external resources related to spec? There's a bunch of good ones on the Cognitect blog and elsewhere that I wouldn't know how to find if I were looking at it for the first time.
Depends what they are
The community/resources page is one place but may not be best for everything
The docs actually say: > By default, pr and prn print in a way that objects can be read by the reader
@shaun-mahood give me examples and I can help find answers
@alexmiller: Here's the list just gleaned from the Cognitect blog http://blog.cognitect.com/blog/2017/3/24/3xeif9bxaom78qyzwssgwz1leuorh4 http://blog.cognitect.com/blog/2017/1/3/spec-destructuring http://blog.cognitect.com/blog/2016/12/9/works-on-my-machine-self-healing-code-with-clojurespec-1 http://blog.cognitect.com/blog/2016/10/5/interactive-development-with-clojurespec http://blog.cognitect.com/blog/2016/9/29/agility-robustness-clojure-spec http://blog.cognitect.com/blog/2016/9/14/focus-on-spec-combining-specs-with-sor http://blog.cognitect.com/blog/2016/8/24/combining-specs-with-and http://swannodette.github.io/2016/06/03/tools-for-thought A bunch from searching Medium https://product.gomore.com/end-to-end-integration-tests-with-clojure-spec-d4a48cbf92b5 https://medium.com/@rplevy/temporal-higher-order-contracts-with-clojure-spec-e92e795665d https://medium.com/degree9/data-validation-schema-spec-5547e33596bd There are a bunch of conference videos as well, plus the spec screencasts on ClojureTV One other thing that I haven't seen anywhere are the notes from your spec workshop, though I don't know if that's meant to be publicly available. If having any of this stuff (or type of stuff) is desirable, I'm happy to work on a PR for it. I know I've seen other interesting and exciting stuff on Spec elsewhere too.
I just noticed your previous reply - the main motivation for my question was realizing that if I only look at http://clojure.org as it stands right now, none of the really interesting or exciting use cases jump out at me. Might not be a goal though, so I didn't want to put any work into a PR without figuring out what kind of thing might be useful for others.
@shaun-mahood broadly, I think itâs hard to give a list of blog entries the right context to be useful and survive well over time. It just doesnât make sense to try to track every spec blog (most of which are now out of date). Whatâs useful on the site is curated reference or tutorial content that is kept up to date. So I guess largely, I would say these should not be added to http://clojure.org. One thing that I have been (very slowly) working on is a reference page for spec which I think is a good complement in between the rationale, the guide, and the api docs.
and the spec workshop notes are not intended to be public - they are training materials copyright Cognitect and represent probably 100 hours of work over the last year.
That sounds reasonable to me. I love the idea of a reference page - I'm still trying to come to grips with the boundaries of the new clojure and clojurescript site.
I hope the workshop notes at least made the book easier to write.
It was definitely worthwhile to take at last years Conj, I would consider taking it again to pick up the new stuff and the bits I missed.