4 ms·

A great teaching technique I learned from a very good match teacher is that when explaining core concepts, the simplified definitions don't need to be completel

A great teaching technique I learned from a very good match teacher is that when explaining core concepts, the simplified definitions don't need to be completely right. They are much simpler to grasp and adding exceptions to these is also quite easy compared to trying to understand correct, but complex, definitions at the beginning.

ajross 1y ago
Yeah, but the whole purpose here is "flattening the learning curve", and telling people code will work when it won't is doing the opposite. That bullet, at its most charitable, defines the "idealized goal" of the borrow collector. The actual device is much less capable (as it must be, as the goal is formally undecidable!), and "learning rust" requires understanding how.
- AStonesThrow 1y ago
  Ironically, most people understand "learning curves" counterintuitively. If a "learning curve" is a simple X-Y graph with "time" and "knowledge" being on each axis respectively, then what sort of learning curve is preferable: a flatter one or a steep one? Clearly, if you graph large increases of knowledge over shorter periods of time, a steeper learning curve is more preferable. "Flattening the learning curve" makes it worse! But for some reason, people always reverse this meaning, and so the common idiom breaks down for people who try to reason it out.
  - zigzag312 1y ago
    Replace "knowledge" with "required knowledge". It's not about how efficiently you can learn, but how much do you need to learn in a specific amount of time. If you need to learn a lot in short amount of time (which is a hard thing to do) the curve is steep. You can flatten the curve by increasing the time you have available or by requiring less knowledge.
  - zahlman 1y ago
    > But for some reason, people always reverse this meaning, and so the common idiom breaks down for people who try to reason it out. Because one imagines the "curve" like physical topology, with the goal of reaching the top.
- zigzag312 1y ago
  > ... defines the "idealized goal" of the borrow collector. The actual device is much less capable I think here you expanded on the original point in a good way. I would then continue with adding additional set of points covering the issue in greater detail and a set of examples of where this commonly happens and how to solve it.
- zahlman 1y ago
  > Yeah, but the whole purpose here is "flattening the learning curve", and telling people code will work when it won't is doing the opposite. "Flattening the learning curve" is perhaps a wrong metaphor - you can't actually change what needs to be learned; you can only make it easier to learn. Saying something that is usually right and can be corrected later is a standard pedagogical approach - see https://en.wikipedia.org/wiki/Wittgenstein%27s_ladder https://en.wikipedia.org/wiki/Wittgenstein%27s_ladder . To extend the metaphor, the ladder is there to help you climb the learning curve.
  - ajross 1y ago
    It's not "usually right" though. Rust can't compile a doubly-linked list[1] without unsafe! And people trip over this immediately when they start writing Rust, because that kind of code is pervasive in other environments. Thus statements like "Rust just doesn't like dangling pointers" are unhelpful, because while it's true it's not sufficient to write anything but the most trivial code. [1] Or basically any graph-like data structure that can't be trivially proven to be acyclic; even lots of DAG-like graphs that "should" be checkable aren't.
    - zahlman 1y ago
      People write non-trivial code all the time without worrying about that sort of thing. Quite a lot can be done with plain tree structures. In the real world, your data is flat and even your conventions for interpreting it as non-flat (such as, say, JSON) only create trees that perhaps simulate back-links with another informal protocol.
      - ajross 1y ago
        Sigh. The whole premise of the linked article is, in fact, that people hit validation problems with the borrow checker early on when learning rust and that attention is needed to "flatten the learning curve" to assist their understanding of what we all agree is a unique and somewhat confusing set of semantics relative to competing languages. Rust flaming is just so terribly exhausting. No matter how reasonable and obvious a point is there's always someone willing to go to the mattresses in a fourty-comment digression about how Rust is infallible.

ajross 1y ago

Yeah, but the whole purpose here is "flattening the learning curve", and telling people code will work when it won't is doing the opposite. That bullet, at its most charitable, defines the "idealized goal" of the borrow collector. The actual device is much less capable (as it must be, as the goal is formally undecidable!), and "learning rust" requires understanding how.

AStonesThrow 1y ago
Ironically, most people understand "learning curves" counterintuitively. If a "learning curve" is a simple X-Y graph with "time" and "knowledge" being on each axis respectively, then what sort of learning curve is preferable: a flatter one or a steep one? Clearly, if you graph large increases of knowledge over shorter periods of time, a steeper learning curve is more preferable. "Flattening the learning curve" makes it worse! But for some reason, people always reverse this meaning, and so the common idiom breaks down for people who try to reason it out.
- zigzag312 1y ago
  Replace "knowledge" with "required knowledge". It's not about how efficiently you can learn, but how much do you need to learn in a specific amount of time. If you need to learn a lot in short amount of time (which is a hard thing to do) the curve is steep. You can flatten the curve by increasing the time you have available or by requiring less knowledge.
- zahlman 1y ago
  > But for some reason, people always reverse this meaning, and so the common idiom breaks down for people who try to reason it out. Because one imagines the "curve" like physical topology, with the goal of reaching the top.
zigzag312 1y ago
> ... defines the "idealized goal" of the borrow collector. The actual device is much less capable I think here you expanded on the original point in a good way. I would then continue with adding additional set of points covering the issue in greater detail and a set of examples of where this commonly happens and how to solve it.
zahlman 1y ago
> Yeah, but the whole purpose here is "flattening the learning curve", and telling people code will work when it won't is doing the opposite. "Flattening the learning curve" is perhaps a wrong metaphor - you can't actually change what needs to be learned; you can only make it easier to learn. Saying something that is usually right and can be corrected later is a standard pedagogical approach - see https://en.wikipedia.org/wiki/Wittgenstein%27s_ladder https://en.wikipedia.org/wiki/Wittgenstein%27s_ladder . To extend the metaphor, the ladder is there to help you climb the learning curve.
- ajross 1y ago
  It's not "usually right" though. Rust can't compile a doubly-linked list[1] without unsafe! And people trip over this immediately when they start writing Rust, because that kind of code is pervasive in other environments. Thus statements like "Rust just doesn't like dangling pointers" are unhelpful, because while it's true it's not sufficient to write anything but the most trivial code. [1] Or basically any graph-like data structure that can't be trivially proven to be acyclic; even lots of DAG-like graphs that "should" be checkable aren't.
  - zahlman 1y ago
    People write non-trivial code all the time without worrying about that sort of thing. Quite a lot can be done with plain tree structures. In the real world, your data is flat and even your conventions for interpreting it as non-flat (such as, say, JSON) only create trees that perhaps simulate back-links with another informal protocol.
    - ajross 1y ago
      Sigh. The whole premise of the linked article is, in fact, that people hit validation problems with the borrow checker early on when learning rust and that attention is needed to "flatten the learning curve" to assist their understanding of what we all agree is a unique and somewhat confusing set of semantics relative to competing languages. Rust flaming is just so terribly exhausting. No matter how reasonable and obvious a point is there's always someone willing to go to the mattresses in a fourty-comment digression about how Rust is infallible.