61–70 of 167 posts
What utter rubbish. This type of paper has no place in a professional environment.
Could you give some reasons for your statement? Why do you think it's rubbish?
/s.
Earlier quoted context omitted.
> 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…
Thing is, what does actually "The experience of trying to write in a truly functional style" mean in practice. FP Lisp/Scheme, FP ML, FP Haskell/Miranda, FP Idris, FP Scala, FP Kotlin, FP OCaml, FP ATS, FP .... ? All of them express different views of what Functional Programming is supposed to be like.
"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).
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)
Tail recursion of course is great to have, but you can certainly FP without it, even in a language that supports it. I mean, what if you don't put the recursive call in tail position in a function written in a language that supports tail recursion? It would still be FP.
> object-oriented programming is best for problems with a large number of related data abstractions organized in a hierarchy
In OO books, maybe. In practice, OO is the way to compose very large systems out of big components. For hierarchies of data abstractions, very often OO is far from best.
> Popular mainstream languages such as Java or C++ support just one or two separate paradigms.
They support most of them, esp. modern C++, and C#. E.g. quite recently I was programming C++ in monotonic data flow paradigm, because MS media foundation.
> 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?
What utter rubbish. This type of paper has no place in a professional environment.
Could you give some reasons for your statement? Why do you think it's rubbish?
Of course, many programmers would never need this stuff and many have no formal qualifications but they still produce what they need to without problems. They certainly do not need to know about paradigms vs concepts vs models etc. even if it is interesting.
Of course, there ARE people who need to know this stuff to do their job well but they are quite up the food chain compared to most of us. They might also be corporate, who of us sits down and thinks, shall I do this in OO or functional? Which paradigm fits? Most of us know few languages and use what we know.
Earlier quoted context omitted.
Does C++ support lazy evaluation?
templates are lazily evaluated
At runtime? like Scheme?
Earlier quoted context omitted.
A rather odd example with Result type systems: Say you have a function that returns the results of three other functions together in a tuple and the first one errors. The other two can still run and their result can be returned in the tuple along with an Error for the first function.
Ah, so using Result types you can return `(Optional , Optional , Optional )` – each can fail or succeed independently. But you can't do that if you're using exceptions to signal errors – it's like returning `Optional ` , you get either all the results or nothing. Good example, thanks!
function f (...) {
val a = something.a();
val b = something.b();
val c = something.c();
return (a,b,c);
}
function f(...) {
val a = default_a;
val b = default_b;
val c = default_c;
try {
a = something.a();
} catch {
a = error_value_a;
}
...
}