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

41–50 of 167 posts

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

#41

Post by pjmlp »

AnimalMuppet wrote: post #16
tiniuclx wrote: post #2

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

I think it's also how you should pick languages for a project. What is the worst yak-shaving aspect of the code you're going to have to write for this particular project? What language will go the furthest toward making that yak shaving go away? Pick that language.

I pick the languages based on the platform stack I have to use and not the other way around.

Basically the first class languages on a given platform, or having official bindings for a specific set of libraries that must be used.

My experience has proven it is the best path for lowest attrition.

Every time I decided to do otherwise I repented later on.

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

#43

Post by Fellshard »

pjmlp wrote: post #33
atilaneves wrote: post #28

"Popular mainstream languages such as Java or C++ support just one or two separate paradigms" Java, ok. But C++??? That language has everything and the kitchen sink, including pure functional programming (templates).

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

Higher-order functions are extremely constrained given that lambdas boil down to fixed interfaces, and there's very few tools for e.g. partial application and converting between function types. A lot of that is probably due to primitive variants and checked exceptions causing genericity to be extremely limited, so they capped the utility of lambdas in their design.

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

#44

Post by vram22 »

gwright wrote: post #17
jstimpfle wrote: post #5

Earlier quoted context omitted.

Look up the definition of "simple". How exactly do you distinguish "exceptional" from "non-exceptional"?

The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_. His definition depends on the notion of Design by Contract. An exception is an event that causes a function/method to fail because it is unable to satisfy its contract. The caller is then responsible for cleaning things up (so it can satisfy its contract) or it also triggers an exceptio…

>I highly recommend Object Oriented Software Construction.

I do, too. I had read most of the book [1] some years ago. It is really good. But readers should know that they need to be ready to put in enough time to read, understand and digest it, not just because it is a thick book, although it is that, but because, true to Bertrand Meyer's style, it is detailed, systematic, thorough, etc. It's not one of those books where you can read it in a few days and then start applying its stuff to your work, nor is it for casual programmers who are only into the field to make some quick bucks.

[1] https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...

BTW, the book may have an Easter egg in it.

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

#45

Post by pjmlp »

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)

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.

Ah, and Haskell does not require TCO on their language specification, so it isn't an FP language according to your arbitrary definition.

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

#46

Post by pjmlp »

Fellshard wrote: post #43
pjmlp wrote: post #33

Earlier quoted context omitted.

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

Higher-order functions are extremely constrained given that lambdas boil down to fixed interfaces, and there's very few tools for e.g. partial application and converting between function types. A lot of that is probably due to primitive variants and checked exceptions causing genericity to be extremely limited, so they capped the utility of lambdas in their design.

What is relevant is that lambda calculus can be expressed.

Everything else are just variations on "What is FP" and sugar coating.

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

#47

Post by rq1 »

atilaneves wrote: post #28

"Popular mainstream languages such as Java or C++ support just one or two separate paradigms" Java, ok. But C++??? That language has everything and the kitchen sink, including pure functional programming (templates).

http://conal.net/blog/posts/the-c-language-is-purely-functio...

https://news.ycombinator.com/item?id=618817

https://news.ycombinator.com/item?id=9088676

:-)

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

#49

Post by wellpast »

dahart wrote: post #25
de_Selby wrote: post #24

Earlier quoted context omitted.

>I honestly can’t tell if this is a good joke... I'll help out: It's a joke.

For sure? I skimmed the whole thing and couldn’t immediately find any other jokes. Seems an odd choice to throw in one random deadpan comment about the coincidence of 31 being near a power of two.

> Seems an odd choice to throw in one random deadpan comment...

But then again it gives the joke a special nonplussing hilarity that it wouldn’t acquire otherwise.

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

#50

Post by bunderbunder »

pjmlp wrote: post #46
Fellshard wrote: post #43

Earlier quoted context omitted.

Higher-order functions are extremely constrained given that lambdas boil down to fixed interfaces, and there's very few tools for e.g. partial application and converting between function types. A lot of that is probably due to primitive variants and checked exceptions causing genericity to be extremely limited, so they capped the utility of lambdas in their design.

What is relevant is that lambda calculus can be expressed. Everything else are just variations on "What is FP" and sugar coating.

> What is relevant is that lambda calculus can be expressed.

That's a criterion that's so broad as to be almost meaningless, though. The lambda calculus can be expressed in any Turing-complete language.

I wouldn't personally consider a language to support a paradigm unless programming in that paradigm feels natural in that language. Java supports using a few functional techniques. The experience of trying to write in a truly functional style, though, is painful.

Post reply on HN