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

151–160 of 167 posts

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

#151

Post by jstimpfle »

gdy wrote: post #150
jstimpfle wrote: post #135

Earlier quoted context omitted.

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.

Well, this example seems somewhat contrived to me because these errors are not the errors happening in the compiler, they are diagnostic messages describing the errors in the input data. Any chance you have another example?

"An error happening in the compiler". What's that? If you mean a bug detected, then it should be handled with abort().

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

#152

Post by gdy »

jstimpfle wrote: post #151
gdy wrote: post #150

Earlier quoted context omitted.

Well, this example seems somewhat contrived to me because these errors are not the errors happening in the compiler, they are diagnostic messages describing the errors in the input data. Any chance you have another example?

"An error happening in the compiler". What's that? If you mean a bug detected, then it should be handled with abort().

An error related to the file system, for example.

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

#153

Post by jstimpfle »

gdy wrote: post #152
jstimpfle wrote: post #151

Earlier quoted context omitted.

"An error happening in the compiler". What's that? If you mean a bug detected, then it should be handled with abort().

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.

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

#154

Post by jstimpfle »

beaconstudios wrote: post #137
mac01021 wrote: post #128

Earlier quoted context omitted.

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.

There is a very popular talk by Rich Hickey (creator of Clojure), "Simple vs easy". Maybe that was what popularized the distinction among many programmers.

It's really not an arbitrary definition if you think about it etymologically. Very freely sim-ple is "unfolded" (c.f. pliers, plier qc). Whereas com-plex is "folded together". "Easy" relates more to a state of ignorance. It's about the user of the thing, not about the thing itself. (NB I'm just making this up. I'm not a linguist so I might be wrong).

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

#155

Post by beaconstudios »

jstimpfle wrote: post #154
beaconstudios wrote: post #137

Earlier quoted context omitted.

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.

There is a very popular talk by Rich Hickey (creator of Clojure), "Simple vs easy". Maybe that was what popularized the distinction among many programmers. It's really not an arbitrary definition if you think about it etymologically. Very freely sim-ple is "unfolded" (c.f. pliers, plier qc ). Whereas com-plex is "folded together". "Easy" relates more to a state of ignorance. It's about the user of the thing, not abou…

it makes sense as a distinction and I'll likely use it going forwards. The only thing I objected to was the idea that this distinction is something I should already know as a programmer. I guess it comes down to a case of separate bubbles/backgrounds, as I've never heard the distinction before in my time in industry and I'd guess it's considered standard jargon within your environment?

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

#156

Post by rydel »

pjmlp wrote: post #148
rydel wrote: post #141

Earlier quoted context omitted.

There are many definitions of FP. IMHO the “no side effects” is the best one. Even Clojure is functional, but partially IMHO, bc it is for JVM which has not been design for FP. And my definition is not an arbitrary one. This is the most broadly one I think. But when you use same word in different contexts, then the word might have different meaning.

Which means OCaml, Common Lisp, Scheme, F#, SML are out of the game as FP languages according to you.

Is I wrote: IMO these language are not fully functional. TCO/TCE is crucial for operations on tree like data structures. And also as I wrote: it all depends in which context we are talking to. Scheme specification makes it clear that TCO/TCE is required. If I am not wrong, F# is the same thing as Scala, but in .Net world(?) - Scala cannot be treaded as clear functional, because it is for JVM which was not designed for functional programming. Surely, many languages can have more or less functional functionalities, but having a subset of properties which defines what is functional, cannot be treated as functional in the full sense.

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

#157

Post by rydel »

charlysl wrote: post #64
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)

According to the pdf's author, the crucial feature of FP is that there is no visible non-determinism. This means that every time you call a function with the same arguments it is guaranteed that you will get the same result. The other key feature is that there are no visible side-effects when calling a function. Tail recursion of course is great to have, but you can certainly FP without it, even in a language that su…

The no non-determinism feature is very good example why TCO/TCE is crucial - each time you call a recursive function the state is changing- another stack is created. Therefore the same function which operates on unknown argument size(list, tree) can have different behavior - stack overflow might happen or not and we don’t know when.

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

#158

Post by jstimpfle »

beaconstudios wrote: post #155
jstimpfle wrote: post #154

Earlier quoted context omitted.

There is a very popular talk by Rich Hickey (creator of Clojure), "Simple vs easy". Maybe that was what popularized the distinction among many programmers. It's really not an arbitrary definition if you think about it etymologically. Very freely sim-ple is "unfolded" (c.f. pliers, plier qc ). Whereas com-plex is "folded together". "Easy" relates more to a state of ignorance. It's about the user of the thing, not abou…

it makes sense as a distinction and I'll likely use it going forwards. The only thing I objected to was the idea that this distinction is something I should already know as a programmer. I guess it comes down to a case of separate bubbles/backgrounds, as I've never heard the distinction before in my time in industry and I'd guess it's considered standard jargon within your environment?

I would assume most HN folks have heard of Rich Hickey and his talks. Surely not all of them have. Learning never ends :-)

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

#159

Post by beaconstudios »

jstimpfle wrote: post #158
beaconstudios wrote: post #155

Earlier quoted context omitted.

it makes sense as a distinction and I'll likely use it going forwards. The only thing I objected to was the idea that this distinction is something I should already know as a programmer. I guess it comes down to a case of separate bubbles/backgrounds, as I've never heard the distinction before in my time in industry and I'd guess it's considered standard jargon within your environment?

I would assume most HN folks have heard of Rich Hickey and his talks. Surely not all of them have. Learning never ends :-)

I knew about him, but haven't seen / heard of his talks.

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

#160

Post by sevensor »

nisse72 wrote: post #131
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:/…

This is the most plausible candidate I've seen suggested.
Post reply on HN