91–100 of 167 posts
Earlier quoted context omitted.
True. But I think that you can generally break them down into a few broad categories of functional style, and none of them can be followed comfortably in Java.
Comfort is not a programming paradigm. Just because only might need a bit more boilerplate for currying or partial applications, doesn't prevent writing FP libraries in modern Java.
Earlier quoted context omitted.
You realize that the book it's excerpted from is considered one of the more important computer science texts? You're going to have to offer a great deal more useful critique than "utter rubbish" to gain any meaningful agreement here.
Actually, the chapter is based on CTM, but seems to be from a more recent work. "This chapter is partly based on the book [50], familiarly known as CTM, which gives much more information on many of the paradigms and concepts presented here. But this chapter goes further and presents ideas and paradigms not covered in CTM." I poked around a bit on Van Roy's website, but couldn't find the source. It would be interestin…
Earlier quoted context omitted.
I would have guessed Plan 9 just from the timing, but I'm not sure the failure there was due to the wrong use of inheritance.
My guess would be Ada. "Billions of dollars" => Government/DoD is involved.
Unless a survivor of the project can chime in, I'm going indulge in a little idle speculation and agree that defense sounds like a good candidate for losing a billion dollars. Maybe not DoD itself, but a big contractor?
Earlier quoted context omitted.
True. But I think that you can generally break them down into a few broad categories of functional style, and none of them can be followed comfortably in Java.
Comfort is not a programming paradigm. Just because only might need a bit more boilerplate for currying or partial applications, doesn't prevent writing FP libraries in modern Java.
Disregarding “comfort”, or rather, how much the language lends itself to a style, makes the notion of programming paradigms meaningless, and we’re still left with something we all know exists, but have no way to express.
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)
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…
The 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…
Earlier quoted context omitted.
Comfort is not a programming paradigm. Just because only might need a bit more boilerplate for currying or partial applications, doesn't prevent writing FP libraries in modern Java.
But since its all turing complete... this can be said of anything. There’s nothing stopping you from doing OOP in haskell, or functional in C, or procedural in prolog, if you’re willing to put in the effort. Disregarding “comfort”, or rather, how much the language lends itself to a style, makes the notion of programming paradigms meaningless, and we’re still left with something we all know exists, but have no way to…
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…
The 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…
So, is the increased expressiveness worth the decreased predictability? For one developer, it probably is worth it. For a large team distributed over space and time, it probably isn't, even if everyone is comfortable with each individual paradigm.
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…
The 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…
I won't dispute the problems in the industry, but I'm not sure you can really say the career is relatively short-lived. I've been at it for 20 years, and while there are far fewer of my age-peers than there are of younger coders, the number is also far from zero. The "requirement" that you move to a related field doesn't seem nearly as certain as when I was younger (I've avoided all efforts at moving away from coding itself with only minimal effort on my part), and just landed a new job pretty effortlessly.
In terms of the topic, I agree that newer coders should tackle a bunch of problems in a few different approaches rather than trying to master them all from the start (I certainly haven't, even as an old fogey), but in terms of troubles I've found lack of free time/energy to do so to be the bigger obstacle rather than no longer being a programmer. Then again, the problem I see most among younger coders is not trying to master everything and failing, it's treating everything as a nail for their single hammer.
My anecdotal experience is not data, but it is all I have right now: Do you have a stronger source of information that the "average programming career is relatively short-lived"? I've been at this for 20ish years and currently expect another 20 more, but if that's foolish I'd like to know for (reasonably) certain.