3 ms·
I think it works both ways. There are inherently some changes that are extremely hard to make to a well-constructed functional program, and there are equally s
by DarkShikari 17y ago
I think it works both ways.
There are inherently some changes that are extremely hard to make to a well-constructed functional program, and there are equally some changes that are hard to make to a well-constructed procedural program.
I would hypothesize there is no language paradigm in existence that provides optimal efficiency for implementing all possible types of architecture changes.
- gruseom 17y agoI think what you're saying here is close to what the OP is arguing. The title obscures this a little bit, but it's clear from the second paragraph that he's arguing against purely functional programming.
- omouse 17y agoYour hypothesis would be correct because languages only scratch the surface of thought. The underlying computations invoked are the important thing and you must understand them before you implement them, no matter which language you're using. Obviously some languages are easier to work with and give you better abstractions to work with making it quicker to write the code but you still have to understand what the heck it is you're really trying to do.
- ajross 17y agoI think the first part of your hypothesis is correct, but not quite the second. Most imperative languages support deep recursion and reentrancy, which means that they're a proper superset of (most of) functional languages. You may need to create a "closure" by hand and pass it around, but there's nothing that's fundamentally impossible. The example in the article about adding a side effect and cross-dependency to a deep function really isn't possible in functional terms without changing the design (i.e. adding the state to the function's interface).