This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (7)
- # babashka (105)
- # beginners (67)
- # braveandtrue (11)
- # cider (8)
- # clojure (62)
- # clojure-conj (4)
- # clojure-poland (1)
- # clojure-spec (9)
- # clojure-uk (8)
- # clojurescript (49)
- # core-typed (11)
- # cursive (4)
- # emacs (1)
- # fulcro (1)
- # graalvm (24)
- # hoplon (10)
- # hyperfiddle (1)
- # off-topic (32)
- # re-frame (7)
- # reitit (1)
- # sql (1)
interesting read https://clojureverse.org/t/worried-about-types-clojure-elitism/616/20 nice to see your @borkdude thoughts there as well 🙂
@denisgrebennicov I think developers are either "static typing" people or they aren't. I've been a commercial developer for over 30 years and I spent about a decade working with C/C++ which don't have much of a type system, then about a decade working with Java/Groovy/Scala which do, and now close to a decade working with Clojure. Along the way, I've done a lot of work on source code analysis systems (starting with a type inference engine written in Prolog back in my PhD days). With all that experience, I can honestly say I'm not in the "static typing" camp these days.
@seancorfield interesting theory. I need to think about that for a while What about optional typing like Typescript? Is it like best of both worlds?
clojure.spec -based solutions tend to be a nice middle ground. You get strong API contracts, but no monads, generics, or similar rabbit holes.
The same cannot be said of Typescript. Likewise many gradual/optional solutions (like Ruby Sorbet) are seemingly modelled after either Java or Haskell; that IMO is not particularly suitable for dynlangs (if I wanted Haskell I would choose Haskell in the first place)
IMO in practice you do get a type system: in form of documentation, errors, coercions, etc And it achieves some things generally impossible in a static system, so it's a decent tradeoff
@U45T93RA6 any video of practical clojure.spec you could recommend I have some questions, but wanna do my homework first 😅
I think I learned spec gradually (how fit! ;p) Many resources, many approaches. I think someone even got to make music with spec? https://github.com/nedap/speced.def which I authored might be an interesting read. Its api resembles typed languages, with similar benefits (uniquely: performance). When focusing on :pre/:post, normally the assumption is that you have a traditional testing pyramid to exercise those defns' assertions. Not everyone thinks like that, defending instead to go all generative.
@denisgrebennicov "Is [optional/gradual typing] like best of both worlds?" -- Perhaps. But idiomatic Clojure is extremely hard to annotate with static-style typing in any reasonable manner. I spent quite a while looking at using
core.typed with parts of our code. I started with Prismatic's Schema (run time checking), then switched to
core.typed (static checking), then Schema again, then
core.typed again. And then I gave up --
core.typed was too hard to use and I found myself refactoring code purely to satisfy the type checker, and it ended up being less idiomatic, and harder to read; Schema didn't really add much benefit, for me, over my regular testing -- and it required good test coverage anyway to exercise the Schema checking at runtime (and I found Schema annotations just plain noisy in the code, making the code harder to read).
By contrast, Spec takes a rather different approach and can be used in many different ways, both in production code for data validation, and in testing for assertions on function arguments, function behavior (return values), data shapes... as well as generating example data and full-on generative testing.
I wrote about our usage of Spec a few months ago https://corfield.org/blog/2019/09/13/using-spec/
@seancorfield hmmm. Interesting experience. I will read your blog post. Thanks for the link 🙂
I'm trying to understand this quote by Alan Perlis: "Recursion is the root of computation since it trades description for time." Do you know what he meant by this?
don't know if it's helpful, but found this: https://cs.stackexchange.com/questions/91974/alan-perlis-epigram-on-recursion
https://beautifulracket.com/appendix/why-racket-why-lisp.html Some more praise for LISP, in case you haven't had enough. All thanks to the Alan Perlis quote above, which sent me down the rabbit hole, :man-shrugging:
I keep getting reminded of this http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
I'd heard of it but never really knew what it was. Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.