8 ms·

When I was in college, one CS professor explained the difficulty of coding to me in terms of discreteness vs continuity. In the real world, things are continuou

When I was in college, one CS professor explained the difficulty of coding to me in terms of discreteness vs continuity. In the real world, things are continuous. If you accidentally build your structure with 9 supports instead of 10, then you only lose 10% of the strength of the structure, more or less. The strength varies continuously with the amount of support. But if you're writing a 10-line program and you forget one of the lines (or even one character), the program isn't 10% wrong, it's 100% wrong. (For example, instead of compiling and running correctly, it doesn't compile at all. Completely different results.) Of course this logic doesn't hold up all the time. Sometimes you can remove a critical support and collapse a structure, and sometimes removing a line of code has little to no effect, but the point is that in programming, a small change can have an unboundedly large effect, which is the definition of discontinuity. (I believe it was this professor, who was my teacher for discrete math: http://www.cs.virginia.edu/~jck/ http://www.cs.virginia.edu/~jck/ )

reikonomusha 12y ago
That's closer to the definition of instability than it is discontinuity.
- rcthompson 12y ago
  "In mathematics, a continuous function is, roughly speaking, a function for which small changes in the input result in small changes in the output." [1] I could clarify and say that the change doesn't have to be unboundedly large in absolute terms, but rather relative to the change in input. (i.e. a jump discontinuity from 0 to 1 is not absolutely unbounded, but it is relative to an arbitrarily small change across the jump.) [1] http://en.wikipedia.org/wiki/Continuous_function http://en.wikipedia.org/wiki/Continuous_function
- deleted 12y ago
  [deleted]
deleted 12y ago
[deleted]
SilasX 12y ago
Unless you're doing Rails, in which case it'll be read as a magic method and guess what you meant :-P Seriously, that was a major sticking point for me having programmed for a long time: going from "if you have not declared that identifier, game over" to "magic happens".
- lelandbatey 12y ago
  That is absolutely something that irritates me. I've just inherited a large RoR application, and the amount of "magic" and things by convention is driving me crazy. There should be answers to questions like "why is this the way it is?!" On a side note, if anyone has some great resources for RoR, I'd love to have them linked. I suspect my inexperience is the source of my problems, and I'm welcome to any assistance any one would like to give.
  - quetzthecoatl 12y ago
    Convention over configuration is awesome, if you know the conventions. If you don't, it's all magic. At least with configurations, you can read them and get some pointers.
  - grey-area 12y ago
    The guides on the ror website are pretty good: http://guides.rubyonrails.org/ http://guides.rubyonrails.org/ Which bits did you find were magic? The bits of convention I can think of you'd have to know about are: DB naming conventions - these are used so that it can do joins etc easily behind the scenes, they're pretty simple so not a huge problem I find. Rendering at the end of controller actions - it'll render the template with the same path as your route - again relatively straightforward. Class loading - lots of things are loaded at startup time, so that you don't have to include files - I have mixed feelings about this, it feels easy and simple at first, but could leave you unsure where code comes from or which methods you can use in which files (e.g. view helpers). Definitely more magic. One other area which does lead to real problems is that rails sites often use a lot of libraries in the form of gems - this leads to unknown, sometimes poorly maintained or inappropriate code being pulled in at runtime, and makes it far harder to reason about things like say authentication if using a gem. This is my biggest complaint with rails - lack of transparency of code paths when using gems like devise, paperclip etc but it is unfortunately quite common in web frameworks They actually got rid of quite a few bits of method_missing madness I think recently so that magic is gone at least (all those magic find_by_ methods are deprecated or removed, not sure which as I never used them). I haven't found the conventions get in the way much as it's something you learn once and can apply anywhere, but completely understand why someone might object to some of the magic setup for helpers/rendering.
bhaumik 12y ago
Wahoowa! This also explains the popularity of interactive platforms like Codecademy/CodeSchool/Treehouse, etc. Ton of handholding and pre-filled syntax. We describe them to our students as "coding on training wheels." Cathy, a new frontend student, experienced similar struggles when starting her first real project - a simple HTML/CSS resume. She spent countless hours fixing minor typos and almost quit. It wasn't until she was reassured that this was _normal_ and "real" programming was much different from codecademy did she feel like she was truly learning. She wrote about her first month (with similar highs and lows as OP's visual) in this post: http://blog.thinkful.com/post/98829096308/my-first-month-coding-an-emotional-roller-coaster http://blog.thinkful.com/post/98829096308/my-first-month-cod.... side note: Erik (OP) is an incredible guy, we had the pleasure to share our experiences in Edtech and it's obvious that he truly cares about student outcomes.
- chii 12y ago
  > She spent countless hours fixing minor typos and almost quit. it's interesting anecdote! When i was at uni, i noticed that a large number of "beginners" tend to fall into this category too - frustrated at minor typos/language idiosyncrasies. Those who had the mental strength to endure it end up passing the class, while those that just gave up will almost inevitably change their major (and thus, stop programming i guess?). But i think this is a result of poor educational methods, not because of an inherent property in programming.
