6 ms·

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

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.
        willtim 8y ago
        > A static type system like Elm doesn't fix logical bugs Static type systems can absolutely catch logical bugs! Proof that a list is non-empty or that a reference is never null are simple examples. > Types do not contain the real logic of your program. Types can completely determine the logic of many parts of your program. In Haskell, I often don't have to write custom traversal code, it's selected for me based on the types. > Types are somewhat useful for verifying data is passed around in the correct shape in a program This is only the start of what types can do, try learning Haskell. > but to say it prevents most obvious errors is naive. No, naive is dismissing static type systems to the point that not even extra testing is done to compensate. > 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. Elm's aim is to be a basic easy-to-learn language (no operator overloading etc). Personally, generic (polytopic) programming feels like a more elegant approach than macros. Haskell offers both.
        yogthos 8y ago
        Haskell was my first FP language, I used it for about a year, and worked with Scala briefly after. My experience is that you're really trading one set of problems for another in practice. Static typing can guarantee that you avoid a certain class of errors, but it often results in code that's longer and more difficult to understand opening opportunities for different kinds of errors. There is absolutely no empirical evidence to suggest that the trade off is strictly superior in practice. Static typing can catch inconsistencies at the cost of structuring your code in a way that the type checker can understand. This is often at odds with making it readable for the human. A proof only has value as long as the human reader can understand it. Here's a concrete example of what I'm talking about: https://github.com/davidfstr/idris-insertion-sort/blob/master/InsertionSort.idr https://github.com/davidfstr/idris-insertion-sort/blob/maste... An insertion sort written in Idris has over 250 lines of code that you have to understand to know that it's implemented correctly. A python version would have about 10 lines or less. I'd have much easier time guaranteeing that the 10 lines do exactly what was intended than the 250 lines of type specifications. Of course, you could relax the type guarantees in Idris as well, but at that point you accept that working around the static checker has benefit and it's just a matter of degrees of comfort. In general, the more constraints you specify via types the more of your program logic moves into type specifications. What this really means is that you're writing a metaprogram that emits your logic. However, there's no automated checker for that metaprogram that you wrote using the types. You still have to understand it to be correct in order to know that it's doing what you want it to. At this point you're basically living in a programmer version of the Plato's Cave. The real question is not whether you can do something using a static type system or not. The discussion has to center around how that compares to alternative approaches such as testing, gradual typing, and runtime contracts.

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.
      - willtim 8y ago
        > A static type system like Elm doesn't fix logical bugs Static type systems can absolutely catch logical bugs! Proof that a list is non-empty or that a reference is never null are simple examples. > Types do not contain the real logic of your program. Types can completely determine the logic of many parts of your program. In Haskell, I often don't have to write custom traversal code, it's selected for me based on the types. > Types are somewhat useful for verifying data is passed around in the correct shape in a program This is only the start of what types can do, try learning Haskell. > but to say it prevents most obvious errors is naive. No, naive is dismissing static type systems to the point that not even extra testing is done to compensate. > 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. Elm's aim is to be a basic easy-to-learn language (no operator overloading etc). Personally, generic (polytopic) programming feels like a more elegant approach than macros. Haskell offers both.
        yogthos 8y ago
        Haskell was my first FP language, I used it for about a year, and worked with Scala briefly after. My experience is that you're really trading one set of problems for another in practice. Static typing can guarantee that you avoid a certain class of errors, but it often results in code that's longer and more difficult to understand opening opportunities for different kinds of errors. There is absolutely no empirical evidence to suggest that the trade off is strictly superior in practice. Static typing can catch inconsistencies at the cost of structuring your code in a way that the type checker can understand. This is often at odds with making it readable for the human. A proof only has value as long as the human reader can understand it. Here's a concrete example of what I'm talking about: https://github.com/davidfstr/idris-insertion-sort/blob/master/InsertionSort.idr https://github.com/davidfstr/idris-insertion-sort/blob/maste... An insertion sort written in Idris has over 250 lines of code that you have to understand to know that it's implemented correctly. A python version would have about 10 lines or less. I'd have much easier time guaranteeing that the 10 lines do exactly what was intended than the 250 lines of type specifications. Of course, you could relax the type guarantees in Idris as well, but at that point you accept that working around the static checker has benefit and it's just a matter of degrees of comfort. In general, the more constraints you specify via types the more of your program logic moves into type specifications. What this really means is that you're writing a metaprogram that emits your logic. However, there's no automated checker for that metaprogram that you wrote using the types. You still have to understand it to be correct in order to know that it's doing what you want it to. At this point you're basically living in a programmer version of the Plato's Cave. The real question is not whether you can do something using a static type system or not. The discussion has to center around how that compares to alternative approaches such as testing, gradual typing, and runtime contracts.