7 ms·

Dijkstra Was Wrong About 'Radical Novelty'

77 points by azhenley 6y ago

averros 6y ago
Nope. Dijkstra was and still is right. The newfangled ways of teaching how to code managed to produce a generation of really poor-quality software "engineers" producing atrocious slow and buggy bloatware. You cannot be a good engineer if you reason with analogies and metaphors instead of understanding how things actually work, at multiple levels, and knowing what and when can be abstracted and which lower-level details are important and should not be ignored. So... if you want to become a decent software engineer, start with learning digital electronics and assembly. This way you won't need "metaphors" for arrays and such - because you will know that a static array is just multiplication by constant followed by addition to a constant and dereferencing of the resulting address.
- forgotmypw17 6y ago
  .
  - averros 6y ago
    Thank you, I guess. I've been a practicing software engineer for over 40 years now, and watching the decline of my profession over the decades is quite painful.
- rfrey 6y ago
  From your comment history, you appear to be shadow banned. A perusal of your dead comments does not immediately reveal why.
  - dredmorbius 6y ago
    https://news.ycombinator.com/item?id=20110663 https://news.ycombinator.com/item?id=20110663
- Twisol 6y ago
  Although I agree with the core of your argument, I think this position is a little reductionist. Yes, you really do need to understand what's going on under the hood (though, choose your hood). But you're also almost-but-not-explicitly saying that analogies and metaphors are not valuable tools for engineering. I really strongly disagree with that. As one example, I find analogies downright necessary when working with a complex domain -- you have to find ways to speak domainese in the software world, or speak programese in the domain world, and analogies are precisely the tool for that job. It's easy to think that domain concepts should have a 1-1 representation in the software world, but in my experience, that's neither true nor productive. You do need to understand (and document for others!) the mappings between those concepts, but they shouldn't be so rigid. On a related note, I'm reminded of Terence Tao's thoughts on rigor in mathematics [0]. He divides expertice into pre-rigor, rigor, and post-rigor phases. It's necessary to understand the rigorous elements, but those (a) build on intuititons built up over time in the pre-rigor phase and (b) support expert, formalizable intuitions in the post-rigor phase. [0] https://terrytao.wordpress.com/career-advice/theres-more-to-mathematics-than-rigour-and-proofs/ https://terrytao.wordpress.com/career-advice/theres-more-to-... > So... if you want to become a decent software engineer, start with learning digital electronics and assembly. I disagree here too, though less strongly. I think it's important to have approximate intuitions that can be refined, rather than trying to manufacture a precise understanding out of nothing. Those intuitions can be built up by trying, failing, and accomplishing projects that you're motivated by. Even if Djikstra is right about "radical novelty", you obtain a certain amount of mechanical sympathy just by fighting with the computer and learning its needs. The "Purpose-First Programming" research [1] that this article's submitter also submitted today seems relevant. [1] https://news.ycombinator.com/item?id=25256874 https://news.ycombinator.com/item?id=25256874
- acbart 6y ago
  I believe you misunderstand how the process of learning occurs. If you really want to deeply understand something, it's a whole process of connecting up existing facts and schemas in your brain. That happens more smoothly over time by processes like seeing metaphors. A good teaching metaphor always involves a description of how the metaphor fails. Learning from metaphors is not a weakness, nor is it the only plank to build a house of knowledge on. Eventually, you will need to understand the mechanics too, but there's nothing wrong with starting with metaphor, or examples, or visualizations, or interactive simulations, or any other teaching scaffold. Also, don't gatekeep the field, unless you have a citation that proves that modern teaching techniques have really led to a decrease in quality of software engineers. I really doubt you have any concrete measure you can point to that won't be anecdotal, but if you have one I am interested in hearing why you think you can strongly believe that folks have gotten wore over time because we got better at teaching.
  - mlyle 6y ago
    > Also, don't gatekeep the field, unless you have a citation that proves that modern teaching techniques have really led to a decrease in quality of software engineers. I don't think modern teaching techniques have. I think the profession has done admirably (but not good enough) at cultivating the basics in more people than managed it ever before. But when you multiply the size of the profession by so much, even if teaching improves greatly, odds are you're including a lot more volatility in the amount of ability/intrinsic interest/talent. There's people who are making it today who'd never have been good enough 20-40 years ago. We need a bunch more programmers and software engineers now, so we tolerate it. And thankfully, improvements in tooling, debugging, and instrumentation, along with a bunch more available performance and storage, limit the harms.
