That's one of the largest (and apparently most useful) Elm apps in the wild that I've heard of, and the fact that it exists and they had an overall good experience with it inspires me even more to try to learn and use Elm.
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.
It's nothing more than being happy that this somewhat academic and niche language is being adopted in the real-world.
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.
I think that even the most liberal estimate on line count would be half what you typically find in Elm.
https://medium.freecodecamp.org/a-real-world-comparison-of-f...
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.
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/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.
Your view on the role of types is unfortunate if you think term logic is simply mirrored at the type level (Plato's Cave). The Curry-Howard correspondence tells us to think of types as logical propositions with terms as their proofs.
The reality is that in most cases there's a cost benefit analysis regarding how much time you can spend on a particular feature and the strength of the guarantees.
>The Curry-Howard correspondence tells us to think of types as logical propositions with terms as their proofs.
Hence my point that you end up writing a metaprogram that emits the logic. Ensuring that the metaprogram is correct is a manual process. The more complex the proof, the harder it becomes to understand.
Consider Fermat's conjecture. It's trivial to state it, it's trivial to test it to be correct for a given set of inputs. However, proving it for the general case is quite difficult, and only a handful of people in the world can follow that proof.
This is a strawman, conventional static type system can't prove all general cases either and no body is saying that they do that. Yet, they being a superset of dynamic typing, they allow to have the same expesiveness as such by providing a bypass like 'Object' or 'any'.
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.
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.
However I think there's a difference between "with care, runtime errors are rare", and "by default, number of runtime errors is zero".
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.
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.
And I don’t agree with it. I’m aware Elm doesn’t have dependent types.
> "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.
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
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-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.
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).
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.... [2] https://clojure.org/guides/spec [3] https://re-find.it/
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/mas...
Of course, if it makes you feel better personally that's great for you and you should keep using it. However, if you're going to make wide sweeping claims regarding that, then they have to be rooted in more than just your personal experience and rationalizing.
It's a lot of lines, but how many characters is it?