Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
1–10 of 167 posts
Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
#2An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program.
Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patterns redundant? Looking at Rust through this lens makes it clear that it aims to eliminate C-style manual memory management.
However, it does make me wonder: How do languages such as JavaScript and Python stand out from their predecessors, and what problems do they uniquely solve?
Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
#3An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program. Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patt…
> exceptions
> simplifying
Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding...
A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests.
An even better (but orthogonal) way is to structure the code so it does only one thing at a time, and does any one thing only in one place (ideally).
Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
#4An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program. Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patt…
> exceptions > simplifying Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding... A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests. An even better (but orthogonal) way is to structure the code so it does onl…
compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.
Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
#5Earlier quoted context omitted.
> exceptions > simplifying Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding... A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests. An even better (but orthogonal) way is to structure the code so it does onl…
compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.
Look up the definition of "simple".
How exactly do you distinguish "exceptional" from "non-exceptional"?
Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
#6Earlier quoted context omitted.
> exceptions > simplifying Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding... A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests. An even better (but orthogonal) way is to structure the code so it does onl…
compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.
Don't mix up simple and easy, they are orthogonal concepts.
Exceptions are in no way simpler than C-style error codes, but in many cases they might be easier to work with.
Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
#7Earlier quoted context omitted.
compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.
Look up the definition of "simple". How exactly do you distinguish "exceptional" from "non-exceptional"?
> Look up the definition of "simple".
There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise.
I would say exceptional is a situation that is rare and unexpected. When saving a record to a table with a unique constraint, I would expect the constraint to prevent saving but I would not usually attempt to handle/recover the app running out of memory.
So it's situational and I'd say the distinction is between whether you will be explicitly handling the event as part of normal behaviour. The more stable the app needs to be, the more situations need to be handled.
Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
#8Earlier quoted context omitted.
Look up the definition of "simple". How exactly do you distinguish "exceptional" from "non-exceptional"?
> Look up the definition of "simple". There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. I would say exceptional is a situation that is rare and unexpected. When saving a record to a table with a unique constraint, I would expect the constraint to prevent saving but I would not usually attempt to handle/recover the app running out of memory. So it's situational and I'd…
I agree and I think the conclusion is that it's up to the caller to decide what is exceptional. But unfortunately it's the callee who decides how the result is returned.
And it's not only the caller, but also the caller of the caller, and so on, who needs to be prepared for exceptions. This all has severe ramifications on the code structure.
> There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise.
Sorry. I need to control myself. It's not about you. As another commenter stated there is an agreed upon distinction between simple and easy. The distinction is important especially among programmers, and what you described might be easy but it's not simple.
Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
#9Earlier quoted context omitted.
> Look up the definition of "simple". There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. I would say exceptional is a situation that is rare and unexpected. When saving a record to a table with a unique constraint, I would expect the constraint to prevent saving but I would not usually attempt to handle/recover the app running out of memory. So it's situational and I'd…
I agree and I think the conclusion is that it's up to the caller to decide what is exceptional. But unfortunately it's the callee who decides how the result is returned. And it's not only the caller, but also the caller of the caller, and so on, who needs to be prepared for exceptions. This all has severe ramifications on the code structure. > There's no need to be dismissive. I refer to simple as simple to use, not…
agreed, there are better ways to handle such circumstances (such as an Either/Validation monad). But I still think exceptions are better than error codes. If you don't handle an error code, you can proceed through your application in an invalid state. If you don't handle an exception, the application crashes out. I think the latter is preferable in most circumstances.
Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]
#10Earlier quoted context omitted.
compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.
Don't mix up simple and easy, they are orthogonal concepts. Exceptions are in no way simpler than C-style error codes, but in many cases they might be easier to work with.
simple to use versus simple to understand. I was referring to the former.