11 ms·
"it became clear that we needed to ensure that every single condition was handled and accounted for in the code" This is a feature of several (mostly functiona
by dajonker 8y ago
"it became clear that we needed to ensure that every single condition was handled and accounted for in the code"
This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other languages.
- kbumsik 8y ago> This is a feature of several (mostly functional) programming languages This is just one of a common practice of programming, not a feature of functional languages. These practices are not even "reinventing the wheel". I mean, this is obvious in many areas: from implementing complex logics like Kubernetes to making hardware drivers in C. Programming languages themselves can't automagically ensure every single conditions because these often happen outside of the program (e.g. targeting hardware state). We need to cover and test all cases by hand anyway.
- dfox 8y agoThis is one of the painfully obvious facts that tend to be totally ignored by most. Even if you formally verify all of you code it does not mean that you have covered all the possible states of the outside world. And this can mean both unexpected states on the outside and unexpected hardware failures. On one project I work with guy with significant railway signalling experience and this is one of the issues that I'm somewhat unable to explain to him. Probably because our product's design target is not to fail-fast-and-safe but fail-secure.
- topmonk 8y agoWhy do you say Haskell is an example of this? You can return undefined for anything, and have incomplete pattern matching, where if you don't mention a particular case, there is a runtime crash. An example would be head, which takes the first element of a list and throws an error on an empty list. I really love Haskell but it seems as if they are going for something different here than what Haskell provides.
- deleted 8y ago[deleted]
- swsieber 8y agoNow Rust on the other hand ... (runs away). In all seriousness though, Rust does get a little closer - it requires exhaustive matching (or explicit opt out) and deliberate error handling (or explicit opt out). There are still ways around it, but the happy path in Rust is handling errors.... well, maybe not happy. It is a little verbose.
- dajonker 8y agoMy point was not really to mention a particular programming language, but rather to make the point that people seem to continuously reinvent the wheel rather than reading up on history and investigating other programming languages. If you only know C/Java/Python/Go and you learn about <radically-different-language>, it will probably make you a better programmer even if you never write a single line of <radically-different-language>.
- abraae 8y agoI've learned the most from shifting levels of abstraction, rather than between programming languages. When I started at Oracle, on the first day my head near exploded as everyone communicated in ER diagrams instead of pseudo code or more procedural form. Learning to design databases at scale, and learning how far to go in making things metadata driven was hugely educational. More recently, breaking up legacy application domains into microservices and defining the APIs between them feels to be like a "higher" skill than database design/object modeling. Probably doing IoT projects would help bring some other skills to the fore.
- nightski 8y agoThat's not really a limitation of the "language" but more of an implementation detail of GHC and Prelude imo. There are very few escape hatches from the type system and you can run the compiler so that these cases are treated as a compile time error.
- dllthomas 8y ago
- shados 8y agoI 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.
- atrocious 8y agoWhich metrics?
- shados 8y agoAmount of bugs that end up in production. A reasonably important and easy to measure metric.
- yawaramin 8y agoNot 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.
- jnbiche 8y agoCode 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.
- shados 8y ago"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.
- endymi0n 8y agoI know a business coach who regularly asks his audience "Who here makes better burgers than McDonalds?". When half the audience raises their hand, he asks them why they don't outsell this giant company. Functional programming advocats, especially for the "pure" ones like Haskell, always strike me as odd. It seems that all the beauty of those languages make people obsess over that beauty and purity while keeping them from being productive. Meanwhile, people with simpler languages like Go just get stuff done that is useful and makes people happy. Now if I _ever_ came across a useful Haskell product, I'd be happy to test drive it, shouldn't be a problem by now with all the container technology. But the closest I ever came to using a functionally developed product was RabbitMQ (written in Erlang). That one was _such_ a pain to use and operate — must have been the developers still dreaming in the purity of its code instead of writing some installation docs. I moved on to Kafka later and didn't regret it a minute. Rant off.
- progval 8y ago> Now if I _ever_ came across a useful Haskell product There's at least git-annex and pandoc
- root_axis 8y agoI agree with the general sentiment of your post, but the idea that Kafka is somehow less painful to operate than Rabbit is ridiculous. I love Kafka, but I can't think of a more painful software to maintain in production.
- neeleshs 8y ago
- beefeater 8y agoIf you need to make sure every condition is handled, write a test for every condition.
- lmm 8y agoWhy? That's both more work and more error-prone than just using a language that will ensure it.
- lgunsch 8y agoIf every condition is important to the business, as is implied in this case, it would be very valuable to have tests to cover them.
- lmm 8y agoThe business wants to know all conditions are handled appropriately, to a certain level of confidence. Tests are one way of achieving this but by no means the only way.
- intuitionist 8y agoIn general, I think that if you find yourself "needing" to write in an intentionally complex and verbose style, this is symptomatic of bad design choices elsewhere, maybe even at the language level.
- karmasimida 8y ago> This is a feature of several (mostly functional) programming languages, e.g. Haskell I didn't see that. In fact this speaks to me as mission critical software like this needs to be as tediously documented as possible to eliminate surprises. Those branches and conditions are collected through a huge pool of trial-and-errors, implying Haskell can provide those valuable use cases out-of-box is misleading, no it can't. Model checker like TLA+ or Pluscad might do the trick.
- pwm 8y agoI think what the parent comment referred to is that in Haskell if/then/else is an expression (like everything else) so you must by definition have to have an else “branch”. Basically it frees you from a subtle type of error.
- karmasimida 8y agoThose are micro level features. For mission critical module like this, it is unlike those low-level bugs will be left without notice. But the true complexity is coming from states, and combination of states, and many of those are unknown to the developer until certain incidents kicked in. Good programming practice can't relieve programmers from the cognitive burden of reasoning the outcome of those combinations.
- deleted 8y ago[deleted]
- weberc2 8y agoIs it possible that there are other criteria besides ADTs which factor into choosing a programming language?