5 ms·

> I can't memorize all thousands of functions to manipulate lists and hashs in clojure (get-in, map-vals, conj, dissoc, select-keys, sorted-map-by, do you know

> I can't memorize all thousands of functions to manipulate lists and hashs in clojure (get-in, map-vals, conj, dissoc, select-keys, sorted-map-by, do you know what all those do?) which do a lot, I felt clojure was dense, the opposite of little cognitive load In fact you need to memorize 10-20 functions to be productive in Clojure. Many of them are common across the other FP languages and some FP libraries for imperative languages and most of them cover common patterns for vector/map manipulation. Yes, the names could be confusing at first but there is good reasoning and logic behind them so it’s easy to learn. > because in fact I love how productive I am with Elm This is interesting because according to Real World App benchmarks Elm implementation has ~4x more lines of code then Clojurescript one [1]. How could it be more productive to write 4x code for the same result? [1] https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e...

frankiesardo 5y ago
elm-format naturally creates more lines than formatted clj code. Also, you have extra code for types, but also the convenience of a great type system. If you were to add clojure.spec to RWA it would probably be just as verbose.
- achikin 5y ago
  I ask myself is the type system that great if you need to write times more LOC just for the sake of it? More lines lead to more bugs exponentially. As for the spec - the benefit of it is that you are not forced to add it everywhere. You can cover crucial points of program only and leave the rest uncluttered.
  - goodoldneon 5y ago
    It’s extremely reductive to say “more lines = more bugs”. Are Perl one-liners the most bug-free way to write software? Types drastically reduce bugs.
grayrest 5y ago
> How could it be more productive to write 4x code for the same result? Lines of code in Elm is not directly comparable to Clojure. The standard Elm formatting uses very short lines and lots of vertical whitespace. Without looking at it, I'd guess 1.5-2x more actual code bytes for Elm. As for why the increased size would be more productive, Elm is content to trade verbosity for lower cognitive load/fewer concepts so it's slightly boilerplate and every app I've run across shares the Elm architecture so the patterns are similar. I prefer Clojure/Clojurescript and re-frame in particular for the task but I can see how someone with different preferences would be faster in Elm.
wk_end 5y ago
I’ve never personally tried Clojure[script] or Elm, so I have no real skin in this game, and I love Lisp and Scheme and Haskell alike, but: Writing 4x more lines code can be more productive if your IDE makes it easier to write that code because of better tooling - say, because it can help refactor or provide effective type-directed autocomplete, so you don’t need to waste lots of time looking up documentation. Or, you can be more productive even just if the documentation is better-organized, meaning when you have to look things up it takes you less time to find what you need. Or, if the documentation is better, so you have to spend less time staring at it to understand. Or, if there’s a larger community that provides solutions that are a google away when you’re stuck. Or if the type-checker is better at catching errors in advance, meaning that even if you spend more time writing code, you spend less time testing and debugging it. Or (and I’m speaking generally here and everywhere) if the compiler is significantly faster, so testing becomes less painful. Or if the debugging tools are better, so that debugging is less painful. Or if the code is considerably more readable, meaning you spend less time reading old code or others’ code and saying, “wait, what does this do again?” Or, honestly, even if your lines of code are 1/4 as dense you can write 4x as many lines of code with, all other things being equal, roughly the same amount of productivity. I’m sure there’s other things too. LOC is a questionable metric for the productivity a language ecosystem can provide is what I’m saying, basically.

frankiesardo 5y ago

elm-format naturally creates more lines than formatted clj code. Also, you have extra code for types, but also the convenience of a great type system. If you were to add clojure.spec to RWA it would probably be just as verbose.

achikin 5y ago
I ask myself is the type system that great if you need to write times more LOC just for the sake of it? More lines lead to more bugs exponentially. As for the spec - the benefit of it is that you are not forced to add it everywhere. You can cover crucial points of program only and leave the rest uncluttered.
- goodoldneon 5y ago
  It’s extremely reductive to say “more lines = more bugs”. Are Perl one-liners the most bug-free way to write software? Types drastically reduce bugs.

grayrest 5y ago

> How could it be more productive to write 4x code for the same result? Lines of code in Elm is not directly comparable to Clojure. The standard Elm formatting uses very short lines and lots of vertical whitespace. Without looking at it, I'd guess 1.5-2x more actual code bytes for Elm. As for why the increased size would be more productive, Elm is content to trade verbosity for lower cognitive load/fewer concepts so it's slightly boilerplate and every app I've run across shares the Elm architecture so the patterns are similar. I prefer Clojure/Clojurescript and re-frame in particular for the task but I can see how someone with different preferences would be faster in Elm.

wk_end 5y ago

I’ve never personally tried Clojure[script] or Elm, so I have no real skin in this game, and I love Lisp and Scheme and Haskell alike, but: Writing 4x more lines code can be more productive if your IDE makes it easier to write that code because of better tooling - say, because it can help refactor or provide effective type-directed autocomplete, so you don’t need to waste lots of time looking up documentation. Or, you can be more productive even just if the documentation is better-organized, meaning when you have to look things up it takes you less time to find what you need. Or, if the documentation is better, so you have to spend less time staring at it to understand. Or, if there’s a larger community that provides solutions that are a google away when you’re stuck. Or if the type-checker is better at catching errors in advance, meaning that even if you spend more time writing code, you spend less time testing and debugging it. Or (and I’m speaking generally here and everywhere) if the compiler is significantly faster, so testing becomes less painful. Or if the debugging tools are better, so that debugging is less painful. Or if the code is considerably more readable, meaning you spend less time reading old code or others’ code and saying, “wait, what does this do again?” Or, honestly, even if your lines of code are 1/4 as dense you can write 4x as many lines of code with, all other things being equal, roughly the same amount of productivity. I’m sure there’s other things too. LOC is a questionable metric for the productivity a language ecosystem can provide is what I’m saying, basically.