- meroes 6y ago
  Is it the method of teaching really? Or is it that good-enough, quickest to market, and diverse programs often win in a capitalistic market? Capitalism is all about finding new opportunities. Nothing is static. Pedagogy or otherwise.
empthought 6y ago
I don’t think this author understands Dijkstra’s essay the way I understand it. Dijkstra was very specific about advising people to not assign agency to computer programs, nor to rely on operational reasoning. However, the cited examples involve either the explanation of the concepts of programming (rather than reasoning about a program itself), or the very same thing that Dijkstra exhorted us to do... read what the program “says”, i.e. its denotation. Reason about it mathematically and logically, deducing its nature, instead of watching it like a mechanism and abducting various properties.
- inimino 6y ago
  Exactly. The author misunderstood Dijkstra's essay entirely, or perhaps just wanted to stir up controversy. Furthermore, it's ridiculous to condescendingly imply that Dijkstra was simply unaware of Piaget whose work was already at the height of popularity well before that time. Here's the original, which, 32 years later, is still a much better read than this critique of it! https://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF https://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF
  - Barrin92 6y ago
    >Furthermore, it's ridiculous to condescendingly imply that Dijkstra was simply unaware of Piaget whose work was already at the height of popularity well before that time. It's not so condenscending given that his entire essay is basically a bunch of unsubstantiated hot takes, for example: " It is probably more illuminating to go a little bit further back, to the Middle Ages. One of its characteristics was that "reasoning by analogy" was rampant; another characteristic was almost total intellectual stagnation, and we now see why the two go together. A reason for mentioning this is to point out that, by developing a keen ear for unwarranted analogies, one can detect a lot of medieval thinking today." This is essentially the unreflected pop-culture reading of the middle ages as the 'dark ages' (I also have no idea how Dijkstra determined that reasoning by analogy was particularly a feature of medieval society), which happens to be wrong, and ironically is in itself a sort of sloppy analogy of the kind he just denounced
troupe 6y ago
It appears to me that the problem with reasoning by analogy is that we often focus on how x is analogous to y, but skip over the part where we think about how x is not like y. Without intentionally making that step, we bring a lot of unwanted assumptions into our understanding of x because we haven't focused on the ways it is different.
- Twisol 6y ago
  > we often focus on how x is analogous to y, but skip over the part where we think about how x is not like y. Yes! Regardless of whether Djikstra is 100% right or wrong about "radical novelty", software engineering is relatively more novel than more familiar activities (is that phrasing tautological?). Analogies are comforting, because they make a strange thing look less strange. But we have to take both sides of the cut: we can compress our knowledge based on these similarities, while carving away those same similarities to highlight the differences in their own right. A well-posed set of analogies can surgically lay out the internal structure of a concept. (But we still have to grapple with the pieces!)
  - troupe 6y ago
    Here is an interesting study showing that our solution to a problem greatly depends on the metaphors used to describe the problem. This isn't necessarily good or bad, but it does mean we may think we are coming up with solutions to the problem but be unaware that we are greatly constrained by the words used to describe the problem. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0016782 https://journals.plos.org/plosone/article?id=10.1371/journal...
    - Twisol 6y ago
      Ooooh, yes, I remember talking about this article with a coworker some months ago. > we are greatly constrained by the [metaphors] used to describe the problem. Linguistic relativity might be controversial, but this, I feel, is a "correct" kernel of that idea. (Forgive the slight recombining of your sentiment!)
