This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (4)
- # beginners (14)
- # boot (41)
- # capetown (1)
- # carry (10)
- # clojure (168)
- # clojure-czech (11)
- # clojure-mexico (3)
- # clojure-quebec (1)
- # clojure-russia (63)
- # clojure-spec (108)
- # clojure-uk (44)
- # clojurescript (37)
- # component (5)
- # data-science (2)
- # datascript (5)
- # datomic (3)
- # defnpodcast (9)
- # dirac (14)
- # emacs (18)
- # events (1)
- # funcool (2)
- # garden (2)
- # hoplon (48)
- # leiningen (6)
- # numerical-computing (1)
- # off-topic (8)
- # om (61)
- # onyx (22)
- # proton (14)
- # re-frame (50)
- # reagent (2)
- # uncomplicate (1)
- # untangled (41)
- # vim (5)
- # yada (5)
I've now gotten to the point where all I see reading Clojure code is a sea of type errors.
@martintrojer: time to move on…. start using Haskell and tell us what it is like on the other side
I’m enjoying being back in clojure-land for a bit - all I see is “stuff I won’t be able to do next time I’m forced back to a strongly typed language” 🙂
- Read in config as a map of stuff, some list some sets some vectors, then extract stuff from it as needed
- Subscribe to a JMS queue, on each message try parsing it as an Int (which is expected) and conj it onto a list (in an atom). However, if I get something that isn’t an int, log it and conj it onto the list anyway, something later can handle errors for me.
surely you can do all that in a typed language, with appropriate use of sum or tagged types, or writers or whatever ? ?
You definitely can - but you would spend an age writing all those types. And you could only do it in a “good” typed language, which narrows the field a lot.
i guess the deal you are making is that you spend the time on defining types beforehand in exchange for not spending time hunting down bugs later
Yep - feels like premature optimisation to me. I don’t actually get very many type bugs. The ones I do get are generally short-lived - mistakes made during coding or refactoring - and even rudimentary unit/integration tests catch them.
type bugs are a wide net for me. all the nil stuff, shape errors, keyword typos etc
could be - i can't judge - i haven't done a significant project in a language with a powerful type system - i would definitely like to
The closest I’ve done was Scala - and yes, there are things I miss from there. Type-based pattern matching, and type-safe Options (maybe monad) were great. Maybe I just haven’t spent enough time in “good” languages 🙂
Yeah, people who say types are bad since they wasted too many years in Java doesn't know the whole story.
Everybody needs to write an parser in Parsec and experience the week-long grin when the Applicative Functor penny drops.
The flip side is people who say “types are awesome” and then don’t offer up a language that implements them properly that is widely used enough for us to get paid using it 🙂
Generative testing is another thing I’d love to play with properly, if I were using a “good” typed language - I’ve seen some magic testing done in Haskell. I’ll be interested to see how well they work with spec - haven’t had a chance to play yet.
I expected it to be really useful for testing validation rules, but had difficulty expressing good properties
… except of course, last time I asked a Haskell fan “can the type system do X” they said “ah, no, Haskell’s type system is not up to it, you should be using Idris” 😉
Anyone here worked through this book before? (https://www.packtpub.com/big-data-and-business-intelligence/clojure-data-science)
i read half of it (before i joined mastodonC), and found it very interesting. It is quite a bit of work though!
I did find that once i got used to the format i could use it more as a reference when i got stuck doing stuff