This also points to a bigger issue with Elm not living up to its "no runtime exceptions" hype. Conceivably it could avoid having runtime exceptions through stricter type-checking but there are things like testing equality of functions or unfortunate recursive declarations (at least as of 0.16) that will lead to runtime exceptions. "Worse", when you get an exception, it's generally harder to debug than a JavaScript "undefined in not a function". The exceptions are probably more rare than the JavaScript exceptions, but that they happen at all is a problem when the hype says they don't exist. Truth in advertising would call for listing out all of the places where the Elm runtime can throw exception and providing some guidance about the causes. With that in hand, developers know what to avoid and the Elm team (i.e., Evan) can talk about how those cases are going to be eliminated over time.
This all matters to me because I'm looking at trying to sell a team on using Elm for some major development work. A few of us have spent a few months building with Elm and we like the immutability and the lack of exceptions — the runtime exceptions above are generally fatal which is an entirely different issue from programming in an environment where code can throw an exception whenever it is "unhappy" — which would seem to depend on static type-checking to make manageable. It took a while for us to adapt to the syntax but that discomfort has passed. There are still some technical hurdles — support for binary data, reading layout information back from the DOM since Elm has shifted away from its "let's replace HTML" origins, etc — but those seem like things that will either be resolved or we will find ways to work around. But from a strategic standpoint, it's harder to sell Elm. It's a custom tool stack that seems to be bottlenecked through one person and which doesn't always live up to its hype. This is why I've expressed concern elsewhere about the shift from Elm 0.16 to the better but incompletely documented Elm 0.17 and the fact that two months in, the documentation is still incomplete. Anyone doing a technical review from the outside or from within the team would be justified in drilling down hard on my advocacy for using Elm. Thirteen years ago, I and one other engineer picked Lua as the key basis for building Lightroom. That raised some eyebrows but we could point to the health of the Lua ecosystem, to the stability of the offering, and to the fact that a number of developers were successfully using it on commercial work. It feels harder to make that case right now for Elm and that's frustrating because I would like Elm to be a viable answer. Mark > On Jul 10, 2016, at 11:17 AM, Mark Hamburg <[email protected]> wrote: > > Elm already has some built-in typeclass like concepts — e.g., comparable — so > tracking equatable as a required property wouldn't seem like an entirely new > notion. On the other hand, generating useful error messages would require > being able to report the path through the logic that leads to where equatable > matters and through the data structures to where equatable isn't feasible. > > Mark > >> On Jul 9, 2016, at 11:59 PM, Joey Eremondi <[email protected]> wrote: >> >> Now, I'm not saying that it's worth it to have typeclasses, and I realize >> there are disadvantages that make them likely unsuitable for Elm. >> >> But when an issue like this arises, it's worth mentioning that this is >> *exactly* the kind of problem that typeclasses solve. >> >> Passing around a comparison function would also solve this, though in a >> verbose way that, to my knowledge, nobody has actually really tried. >> >>> On Jul 9, 2016 6:49 PM, "Max Goldstein" <[email protected]> wrote: >>> Yes, this is the expected behavior. You can't equate functions, even in >>> theory, except that reference equality implies function equality. That's >>> exactly what you see in your first case >>> >>> Yes it would be nice for the compiler to catch this, but it's less trivial >>> than you may think, since it has to track functions in data structures >>> nested arbitrarily deeply. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
