4 ms·

Throwing is a side effect breaking flow of control for no good reason. It’s takes you down the same path as all other spaghetti code. Not as much elegance as i

Throwing is a side effect breaking flow of control for no good reason. It’s takes you down the same path as all other spaghetti code. Not as much elegance as it is about purity. Minimizing side effects is the number one way to reduce bugs. It should be the number one guiding principle when creating out reliable software. Which means, you simply cannot use the primitive try catch or similar construct. Don’t break flow of control. Guide it to a terminal value instead. These days, when I see try-catch and if-else constructs (which is in most codebases) it’s clear there will be bugs over the life of the application. It’s fine, use them, but there is a world of greatness when you ditch these faulty constructs. Just like ditching OOP constructs. All built on false premises.

platinumrad 8y ago
This is what happens when you read just one chapter of Learn You a Haskell kids. Monads, not even once.
carapace 8y ago
You're correct, but you are arguing with fools. If they could understand what you're saying they would already. A few of them will get there eventually but software development will be a tire-fire, a cornucopia of bugs, for a while yet to come I think.
- platinumrad 8y ago
  Nobody here is saying that monadic error handling isn't good (in case it wasn't abundantly clear, my comment was this thing that people call a "joke"). The issue is pmichalina flippantly disparaging asserts, one of the few good things left in this hell world: https://www.microsoft.com/en-us/research/publication/assessing-the-relationship-between-software-assertions-and-code-qualityan-empirical-investigation/ https://www.microsoft.com/en-us/research/publication/assessi...
  - carapace 8y ago
    It wasn't abundantly clear, but I'm often humorless. Sorry for being so crusty. I just found out that about a third of my professional career was essentially waste because I was too thick to adopt Prolog twenty years ago. It almost physically hurts to think about it. Anyway, I think OP's right about assertions being a code smell: an assertion is literally the place where you tell the machine you don't know exactly what you're doing, eh? I've been working towards an error-free mode of development, a combination of Dr. Margaret Hamilton's "Higher Order Software" concept that developed out of the Apollo 11 project with mathematical derivation of programs. I'm just about ready to "productize" it but I'm not going to market it to other developers. I'm going to sell it directly to consumers. They won't know enough to argue with the method, they'll just be able to use the computer to solve problems, I won't tell them that they are programmers. Bottom line: error-free software development methods have been available for decades but the industry tends to ignore them. In 2018 writing "assert", "throw" or "raise", etc. is a code smell: you are doing it worng. If I sound cranky it's because I am.
    - platinumrad 8y ago
      I hope you succeed, and I say that sincerely, but regardless of whether or not program synthesis should have been pursued more aggressively in the past, I'm not aware of any support for your statement that "error-free software development methods have been available for decades" for any reasonable definitions of "error-free" or "available". >Anyway, I think OP's right about assertions being a code smell: an assertion is literally the place where you tell the machine you don't know exactly what you're doing, eh? The whole point of the original article is that, today, the only thing keeping planes in the air is fault tolerance and lots of redundancy (see also: Erlang). Assertions are about humility and it's good to be humble. >In 2018 writing "assert", "throw" or "raise", etc. is a code smell: you are doing it worng. But somehow writing ">>=" isn't? On one hand you seem to suggest that error handling is bad because there shouldn't be errors (what about I/O? user error?) while on the other hand you seem to be defending the position that monadic error handling is a panacea.
      - carapace 8y ago
        > I hope you succeed, and I say that sincerely Cheers! Me too. (^_^) Brother, I really don't want to have this argument again. I don't care anymore if my peers believe me or not. I'm just going to bring it to market as best I can and see how it goes. Thank you for the well-wishing, and I apologize again for being so cranky. A few lil points: > I'm not aware of any support for your statement that "error-free software development methods have been available for decades" for any reasonable definitions of "error-free" or "available". I know. You are making my point: The methods are there, and no one has ever even heard of them. The primary method I am talking about was developed by Margaret Hamilton during the Apollo 11 mission to the Moon, and she has unsuccessfully marketed ever since AFAIK. Dijkstra once reviewed it and panned it harshly. It was a rare case of him not getting it. It went right over his head. Hamilton, by the way, is the person who first coined the term "Software Engineering". I'm not going to go into it further now, suffice it to say if you are typing text into a text editor to write code you are doing it wrong. There's a book, "System Design from Provably-Correct Constructs" by James Martin, that presents Hamilton's method if you're interested. > The whole point of the original article is that, today, the only thing keeping planes in the air is fault tolerance and lots of redundancy (see also: Erlang). Assertions are about humility and it's good to be humble. Planes stay in the air because they are designed to survive the failure of the individual parts. Now I would never suggest that proven-correct software cannot fail. Of course it can. Need I invoke the Cosmic Rays? I heed Murphy. But you only write an assertion if you're not certain, eh? You're saying, in code, I think this will never ever happen, so if it does STOP-THE-LINE. That kind of uncertainty is absurd, inexcusable, in software. (One of the very few realms that this is true, Herr Gödel notwithstanding. Software is electrified math, math is the "Art of What is Certain".) I'm saying that our current common methods of software development are pathetic, that we are working far too hard to write software with far too many bugs, and it doesn't have to be this way. I'm further saying (to the OP) not to waste breath arguing with folks who can't or won't even accept the possibility! I've been doing it for a few years now and it's thankless. I've managed to convince exactly one other person and he's a brilliant programmer who came to it from a background in philosophy. He's a thinker rather than a puzzle-addict or complexity junkie. Anyhow, if I manage to bring this thing together I'll make a noise here on HN (despite YC getting into bed with the Chinese Communists, the greedy fools.) > On one hand you seem to suggest that error handling is bad because there shouldn't be errors (what about I/O? user error?) while on the other hand you seem to be defending the position that monadic error handling is a panacea. Nope. Nothing like that. I can't explain it all her and now, but uh... Have you heard of Elm-lang? They boast zero front-end errors. Zero. The Elm compiler makes the JavaScript and it does not error. They do not write "error handling" to achieve this.