Syzygies 6y ago
A monad walks into a bar...
- Twisol 6y ago
  (Joke well taken!) Category theory was founded on topics like algebraic topology, so there's actually a rich framework of analogies to draw on between the two topics. The problem is, most of us aren't algebraic topologists. I want to find a better set of analogies between category theory and software engineering, that aren't so coupled to yet other fields of mathematics. I feel like they exist, but in a lot of ways, I'm still in the pre-rigor phase on category theory :(
kaymanb 6y ago
I really like that there is active research being done in this area. It's interesting to see a constructivist lens applied to teaching concepts in computer science, and I would agree with the author that Dijkstra's insistence on a "blank mind" is the wrong approach. It seems like it would limit learning to those who "just get it", especially for introductory concepts that are typically taught to students who don't have the maturity to dive into abstract reasoning straight away.
taeric 6y ago
This feels like a criticism that takes the straw man version of dijkstra's essay and burns it. Too easily, all told. I have issues with how he is often portrayed, but I have rarely seen Dijkstra portrayed as ignorant. The more common view is of arrogant. Even from friends that completely valued his cutting remarks. Such that this feels more like a piece designed to get visibility from attacking a great in the industry. :(
amw-zero 6y ago
I’ve read a lot from Djikstra, but never this one. After giving it a read, it’s one of his most concise summaries of his overall philosophy. If he’s wrong about anything, it’s how formal methods are not up to speed with the scale of software that we want to build, and that I believe we can never get away from operational reasoning. I’ve been keeping a bug journal for some time now. It’s very enlightening because instead of making things up, I have raw data about what goes wrong at work, for me. For me, logic errors account for probably 40% of bugs. Another 40% are operational problems, mostly performance related. The rest are typos and unintentional breakages of parts of the program that are unknowingly coupled to something I changed. All that being said, even when he’s wrong, he’s right. Logical soundness must come first. This cannot be done without math. All programmers are doing math whether they acknowledge it or not, specifically mathematical logic and set theory. Refactors to improve performance must keep the logical function of the program the same. I believe him wholeheartedly when he says: > The statement that a given program meets a certain specification amounts to a statement about all computations that could take place under control of that given program. And since this set of computations is defined by the given program, our recent moral says: deal with all computations possible under control of a given program by ignoring them and working with the program. We must learn to work with program texts while (temporarily) ignoring that they admit the interpretation of executable code. This man understood computation far more deeply than anyone out there today. Today, we have completely baseless claims being spouted like religion. We are in the era of the personality - a person’s personality determines how much they are listened to in our field. That is tragic, and while Djikstra might not have the answer for software of our scale, he has the only correct point of view in my opinion.
- qsort 6y ago
  I agree a lot with Dijkstra as well, especially when he denounces how childish it is to compare computational processes with physical ones instead of understanding them for what they are (i.e. 'the radical novelty'), but to play the devil's advocate, formal thinking is not how we learn. I personally find it hard to understand a concept, even in pure math, if I don't understand the motivations that lead to that concept being formulated (not necessarily practical applications, I'm fine with purely theoretical concepts, just why that definition solves a problem, I guess); it's simply too much to ask someone to "get" programming without an intuition of what types of problems it solves. The fact that more and more people get into programming, even professionally, without proper mathematical fundamentals is another topic entirely.
disgruntledphd2 6y ago
> In 1988 when Dijkstra wrote this piece, cognitive science journals were only about a decade old, and learning sciences wasn’t established until the 1990s. Cognitive science is a re-branding of earlier work in psychology, and constructivism has been around since the late 50's (see Jerome Bruner's work). It's potentially a sad commentary on academia that fields appear to ignore other fields more than N hops away, where N>=2.
js8 6y ago
I think Dijkstra was ahead of time. Whatever you do with computers, you shall not use words like "kill", "master", "slave", "blacklist", "whitelist"...
rustybolt 6y ago
People stating that a view on something is 'wrong' really grind my gears.
cafard 6y ago
The essay appeared in the CACM with a number of other essays objecting to it, if I recall correctly.
ExcavateGrandMa 6y ago
my knowledges is not inert! I pass all the tests while teaching you... and I fully understand what I know! how I do why I doing that way... WTH this is partially wrong... :D
mdpm 6y ago
The map is not the territory; all abstractions are false. Exploring without a map or map-making is futile, and fraught with danger. Both these things can be true.
JoeAltmaier 6y ago
Folks are fond of asserting the computing is lost without math. Yet probably the vast majority of it is written without formalisms of any kind. And the world is still here.
- amw-zero 6y ago
  A programming language is a formalism. The definition of computing is a formalism. The relational database is a mathematical formalism of data. I'm just curious - what programming are you doing that doesn't involve math?
  - JoeAltmaier 6y ago
    Any programming. So, if all it takes is for programming languages to be 'formalism', then pedantically speaking, we're all doing it right. Thanks! My programs are all correct now?
    - amw-zero 6y ago
      "Formalism" is a fancy word for saying that a system has to have an agreed upon shape - hence form. Programming languages have structure - you can't just type random text, there is a specific syntax, with specific semantic rules based on what you type. So all I'm saying is that you are working in a formal system, and you are creating formal logic. Every day. That has nothing to do with correctness. In logic, there is a difference between validity and soundness. A valid argument is one that is in a proper form. You can make valid arguments that are completely untrue. A sound argument is one that is valid and also happens to be true. It's trivial to create a valid program - it either compiles or is executable by the interpreter. But that has nothing to do with soundness. It's quite ironic. The unwillingness to understand something, such as math and logic in this case, leads to criticizing it. You can't evaluate what you don't understand.
      - JoeAltmaier 6y ago
        No, it leads to being misconstrued. I was criticizing simple pedantry. But that was lost I see.
a4444f 6y ago
I'd agree with Dijkstra, provided that he wrote about individual human beings, rather than computers. It is humans that are characterized by radical novelty, not computers, which can be understood by metaphors. It is easy to predict computers (that is why they are useful), and impossible to predict humans.

77 points by azhenley 6y ago

Nope. Dijkstra was and still is right. The newfangled ways of teaching how to code managed to produce a generation of really poor-quality software "engineers" producing atrocious slow and buggy bloatware. You cannot be a good engineer if you reason with analogies and metaphors instead of understanding how things actually work, at multiple levels, and knowing what and when can be abstracted and which lower-level details are important and should not be ignored. So... if you want to become a decent software engineer, start with learning digital electronics and assembly. This way you won't need "metaphors" for arrays and such - because you will know that a static array is just multiplication by constant followed by addition to a constant and dereferencing of the resulting address.

forgotmypw17 6y ago
.
- averros 6y ago
  Thank you, I guess. I've been a practicing software engineer for over 40 years now, and watching the decline of my profession over the decades is quite painful.
rfrey 6y ago
From your comment history, you appear to be shadow banned. A perusal of your dead comments does not immediately reveal why.
- dredmorbius 6y ago
  https://news.ycombinator.com/item?id=20110663 https://news.ycombinator.com/item?id=20110663
Twisol 6y ago
Although I agree with the core of your argument, I think this position is a little reductionist. Yes, you really do need to understand what's going on under the hood (though, choose your hood). But you're also almost-but-not-explicitly saying that analogies and metaphors are not valuable tools for engineering. I really strongly disagree with that. As one example, I find analogies downright necessary when working with a complex domain -- you have to find ways to speak domainese in the software world, or speak programese in the domain world, and analogies are precisely the tool for that job. It's easy to think that domain concepts should have a 1-1 representation in the software world, but in my experience, that's neither true nor productive. You do need to understand (and document for others!) the mappings between those concepts, but they shouldn't be so rigid. On a related note, I'm reminded of Terence Tao's thoughts on rigor in mathematics [0]. He divides expertice into pre-rigor, rigor, and post-rigor phases. It's necessary to understand the rigorous elements, but those (a) build on intuititons built up over time in the pre-rigor phase and (b) support expert, formalizable intuitions in the post-rigor phase. [0] https://terrytao.wordpress.com/career-advice/theres-more-to-mathematics-than-rigour-and-proofs/ https://terrytao.wordpress.com/career-advice/theres-more-to-... > So... if you want to become a decent software engineer, start with learning digital electronics and assembly. I disagree here too, though less strongly. I think it's important to have approximate intuitions that can be refined, rather than trying to manufacture a precise understanding out of nothing. Those intuitions can be built up by trying, failing, and accomplishing projects that you're motivated by. Even if Djikstra is right about "radical novelty", you obtain a certain amount of mechanical sympathy just by fighting with the computer and learning its needs. The "Purpose-First Programming" research [1] that this article's submitter also submitted today seems relevant. [1] https://news.ycombinator.com/item?id=25256874 https://news.ycombinator.com/item?id=25256874
acbart 6y ago
I believe you misunderstand how the process of learning occurs. If you really want to deeply understand something, it's a whole process of connecting up existing facts and schemas in your brain. That happens more smoothly over time by processes like seeing metaphors. A good teaching metaphor always involves a description of how the metaphor fails. Learning from metaphors is not a weakness, nor is it the only plank to build a house of knowledge on. Eventually, you will need to understand the mechanics too, but there's nothing wrong with starting with metaphor, or examples, or visualizations, or interactive simulations, or any other teaching scaffold. Also, don't gatekeep the field, unless you have a citation that proves that modern teaching techniques have really led to a decrease in quality of software engineers. I really doubt you have any concrete measure you can point to that won't be anecdotal, but if you have one I am interested in hearing why you think you can strongly believe that folks have gotten wore over time because we got better at teaching.
- mlyle 6y ago
  > Also, don't gatekeep the field, unless you have a citation that proves that modern teaching techniques have really led to a decrease in quality of software engineers. I don't think modern teaching techniques have. I think the profession has done admirably (but not good enough) at cultivating the basics in more people than managed it ever before. But when you multiply the size of the profession by so much, even if teaching improves greatly, odds are you're including a lot more volatility in the amount of ability/intrinsic interest/talent. There's people who are making it today who'd never have been good enough 20-40 years ago. We need a bunch more programmers and software engineers now, so we tolerate it. And thankfully, improvements in tooling, debugging, and instrumentation, along with a bunch more available performance and storage, limit the harms.
meroes 6y ago
Is it the method of teaching really? Or is it that good-enough, quickest to market, and diverse programs often win in a capitalistic market? Capitalism is all about finding new opportunities. Nothing is static. Pedagogy or otherwise.

empthought 6y ago

I don’t think this author understands Dijkstra’s essay the way I understand it. Dijkstra was very specific about advising people to not assign agency to computer programs, nor to rely on operational reasoning. However, the cited examples involve either the explanation of the concepts of programming (rather than reasoning about a program itself), or the very same thing that Dijkstra exhorted us to do... read what the program “says”, i.e. its denotation. Reason about it mathematically and logically, deducing its nature, instead of watching it like a mechanism and abducting various properties.

inimino 6y ago
Exactly. The author misunderstood Dijkstra's essay entirely, or perhaps just wanted to stir up controversy. Furthermore, it's ridiculous to condescendingly imply that Dijkstra was simply unaware of Piaget whose work was already at the height of popularity well before that time. Here's the original, which, 32 years later, is still a much better read than this critique of it! https://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF https://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF
- Barrin92 6y ago
  >Furthermore, it's ridiculous to condescendingly imply that Dijkstra was simply unaware of Piaget whose work was already at the height of popularity well before that time. It's not so condenscending given that his entire essay is basically a bunch of unsubstantiated hot takes, for example: " It is probably more illuminating to go a little bit further back, to the Middle Ages. One of its characteristics was that "reasoning by analogy" was rampant; another characteristic was almost total intellectual stagnation, and we now see why the two go together. A reason for mentioning this is to point out that, by developing a keen ear for unwarranted analogies, one can detect a lot of medieval thinking today." This is essentially the unreflected pop-culture reading of the middle ages as the 'dark ages' (I also have no idea how Dijkstra determined that reasoning by analogy was particularly a feature of medieval society), which happens to be wrong, and ironically is in itself a sort of sloppy analogy of the kind he just denounced

troupe 6y ago

It appears to me that the problem with reasoning by analogy is that we often focus on how x is analogous to y, but skip over the part where we think about how x is not like y. Without intentionally making that step, we bring a lot of unwanted assumptions into our understanding of x because we haven't focused on the ways it is different.

Twisol 6y ago
> we often focus on how x is analogous to y, but skip over the part where we think about how x is not like y. Yes! Regardless of whether Djikstra is 100% right or wrong about "radical novelty", software engineering is relatively more novel than more familiar activities (is that phrasing tautological?). Analogies are comforting, because they make a strange thing look less strange. But we have to take both sides of the cut: we can compress our knowledge based on these similarities, while carving away those same similarities to highlight the differences in their own right. A well-posed set of analogies can surgically lay out the internal structure of a concept. (But we still have to grapple with the pieces!)
- troupe 6y ago
  Here is an interesting study showing that our solution to a problem greatly depends on the metaphors used to describe the problem. This isn't necessarily good or bad, but it does mean we may think we are coming up with solutions to the problem but be unaware that we are greatly constrained by the words used to describe the problem. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0016782 https://journals.plos.org/plosone/article?id=10.1371/journal...
  - Twisol 6y ago
    Ooooh, yes, I remember talking about this article with a coworker some months ago. > we are greatly constrained by the [metaphors] used to describe the problem. Linguistic relativity might be controversial, but this, I feel, is a "correct" kernel of that idea. (Forgive the slight recombining of your sentiment!)

Syzygies 6y ago

A monad walks into a bar...

Twisol 6y ago
(Joke well taken!) Category theory was founded on topics like algebraic topology, so there's actually a rich framework of analogies to draw on between the two topics. The problem is, most of us aren't algebraic topologists. I want to find a better set of analogies between category theory and software engineering, that aren't so coupled to yet other fields of mathematics. I feel like they exist, but in a lot of ways, I'm still in the pre-rigor phase on category theory :(

kaymanb 6y ago

I really like that there is active research being done in this area. It's interesting to see a constructivist lens applied to teaching concepts in computer science, and I would agree with the author that Dijkstra's insistence on a "blank mind" is the wrong approach. It seems like it would limit learning to those who "just get it", especially for introductory concepts that are typically taught to students who don't have the maturity to dive into abstract reasoning straight away.

taeric 6y ago

This feels like a criticism that takes the straw man version of dijkstra's essay and burns it. Too easily, all told. I have issues with how he is often portrayed, but I have rarely seen Dijkstra portrayed as ignorant. The more common view is of arrogant. Even from friends that completely valued his cutting remarks. Such that this feels more like a piece designed to get visibility from attacking a great in the industry. :(

amw-zero 6y ago

I’ve read a lot from Djikstra, but never this one. After giving it a read, it’s one of his most concise summaries of his overall philosophy. If he’s wrong about anything, it’s how formal methods are not up to speed with the scale of software that we want to build, and that I believe we can never get away from operational reasoning. I’ve been keeping a bug journal for some time now. It’s very enlightening because instead of making things up, I have raw data about what goes wrong at work, for me. For me, logic errors account for probably 40% of bugs. Another 40% are operational problems, mostly performance related. The rest are typos and unintentional breakages of parts of the program that are unknowingly coupled to something I changed. All that being said, even when he’s wrong, he’s right. Logical soundness must come first. This cannot be done without math. All programmers are doing math whether they acknowledge it or not, specifically mathematical logic and set theory. Refactors to improve performance must keep the logical function of the program the same. I believe him wholeheartedly when he says: > The statement that a given program meets a certain specification amounts to a statement about all computations that could take place under control of that given program. And since this set of computations is defined by the given program, our recent moral says: deal with all computations possible under control of a given program by ignoring them and working with the program. We must learn to work with program texts while (temporarily) ignoring that they admit the interpretation of executable code. This man understood computation far more deeply than anyone out there today. Today, we have completely baseless claims being spouted like religion. We are in the era of the personality - a person’s personality determines how much they are listened to in our field. That is tragic, and while Djikstra might not have the answer for software of our scale, he has the only correct point of view in my opinion.

qsort 6y ago
I agree a lot with Dijkstra as well, especially when he denounces how childish it is to compare computational processes with physical ones instead of understanding them for what they are (i.e. 'the radical novelty'), but to play the devil's advocate, formal thinking is not how we learn. I personally find it hard to understand a concept, even in pure math, if I don't understand the motivations that lead to that concept being formulated (not necessarily practical applications, I'm fine with purely theoretical concepts, just why that definition solves a problem, I guess); it's simply too much to ask someone to "get" programming without an intuition of what types of problems it solves. The fact that more and more people get into programming, even professionally, without proper mathematical fundamentals is another topic entirely.

disgruntledphd2 6y ago

> In 1988 when Dijkstra wrote this piece, cognitive science journals were only about a decade old, and learning sciences wasn’t established until the 1990s. Cognitive science is a re-branding of earlier work in psychology, and constructivism has been around since the late 50's (see Jerome Bruner's work). It's potentially a sad commentary on academia that fields appear to ignore other fields more than N hops away, where N>=2.

js8 6y ago

I think Dijkstra was ahead of time. Whatever you do with computers, you shall not use words like "kill", "master", "slave", "blacklist", "whitelist"...

rustybolt 6y ago

People stating that a view on something is 'wrong' really grind my gears.

cafard 6y ago

The essay appeared in the CACM with a number of other essays objecting to it, if I recall correctly.

ExcavateGrandMa 6y ago

my knowledges is not inert! I pass all the tests while teaching you... and I fully understand what I know! how I do why I doing that way... WTH this is partially wrong... :D

mdpm 6y ago

The map is not the territory; all abstractions are false. Exploring without a map or map-making is futile, and fraught with danger. Both these things can be true.

JoeAltmaier 6y ago

Folks are fond of asserting the computing is lost without math. Yet probably the vast majority of it is written without formalisms of any kind. And the world is still here.

amw-zero 6y ago
A programming language is a formalism. The definition of computing is a formalism. The relational database is a mathematical formalism of data. I'm just curious - what programming are you doing that doesn't involve math?
- JoeAltmaier 6y ago
  Any programming. So, if all it takes is for programming languages to be 'formalism', then pedantically speaking, we're all doing it right. Thanks! My programs are all correct now?
  - amw-zero 6y ago
    "Formalism" is a fancy word for saying that a system has to have an agreed upon shape - hence form. Programming languages have structure - you can't just type random text, there is a specific syntax, with specific semantic rules based on what you type. So all I'm saying is that you are working in a formal system, and you are creating formal logic. Every day. That has nothing to do with correctness. In logic, there is a difference between validity and soundness. A valid argument is one that is in a proper form. You can make valid arguments that are completely untrue. A sound argument is one that is valid and also happens to be true. It's trivial to create a valid program - it either compiles or is executable by the interpreter. But that has nothing to do with soundness. It's quite ironic. The unwillingness to understand something, such as math and logic in this case, leads to criticizing it. You can't evaluate what you don't understand.
    - JoeAltmaier 6y ago
      No, it leads to being misconstrued. I was criticizing simple pedantry. But that was lost I see.

a4444f 6y ago

I'd agree with Dijkstra, provided that he wrote about individual human beings, rather than computers. It is humans that are characterized by radical novelty, not computers, which can be understood by metaphors. It is easy to predict computers (that is why they are useful), and impossible to predict humans.