Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

info.ucl.ac.be

Post reply on HN
Print view View original

161–167 of 167 posts

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#161

Post by gdy »

jstimpfle wrote: post #153
gdy wrote: post #152

Earlier quoted context omitted.

An error related to the file system, for example.

A file system error isn't an error happening in the compiler . The file system is an external system. So this error isn't really any different than a syntax error or type error. I would not treat it differently except making a different error message. Of course you cannot parse a file you cannot read, so there is a dependency which means that sooner or later you need to "act" on the error.

Well, grouping errors in your example makes sense when all of them happened during processing a particular input which is expected to be invalid sometimes.

Could you share another example where accumulating errors makes sense?

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#162

Post by jstimpfle »

gdy wrote: post #161
jstimpfle wrote: post #153

Earlier quoted context omitted.

A file system error isn't an error happening in the compiler . The file system is an external system. So this error isn't really any different than a syntax error or type error. I would not treat it differently except making a different error message. Of course you cannot parse a file you cannot read, so there is a dependency which means that sooner or later you need to "act" on the error.

Well, grouping errors in your example makes sense when all of them happened during processing a particular input which is expected to be invalid sometimes. Could you share another example where accumulating errors makes sense?

You can do it with anything. Analyze all the files in a directory, for instance. Do all the IO in parallel and merge the results at a central point. Some files might be corrupt or whatever. Merge the results at a central point. Only then present them to the user in a sensible order.

A real life example: Asynchronous webservers usually have worker threads for I/O. I/O errors need to be routed to the originators of the I/O requests (which are in other threads). Exceptions cannot do that.

Here's the general point: Whether any given thing is an "Error" is highly subjective and context dependent. But clearly the error is data, so why take away the possibility to process it like any other data?

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#163

Post by gdy »

jstimpfle wrote: post #162
gdy wrote: post #161

Earlier quoted context omitted.

Well, grouping errors in your example makes sense when all of them happened during processing a particular input which is expected to be invalid sometimes. Could you share another example where accumulating errors makes sense?

You can do it with anything. Analyze all the files in a directory, for instance. Do all the IO in parallel and merge the results at a central point. Some files might be corrupt or whatever. Merge the results at a central point. Only then present them to the user in a sensible order. A real life example: Asynchronous webservers usually have worker threads for I/O. I/O errors need to be routed to the originators of the…

This is an interesting conversation for me, but I still don't quite understand your reasoning.

IMO, using exceptions doesn't preclude treating errors as data.

In your example with parallel processing, you could throw an error as exception, let it unwind the whole stack, catch it and return as the result of the task.

This way you don't couple the code that does the useful work with the code that handles errors.

In other words, I don't understand why you dislike exceptions.

IMO they are a good tool for any task that doesn't require different actions to handle different errors.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#164

Post by jstimpfle »

gdy wrote: post #163
jstimpfle wrote: post #162

Earlier quoted context omitted.

You can do it with anything. Analyze all the files in a directory, for instance. Do all the IO in parallel and merge the results at a central point. Some files might be corrupt or whatever. Merge the results at a central point. Only then present them to the user in a sensible order. A real life example: Asynchronous webservers usually have worker threads for I/O. I/O errors need to be routed to the originators of the…

This is an interesting conversation for me, but I still don't quite understand your reasoning. IMO, using exceptions doesn't preclude treating errors as data. In your example with parallel processing, you could throw an error as exception, let it unwind the whole stack, catch it and return as the result of the task. This way you don't couple the code that does the useful work with the code that handles errors. In oth…

Exceptions are not just data, at least not if you do not always catch them immediately (in which case they are just pointless).

They introduce additional control paths which are hard to reason about. In many languages these are not even explicit. Exceptions require an additional syntax to handle them. And having exceptions requires significant language infrastructure and comes with a huge toll on the structure of software projects. See my topmost comment.

> In your example with parallel processing, you could throw an error as exception, let it unwind the whole stack, catch it and return as the result of the task.

Which would catch only the first encountered error per thread. And not catch all the other errors that we could encounter and report after that.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#165

Post by gdy »

jstimpfle wrote: post #164
gdy wrote: post #163

Earlier quoted context omitted.

This is an interesting conversation for me, but I still don't quite understand your reasoning. IMO, using exceptions doesn't preclude treating errors as data. In your example with parallel processing, you could throw an error as exception, let it unwind the whole stack, catch it and return as the result of the task. This way you don't couple the code that does the useful work with the code that handles errors. In oth…

Exceptions are not just data, at least not if you do not always catch them immediately (in which case they are just pointless). They introduce additional control paths which are hard to reason about. In many languages these are not even explicit. Exceptions require an additional syntax to handle them. And having exceptions requires significant language infrastructure and comes with a huge toll on the structure of sof…

Well, if you don't have exceptions, stack unwinding, RAII, you've got to manually code the same sort of logic using repetitive code. Or you would have to change your design to minimise the pain of hand-coding stack unwinding, most likely paying a price for that in form of damaging other aspects of design. In other words, NOT having exceptions, IMO, results in having to write a huge amount of code accomplishing a trivial task - aborting some unit of functionality upon unexpected error.

"And not catch all the other errors" I think, in most cases after an unexpected error happens it doesn't make sense to continue the task and report more errors, most likely induced by the first error.

Don't get me wrong, there are plenty of cases when returning errors as values is the best fit and using the exceptions would be a disaster, but my point is that, IMO, the situation when errors abort tasks and are handled in more or less the same way is much more common.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#166

Post by tabtab »

doanguyen wrote: post #136
tabtab wrote: post #83

Earlier quoted context omitted.

Re: "always enlightening moments [reading your] comments." Not always : I'm a jerk 22.7% of the time.

I'm curious where's 22.7% comes from?

I'm not telling you because today I happen to be a jerk.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#167

Post by norswap »

wrycoder wrote: post #90
macintux wrote: post #77

Earlier quoted context omitted.

You realize that the book it's excerpted from is considered one of the more important computer science texts? You're going to have to offer a great deal more useful critique than "utter rubbish" to gain any meaningful agreement here.

Actually, the chapter is based on CTM, but seems to be from a more recent work. "This chapter is partly based on the book [50], familiarly known as CTM, which gives much more information on many of the paradigms and concepts presented here. But this chapter goes further and presents ideas and paradigms not covered in CTM." I poked around a bit on Van Roy's website, but couldn't find the source. It would be interestin…

It's from here: https://www.amazon.com/New-computational-paradigms-computer-...

As attested by this: http://lambda-the-ultimate.org/node/3465 and the author's own intervention in these comments.

Post reply on HN