3 ms·

Software developers are especially well-positioned to understand some of the controversial claims of Kuhn: his 'paradigm shift' would be to us a 'refactor'. Not

Software developers are especially well-positioned to understand some of the controversial claims of Kuhn: his 'paradigm shift' would be to us a 'refactor'. Not just adding statements or fixing bugs (accounting for 'anomalies' would be the scientific version), but coming up with new primitive terms through which higher-level program statements are made (conversely, new terms/entities comprising the foundation of a theory). My recollection when reading Structure of Scientific Revolutions was that toward the very end of the book he gets into some more traditional philosophy in relation to incommensurability, which centers around the technical impossibility of comparing paradigms and drawing metaphysical conclusions from that. But for most of the book he speaks very practically about making comparisons and talks about various measures that can be used to evaluate the efficacy of competing paradigms (e.g. accuracy with which theoretical claims match experimental measures, and number of claims which can be verified experimentally). The article talks about a frustration of Kuhn's where "... Kuhn felt his critics disagreed not with his actual views but with distortions of his views — with the views of a fictional Kuhn." That has certainly been my experience in coming across discussions of Kuhn after reading Structure of Scientific Revolutions: "huh? Did we read the same book?" Most all of what he says is pretty common sensical, practical, illuminating and informed by history—but it seems that folks aren't interested in that and would prefer to ignore 95% of the book and respond to his concluding philosophical synthesis (which I mostly dismissed as an insignificant somewhat egotistical decoration tacked on to the book). This bit from the article neatly clarifies the whole issue, IMO: > The issue here is not the denial of reality, but the denial of an absolutely preferred way of talking about it. Statements can be true or false, but not whole languages. As Kuhn puts it, “The ways of being-in-the-world which a lexicon provides are not candidates for true/false.”

bendbro 8y ago
That software development devolves into a debate of epistemology, and often a very political debate at that, is the saddest thing I've had to experience. It's made me interested in both politics and epistemology.
antonvs 8y ago
> his 'paradigm shift' would be to us a 'refactor'. Just refactoring existing code is not usually a significant enough change to qualify as a paradigm shift. A paradigm shift is more like a rewrite using a different, uh, paradigm - say, functional instead of object-oriented, or Big Data instead of relational. I agree with the rest of your comment. I read SoSR in Philosophy of Science and have found it provides a very useful perspective. Although it's fun to contrast it with Feyerabend's "Against Method" to remind oneself of the range of viable perspectives here.
- westoncb 8y ago
  Sure--it would need to be a refactor of the foundations of the code base, and not just splitting a method in two or something. If you look closely at the word 'refactor' though, you'll see it's actually referring explicitly to what happens at the heart of Kuhnian paradigm shifts. Further, the impact of such refactors can certainly be of sufficient magnitude to be identified with a paradigm shift. You can find Stephen Wolfram speaking to this effect in regards to working on Mathematica. My personal experience also fits with the pattern described by Kuhn: because you couldn't think of better primitives initially, you need to introduce excessive complication which functions much like the classic example with circular orbits + epicycles. Then! it occurs to you, some new way of viewing the whole core of your problem; you refactor; ever thing is comparatively smooth as butter. I think part of the reason that isn't so often brought up in typical software engineering blogs or whatever is that developers are not often in a situation conducive to it playing out that way. The only times I've seen it were when I was working with a very deep codebase, as opposed to wide--and it required me to keep the problem regularly in mind for weeks or months at a time before some insight emerged seemingly spontaneously.