superobserver 12y ago
> But if you're writing a 10-line program and you forget one of the lines (or even one character), the program isn't 10% wrong, it's 100% wrong. (For example, instead of compiling and running correctly, it doesn't compile at all. Completely different results.) This is where the beauty/simplicity of some programming languages, namely, intepreted languages (e.g., Python), comes in: if a bad line of code never gets executed, then the program itself will run fine. In other words, if the line is never called in the program, then you'll not know that the functionality that that line presented was bad. In this case, the analogy breaks down a bit - and also shows why certain languages are easier to learn than others (e.g., Python vs. C++).
- nsomaru 12y ago
  I'd rather know when something is incorrect, rather than pushing to production and finding out later because someone else took that code path.
  - DougWebb 12y ago
    If you rely on your compiler to tell you that your code is correct, there are whole classes of bugs that are waiting to surprise you in production. I think that many years of developing large applications in Perl were really good for me. Perl is compiled when you run it, so you get the basic-syntax check that you get with other languages. But it's also very lenient, so you learn through experience to get your logic right, test return values, and do all of the things that help make sure that a program which executes is executing correctly.
    - brianwawok 12y ago
      There is a difference from RELY on compile to catch 100% of bugs, vs having an awesome type system that can take whole CLASSES of bugs and make them impossible to get past a compile. Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. Is either ideal? No. Can both be improved by adding a few tests? Yes.
__throwaway2015 12y ago
In a general sense, it can be more difficult to reason about what effect adding or removing something will have because the skill is still being developed.
- rcthompson 12y ago
  Yes, but that's true of any new skill that one might try to learn. I'm talking about specifically what makes programming harder than other things to learn. When things are continuous, you can at least experiment by making small changes and be confident that those changes will only have small effects.
rapind 12y ago
If you're lucky it won't compile. It's when it's 2% wrong that makes programming so hard.
the_cat_kittles 12y ago
i say its "brittle" ...those words discrete and continuous dont really apply cleanly, though i understand the idea somewhat intuitively
- emmelaich 12y ago
  Yes, "brittle" is how it's been described to me and how I describe it to others.
Yhippa 12y ago
I remember this one thing he pounded into our brains: "CS doesn't stand for Computer Science. It stands for Common Sense!" Heard ad nauseam in CS 340.
SiVal 12y ago
With respect to your CS prof at one of my favorite places (Go Cavaliers!), this is not an issue of discrete vs. continuous. If your structure can have either 9 or 10, but not 9.001, supports, it is discrete, not continuous, regardless of failure mode. And remove one of the 3 legs of your stool, and you probably wouldn't have 2/3rds of its support remaining, but whether you did or didn't would be an issue of proportionality, not continuity. There are a lot of jumbled concepts here, most of which don't matter anyway, because what you are talking about is the phenomenon of graceful degradation. In the physical world, both natural and man-made, almost nothing at the macro scale is ever perfect, so the best designs tend to be those that remain good enough under the widest range of circumstances vs. a more common software goal of being perfect under perfectly controlled circumstances. As software gradually moves out from the wall garden of a single mainframe to fill the world with interacting systems spanning diverse machines, sensors, communications channels, data types, etc., design for graceful degradation becomes more and more of a focus for professional software architects. Coding in the gracefully degrading way is much harder than coding in the "if even one of your ten lines is wrong, you crash" tradition. The fact that even the latter is so hard for us humans means we will need more and more help from machines that learn what to do without being explicitly told by us.
- rcthompson 12y ago
  I agree that "discrete vs continuous" is not the perfect way of expressing the difference; it's just an analogy. (But the structural support example is continuous. You could have 9.5 supports by adding a 10th support with half the strength, etc. "Amount of support" is the continuous measure.) But it's not just an issue of graceful degradation. The fact that tiny changes in a program can have very large effects is a feature, not a bug. We grade programming languages on their ability to concisely express complex operations, and that conciseness necessarily means that very different operations are going to have similar expressions (e.g. subsetting rows vs columns of a matrix typically differ only by a small transposition of characters, but the effect is completely different). You can write software that degrades gracefully, but one syntax error (or other "off-by-one-character" problem) is still going to kill the program. You can talk about running your program on a large set of redundant servers with no single point of failure, so that you can update them one-by-one with no downtime, and that makes you robust against even syntax errors. But that's not helping you teach novices how to write code.
