4 ms·
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 concep
by charlysl 8y ago
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 project. Rather, what he advocates is that you should use a language that supports multiple cleanly separated concepts (close to what is called multiparadigm), and then you select the simplest set of concepts for each program component.
This is the principle of least expresiveness, you should choose the simplest model (simple meaning that it is easy to reason about and to get right) that keeps the code natural (meaning there is little code unrelated to the problem at hand, little plumbing).
Each model has an associated set of programming techniques, like accumulators for FP or transactions for stateful concurrency.
It is possible to mix and match components that are written in different models by using impedance matching, which consists of creating an abstraction in the more expressive model that wraps the other component. An example would be a serializer, which allows you to plug a non concurrent component in concurrent program.
Basically, you should use FP as much as you can, but you can't if your program needs, say, visible non-determinism, like a server in a client-server application. But then you can add just one concept, ports, to the declarative concurrent model, and you have a new model that allows a whole constellation of new programming techniques, the concurrent message passing model, Erlang-like. The non-determinism in this model is restricted to the ports, the only place where it's required, the rest of the program can still be functional.
Other situations where FP might get stretched are when modularity or performance are a priority.
This book helped me realize the whole FP vs OO debate is sterile, the ideal is to have a language that allows you to use FP in a natural way, and switch to, say, OO, in a natural way in some cases.
- billfruit 8y agoCTM has a wonderful premise; and unlike SICP, it does not aim to be freshman text book, and hence can jump headlong into the depth of the matter. Though I could'nt progress after a while, when they started to use a difference-list method, to achieve a semblance of stateful behaviour while using a declarative model. I couldn't understand that till until I later studied some Prolog.
- suprfnk 8y agoFor 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 https://www.info.ucl.ac.be/~pvr/book.html Seems like a very interesting read!
- karakot 8y agoI'd say the book itself is on par with SICP (if you can deal with Oz IDE).
- tabtab 8y agoThe problem with "choose the best paradigm/computational-model for the job" is that mastering each of the possibilities takes a lot of time for the average programmer. It may be better to master a few than spend so much extra time mastering them all. I have accused some academics of "promoting ideas that require more education" so as to line their wallet. It didn't go over well and I got counter-accused of "promoting mediocrity" so that "my type" don't have to learn. (I don't believe such bias is intentional, just human nature. We are all biased in ways we don't know just by the fact we only live one life.) Rather than delve back into that bitter debate, I ask that people consider the economics of it: is it better on a macro-economic scale to spend extra education to master many paradigms/techniques, or to settle on a few to get through school/training faster? (There's always going to be niches that need specialized training/skills.) The average programming career is relatively short-lived: you either have to move into management, analysis, project planning, etc. or be subject to agism. For good or bad, the industry doesn't "like" old programmers. RSI (wrist problems) is also common with seasoned programmers. Thus, I believe the shorter-education approach is the economically logical one. You are welcome to disagree.
- imh 8y agoPerhaps if most everything an industry uses is learned in college, you're setting that industry up for a low skill cap and thus maybe ageism. Anyways, if someone can get more done by using skills XYZ, maybe they'll outcompete firms not using it, and now we all have to learn XYZ or be relegated to more junior positions ¯\_(ツ)_/¯
- tabtab 8y agoRe: if someone can get more done by using skills XYZ, maybe they'll outcompete firms not using it... Some orgs might be, but they are better off hiding their secret from competitors, and thus we are not likely to hear about it. Warren Buffett often expresses shock that universities and investment organizations ignore his well-published techniques, following BS and fads instead. He and other "value investors" have big bucks lasting decades to prove it; they don't. They only have silver words and catchy-sounding theories. IT is the same, I'm afraid to say. The GREAT LIE of IT is that there's not a lot of real science in "computer science", beyond machine efficiency. It's much easier to do science and math to test and measure machines than it is the human mind, but code is meant for the human mind as much as machines. Humans make, read, and modify software, not machines: computers are just dumb automatons (hopefully) following instructions verbatim.
- jonhohle 8y ago> Rather, what he advocates is that you should use a language that supports multiple cleanly separated concepts (close to what is called multiparadigm), and then you select the simplest set of concepts for each program component. 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.