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

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

#141

Post by rydel » Tue, Nov 06, 2018, 11:54 AM UTC

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…

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.

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

#142

Post by rydel » Tue, Nov 06, 2018, 11:57 AM UTC

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…

Java class can be functional also. Depends how you look. If a class doesn’t operates on side effects, but keeps the mutation only inside the class, then the class can be defined as functional. But on the method level it might be not.

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

#143

Post by rydel » Tue, Nov 06, 2018, 1:15 PM UTC

13415 wrote: post #87

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)

Tail call optimization is more or less unimportant, because you can express any recursion with iteration and most of the time the explicitly iterative version is even safer and better. TCO only adds zero-cost for recursions based on tail calls, that's nice to have but recursion is a bit of a hobby-horse of CS professors anyway. It only makes sense in languages that have their own stack, i.e., have no hard stack limit…

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]

#144

Post by pvanroy » Tue, Nov 06, 2018, 3:46 PM UTC

As the author, I must say I really enjoyed your detailed comments and Biblical exegesis on my paper. FYI, your guess on the big OOP failure is correct. Also, the Baskin Robbins footnote is a joke between myself and a physicist friend. The paper is a chapter in a book on computer music published by IRCAM that is worth reading too. Keep up the good work!

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

#145

Post by rydel » Tue, Nov 06, 2018, 6:41 PM UTC

13415 wrote: post #87

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)

Tail call optimization is more or less unimportant, because you can express any recursion with iteration and most of the time the explicitly iterative version is even safer and better. TCO only adds zero-cost for recursions based on tail calls, that's nice to have but recursion is a bit of a hobby-horse of CS professors anyway. It only makes sense in languages that have their own stack, i.e., have no hard stack limit…

Another thing about recursion is that it is really powerful for operation on tree like data structures/objects

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

#146

Post by pjmlp » Tue, Nov 06, 2018, 6:50 PM UTC

rydel wrote: post #138

pjmlp wrote: post #45

Earlier quoted context omitted.

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.

Oh, and I thought all these years that OCaml was a FP language, go figure!

    open Printf;;

    printf "After all OCaml isn't a FP language\n";
    for idx = 1 to 10 do
        printf "%d\n" idx
    done

Same goes to Common Lisp, F#, Scala, Clojure.

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

#147

Post by pjmlp » Tue, Nov 06, 2018, 6:52 PM UTC

rydel wrote: post #143

13415 wrote: post #87

Earlier quoted context omitted.

Tail call optimization is more or less unimportant, because you can express any recursion with iteration and most of the time the explicitly iterative version is even safer and better. TCO only adds zero-cost for recursions based on tail calls, that's nice to have but recursion is a bit of a hobby-horse of CS professors anyway. It only makes sense in languages that have their own stack, i.e., have no hard stack limit…

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

As replied on another thread, you just killed a couple of FP languages with that definition.

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

#148

Post by pjmlp » Tue, Nov 06, 2018, 6:58 PM UTC

rydel wrote: post #141

pjmlp wrote: post #45

Earlier quoted context omitted.

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…

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.

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

#149

Post by nybble41 » Tue, Nov 06, 2018, 7:14 PM UTC

pjmlp wrote: post #147

rydel wrote: post #143

Earlier quoted context omitted.

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

As replied on another thread, you just killed a couple of FP languages with that definition.

Those are not FP languages. They are, at best, "functional-first" multi-paradigm languages. (Common Lisp and Scheme are in this category.) Unfortunately, FP is more about what is excluded (side effects) than what is included (closures, continuations, sum types, etc.), so mixing FP with any amount of imperative/procedural code tends to result in an awkward and less efficient form of imperative programming without the primary benefit of FP (referential transparency).

The "function" in "functional programming" refers to mathematical functions, which are fixed mappings from inputs to results with no side effects. If your "functions" can have side-effects then they're not functions, they're procedures. Programs composed of effectful procedures are imperative, not functional.

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

#150

Post by gdy » Tue, Nov 06, 2018, 11:45 PM UTC

jstimpfle wrote: post #135

gdy wrote: post #133

Earlier quoted context omitted.

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.

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?