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

131–140 of 167 posts

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

#131

Post by nisse72 »

sevensor wrote: post #52

> We end our discussion of inheritance with a cautionary tale. In the 1980s, a very large multinational company initiated an ambitious project based on object-oriented programming. Despite a budget of several billion dollars, the project failed miserably. One of the principal reasons for this failure was a wrong use of inheritance. Who did that, exactly?

Based on the footnote I'm fairly certain it was Ellemtel, a joint venture between Ericsson and Televerket (the Swedish national telecom before it was privatised), and the project was AXE-N:

The AXE-N venture was to be the most expensive industrial project in Sweden after Saab’s JAS fighter. One calculation estimates that it cost Ericsson SEK 10 billion. The project has often been described as a total failure.

https://www.ericsson.com/en/about-us/history/changing-the-wo...

Swedish wikipedia has more information: https://sv.wikipedia.org/wiki/AXE-N

Some people here might know Ellemtel from their C++ style guide, which was a byproduct of the AXE-N project. In Emacs "ellemtel" is one of the built in choices for CC Mode style.

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

#132

Post by lysium »

rydel wrote: post #39
pjmlp wrote: post #33

Earlier quoted context omitted.

Even Java, after lambdas and immutable data structures introduction it is quite debatable.

Having lambda doesn’t mean to be FP. One of the core features missing in Java (JavaScript also) is TCO(tail call optimization)

I think the concept you describe is better named tail call eliminiation.

“Optimization” makes it sound as if you could turn it off or on for performance reasons. Instead, programs rely on tail call elimination being in place or otherwise they would not work.

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

#133

Post by gdy »

jstimpfle wrote: post #31
uryga wrote: post #26

Earlier quoted context omitted.

> Exceptions imply a temporal coupling from error occurrence to error handling. Could you expand on this? I understood your statement as "Exceptions sort-of force you to handle an error the moment it occurs", but I'm having trouble seeing why this would be specific to exceptions and not the case with other error handling solutions. (I don't mean to sound like a big exception-defender – I prefer ML/Rust-style Result t…

In some cases immediate action might have to be taken (like calling abort()) but very often that is not the case. Another strategy is to collect errors. Then decide what to do them at another point (no temporal or physical coupling!). After all errors are collected, you can group them, sort them, or aggregate them. Whatever is appropriate. Looking at errors as just data avoids the "exceptional vs non-exceptional" hai…

What are you going to do with the errors once you have collected them?

What is the point of sorting or grouping them?

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

#135

Post by jstimpfle »

gdy wrote: post #133
jstimpfle wrote: post #31

Earlier quoted context omitted.

In some cases immediate action might have to be taken (like calling abort()) but very often that is not the case. Another strategy is to collect errors. Then decide what to do them at another point (no temporal or physical coupling!). After all errors are collected, you can group them, sort them, or aggregate them. Whatever is appropriate. Looking at errors as just data avoids the "exceptional vs non-exceptional" hai…

What are you going to do with the errors once you have collected them? What is the point of sorting or grouping them?

A simple example from the compiler I'm working on right now: I output type errors of expressions sorted by their location in the source file, instead of in the order they are detected. I also don't error out on the first one, but find all at once. I could also group warnings and errors together, output only the first N errors, or... whatever I fancy. Errors are just data.

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

#136

Post by doanguyen »

tabtab wrote: post #83
doanguyen wrote: post #60

With this kind of articles, I just want to thank HN and all of these useful discussions. It's always enlightening moments while reading you guys comments.

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?

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

#137

Post by beaconstudios »

mac01021 wrote: post #128
beaconstudios wrote: post #7

Earlier 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…

You're not being dismissed. You're being corrected. The GP, along with many other people, are trying to get software professionals to standardize on a definition of simple that means something like "composed of a single element; not compound" or "easy to reason about". Under such a standard, it makes no sense to talk about "simple to use" vs "simple to understand". You can talk about "easy to use" vs "easy to underst…

no-one told me about this standard when I entered the industry. If it comes from some blog post that I haven't read, how am I meant to know that some small selection of developers prefer "simple/easy" as a dichotomy? It's not a correction if it's just a different opinion.

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

#138

Post by rydel »

pjmlp wrote: post #45
rydel wrote: post #39

Earlier quoted context omitted.

Having lambda doesn’t mean to be FP. One of the core features missing in Java (JavaScript also) is TCO(tail call optimization)

First of all not all FP languages have TCO, Scheme is probably the only one that actually requires it on its language specification. Secondly stuff like LINQ was already available in Smalltalk. So all those map/filter/fold/.... constructs from lambda calculus, which Java now enjoys. Then if we apply the modern concept of only Haskell is FP, then there are a couple of FP languages that won't meet the classification. A…

It depends. As we know, FP is all about not having side effects. Having “for” loop requires to mutate the pointer of given iteration.

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

#139

Post by jstimpfle »

gnoack wrote: post #104
jstimpfle wrote: post #27

Earlier quoted context omitted.

> Warning: Textual logging is not an error handling strategy. Logs are not meant for machine consumption so it’s hard to have automated monitoring based on them. I'd beg to disagree. As for the general statement of your post, I like how you're talking about stakeholders and (specification) bounds but I don't think it's an actionable viewpoint. The idea of "Bubbling up errors" inside a program is caught in the softwar…

Thanks for the feedback. :) To clarify, in the context of the article, "making errors observable from the outside" is not meant at the per-function level, but meant at the level of the whole program, which includes abort(). I should improve the wording there. abort() is perfectly legitimate if you can't recover within the same process. It's not at odds with routing to the right stakeholder, as long as the parent proc…

OK I had probably skimmed too much but now I think we're just talking about different things here. I like your post, so let's give it another chance: https://news.ycombinator.com/item?id=18390030 :-)

Regarding textual logging, I think it works wonderfully and I don't think it's at odds with schema-ful reporting. One good way is to include error codes. Informal messages are at least as important. They are ergonomic to humans and their meanings are easy to look up with a web search.

Of course textual logging can always be supported by other means, like crash dumps.

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

#140

Post by rydel »

zbuttram wrote: post #95
rydel wrote: post #39

Earlier quoted context omitted.

Having lambda doesn’t mean to be FP. One of the core features missing in Java (JavaScript also) is TCO(tail call optimization)

Just wanted to point out that JS has TCO coming, just a question of if/when engines have it implemented. Looks like Safari/JSCore is pretty much the only one so far though: https://kangax.github.io/compat-table/es6/#test-proper_tail_...

Yes. I am well aware about that. I look forward to TCO/TCE be supported on other platforms.
Post reply on HN