pwg 12y ago
Then you might enjoy example 7 on page 18 of this document: UNIQUE ETHICAL PROBLEMS IN INFORMATION TECHNOLOGY By Walter Maner http://faculty.usfsp.edu/gkearns/articles_fraud/computer_ethics.pdf http://faculty.usfsp.edu/gkearns/articles_fraud/computer_eth...
- rcthompson 12y ago
  Well, that's probably where my CS prof got the example. Thanks for pointing me to the likely source!

reikonomusha 12y ago

That's closer to the definition of instability than it is discontinuity.

rcthompson 12y ago
"In mathematics, a continuous function is, roughly speaking, a function for which small changes in the input result in small changes in the output." [1] I could clarify and say that the change doesn't have to be unboundedly large in absolute terms, but rather relative to the change in input. (i.e. a jump discontinuity from 0 to 1 is not absolutely unbounded, but it is relative to an arbitrarily small change across the jump.) [1] http://en.wikipedia.org/wiki/Continuous_function http://en.wikipedia.org/wiki/Continuous_function
deleted 12y ago
[deleted]

deleted 12y ago

[deleted]

SilasX 12y ago

Unless you're doing Rails, in which case it'll be read as a magic method and guess what you meant :-P Seriously, that was a major sticking point for me having programmed for a long time: going from "if you have not declared that identifier, game over" to "magic happens".

lelandbatey 12y ago
That is absolutely something that irritates me. I've just inherited a large RoR application, and the amount of "magic" and things by convention is driving me crazy. There should be answers to questions like "why is this the way it is?!" On a side note, if anyone has some great resources for RoR, I'd love to have them linked. I suspect my inexperience is the source of my problems, and I'm welcome to any assistance any one would like to give.
- quetzthecoatl 12y ago
  Convention over configuration is awesome, if you know the conventions. If you don't, it's all magic. At least with configurations, you can read them and get some pointers.
- grey-area 12y ago
  The guides on the ror website are pretty good: http://guides.rubyonrails.org/ http://guides.rubyonrails.org/ Which bits did you find were magic? The bits of convention I can think of you'd have to know about are: DB naming conventions - these are used so that it can do joins etc easily behind the scenes, they're pretty simple so not a huge problem I find. Rendering at the end of controller actions - it'll render the template with the same path as your route - again relatively straightforward. Class loading - lots of things are loaded at startup time, so that you don't have to include files - I have mixed feelings about this, it feels easy and simple at first, but could leave you unsure where code comes from or which methods you can use in which files (e.g. view helpers). Definitely more magic. One other area which does lead to real problems is that rails sites often use a lot of libraries in the form of gems - this leads to unknown, sometimes poorly maintained or inappropriate code being pulled in at runtime, and makes it far harder to reason about things like say authentication if using a gem. This is my biggest complaint with rails - lack of transparency of code paths when using gems like devise, paperclip etc but it is unfortunately quite common in web frameworks They actually got rid of quite a few bits of method_missing madness I think recently so that magic is gone at least (all those magic find_by_ methods are deprecated or removed, not sure which as I never used them). I haven't found the conventions get in the way much as it's something you learn once and can apply anywhere, but completely understand why someone might object to some of the magic setup for helpers/rendering.

bhaumik 12y ago

Wahoowa! This also explains the popularity of interactive platforms like Codecademy/CodeSchool/Treehouse, etc. Ton of handholding and pre-filled syntax. We describe them to our students as "coding on training wheels." Cathy, a new frontend student, experienced similar struggles when starting her first real project - a simple HTML/CSS resume. She spent countless hours fixing minor typos and almost quit. It wasn't until she was reassured that this was _normal_ and "real" programming was much different from codecademy did she feel like she was truly learning. She wrote about her first month (with similar highs and lows as OP's visual) in this post: http://blog.thinkful.com/post/98829096308/my-first-month-coding-an-emotional-roller-coaster http://blog.thinkful.com/post/98829096308/my-first-month-cod.... side note: Erik (OP) is an incredible guy, we had the pleasure to share our experiences in Edtech and it's obvious that he truly cares about student outcomes.

chii 12y ago
> She spent countless hours fixing minor typos and almost quit. it's interesting anecdote! When i was at uni, i noticed that a large number of "beginners" tend to fall into this category too - frustrated at minor typos/language idiosyncrasies. Those who had the mental strength to endure it end up passing the class, while those that just gave up will almost inevitably change their major (and thus, stop programming i guess?). But i think this is a result of poor educational methods, not because of an inherent property in programming.

superobserver 12y ago

