3 ms·

There is also a big difference between spending one hour debugging runtime errors on any given day or week vs. the time it takes to write 3x or 4x the code and

There is also a big difference between spending one hour debugging runtime errors on any given day or week vs. the time it takes to write 3x or 4x the code and handle compiler errors. Ultimately there are tradeoffs in how time is spent in both languages. Each developer will prefer different tradeoffs. I think in terms of net time spent on the whole dev cycle, it's hard to beat Clojurescript.

yakshaving_jgt 8y ago
I have the exact opposite opinion :)
- hellofunk 8y ago
  The problem with static typing confidence is it suggests no runtime errors, but really all it does is handle a certain class of runtime errors. To say that Elm has no runtime crashes is one thing, but it still suffers from all the runtime problems of any language when logic isn't written properly to account for different and unexpected values. Does your compiler guarantee that you don't have a "cents" value that is greater than 99? Or, for example, consider division by zero, which is another interesting case. Clojurescript, on the other hand, has a novel system in place for handling runtime issues of any kind (types, values, whatever), because this is where it excels -- runtime dynamism.
  - yakshaving_jgt 8y ago
    This argument is essentially “the tool doesn’t protect me from everything, therefore it’s better to have no protection at all.” And I don’t agree with it. I’m aware Elm doesn’t have dependent types.
    - hellofunk 8y ago
      Well, you wrote: > "by default, number of runtime errors is zero" And that's just a silly argument to make about any language and I hope Elm developers don't have false confidence about this.
      - razze 8y ago
        In all fairness, it can happen, but it becomes very very unlikely. Here have some real world stats https://docs.google.com/presentation/d/1LM_W2BRs_ItT-SPDe70C10cbwhGNHGQlJ1fVnAdnRIY/edit#slide=id.g3f8b28aef2_0_238 https://docs.google.com/presentation/d/1LM_W2BRs_ItT-SPDe70C...
    - yogthos 8y ago
      There is a cost associated with eliminating this class of errors using static typing. The cost is that you're restricted to a set of statements that the type checker can verify to be correct. Writing code for the benefit of the type checker is often at odds with writing it in a way that conveys the meaning best to the human reader. This is necessarily less expressive than the dynamic approach. Code written in dynamic languages tends to do a better job of expressing its intent because it can be written in a more direct fashion. Here's a concrete real world example of what I'm talking about: >When I first wrote the core.async go macro I based it on the state monad. It seemed like a good idea; keep everything purely functional. However, over time I've realized that this actually introduces a lot of incidental complexity. And let me explain that thought. >What are we concerned about when we use the state monad, we are shunning mutability. Where do the problems surface with mutability? Mostly around backtracking (getting old data or getting back to an old state), and concurrency. >In the go macro transformation, I never need old state, and the transformer isn't concurrent. So what's the point? Recently I did an experiment that ripped out the state monad and replaced it with mutable lists and lots of atoms. The end result was code that was about 1/3rd the size of the original code, and much more readable. >So more and more, I'm trying to see mutability through those eyes: I should reach for immutable data first, but if that makes the code less readable and harder to reason about, why am I using it? https://groups.google.com/forum/#!topic/clojure/wccacRJIXvg https://groups.google.com/forum/#!topic/clojure/wccacRJIXvg Another example of something that's trivial in a dynamic language, but difficult to do in a static one would be Ring middleware: https://github.com/ring-clojure/ring/wiki/Middleware-Patterns https://github.com/ring-clojure/ring/wiki/Middleware-Pattern... So really what you're doing with static typing is trading one set of problems for another. This is perfectly fine if those are the kinds of problems you prefer to deal with, but it's important to recognize that you are making a trade off as opposed to getting something for free here.
      - a-saleh 8y ago
        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/

yakshaving_jgt 8y ago

I have the exact opposite opinion :)

hellofunk 8y ago
The problem with static typing confidence is it suggests no runtime errors, but really all it does is handle a certain class of runtime errors. To say that Elm has no runtime crashes is one thing, but it still suffers from all the runtime problems of any language when logic isn't written properly to account for different and unexpected values. Does your compiler guarantee that you don't have a "cents" value that is greater than 99? Or, for example, consider division by zero, which is another interesting case. Clojurescript, on the other hand, has a novel system in place for handling runtime issues of any kind (types, values, whatever), because this is where it excels -- runtime dynamism.
- yakshaving_jgt 8y ago
  This argument is essentially “the tool doesn’t protect me from everything, therefore it’s better to have no protection at all.” And I don’t agree with it. I’m aware Elm doesn’t have dependent types.
  - hellofunk 8y ago
    Well, you wrote: > "by default, number of runtime errors is zero" And that's just a silly argument to make about any language and I hope Elm developers don't have false confidence about this.
    - razze 8y ago
      In all fairness, it can happen, but it becomes very very unlikely. Here have some real world stats https://docs.google.com/presentation/d/1LM_W2BRs_ItT-SPDe70C10cbwhGNHGQlJ1fVnAdnRIY/edit#slide=id.g3f8b28aef2_0_238 https://docs.google.com/presentation/d/1LM_W2BRs_ItT-SPDe70C...
  - yogthos 8y ago
    There is a cost associated with eliminating this class of errors using static typing. The cost is that you're restricted to a set of statements that the type checker can verify to be correct. Writing code for the benefit of the type checker is often at odds with writing it in a way that conveys the meaning best to the human reader. This is necessarily less expressive than the dynamic approach. Code written in dynamic languages tends to do a better job of expressing its intent because it can be written in a more direct fashion. Here's a concrete real world example of what I'm talking about: >When I first wrote the core.async go macro I based it on the state monad. It seemed like a good idea; keep everything purely functional. However, over time I've realized that this actually introduces a lot of incidental complexity. And let me explain that thought. >What are we concerned about when we use the state monad, we are shunning mutability. Where do the problems surface with mutability? Mostly around backtracking (getting old data or getting back to an old state), and concurrency. >In the go macro transformation, I never need old state, and the transformer isn't concurrent. So what's the point? Recently I did an experiment that ripped out the state monad and replaced it with mutable lists and lots of atoms. The end result was code that was about 1/3rd the size of the original code, and much more readable. >So more and more, I'm trying to see mutability through those eyes: I should reach for immutable data first, but if that makes the code less readable and harder to reason about, why am I using it? https://groups.google.com/forum/#!topic/clojure/wccacRJIXvg https://groups.google.com/forum/#!topic/clojure/wccacRJIXvg Another example of something that's trivial in a dynamic language, but difficult to do in a static one would be Ring middleware: https://github.com/ring-clojure/ring/wiki/Middleware-Patterns https://github.com/ring-clojure/ring/wiki/Middleware-Pattern... So really what you're doing with static typing is trading one set of problems for another. This is perfectly fine if those are the kinds of problems you prefer to deal with, but it's important to recognize that you are making a trade off as opposed to getting something for free here.
    - a-saleh 8y ago
      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/