Fork me on GitHub
#off-topic
<
2019-12-29
>
Denis G00:12:57

interesting read https://clojureverse.org/t/worried-about-types-clojure-elitism/616/20 nice to see your @borkdude thoughts there as well 🙂

seancorfield00:12:42

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

Denis G00:12:41

@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?

vemv00:12:37

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)

Denis G00:12:38

doesn’t clojure.spec provide runtime checks only?

vemv00:12:53

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

Denis G00:12:09

@U45T93RA6 any video of practical clojure.spec you could recommend I have some questions, but wanna do my homework first 😅

vemv00:12:53

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.

Denis G01:12:06

thanks 🙂

seancorfield01:12:43

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

seancorfield01:12:12

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.

seancorfield01:12:42

I wrote about our usage of Spec a few months ago https://corfield.org/blog/2019/09/13/using-spec/

Denis G01:12:21

@seancorfield hmmm. Interesting experience. I will read your blog post. Thanks for the link 🙂

p-himik17:12:22

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?

1
hindol20:12:22

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:

👍 2
Gulli20:12:12

Sorry about that 🙂

Gulli20:12:43

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.

Nate Sutton20:12:14

haaa, it's not bad to be reminded of it, it's just such an issue in every lisp community I've interacted with