4 ms·

I think something similar happens with programmers: * I vaguely remember ambling around when I first started writing C programs, using a debugger whenever it b

I think something similar happens with programmers: * I vaguely remember ambling around when I first started writing C programs, using a debugger whenever it broke, and generally just slapping for loops and variables together until it worked. I had some intuition for how things worked, but it often took hours of hard debugging. I perceived code purely operationally - "This line sets this variable to 5". * At some point, you start structuring things into modules, subroutines, etc. You might learn 'best practices' and try intently to practice each one. You'll unit test everything, or otherwise hold strong opinions on how things should be done. Debugging is approached in a more scientific manner. You start to feel like you can get a handle on just about any bug, since you have tools and methods for reasoning about them. There is a lot of focus on verifying code, but not so much on validating. I perceived sections of code as implementing some intuitive concept - "This class represents a bullet, and its methods are reasonable things for working with bullets" * Now, I rarely spend any time worrying about the best practice of the day just for the sake of it. I generally focus on getting the current task done, but I intuitively know when to apply a certain practice. For example, I might write a test or two after writing algorithmic code. I rarely spend any time at all debugging my own code, since it tends to just work. Since verification is so easy, most of my focus is on validation: "Am I even building the right thing? Will this way of laying things out have acceptable performance characteristics? Does this way of laying out the types mirror how I think about the problem? Is everything I'm writing necessary to solve the problem?" I perceive most code as a formless soup of syntax trees with an operational semantics, and reason about the segments of the trees themselves. I imagine that Terence's breakdown is relevant to many professions besides just mathematics.

contravariant 11y ago
Well, programming and mathematics are really two sides of the same coin. But I agree that this breakdown will likely apply to many other professions. The reason being that mathematics is in essence the art of working with rules (in an abstract sense). Since almost any professions requires you to work with some rules (some very concrete, others more subjective) learning that part will resemble learning mathematics. Unfortunately you're very unlikely to encounter this part of mathematics if you don't go beyond high school level. I think some people want to introduce it through programming, but I'm not sure if that'll be any more effective.
mannykannot 11y ago
For many professional programmers, the rigorous stage of their education never got to the techniques for proving the correctness of programs, or even a realization that such techniques exist. We see this in the discussion of design issues, where informal arguments based on rules-of-thumb, reasonableness, best practices and aphorisms (e.g. "code smells") predominate. There is a tendency for dogmatism to arise in this environment ("thou shalt never write the same expression more than once - always factor it into a function.") (dogmatic thinking is probably confined to a small minority, but because they are vocal, they tend to dominate the discussion.) I am not one of those who think a transition to formal methods is feasible, let alone that it would solve software's problems. I am also aware that many programmers are effective in putting their general critical thinking and reasoning skills to work in writing correct code (this is one of the reasons why some people without any formal CS education can become excellent programmers.) Nevertheless, and speaking only from my own experience, I think some exposure to more rigorous approaches would help programmers tackle tricky problems, such as those that arise in matters of concurrency or security.

contravariant 11y ago

Well, programming and mathematics are really two sides of the same coin. But I agree that this breakdown will likely apply to many other professions. The reason being that mathematics is in essence the art of working with rules (in an abstract sense). Since almost any professions requires you to work with some rules (some very concrete, others more subjective) learning that part will resemble learning mathematics. Unfortunately you're very unlikely to encounter this part of mathematics if you don't go beyond high school level. I think some people want to introduce it through programming, but I'm not sure if that'll be any more effective.

mannykannot 11y ago

For many professional programmers, the rigorous stage of their education never got to the techniques for proving the correctness of programs, or even a realization that such techniques exist. We see this in the discussion of design issues, where informal arguments based on rules-of-thumb, reasonableness, best practices and aphorisms (e.g. "code smells") predominate. There is a tendency for dogmatism to arise in this environment ("thou shalt never write the same expression more than once - always factor it into a function.") (dogmatic thinking is probably confined to a small minority, but because they are vocal, they tend to dominate the discussion.) I am not one of those who think a transition to formal methods is feasible, let alone that it would solve software's problems. I am also aware that many programmers are effective in putting their general critical thinking and reasoning skills to work in writing correct code (this is one of the reasons why some people without any formal CS education can become excellent programmers.) Nevertheless, and speaking only from my own experience, I think some exposure to more rigorous approaches would help programmers tackle tricky problems, such as those that arise in matters of concurrency or security.