oftenwrong 8y ago
If you application is interacting with the outside world, you will be dealing with side-effects, and sometimes error conditions will happen. For example, today I am working on a service that: - uses a database - calls external APIs - publishes and consumes from a message broker - interacts with local and remote filesystems over a variety of protocols All of these things entail error conditions, most of which throw exceptions in the corresponding libraries. Sometimes they are converted to Either/Maybe, and sometimes they are wrapped in "native" checked exceptions. The important bits: 1. The type system and compiler make sure the programmer has to deal with the error conditions at some point. From a programmer's perspective, a checked exception bubbling up the stack is not very different from returning a monadic object up the stack. 2. The core of the application is entirely pure. No exceptions (in both senses of the word). All side effects are pushed to the boundaries.

platinumrad 8y ago

This is what happens when you read just one chapter of Learn You a Haskell kids. Monads, not even once.

carapace 8y ago

You're correct, but you are arguing with fools. If they could understand what you're saying they would already. A few of them will get there eventually but software development will be a tire-fire, a cornucopia of bugs, for a while yet to come I think.

platinumrad 8y ago
Nobody here is saying that monadic error handling isn't good (in case it wasn't abundantly clear, my comment was this thing that people call a "joke"). The issue is pmichalina flippantly disparaging asserts, one of the few good things left in this hell world: https://www.microsoft.com/en-us/research/publication/assessing-the-relationship-between-software-assertions-and-code-qualityan-empirical-investigation/ https://www.microsoft.com/en-us/research/publication/assessi...
- carapace 8y ago
  It wasn't abundantly clear, but I'm often humorless. Sorry for being so crusty. I just found out that about a third of my professional career was essentially waste because I was too thick to adopt Prolog twenty years ago. It almost physically hurts to think about it. Anyway, I think OP's right about assertions being a code smell: an assertion is literally the place where you tell the machine you don't know exactly what you're doing, eh? I've been working towards an error-free mode of development, a combination of Dr. Margaret Hamilton's "Higher Order Software" concept that developed out of the Apollo 11 project with mathematical derivation of programs. I'm just about ready to "productize" it but I'm not going to market it to other developers. I'm going to sell it directly to consumers. They won't know enough to argue with the method, they'll just be able to use the computer to solve problems, I won't tell them that they are programmers. Bottom line: error-free software development methods have been available for decades but the industry tends to ignore them. In 2018 writing "assert", "throw" or "raise", etc. is a code smell: you are doing it worng. If I sound cranky it's because I am.
  - platinumrad 8y ago
    I hope you succeed, and I say that sincerely, but regardless of whether or not program synthesis should have been pursued more aggressively in the past, I'm not aware of any support for your statement that "error-free software development methods have been available for decades" for any reasonable definitions of "error-free" or "available". >Anyway, I think OP's right about assertions being a code smell: an assertion is literally the place where you tell the machine you don't know exactly what you're doing, eh? The whole point of the original article is that, today, the only thing keeping planes in the air is fault tolerance and lots of redundancy (see also: Erlang). Assertions are about humility and it's good to be humble. >In 2018 writing "assert", "throw" or "raise", etc. is a code smell: you are doing it worng. But somehow writing ">>=" isn't? On one hand you seem to suggest that error handling is bad because there shouldn't be errors (what about I/O? user error?) while on the other hand you seem to be defending the position that monadic error handling is a panacea.
    - carapace 8y ago
      > I hope you succeed, and I say that sincerely Cheers! Me too. (^_^) Brother, I really don't want to have this argument again. I don't care anymore if my peers believe me or not. I'm just going to bring it to market as best I can and see how it goes. Thank you for the well-wishing, and I apologize again for being so cranky. A few lil points: > I'm not aware of any support for your statement that "error-free software development methods have been available for decades" for any reasonable definitions of "error-free" or "available". I know. You are making my point: The methods are there, and no one has ever even heard of them. The primary method I am talking about was developed by Margaret Hamilton during the Apollo 11 mission to the Moon, and she has unsuccessfully marketed ever since AFAIK. Dijkstra once reviewed it and panned it harshly. It was a rare case of him not getting it. It went right over his head. Hamilton, by the way, is the person who first coined the term "Software Engineering". I'm not going to go into it further now, suffice it to say if you are typing text into a text editor to write code you are doing it wrong. There's a book, "System Design from Provably-Correct Constructs" by James Martin, that presents Hamilton's method if you're interested. > The whole point of the original article is that, today, the only thing keeping planes in the air is fault tolerance and lots of redundancy (see also: Erlang). Assertions are about humility and it's good to be humble. Planes stay in the air because they are designed to survive the failure of the individual parts. Now I would never suggest that proven-correct software cannot fail. Of course it can. Need I invoke the Cosmic Rays? I heed Murphy. But you only write an assertion if you're not certain, eh? You're saying, in code, I think this will never ever happen, so if it does STOP-THE-LINE. That kind of uncertainty is absurd, inexcusable, in software. (One of the very few realms that this is true, Herr Gödel notwithstanding. Software is electrified math, math is the "Art of What is Certain".) I'm saying that our current common methods of software development are pathetic, that we are working far too hard to write software with far too many bugs, and it doesn't have to be this way. I'm further saying (to the OP) not to waste breath arguing with folks who can't or won't even accept the possibility! I've been doing it for a few years now and it's thankless. I've managed to convince exactly one other person and he's a brilliant programmer who came to it from a background in philosophy. He's a thinker rather than a puzzle-addict or complexity junkie. Anyhow, if I manage to bring this thing together I'll make a noise here on HN (despite YC getting into bed with the Chinese Communists, the greedy fools.) > On one hand you seem to suggest that error handling is bad because there shouldn't be errors (what about I/O? user error?) while on the other hand you seem to be defending the position that monadic error handling is a panacea. Nope. Nothing like that. I can't explain it all her and now, but uh... Have you heard of Elm-lang? They boast zero front-end errors. Zero. The Elm compiler makes the JavaScript and it does not error. They do not write "error handling" to achieve this.

oftenwrong 8y ago

If you application is interacting with the outside world, you will be dealing with side-effects, and sometimes error conditions will happen. For example, today I am working on a service that: - uses a database - calls external APIs - publishes and consumes from a message broker - interacts with local and remote filesystems over a variety of protocols All of these things entail error conditions, most of which throw exceptions in the corresponding libraries. Sometimes they are converted to Either/Maybe, and sometimes they are wrapped in "native" checked exceptions. The important bits: 1. The type system and compiler make sure the programmer has to deal with the error conditions at some point. From a programmer's perspective, a checked exception bubbling up the stack is not very different from returning a monadic object up the stack. 2. The core of the application is entirely pure. No exceptions (in both senses of the word). All side effects are pushed to the boundaries.