> But if you're writing a 10-line program and you forget one of the lines (or even one character), the program isn't 10% wrong, it's 100% wrong. (For example, instead of compiling and running correctly, it doesn't compile at all. Completely different results.) This is where the beauty/simplicity of some programming languages, namely, intepreted languages (e.g., Python), comes in: if a bad line of code never gets executed, then the program itself will run fine. In other words, if the line is never called in the program, then you'll not know that the functionality that that line presented was bad. In this case, the analogy breaks down a bit - and also shows why certain languages are easier to learn than others (e.g., Python vs. C++).

nsomaru 12y ago
I'd rather know when something is incorrect, rather than pushing to production and finding out later because someone else took that code path.
- DougWebb 12y ago
  If you rely on your compiler to tell you that your code is correct, there are whole classes of bugs that are waiting to surprise you in production. I think that many years of developing large applications in Perl were really good for me. Perl is compiled when you run it, so you get the basic-syntax check that you get with other languages. But it's also very lenient, so you learn through experience to get your logic right, test return values, and do all of the things that help make sure that a program which executes is executing correctly.
  - brianwawok 12y ago
    There is a difference from RELY on compile to catch 100% of bugs, vs having an awesome type system that can take whole CLASSES of bugs and make them impossible to get past a compile. Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. Is either ideal? No. Can both be improved by adding a few tests? Yes.

__throwaway2015 12y ago

In a general sense, it can be more difficult to reason about what effect adding or removing something will have because the skill is still being developed.

rcthompson 12y ago
Yes, but that's true of any new skill that one might try to learn. I'm talking about specifically what makes programming harder than other things to learn. When things are continuous, you can at least experiment by making small changes and be confident that those changes will only have small effects.

rapind 12y ago

If you're lucky it won't compile. It's when it's 2% wrong that makes programming so hard.

the_cat_kittles 12y ago

i say its "brittle" ...those words discrete and continuous dont really apply cleanly, though i understand the idea somewhat intuitively

emmelaich 12y ago
Yes, "brittle" is how it's been described to me and how I describe it to others.

Yhippa 12y ago

I remember this one thing he pounded into our brains: "CS doesn't stand for Computer Science. It stands for Common Sense!" Heard ad nauseam in CS 340.

SiVal 12y ago

With respect to your CS prof at one of my favorite places (Go Cavaliers!), this is not an issue of discrete vs. continuous. If your structure can have either 9 or 10, but not 9.001, supports, it is discrete, not continuous, regardless of failure mode. And remove one of the 3 legs of your stool, and you probably wouldn't have 2/3rds of its support remaining, but whether you did or didn't would be an issue of proportionality, not continuity. There are a lot of jumbled concepts here, most of which don't matter anyway, because what you are talking about is the phenomenon of graceful degradation. In the physical world, both natural and man-made, almost nothing at the macro scale is ever perfect, so the best designs tend to be those that remain good enough under the widest range of circumstances vs. a more common software goal of being perfect under perfectly controlled circumstances. As software gradually moves out from the wall garden of a single mainframe to fill the world with interacting systems spanning diverse machines, sensors, communications channels, data types, etc., design for graceful degradation becomes more and more of a focus for professional software architects. Coding in the gracefully degrading way is much harder than coding in the "if even one of your ten lines is wrong, you crash" tradition. The fact that even the latter is so hard for us humans means we will need more and more help from machines that learn what to do without being explicitly told by us.

rcthompson 12y ago
I agree that "discrete vs continuous" is not the perfect way of expressing the difference; it's just an analogy. (But the structural support example is continuous. You could have 9.5 supports by adding a 10th support with half the strength, etc. "Amount of support" is the continuous measure.) But it's not just an issue of graceful degradation. The fact that tiny changes in a program can have very large effects is a feature, not a bug. We grade programming languages on their ability to concisely express complex operations, and that conciseness necessarily means that very different operations are going to have similar expressions (e.g. subsetting rows vs columns of a matrix typically differ only by a small transposition of characters, but the effect is completely different). You can write software that degrades gracefully, but one syntax error (or other "off-by-one-character" problem) is still going to kill the program. You can talk about running your program on a large set of redundant servers with no single point of failure, so that you can update them one-by-one with no downtime, and that makes you robust against even syntax errors. But that's not helping you teach novices how to write code.

pwg 12y ago

Then you might enjoy example 7 on page 18 of this document: UNIQUE ETHICAL PROBLEMS IN INFORMATION TECHNOLOGY By Walter Maner http://faculty.usfsp.edu/gkearns/articles_fraud/computer_ethics.pdf http://faculty.usfsp.edu/gkearns/articles_fraud/computer_eth...

rcthompson 12y ago
Well, that's probably where my CS prof got the example. Thanks for pointing me to the likely source!