4 ms·

In my opinion you get more than just "eliminating a class of bugs", in my (arguably limited) forays into functional programming languages I really liked the typ

In my opinion you get more than just "eliminating a class of bugs", in my (arguably limited) forays into functional programming languages I really liked the type-guided programming. One aspect is "I refactored the code, fixed all the type-errors and everything works", another is "I don't know, what should I write here, compiler, tell me!" with typed-holes, along-side some nice search, such as hoogle (or elm's fancy search [1]) In simmilar fashion, I remember Elm was enforcing a version bump, if you break package public api. On the other hand, you definitely are replacing one set of problems for a different set, and it is up to you to decide what kind of problems you like solving better. For me, access to fast immutable data-structures seem to have the best return-on-investment, and easiest to introduce (i.e. even Javascript or Python have somewhat decent libraries for these). [1] https://klaftertief.github.io/elm-search/ https://klaftertief.github.io/elm-search/

yogthos 8y ago
With Clojure the approach is to use REPL driven development. It's tightly integrated with the editor, and any time you write a function you run it to see that it's doing what you intended. Because you're evaluating code as you're writing it, there's generally no confusion regarding what the code is doing. [1] Meanwhile, immutability as the default makes it natural to structure applications using independent components. This helps with the problem of tracking types in large applications as well. You don't need to track types across your entire application, and you're able to do local reasoning within the scope of each component. You make bigger components by composing smaller ones together, and you only need to know the types at the level of composition which is the public API for the components. Spec [2] is a contract system that's often used to define API boundaries in Clojure. I find it provides an advantage over static typing because it directly focuses on semantic correctness. For example, consider a sort function. The types can tell me that I passed in a collection of a particular type and I got a collection of the same type back. However, what I really want to know is that the collection contains the same elements, and that they're in order. This is difficult to express using most type systems out there, while trivial to do using Spec. Spec also facilitates stuff like hoogle [3]. [1] https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.html https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.... [2] https://clojure.org/guides/spec https://clojure.org/guides/spec [3] https://re-find.it/ https://re-find.it/
- a-saleh 8y ago
  Nice, if I ever will have the pleasure of working in clojure, I will remember the re-find thing you mentioned here :-) But to show more of I really liked when developing with types, take a look at this slightly contrived example [1]. I once tried to refactor a medium size haskell code-base, and ability to just ask the compiler "Hey what should I put in here?" really made my life easier :) [1] https://github.com/paf31/24-days-of-purescript-2016/blob/master/23.markdown https://github.com/paf31/24-days-of-purescript-2016/blob/mas...
  - yogthos 8y ago
    Yeah, there are nice aspects of having static typing as well. Haskell was the first FP language I've used actually, and it was a lot of fun. Eventually I ended up working with Clojure professionally, and I don't find that one approach or the other is strictly better. There are pros and cons to each, and they're both productive.

yogthos 8y ago

With Clojure the approach is to use REPL driven development. It's tightly integrated with the editor, and any time you write a function you run it to see that it's doing what you intended. Because you're evaluating code as you're writing it, there's generally no confusion regarding what the code is doing. [1] Meanwhile, immutability as the default makes it natural to structure applications using independent components. This helps with the problem of tracking types in large applications as well. You don't need to track types across your entire application, and you're able to do local reasoning within the scope of each component. You make bigger components by composing smaller ones together, and you only need to know the types at the level of composition which is the public API for the components. Spec [2] is a contract system that's often used to define API boundaries in Clojure. I find it provides an advantage over static typing because it directly focuses on semantic correctness. For example, consider a sort function. The types can tell me that I passed in a collection of a particular type and I got a collection of the same type back. However, what I really want to know is that the collection contains the same elements, and that they're in order. This is difficult to express using most type systems out there, while trivial to do using Spec. Spec also facilitates stuff like hoogle [3]. [1] https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.html https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.... [2] https://clojure.org/guides/spec https://clojure.org/guides/spec [3] https://re-find.it/ https://re-find.it/

a-saleh 8y ago
Nice, if I ever will have the pleasure of working in clojure, I will remember the re-find thing you mentioned here :-) But to show more of I really liked when developing with types, take a look at this slightly contrived example [1]. I once tried to refactor a medium size haskell code-base, and ability to just ask the compiler "Hey what should I put in here?" really made my life easier :) [1] https://github.com/paf31/24-days-of-purescript-2016/blob/master/23.markdown https://github.com/paf31/24-days-of-purescript-2016/blob/mas...
- yogthos 8y ago
  Yeah, there are nice aspects of having static typing as well. Haskell was the first FP language I've used actually, and it was a lot of fun. Eventually I ended up working with Clojure professionally, and I don't find that one approach or the other is strictly better. There are pros and cons to each, and they're both productive.