News for hackers. Stuff that matters.
Re:Please do not attempt to simplify this code by shados on Thursday December 27, 2018 @05:19PM (#18773145)
I really like the idea of "sound" programming languages. Elm is a great example of a reasonably simple, very sound programming language that force you to handle all cases (short of a compiler bug, hardware failure, or an explicit fail the world statement, it basically cannot throw exceptions).

Unfortunately the odds of this ending up in a mainstream language this decade is pretty low: the extreme focus on terse code and DRY means the average dev balks at the verbosity (thus the coment in the linked piece of code being necessary). It's a shame, as it's objectively superior by many metrics.

Re:Please do not attempt to simplify this code by jnbiche on Thursday December 27, 2018 @07:01PM (#18773772)
Code terseness and case analysis (handling all cases) are totally orthogonal: OCaml is pretty terse and yet the compiler is great at letting you know if you forgot to handle some case.
Re:Please do not attempt to simplify this code by shados on Thursday December 27, 2018 @10:27PM (#18774691)
"In case X, do Y". You can make that pretty terse with clever pattern matching, in term of amount of keystrokes typed, but someone will always come in and feel they can save even more keystrokes by not handling all of the cases.
Re:Please do not attempt to simplify this code by atrocious on Thursday December 27, 2018 @05:35PM (#18773254)
Which metrics?
Re:Please do not attempt to simplify this code by shados on Thursday December 27, 2018 @10:27PM (#18774692)
Amount of bugs that end up in production. A reasonably important and easy to measure metric.
Re:Please do not attempt to simplify this code by yawaramin on Sunday December 30, 2018 @02:46AM (#18787987)
Not really that easy. The amount of production bugs that end up getting measured are the ones that got reported, there are an unknown (and unknowable) number of unreported bugs that you never measure.