3 ms·

I read the article and found myself saying "No, no, no!". Then I read your response here and completely agree with it. How does this difference come about? Ther

I read the article and found myself saying "No, no, no!". Then I read your response here and completely agree with it. How does this difference come about? There's no way to prove who is right. Maybe people's experience of different domains is part of the cause. But mainly I believe the difference comes about due to the different way people's brains work. I think the most harmful thing you can do to a team is mix people together who naturally have different approaches. This aspect never seems to be tackled directly by the interview process.

gingerBill 5y ago
I'm not even saying my approach is "the best" but that there is no silver bullet. Different people and teams will benefit from different styles and approaches. Pluralism in thought and design is better for finding good approaches to things. If people prefer Odin's approach of Zig's approach or vice versa, that's fine and more power to them.
jstimpfle 5y ago
It's less subjective than that. I find exceptions to sort-of work in "boring" software (short running programs like scripts, or systems comprised of short running processes), or in software with low quality standards (sorry to be blunt). It's nice that I can bang out a 100 line Python batch script, and catch and transform that one exception, and otherwise just be happy when the script quits automatically because a file could not be created or some input data was malformed. Whatever, I'll "rm -rf" my temp directory and re-try. Exceptions are also popular in enterprise software - all issues with real-world business logic aside, my idea is that enterprise software doesn't have a lot of complex state after all. There is a domain model that is pretty much single-state as far as most operations on it are concerned. Normally errors are not expected to happen, and for some exceptional situations programmers simply don't care about writing error handling code - the GC will probably clean up to a reasonable state to serve the next request, it will do so in reasonable time, and all will probably just work, and nobody needs to understand what went wrong. (Maybe someone will later have a manual look at the stack trace from when the exception was thrown). If you're not a "happy path" programmer and need control over what situations are handled and when, I don't see that there is a good way with exceptions - because exceptions take away control (control flow) and take away detailed error information as gingerBill described. In my perception (while I don't read a lot of code and certainly not a lot of GC'ed code) most code never cares to catch exceptions, because it's inconvenient, and because that was the idea behind exceptions. Hope I made a reasonable argument. Can't see anything subjective about it.
- jeltz 5y ago
  Pretty much agreed. Especislly web stuff is ususlly "boring" since it delegates the state to the database so if sonething goes wrong there is usually not that much interesring to fo other than cleaning up resources.
- gingerBill 5y ago
  I agree with you here 100%. It's empirically true that all these things commonly happen. So the question is how do you mitigate these issues, if there are better alternatives? That's what I've been trying to do with the design of Odin, and try to nudge the user away from any of this nonsense whilst still being enjoyable to program in.

gingerBill 5y ago

I'm not even saying my approach is "the best" but that there is no silver bullet. Different people and teams will benefit from different styles and approaches. Pluralism in thought and design is better for finding good approaches to things. If people prefer Odin's approach of Zig's approach or vice versa, that's fine and more power to them.

jstimpfle 5y ago

It's less subjective than that. I find exceptions to sort-of work in "boring" software (short running programs like scripts, or systems comprised of short running processes), or in software with low quality standards (sorry to be blunt). It's nice that I can bang out a 100 line Python batch script, and catch and transform that one exception, and otherwise just be happy when the script quits automatically because a file could not be created or some input data was malformed. Whatever, I'll "rm -rf" my temp directory and re-try. Exceptions are also popular in enterprise software - all issues with real-world business logic aside, my idea is that enterprise software doesn't have a lot of complex state after all. There is a domain model that is pretty much single-state as far as most operations on it are concerned. Normally errors are not expected to happen, and for some exceptional situations programmers simply don't care about writing error handling code - the GC will probably clean up to a reasonable state to serve the next request, it will do so in reasonable time, and all will probably just work, and nobody needs to understand what went wrong. (Maybe someone will later have a manual look at the stack trace from when the exception was thrown). If you're not a "happy path" programmer and need control over what situations are handled and when, I don't see that there is a good way with exceptions - because exceptions take away control (control flow) and take away detailed error information as gingerBill described. In my perception (while I don't read a lot of code and certainly not a lot of GC'ed code) most code never cares to catch exceptions, because it's inconvenient, and because that was the idea behind exceptions. Hope I made a reasonable argument. Can't see anything subjective about it.

jeltz 5y ago
Pretty much agreed. Especislly web stuff is ususlly "boring" since it delegates the state to the database so if sonething goes wrong there is usually not that much interesring to fo other than cleaning up resources.
gingerBill 5y ago
I agree with you here 100%. It's empirically true that all these things commonly happen. So the question is how do you mitigate these issues, if there are better alternatives? That's what I've been trying to do with the design of Odin, and try to nudge the user away from any of this nonsense whilst still being enjoyable to program in.