111–120 of 167 posts
> 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?
I have read CTM, the author's book. He did in fact dislike the word "paradigm" and prefered "computation model" instead. A model is a set of concepts. A concept is an orthogonal language feature, like closures, concurrency, explicit state (which he now calls named state), exceptions, etc. His approach is not so much that you should select one language that supports a paradigm that seems the most suitable for a given…
Working in mostly Java shops the last 10 years has shown me that most programmers only know how to add complexity, and not restrict themselves to any strict subset of features. Spring is a good example of this - statically defined, decoupled configuration has morphed into everything configured with the full expressiveness of the host language.
I feel like a curmudgeon when no one seems to understand my preference for well defined boundaries.
Earlier quoted context omitted.
There's a whole lot of stuff you can do, short of writing interpreters, to construct library-level support for a paradigm in a language that lacks language-level support for that paradigm. For example, I would say that GTK+ is written in an object-oriented style. But, despite that, I would not say that OOP is a member of C's repertoire of language paradigms.
That is true, some languages are sufficiently expressive to allow other paradigms to be used within them even though they aren't baked in. But it's not true that all languages can support all paradigms (either directly in the language as designed, or indirectly via library support). OO languages and functional languages support each other's paradigms (more easily) than a pure imperative language would support either.…
And this is extremely relevant to the point. If the primary complaint against function programming in Java is "comfort" and "boilerplate"... Macros address both those problems very well. If Java had macros, it would be very simple to isolate and minimize that boilerplate.
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…
TCO isn't about recursion; it applies to any function call in tail position. Some toolchains only manage to avoid over-allocating stack frames for self-recursive tail calls, but that isn't full TCO, and it doesn't help for other interesting case like mutual recursion, state machines, or continuation-passing style. Compilers which compromise on full support for TCO emit programs with built-in memory leaks; they fail to free data which is no longer needed, and thus unnecessarily exhaust their stack allocation.
Programs which use built-in iterative constructs are still recursive; all that "recursion" means is that the control flow folds back on itself. A traditional "while" loop looks like: (1) stop if a condition is false; (2) otherwise do something; (3) do it again. The "it" in (3) is a recursive reference to the loop.
Now, unstructured explicit recursion is barely better than unstructured "goto", so I'm not advocating that everyone start using tail calls in place of loops. However, bare loops are in much the same position with respect to higher-order primitives such as non-strict folds—and those higher-order primitives are much easier to implement in environments which properly support TCO. Languages where TCO is not customary tend to suffer from a proliferation of built-in constructs—iteration, generators, list comprehensions, coroutines, and the like are all implemented as language features requiring custom code generation, where another language where TCO is customary might relegate such primitives to a library.
Earlier quoted context omitted.
That is true, some languages are sufficiently expressive to allow other paradigms to be used within them even though they aren't baked in. But it's not true that all languages can support all paradigms (either directly in the language as designed, or indirectly via library support). OO languages and functional languages support each other's paradigms (more easily) than a pure imperative language would support either.…
> It's also worth pointing out that C++ really achieved OO (initially) by using macros on top of C. And this is extremely relevant to the point. If the primary complaint against function programming in Java is "comfort" and "boilerplate"... Macros address both those problems very well. If Java had macros, it would be very simple to isolate and minimize that boilerplate.
I have read CTM, the author's book. He did in fact dislike the word "paradigm" and prefered "computation model" instead. A model is a set of concepts. A concept is an orthogonal language feature, like closures, concurrency, explicit state (which he now calls named state), exceptions, etc. His approach is not so much that you should select one language that supports a paradigm that seems the most suitable for a given…
For people like me that didn't know: CTM stands for Concepts, Techniques, and Models of Computer Programming. More info here: https://www.info.ucl.ac.be/~pvr/book.html Seems like a very interesting read!
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.
Earlier quoted context omitted.
> It's also worth pointing out that C++ really achieved OO (initially) by using macros on top of C. And this is extremely relevant to the point. If the primary complaint against function programming in Java is "comfort" and "boilerplate"... Macros address both those problems very well. If Java had macros, it would be very simple to isolate and minimize that boilerplate.
Java emulates macros via annotations and compiler plugins.
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…
Recursion is great, IMHO, as a non-professor type. It allows for much clearer expressions of intent for my methods and functions than the iterative version often achieves. There are some recursive structures that are just much more natural than their iterative counterparts. Parsing (as lysium suggests in the sibling post), for example. But also things like graph and tree traversals, and many search algorithms related…