trashtester 8y ago
"Refactoring" is part of the current paradigm, so the act of refactoring is not a pardigm shift. Consider, however, that you are a computer scientist in 2012 that has been working in the field of image recognition using hand written algorthms for 20 years. You are the best in your field, highly respected. Your code has been refactored so many times that you think it is near perfect. Then along comes a young PhD student named Alex, and presents a completely different way of doing image recognition. Instead of talking about "refactoring", the talks about "retraining" or "rewireing". Instead of talking about "software architecture" he talks about "network topology". While you are "unit testing", he is "regularizing". He is still refactoring and building software architecture, you say, but for him, those are less important. 6 years later, everyone has forgotten about your life's work, and Alex's one paper has been cited 25 000 times and triggered a multi-billion $/year field of study. I think THIS is the on-going paradigm shift in computer science, and it has just started.
- westoncb 8y ago
  > "Refactoring" is part of the current paradigm, so the act of refactoring is not a pardigm shift. The example you cited to justify that claim is a difference in magnitude, not intrinsic structure. I brought up refactoring as an analogy to highlight the key features of another structure less familiar to software developers.
  - trashtester 8y ago
    The point of my example, is that the paradigm shift typically involves new people, with a new outlook, sometimes a different education or skill set, etc. They often are younger (but not always, sometimes they are just visionaries finally proven true, like Hinton). When there is a paradigm shift, there is typically an "old guard" that is not able to or willing to let go of the old way, and that gets left behind. This is why the saying goes: "Science advances one funeral at a time". In most cases (at least in my experience), refactoring is done either by the same team of programmers creating the original version, or a new team with a similar outlook to the old team. This means that there is not really an "old guard" to leave behind. But maybe you meant some other type of refactoring?

bendbro 8y ago

That software development devolves into a debate of epistemology, and often a very political debate at that, is the saddest thing I've had to experience. It's made me interested in both politics and epistemology.

antonvs 8y ago

> his 'paradigm shift' would be to us a 'refactor'. Just refactoring existing code is not usually a significant enough change to qualify as a paradigm shift. A paradigm shift is more like a rewrite using a different, uh, paradigm - say, functional instead of object-oriented, or Big Data instead of relational. I agree with the rest of your comment. I read SoSR in Philosophy of Science and have found it provides a very useful perspective. Although it's fun to contrast it with Feyerabend's "Against Method" to remind oneself of the range of viable perspectives here.

westoncb 8y ago
Sure--it would need to be a refactor of the foundations of the code base, and not just splitting a method in two or something. If you look closely at the word 'refactor' though, you'll see it's actually referring explicitly to what happens at the heart of Kuhnian paradigm shifts. Further, the impact of such refactors can certainly be of sufficient magnitude to be identified with a paradigm shift. You can find Stephen Wolfram speaking to this effect in regards to working on Mathematica. My personal experience also fits with the pattern described by Kuhn: because you couldn't think of better primitives initially, you need to introduce excessive complication which functions much like the classic example with circular orbits + epicycles. Then! it occurs to you, some new way of viewing the whole core of your problem; you refactor; ever thing is comparatively smooth as butter. I think part of the reason that isn't so often brought up in typical software engineering blogs or whatever is that developers are not often in a situation conducive to it playing out that way. The only times I've seen it were when I was working with a very deep codebase, as opposed to wide--and it required me to keep the problem regularly in mind for weeks or months at a time before some insight emerged seemingly spontaneously.

trashtester 8y ago

"Refactoring" is part of the current paradigm, so the act of refactoring is not a pardigm shift. Consider, however, that you are a computer scientist in 2012 that has been working in the field of image recognition using hand written algorthms for 20 years. You are the best in your field, highly respected. Your code has been refactored so many times that you think it is near perfect. Then along comes a young PhD student named Alex, and presents a completely different way of doing image recognition. Instead of talking about "refactoring", the talks about "retraining" or "rewireing". Instead of talking about "software architecture" he talks about "network topology". While you are "unit testing", he is "regularizing". He is still refactoring and building software architecture, you say, but for him, those are less important. 6 years later, everyone has forgotten about your life's work, and Alex's one paper has been cited 25 000 times and triggered a multi-billion $/year field of study. I think THIS is the on-going paradigm shift in computer science, and it has just started.

westoncb 8y ago
> "Refactoring" is part of the current paradigm, so the act of refactoring is not a pardigm shift. The example you cited to justify that claim is a difference in magnitude, not intrinsic structure. I brought up refactoring as an analogy to highlight the key features of another structure less familiar to software developers.
- trashtester 8y ago
  The point of my example, is that the paradigm shift typically involves new people, with a new outlook, sometimes a different education or skill set, etc. They often are younger (but not always, sometimes they are just visionaries finally proven true, like Hinton). When there is a paradigm shift, there is typically an "old guard" that is not able to or willing to let go of the old way, and that gets left behind. This is why the saying goes: "Science advances one funeral at a time". In most cases (at least in my experience), refactoring is done either by the same team of programmers creating the original version, or a new team with a similar outlook to the old team. This means that there is not really an "old guard" to leave behind. But maybe you meant some other type of refactoring?