This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-03
Channels
- # aws (1)
- # bangalore-clj (3)
- # beginners (3)
- # boot (9)
- # business (1)
- # cljs-dev (72)
- # cljsjs (7)
- # clojure (86)
- # clojure-austin (1)
- # clojure-belgium (4)
- # clojure-brasil (14)
- # clojure-conj (3)
- # clojure-dev (10)
- # clojure-italy (4)
- # clojure-poland (14)
- # clojure-russia (36)
- # clojure-spec (144)
- # clojure-uk (50)
- # clojurebridge (1)
- # clojurescript (160)
- # clr (2)
- # core-async (8)
- # cursive (56)
- # datomic (34)
- # devcards (3)
- # emacs (2)
- # ethereum (1)
- # events (3)
- # hoplon (21)
- # jobs (2)
- # leiningen (9)
- # luminus (3)
- # off-topic (1)
- # om (26)
- # onyx (42)
- # pedestal (29)
- # protorepl (1)
- # re-frame (43)
- # reagent (26)
- # rethinkdb (4)
- # ring-swagger (4)
- # spacemacs (5)
- # specter (4)
- # untangled (102)
- # vim (43)
- # yada (10)
@reefersleep so hm, let me try to describe it.
lisp in general feels much more like painting than ML.. same when talking about javascript vs. typescript (classically, not the ES6 madness of our current age). i feel like I can focus on implementation without having to rigorously think about my types up front.
fortunately, clojure, racket, and friends allow me to opt into that when I want those guards when I look away
but I have this deeper intuition when I type a bad lisp/js/ruby statement and something blows up, far more than I do when I get a whole bunch of type vomit and have to trace out a murder scene.
i feel for sure I can try and explore a lot more, faster even with how nice a lot of what Elm does is.
you get stuck into inconvenient architecture decisions with Elm where - what you do may be wrong as the app grows - but you can’t break out of it and so you have to do this full re-factor to actually make it work, losing a day, even if you’re technically making “progress” 100% of that time.
its certainly not prose that I can meld to my thoughts and domain, no matter how much experience I get behind it.
anyway, a lot of people will completely disagree with that perspective, not necessarily here.
plus studies thus far have failed to really show a productivity improvement of static typing. starting to understand why that is for me personally, so I’m happy to shove it to a matter of taste.
Yup, basically, if you're writing tests anyway, you don't need static typing
Also, while static typing prevents certain types of errors, designing proper types takes as much time as fixing errors in dynamically typed program
Most of such "types" are parody on generic data structures anyway
@gerred thank you for expounding on your experiences! 🙂 Personally, I still feel like I would have to experience the process with inflexible type architectures myself, though, thinking about it, I already have done so when I programmed Java for a living... Once worked on a huge app with way too many business responsibilities, and domain classes that suffered from it. Such a fossilized mess.
as an aside, related to what @yury.solovyov said - I wonder why, in Java, specifying that a collection handles items of a specific class or interface is to specify a generic collection. In my experience, this makes the collection more narrow, not more generic. Some kind of Java Newspeak? 🙂
Maybe Java has its own notion of what is generic
Indeed.
yeah, and you should. i’d say an ML type system is completely different from what you’ve experienced wrt Java.