7 ms·

> In a comment below the main post they say that the app they wrote is approximately 45,000 lines of code over 170 Elm files. One thing I've found a bit weird

> In a comment below the main post they say that the app they wrote is approximately 45,000 lines of code over 170 Elm files. One thing I've found a bit weird about the Elm community is how common it is to highlight or even brag about the size of the codebases. One of the reasons I have come to particularly enjoy Clojurescript on the front-end is because of how much code I don't have to write. I once ported an Elm app to Clojurescript and it was only one-third the line count for the same functionality, and generally a smoother experience. I think some developers just love building up these huge, complex worlds and living inside them, and then telling others how big those worlds are.

the_gipsy 8y ago
You make it seem like Elm strives to make big, complex programs and that people would take pride in that. That is not the case. It's nothing more than being happy that this somewhat academic and niche language is being adopted in the real-world.
davidgrenier 8y ago
I think you should read this as being an otherwise 150kloc project in Java. Seriously, at this point IBM should fork a couple hundred thousand dollars just to know how anyone on their staff can recreate this in idiomatic java (or whatever OO language they want) and have you do it in idiomatic clojure/script. I'd be surprised if you managed less than 30k and very surprised if the OO implementation managed less than 100k. Hard data on this kind of debate being hard to come by, we'd learn something from the experiment.
- hellofunk 8y ago
  30K lines of Clojurescript is so enormous on an epic scale. I think that even the most liberal estimate on line count would be half what you typically find in Elm.
  - aaaaaaass 8y ago
    yeah because no types
- yogthos 8y ago
  In this comparison of a minimal "real world" app comparison, Elm version has around 3 times as much code as ClojureScript. https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962 https://medium.freecodecamp.org/a-real-world-comparison-of-f...
  - willtim 8y ago
    An apples and oranges comparison. Any difference would surely be made up by all the tests one would have to write to be sure the clojure code was free of basic errors.
    - yogthos 8y ago
      That's a completely baseless assumption. I have not found the need to write any more tests in Clojure than I have in statically typed languages. The only tests my team ends up writing tend to be end-to-end specification tests, and you would want to have those in any serious project regardless of type discipline.
      - willtim 8y ago
        Tests prove the presence of bugs not their absence. You should be writing more tests if you have no static type system, in order to find the bugs that you would otherwise prove don't exist.
        bgorman 8y ago
        A static type system like Elm doesn't fix logical bugs like wrong indexing, wrong predicate etc, it just finds issues with types. Types do not contain the real logic of your program. Types are somewhat useful for verifying data is passed around in the correct shape in a program, but to say it prevents most obvious errors is naive. Not to mention in Elm you will waste tons of time doing useless tasks like writing encoders/decoders and code that could be moved to macros in a more powerful language.
yakshaving_jgt 8y ago
That’s not how I feel about it. I’d say it’s more “look how many lines of code there are vs how many ways this could break in production”. This will always be very different from your average ClojureScript/Reframe/Reagent app, which may or may not have fewer lines of code (in my experience they’ve been roughly equivalent), but vastly more opportunity for runtime errors.
- yogthos 8y ago
  ClojureScript will have quite a bit less code in a non-trivial project https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962 https://medium.freecodecamp.org/a-real-world-comparison-of-f... Meanwhile, my team has been working with ClojureScript for years, and runtime errors are a really rare occurrence in my experience. Especially if you use Schema or Spec around the API between components.
  - yakshaving_jgt 8y ago
    Great. I'm happy for you. However I think there's a difference between "with care, runtime errors are rare", and "by default, number of runtime errors is zero".
    - hellofunk 8y ago
      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 :)

the_gipsy 8y ago

You make it seem like Elm strives to make big, complex programs and that people would take pride in that. That is not the case. It's nothing more than being happy that this somewhat academic and niche language is being adopted in the real-world.

davidgrenier 8y ago

I think you should read this as being an otherwise 150kloc project in Java. Seriously, at this point IBM should fork a couple hundred thousand dollars just to know how anyone on their staff can recreate this in idiomatic java (or whatever OO language they want) and have you do it in idiomatic clojure/script. I'd be surprised if you managed less than 30k and very surprised if the OO implementation managed less than 100k. Hard data on this kind of debate being hard to come by, we'd learn something from the experiment.

hellofunk 8y ago
30K lines of Clojurescript is so enormous on an epic scale. I think that even the most liberal estimate on line count would be half what you typically find in Elm.
- aaaaaaass 8y ago
  yeah because no types
yogthos 8y ago
In this comparison of a minimal "real world" app comparison, Elm version has around 3 times as much code as ClojureScript. https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962 https://medium.freecodecamp.org/a-real-world-comparison-of-f...
- willtim 8y ago
  An apples and oranges comparison. Any difference would surely be made up by all the tests one would have to write to be sure the clojure code was free of basic errors.
  - yogthos 8y ago
    That's a completely baseless assumption. I have not found the need to write any more tests in Clojure than I have in statically typed languages. The only tests my team ends up writing tend to be end-to-end specification tests, and you would want to have those in any serious project regardless of type discipline.
    - willtim 8y ago
      Tests prove the presence of bugs not their absence. You should be writing more tests if you have no static type system, in order to find the bugs that you would otherwise prove don't exist.
      - bgorman 8y ago
        A static type system like Elm doesn't fix logical bugs like wrong indexing, wrong predicate etc, it just finds issues with types. Types do not contain the real logic of your program. Types are somewhat useful for verifying data is passed around in the correct shape in a program, but to say it prevents most obvious errors is naive. Not to mention in Elm you will waste tons of time doing useless tasks like writing encoders/decoders and code that could be moved to macros in a more powerful language.

yakshaving_jgt 8y ago

That’s not how I feel about it. I’d say it’s more “look how many lines of code there are vs how many ways this could break in production”. This will always be very different from your average ClojureScript/Reframe/Reagent app, which may or may not have fewer lines of code (in my experience they’ve been roughly equivalent), but vastly more opportunity for runtime errors.

yogthos 8y ago
ClojureScript will have quite a bit less code in a non-trivial project https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962 https://medium.freecodecamp.org/a-real-world-comparison-of-f... Meanwhile, my team has been working with ClojureScript for years, and runtime errors are a really rare occurrence in my experience. Especially if you use Schema or Spec around the API between components.
- yakshaving_jgt 8y ago
  Great. I'm happy for you. However I think there's a difference between "with care, runtime errors are rare", and "by default, number of runtime errors is zero".
  - hellofunk 8y ago
    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 :)