This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-12-01
Channels
- # adventofcode (11)
- # aws (8)
- # beginners (70)
- # boot (2)
- # cider (9)
- # cljs-dev (29)
- # cljsrn (2)
- # clojure (67)
- # clojure-android (2)
- # clojure-dusseldorf (5)
- # clojure-greece (12)
- # clojure-italy (4)
- # clojure-nl (3)
- # clojure-poland (3)
- # clojure-russia (5)
- # clojure-spec (80)
- # clojure-uk (9)
- # clojurescript (73)
- # core-async (17)
- # cursive (1)
- # data-science (5)
- # datomic (29)
- # emacs (5)
- # fulcro (257)
- # graphql (2)
- # hoplon (2)
- # jobs (2)
- # klipse (3)
- # leiningen (9)
- # lumo (4)
- # nyc (1)
- # off-topic (48)
- # om (7)
- # other-languages (11)
- # pedestal (4)
- # re-frame (18)
- # remote-jobs (1)
- # rum (10)
- # shadow-cljs (5)
- # spacemacs (20)
- # sql (5)
- # test-check (44)
- # unrepl (8)
- # yada (9)
What did Rich Hickey mean with “types are parochial”? What does parochial mean in that context? I’m not a native speaker, but even looking it up in a dictionary doesn’t fully explain it to me.
What I think he means: types force you to choose a name for a combination of attributes and attributes from different types don’t merge
Pragmatic “app” monad in Haskell :thinking_face:
newtype AppM a = AppM (LoggingT (ReaderT Context (ExceptT AppError IO)) a)
deriving ( Functor, Applicative, Monad, MonadIO
, MonadError AppError, MonadReader Context, MonadLogger)
https://savanni.luminescent-dreams.com/page/haskell-app-monad@borkdude that's my interpretation as well.
or as Brandon put it recently: https://twitter.com/BrandonBloom/status/935570873699909633
but I recognize the feeling of “this would never be a problem in Clojure” when working with typed languages 😉
@borkdude Not sure if it helps but Rich means "parochial" in terms of "narrow scope or outlook" and I took it to mean that types are usually very focused and restrictive, so code is less reusable across domains -- compared to dynamically typed code that can operate on many different concrete types.
Specifically, when you define a class type to represent a data structure, you end up with a set of operations on that class type -- that cannot be used on similar data structures that have a different type. Whereas we have operations on "collections" and "sequences" because we use data instead of specific types of data.
I'd never thought of types that way until I heard Rich say it -- it was sort of a light bulb moment for me (which his talks often are).