What always bothers me about posts like this is the lack of respect for history. While I agree with the author that these abstractions are superior to the code snippets given, the abstractions are far older than Underscore, or Javascript.
But, an astute reader, says “who cares?” You just don’t like JS and are grumpy that a JS library is getting credit. And who gets credit for the ideas doesn’t matter, it’s the ideas that do.
In that regard, one is correct. The origin of the ideas are orthogonal to their value. But I think this represents a serious problem in software engineering: very few people take the time to read and understand the classics. Many people consider software engineering a creative process rather than an engineering process. And in some respect they are right but in general I believe this to be an excuse for not wanting to take the time to study the fundamentals.
Even beyond the classics, I often wonder how many ideas remain lost in PhD theses, etc. and not yet widely acknowledged, even by academia. It’s sort of bittersweet when someone rediscovers something decades later as “new” only to later learn of the earlier research.
I don’t think your rant is tangential at all. It’s all I could think about while reading this article: This is great stuff, and I’m glad the author is promoting it. But it’s upsetting to think of how badly our industry fails to train people, that someone would have only heard of composable collections because of underscore. :(
The field moves fast enough that reading the classics is rarely a good time investment; a lot of the problems that were focussed on at that time are irrelevant now. To the modern reader, underscore is likely to be a more efficient way of learning these ideas than their original sources. What exactly is the “serious problem in software engineering” that you see? Do you think this author would have learned faster or better from “the classics”?
I have to disagree with you. The field does not move particularly fast. This post could have been written in the 1970’s, which was very much a golden era in computer science research. Much of our understanding of distributed systems and databases comes from the 1970’s and 80’s. Program architecture as well, consider DL Parnas' paper On the Criteria to Be Used in Decomposing Systems into Modules from 1972. A small treatise that many developers still don’t follow, IME, due to ignorance rather than actually disagreeing with the paper. Much of the lessons from The Mythical Man-month have been ignored as well. SICP was first published in 1985. The System F type system was discovered in the 70’s yet there are are no mainstream languages with such powerful type systems. The actor model was created in the 1970’s, yet only recent is really getting attention. Much of our understanding of concurrency is decades old despite concurrency only recently becoming a first-class citizen in popular languages. The list goes on.
To be clear, I am not attempting to disparage the original article, I’m lamenting that this article represents idea that are decades older than it and it’s a shame that the ideas are not so engrained in modern developers that someone feels it’s worthwhile to write such an article.
This field does not move particularly fast when it comes to fundamental issues like those discussed in this post. I agree that it’s helpful to see classic concepts applied to familiar contexts, but I think that usually the classics are more enjoyable to read.
That said, the “classic concepts” discussed in this post are map, separation of concerns, higher-order programming, and programming by transforming streams. What “classic” (by which I mean “old”) texts would others here recommend for introducing those concepts? SICP, I guess?
It is important to cite the original research. Underscore and its follow on libraries seemed more about staking out a territory than solving a problem. Not citing sources is disingenuous at best.
I would argue reading the original research, which is directed at conveying an idea is better than reading the source to a library that brings functional programming into an imperative language.
I disagree, when someone puts in hundreds of hours of work into a functional programming library but puts no effort to communicate where the ideas came from is disingenuous. People making stuff and doing no research into what is preceded it or is comparable is not right.
Nearly everything should have a bibliography, not for credit, but to elucidate the graph of knowledge. When people haven’t put the minimal effort needed to see how their creation fits into the existing body of knowledge …
“Doing no research”, while indeed suboptimal behavior, is not at all the same as “intentionally deceiving people”. I wouldn’t even go so far as to say that “doing no research” is unethical, just dumb. But maybe that’s because I’ve been guilty of doing no research many times…
In the See Also section of the readme it should be SOP to put similar projects, inspiration or a call for more info. If one actually thinks something is novel they should say so. Not naming names, but I have come across quite a few projects that seemed like they were breaking new ground, when in fact it was a port from a library in a lesser used language.
I do not. In my professional work, I am sure to cite as much as I can. Not only does it help educate the customer, but it reduces the amount question and answer I have to do. Reference the existing systems, explain why you are different or the same and move on. If an open source app has the same architecture as an internal app, I’ll reference the relevant blog posts.
I used to be bummed when I find that someone has released a project that was similar to my own. Now I get excited and dig in a dissect it with interest.
I do have an upcoming project that will make it onto lobsters, including the bibliography.
Interestingly, Alexander Schepanovski’s “green code” corresponds to Raganwald’s Penny-Wise green code, while his “red code” and “blue code” are Raganwald’s “yellow code”. Raganwald’s “red code” doesn’t make an appearance in this post.
Because both articles are clearly classics, I predict that this is going to add confusion to future discussions about what color code is.
Tangental rant:
What always bothers me about posts like this is the lack of respect for history. While I agree with the author that these abstractions are superior to the code snippets given, the abstractions are far older than Underscore, or Javascript.
But, an astute reader, says “who cares?” You just don’t like JS and are grumpy that a JS library is getting credit. And who gets credit for the ideas doesn’t matter, it’s the ideas that do.
In that regard, one is correct. The origin of the ideas are orthogonal to their value. But I think this represents a serious problem in software engineering: very few people take the time to read and understand the classics. Many people consider software engineering a creative process rather than an engineering process. And in some respect they are right but in general I believe this to be an excuse for not wanting to take the time to study the fundamentals.
Even beyond the classics, I often wonder how many ideas remain lost in PhD theses, etc. and not yet widely acknowledged, even by academia. It’s sort of bittersweet when someone rediscovers something decades later as “new” only to later learn of the earlier research.
Anyway, now I am even more off topic.
I don’t think your rant is tangential at all. It’s all I could think about while reading this article: This is great stuff, and I’m glad the author is promoting it. But it’s upsetting to think of how badly our industry fails to train people, that someone would have only heard of composable collections because of underscore. :(
The field moves fast enough that reading the classics is rarely a good time investment; a lot of the problems that were focussed on at that time are irrelevant now. To the modern reader, underscore is likely to be a more efficient way of learning these ideas than their original sources. What exactly is the “serious problem in software engineering” that you see? Do you think this author would have learned faster or better from “the classics”?
I have to disagree with you. The field does not move particularly fast. This post could have been written in the 1970’s, which was very much a golden era in computer science research. Much of our understanding of distributed systems and databases comes from the 1970’s and 80’s. Program architecture as well, consider DL Parnas' paper On the Criteria to Be Used in Decomposing Systems into Modules from 1972. A small treatise that many developers still don’t follow, IME, due to ignorance rather than actually disagreeing with the paper. Much of the lessons from The Mythical Man-month have been ignored as well. SICP was first published in 1985. The System F type system was discovered in the 70’s yet there are are no mainstream languages with such powerful type systems. The actor model was created in the 1970’s, yet only recent is really getting attention. Much of our understanding of concurrency is decades old despite concurrency only recently becoming a first-class citizen in popular languages. The list goes on.
To be clear, I am not attempting to disparage the original article, I’m lamenting that this article represents idea that are decades older than it and it’s a shame that the ideas are not so engrained in modern developers that someone feels it’s worthwhile to write such an article.
This field does not move particularly fast when it comes to fundamental issues like those discussed in this post. I agree that it’s helpful to see classic concepts applied to familiar contexts, but I think that usually the classics are more enjoyable to read.
That said, the “classic concepts” discussed in this post are
map, separation of concerns, higher-order programming, and programming by transforming streams. What “classic” (by which I mean “old”) texts would others here recommend for introducing those concepts? SICP, I guess?It is important to cite the original research. Underscore and its follow on libraries seemed more about staking out a territory than solving a problem. Not citing sources is disingenuous at best.
I would argue reading the original research, which is directed at conveying an idea is better than reading the source to a library that brings functional programming into an imperative language.
Newer is not better for its own sake.
I’ve downvoted you as “troll” for using “disingenuous”, which I think is a completely unwarranted insult in this context.
I disagree, when someone puts in hundreds of hours of work into a functional programming library but puts no effort to communicate where the ideas came from is disingenuous. People making stuff and doing no research into what is preceded it or is comparable is not right.
Nearly everything should have a bibliography, not for credit, but to elucidate the graph of knowledge. When people haven’t put the minimal effort needed to see how their creation fits into the existing body of knowledge …
“Doing no research”, while indeed suboptimal behavior, is not at all the same as “intentionally deceiving people”. I wouldn’t even go so far as to say that “doing no research” is unethical, just dumb. But maybe that’s because I’ve been guilty of doing no research many times…
I’d put it in the white lie category.
In the See Also section of the readme it should be SOP to put similar projects, inspiration or a call for more info. If one actually thinks something is novel they should say so. Not naming names, but I have come across quite a few projects that seemed like they were breaking new ground, when in fact it was a port from a library in a lesser used language.
This is an interesting idea.
Unfortunately, your account profile here leaves as an entirely anonymous individual.
Do you have some examples of this in your own repos on GitHub / Bitbucket / elsewhere?
I do not. In my professional work, I am sure to cite as much as I can. Not only does it help educate the customer, but it reduces the amount question and answer I have to do. Reference the existing systems, explain why you are different or the same and move on. If an open source app has the same architecture as an internal app, I’ll reference the relevant blog posts.
I used to be bummed when I find that someone has released a project that was similar to my own. Now I get excited and dig in a dissect it with interest.
I do have an upcoming project that will make it onto lobsters, including the bibliography.
Interestingly, Alexander Schepanovski’s “green code” corresponds to Raganwald’s Penny-Wise green code, while his “red code” and “blue code” are Raganwald’s “yellow code”. Raganwald’s “red code” doesn’t make an appearance in this post.
Because both articles are clearly classics, I predict that this is going to add confusion to future discussions about what color code is.