4 ms·

If I've learned anything as a programmer, is that these things move in fashions. People will get sick of result types and exceptions will be hot again. OOP will

If I've learned anything as a programmer, is that these things move in fashions. People will get sick of result types and exceptions will be hot again. OOP will be fashionable once again. The grass is always greener on the other side of the fence.

cmrdporcupine 4y ago
This is quite possibly true, but I feel like exceptions are one of those things... people are just finally cluing into the fact that this is a non-local GOTO, and the consequences for reasoning about program flow can be terrifying, like Djikstra already told us. If exceptions have a "comeback" (they have not gone away in mainstream languages like Java, C#, Python etc.) I hope they come back in a way where they're bundled with static analysis features that help with the reasoning process. When I worked in Java, 10+ years ago, checked exceptions were considered an obnoxious "no-no", and bad style. Mostly because people just wrapped and rethrew them as runtime exceptions. But, like, runtime exceptions are awful, and almost every application I worked in had buckets of garbage in the logs which consisted of uncaught or "caught & logged" exceptions. Such exceptions are particularly troublesome in highly concurrent applications. Exceptions should be exceptional. I think Rust has made the right call here. Handle the error, or panic. Don't make it somebody else's problem.
- xwolfi 4y ago
  Hum, panic as in stop all work ? I like that in Java, units of work can continue after an unhandled exception because you know, sometimes, your software is used by many people in many input variants and say, if you re doing a trading backend, it's bad that you cant fill an order because of a silly parsing bug, but it d be way worse if you had to stop for the day until a dev wakes up and fix it. Log it, and while you fix it the thing still runs for 99% of inputs. Maybe that s what you call "handling" the error ? But it's cool to bubble up the exception because you can share the handler amongst all your downstreams: you may dislike having to do the same exact semi-complex log building everywhere and having it just capture exception at the top most unit of work dispatcher to catch if one threw something to then log and alert your support team in one place, might make sense. Ofc return types can do all that but you contaminate your whole program with handling for bugs you cant well predict the nature off... the only certain thing is that if your program is old and big enough, you'll screw up in innovative ways a general catch will allow to recover from, because you just dismiss the whole input and move to the next.
  - cmrdporcupine 4y ago
    Yes, panic, stop all work. If it's truly an exceptional circumstance, it's unlikely that anything further up can "fix it." Don't even try. Kill the process and restart. Or force the author to fix the bug. If it's an "expected" runtime condition that you can manage and recover from, then it's not "exceptional", is it? So don't use an exception. Pass the information to the caller that needs it, and adjust state accordingly. That's my take these days. I've seen too many systems degrade in cascading failures because of misguided attempts to "recover." Deadlocks, partial failures, explosions, etc. Real fun to diagnose.
    - xwolfi 4y ago
      But what if we need it for critical processes, what if we receive loosely constrained input, what if we want to change it so often that bugs must happen ? (or are you a sort of manager that think bugs can be entirely prevented?) Why are exceptions supposed to be rare ? They re exceptional in the context of what we told the software could happen, but not in the context we're failible humans pissing code as fast as clients can pay us. I never had problem to diagnose a corrupted state following an exception, it's pretty clear. It s much harder to tell dozens of clients that there will no trading in Hong Kong this afternoon because one of them sent an illegal character we didnt think to sanitize, or the exchange inverted two messages against their spec, or a network router dropped a packet. All these are cases I ve seen the last few years, we lost one order in each case, kept the million others trading as normal, handled the potential surprise the next release... Recovery design can be done but you need a strict set of constraints. How do you even recover with a restart after bug fix ? Takes hours just to do, the world has moved on, your states you recovered are useless, you ll sort it the next day ? Maybe imagine a plane software stopping all work because the human pressed two buttons at the same time and the programmer, a human too, forgot this possibility ? Or am I misunderstanding you ? Maybe you work on more one off things like data science when you re the only person interacting with the inputs and outputs ?
- eschaton 4y ago
  This is exactly the Cocoa exception model: Exceptions are treated as assertions, while errors represent things the program or user should be able to act on and recover from. Swift reifies this by not having exceptions at all, just fatal assertions like precondition() and fatalError(), while using try/throw/do/catch for propagation of errors (and making handling them non-optional).
- layer8 4y ago
  I view checked exceptions as syntactic sugar on what could be implemented as result types (as in “Either” result types) behind the scenes. It’s not how they are implemented in Java, but potentially they could. When used in that fashion, they are certainly more ergonomic than explicit result types. Being (type-)checked is crucial for that, of course.
  - cmrdporcupine 4y ago
    Agreed, but back when I worked in Java and I tried to use checked exceptions in my code, team leads and fellow seniors always yelled at me. Still, the catch syntax was very verbose for handling common conditions. Exceptions were the wrong syntactical tool for the job.
- smasher164 4y ago
  Exceptions will come back, but in the form of algebraic effects. All of the work that goes into error handling, asynchrony, mutable state, and IO will be generalized by effects.
  - lmm 4y ago
    Maybe. Algebraic effects have been hyped for about 20 years and all the actual implementations still suck.
    - smasher164 4y ago
      Tbf, I've only seen decent implementations of it over the past couple of years, with Koka and OCaml. There's still work to do to get it to interact nicely with a low-level language, but I'd argue that they're the way forward for newer GC'ed languages.
- mtrower 4y ago
  I would argue that panicking very much makes it somebody else's immediate problem. By this logic, it kind of seems like no function should ever return errors at all -- handle the situation or panic, right? Sure, kicking the ball up the chain out of laziness is, well, laziness. But plenty of times, it's done out of the knowledge (or at least hope) that somebody up the chain has a better idea of how to handle the situation than you do.
- zarzavat 4y ago
  Sometimes a nonlocal goto is exactly what you want. Consider some kind of validator/parser class/function, with a public entrypoint and a bunch of private subroutines that can fail when they hit invalid input: public parse() { try { this.parseX(); this.parseY(); this.parseFoo(); ... } catch (e) { throw new Error(...) } } private parseY() { this.y = this.input.y.map(a => { if (bad data) throw new Error("corrupt data"); ... }) } It's common in such situations to want to have one central point to collect errors in order to produce a single error type result. It is possible to manually thread Results all the way through your logic, but that clutters the code with error handling. Rust's Try operator makes it easier but it's still awkward. Exceptions allow us to concentrate on the two most important parts: where the exceptions are generated, and where they are handled (in this case, the root of the public interface). I definitely agree that exceptions are not perfect. They have their own flaws, especially for public interfaces. But as control flow they are useful in many cases.
agumonkey 4y ago
90s OOP not much but I believe we ran the FP cycle and its ideas have been adopted as much as possible. I think there might be another more mathematical and practical (to cut the verbosity and improve reuse) revival of OO, context/aspect for some bit of meta maybe .. or contracts or multipledispatch.
- cmrdporcupine 4y ago
  I'm holding out for the wave of logic / declarative / relational programming. That's my nerd preference.
  - agumonkey 4y ago
    Oh that could make sense, usually there's the imperative > functional > logic thinking ladder.. and there's scryer, ciao, datalog and a few other logic systems popping up recently. I'd love that too, i'm very much in love with it.
- qualudeheart 4y ago
  I am highly bullish on systems programming. As high performance computing becomes more important, so esoteric hardware will. I work in embedded and see some of this, as have my friends in the ML space. We’ll see the Zigs, Nims and Rusts of the world mature along with special languages for things like tensor processing units. AI will make it much easier for humans to work using those languages.
msla 4y ago
I think some things are fashions and some are lessons learned. For example, English-like syntax is out. Cobol has it because it was invented for its predecessor and Cobol's still around, SQL has it because its designers copied Cobol before we'd learned better, and that's it. We still use words in our syntax but explicit block structure with punctuation is now known to be easier to read. Speaking of block structure: Line numbers are gone. Unrestricted use of goto (as in, using goto to go from anywhere in the program to anywhere else in the program) is also gone. These things aren't fashion: We've learned better. We're more likely to invent a different kind of structure than to go back to that. Similarly, languages with absolutely no type system are also out: You can have the types on variables, like Haskell, or values, like Python, but choosing to have neither, like BLISS and BCPL, is no longer an option unless you're actually writing in assembly language. Other things, like column-oriented formatting, are gone because technology moved on. Even Cobol abandoned that one.

cmrdporcupine 4y ago

This is quite possibly true, but I feel like exceptions are one of those things... people are just finally cluing into the fact that this is a non-local GOTO, and the consequences for reasoning about program flow can be terrifying, like Djikstra already told us. If exceptions have a "comeback" (they have not gone away in mainstream languages like Java, C#, Python etc.) I hope they come back in a way where they're bundled with static analysis features that help with the reasoning process. When I worked in Java, 10+ years ago, checked exceptions were considered an obnoxious "no-no", and bad style. Mostly because people just wrapped and rethrew them as runtime exceptions. But, like, runtime exceptions are awful, and almost every application I worked in had buckets of garbage in the logs which consisted of uncaught or "caught & logged" exceptions. Such exceptions are particularly troublesome in highly concurrent applications. Exceptions should be exceptional. I think Rust has made the right call here. Handle the error, or panic. Don't make it somebody else's problem.

xwolfi 4y ago
Hum, panic as in stop all work ? I like that in Java, units of work can continue after an unhandled exception because you know, sometimes, your software is used by many people in many input variants and say, if you re doing a trading backend, it's bad that you cant fill an order because of a silly parsing bug, but it d be way worse if you had to stop for the day until a dev wakes up and fix it. Log it, and while you fix it the thing still runs for 99% of inputs. Maybe that s what you call "handling" the error ? But it's cool to bubble up the exception because you can share the handler amongst all your downstreams: you may dislike having to do the same exact semi-complex log building everywhere and having it just capture exception at the top most unit of work dispatcher to catch if one threw something to then log and alert your support team in one place, might make sense. Ofc return types can do all that but you contaminate your whole program with handling for bugs you cant well predict the nature off... the only certain thing is that if your program is old and big enough, you'll screw up in innovative ways a general catch will allow to recover from, because you just dismiss the whole input and move to the next.
- cmrdporcupine 4y ago
  Yes, panic, stop all work. If it's truly an exceptional circumstance, it's unlikely that anything further up can "fix it." Don't even try. Kill the process and restart. Or force the author to fix the bug. If it's an "expected" runtime condition that you can manage and recover from, then it's not "exceptional", is it? So don't use an exception. Pass the information to the caller that needs it, and adjust state accordingly. That's my take these days. I've seen too many systems degrade in cascading failures because of misguided attempts to "recover." Deadlocks, partial failures, explosions, etc. Real fun to diagnose.
  - xwolfi 4y ago
    But what if we need it for critical processes, what if we receive loosely constrained input, what if we want to change it so often that bugs must happen ? (or are you a sort of manager that think bugs can be entirely prevented?) Why are exceptions supposed to be rare ? They re exceptional in the context of what we told the software could happen, but not in the context we're failible humans pissing code as fast as clients can pay us. I never had problem to diagnose a corrupted state following an exception, it's pretty clear. It s much harder to tell dozens of clients that there will no trading in Hong Kong this afternoon because one of them sent an illegal character we didnt think to sanitize, or the exchange inverted two messages against their spec, or a network router dropped a packet. All these are cases I ve seen the last few years, we lost one order in each case, kept the million others trading as normal, handled the potential surprise the next release... Recovery design can be done but you need a strict set of constraints. How do you even recover with a restart after bug fix ? Takes hours just to do, the world has moved on, your states you recovered are useless, you ll sort it the next day ? Maybe imagine a plane software stopping all work because the human pressed two buttons at the same time and the programmer, a human too, forgot this possibility ? Or am I misunderstanding you ? Maybe you work on more one off things like data science when you re the only person interacting with the inputs and outputs ?
eschaton 4y ago
This is exactly the Cocoa exception model: Exceptions are treated as assertions, while errors represent things the program or user should be able to act on and recover from. Swift reifies this by not having exceptions at all, just fatal assertions like precondition() and fatalError(), while using try/throw/do/catch for propagation of errors (and making handling them non-optional).
layer8 4y ago
I view checked exceptions as syntactic sugar on what could be implemented as result types (as in “Either” result types) behind the scenes. It’s not how they are implemented in Java, but potentially they could. When used in that fashion, they are certainly more ergonomic than explicit result types. Being (type-)checked is crucial for that, of course.
- cmrdporcupine 4y ago
  Agreed, but back when I worked in Java and I tried to use checked exceptions in my code, team leads and fellow seniors always yelled at me. Still, the catch syntax was very verbose for handling common conditions. Exceptions were the wrong syntactical tool for the job.
smasher164 4y ago
Exceptions will come back, but in the form of algebraic effects. All of the work that goes into error handling, asynchrony, mutable state, and IO will be generalized by effects.
- lmm 4y ago
  Maybe. Algebraic effects have been hyped for about 20 years and all the actual implementations still suck.
  - smasher164 4y ago
    Tbf, I've only seen decent implementations of it over the past couple of years, with Koka and OCaml. There's still work to do to get it to interact nicely with a low-level language, but I'd argue that they're the way forward for newer GC'ed languages.
mtrower 4y ago
I would argue that panicking very much makes it somebody else's immediate problem. By this logic, it kind of seems like no function should ever return errors at all -- handle the situation or panic, right? Sure, kicking the ball up the chain out of laziness is, well, laziness. But plenty of times, it's done out of the knowledge (or at least hope) that somebody up the chain has a better idea of how to handle the situation than you do.
zarzavat 4y ago
Sometimes a nonlocal goto is exactly what you want. Consider some kind of validator/parser class/function, with a public entrypoint and a bunch of private subroutines that can fail when they hit invalid input: public parse() { try { this.parseX(); this.parseY(); this.parseFoo(); ... } catch (e) { throw new Error(...) } } private parseY() { this.y = this.input.y.map(a => { if (bad data) throw new Error("corrupt data"); ... }) } It's common in such situations to want to have one central point to collect errors in order to produce a single error type result. It is possible to manually thread Results all the way through your logic, but that clutters the code with error handling. Rust's Try operator makes it easier but it's still awkward. Exceptions allow us to concentrate on the two most important parts: where the exceptions are generated, and where they are handled (in this case, the root of the public interface). I definitely agree that exceptions are not perfect. They have their own flaws, especially for public interfaces. But as control flow they are useful in many cases.

agumonkey 4y ago

90s OOP not much but I believe we ran the FP cycle and its ideas have been adopted as much as possible. I think there might be another more mathematical and practical (to cut the verbosity and improve reuse) revival of OO, context/aspect for some bit of meta maybe .. or contracts or multipledispatch.

cmrdporcupine 4y ago
I'm holding out for the wave of logic / declarative / relational programming. That's my nerd preference.
- agumonkey 4y ago
  Oh that could make sense, usually there's the imperative > functional > logic thinking ladder.. and there's scryer, ciao, datalog and a few other logic systems popping up recently. I'd love that too, i'm very much in love with it.
qualudeheart 4y ago
I am highly bullish on systems programming. As high performance computing becomes more important, so esoteric hardware will. I work in embedded and see some of this, as have my friends in the ML space. We’ll see the Zigs, Nims and Rusts of the world mature along with special languages for things like tensor processing units. AI will make it much easier for humans to work using those languages.

msla 4y ago

I think some things are fashions and some are lessons learned. For example, English-like syntax is out. Cobol has it because it was invented for its predecessor and Cobol's still around, SQL has it because its designers copied Cobol before we'd learned better, and that's it. We still use words in our syntax but explicit block structure with punctuation is now known to be easier to read. Speaking of block structure: Line numbers are gone. Unrestricted use of goto (as in, using goto to go from anywhere in the program to anywhere else in the program) is also gone. These things aren't fashion: We've learned better. We're more likely to invent a different kind of structure than to go back to that. Similarly, languages with absolutely no type system are also out: You can have the types on variables, like Haskell, or values, like Python, but choosing to have neither, like BLISS and BCPL, is no longer an option unless you're actually writing in assembly language. Other things, like column-oriented formatting, are gone because technology moved on. Even Cobol abandoned that one.