Now that we're done studying the four principle ideas of calculus--[url=https://www.geogebra.org/m/x39ys4d7#material/ftvamrcu]functions[/url], [url=https://www.geogebra.org/m/x39ys4d7#material/zruqdnrq]limits[/url], [url=https://www.geogebra.org/m/x39ys4d7#material/rwdrnrw6]derivatives[/url] and [url=https://www.geogebra.org/m/x39ys4d7#material/ufsyvbbx]integrals[/url]--I hope you'll agree that calculus is not impossible. Intricate? Sure. Surprising? Absolutely! But [i]impossible[/i]? No way. [br][br]In some sense, you can summarize calculus really simply:[br][br][list][*][url=https://www.geogebra.org/m/x39ys4d7#material/ftvamrcu]Functions[/url] are a great tool for making mathematical models of the world you live in.[/*][*][url=https://www.geogebra.org/m/x39ys4d7#material/rwdrnrw6]Derivatives[/url] of functions provide you information about the growth rate of a function.[/*][*][url=https://www.geogebra.org/m/x39ys4d7#material/ufsyvbbx]Integrals[/url] of functions provide you with information about the accumulated effect of a function.[/*][*][url=https://www.geogebra.org/m/x39ys4d7#material/zruqdnrq]Limits[/url] are the "guts" under the hood of both derivatives and integrals.[/*][*][url=https://www.geogebra.org/m/x39ys4d7#material/hveqkv6m]The Fundamental Theorem of Calculus [/url]relates bullet points 2 and 3 in a surprising and useful way.[/*][/list][br]And even if you're still shaky with the concepts "growth rate" and "accumulated effect", you can simplify them both down to their geometrical (if not utilitarian) core. The derivative is a tool for finding the slope of the tangent (AKA "matching") line of a function, and the integral is a tool for finding the area under the graph of a function.[br][br]So why is it a common refrain that "Calculus is [i]impossible[/i]"? I think it's because Calculus pushes you to be extremely flexible with object types and object equivalencies, and if you don't keep track of objects--specifically which are equivalent and which are not--calculus actually is impossible. [br][br]What does that mean? Think back to the [url=https://www.geogebra.org/m/x39ys4d7#material/rwdrnrw6]definition of the derivative[/url]. This is the first major definition of calculus. What we learned was that if a function [code]f(x)[/code] is a mathematical model, then the derivative of [code]f(x)[/code] is [i]another function, [/i][code]f'(x)[/code][i],[/i] that keeps track of the growth rate of [code]f(x)[/code]. In other words, derivatives tell you how a model of a quantity is changing. Or you might also describe the derivative in an object-oriented fashion: the "[code]derivative[/code]" acts on "[code]function[/code]" objects to produce new "[code]function[/code]" objects (derivatives) that report "[code]growth rate[/code]" objects. [br][br]But if you start unpacking this definition, there's quite a few other objects that are swirling around under the hood, some are equivalent, some are not. Let's walk through them. First of all what exactly is the "[code]growth rate[/code]" object the derivative reports? Intuitively it's how quickly the function [code]f(x)[/code] is growing. But the mathematical construction of a "[code]growth rate[/code]" object was actually as a "[code]slope of the tangent line[/code]" object. So the "[code]derivative[/code]" concept actually reported a "[code]slope of the tangent line[/code]" object, and in the context of a model, a "[code]slope of the tangent line[/code]" object is equivalent to a "[code]growth rate" [/code]object. What's worse: in a mathematical vacuum--where a function is [i]not[/i] a mathematical model--there is no relationship between these objects; the equivalence only exists when the original "[code]function[/code]" object is a model of something real. Are you starting to see how calculus is challenging you to be flexible with object types?[br][br]But that's hardly the end. What's a "[code]slope of tangent line[/code]" object? As [url=https://www.geogebra.org/m/x39ys4d7#material/nppaxatp]we saw when defining it[/url], "[code]slope of tangent line[/code]" objects are really "[code]limit of slope of secant line[/code]" objects. Yet another object equivalency, but this one [i]is[/i] valid in a mathematical vacuum! [br][br]To understand the derivative fully you really do need to have a firm understanding of the relationships amongst these object types. Slip up just one of these object types, and you really don't understand what's going on, and worse yet, it might actually be [i]impossible[/i] to proceed.[br][br]For instance, a common mistake is for people to mix up a "[code]slope of tangent line[/code]" object with simply a "[code]tangent line[/code]" object when trying to gain conceptual understanding of the derivative. But that's wrong. The derivative does [i]not[/i] report back tangent lines; it reports back a [i]slope[/i] of a tangent line. If that object equivalence isn't correct, problems immediately start to form. For instance, if a student incorrectly expects a derivative to report back a "[code]tangent line[/code]" object, but when they use a derivative they get a "[code]number[/code]" object as an output, confusion ensues. [i]"What is this thing? Where's the line? Where's the y-intercept?"[/i] This type of mistake is exactly where I believe the common refrain "calculus is impossible" stems from. The processes of calculating and using derivatives are entirely mechnical, but understanding the objects that you are interfacing with is tricky.[br][br]The good news is, developing comfort around object types is precisely one of the skills acquired in computer programming, and it's no accident that this book relied so heavily on Geogebra. Using a computer forces you to think carefully about object types. If you attempt to use a "[code]line[/code]" object where a "[code]number[/code]" object is expected, you get an error, and are forced to confront it before you can move forward. Although it's frustrating, immediate feedback that an object-type-error has occurred is better than spending time with the error and allowing it to creep in and poison other parts of your conceptual understanding. [br][br]So what can we do about this? How can we get people to stop staying "calculus is impossible?" In my opinion, the pathway is to push people to think about calculus in an object-oriented perspective. Students of calculus don't need much practice with computations and calculations; let the computer do most of that. But students [i]do[/i] need to be challenged to think in an object-oriented fashion. This is precisely one of the subtle things I did throughout this book. I went to great lengths to identify object types as accurately as possible in the hope that you might start to think this way as well. As one example, throughout the [url=https://www.geogebra.org/m/x39ys4d7#chapter/398513]chapter on functions[/url], I made a point out of fumbling with object types, specifically, I was purposefully clumsy with "[code]point on graph of function[/code]" objects and "[code]output of function[/code]" objects (which are special "[code]number[/code]" objects) to force you to develop flexibility. In my opinion however, you really can't tell the reader you're doing this because telling them we're about to study "object type flexibility" really will scare people away, and that would defeat the whole purpose of the book.[br][br]It's worth pointing out also that there were plenty of times where I simply couldn't be exactly accurate with object types because the language would become too cumbersome. A good example is near the end of "[url=https://www.geogebra.org/m/x39ys4d7#material/yqenataa]Falling Stuff on Earth[/url]". I wrote [br][br][quote]The code snippet [code]intersect(s(x),y=0)[/code] will find two points, one of which is [code]SPLAT!=(62.79,0)[/code] the time the model predicts the missile will land.[/quote]Do you see the object error? I'm wrongly identifying [code]SPLAT!,[/code] which is a "[code]point[/code]" object, as a "[code]time[/code]" object. Only the x-coordinate of SPLAT! is a "[code]time[/code]" object. I did this because the language would become unwieldy if I said "the x-coordinate of which is the time the model predicts the missile will land."[br][br]Nonetheless, it's a minor error, and I expect you read right through it, quickly building a temporary "[code]point[/code]" and "[code]time[/code]" object equivalency on the spot to make sense of the situation. This is a sure sign that you deeply understand the object equivalencies that are swirling around and are able to be flexible with them. That said, if you attempt to use [code]SPLAT![/code] in the function [code]s(x)[/code], Geogebra will respond with an error. The function [code]s(x)[/code] can only accept "[code]number[/code]" objects. If you give it a "[code]point[/code]" object it really isn't sure what to do with it. If you want to feed [code]SPLAT![/code] to [code]s(x)[/code], you'd need to use something like [code]x(SPLAT!)[/code] to obtain the x-coordinate of [code]SPLAT![/code] as a "[code]number[/code]" object, and only then can you feed that "[code]number[/code]" object to [code]s(x)[/code].[br][br]You might balk at needing to do such things, but it is my firm belief that understanding the [i]relationships between the concepts and[/i] [i]objects[/i] is the real challenge in calculus. The algebraic calculations themselves are mechanical and the stuff a computer can do. But knowing what object relates to what other object, how they are similar, and how they are different; this is the job of us humans and this is what must be taught in calculus courses to achieve students success.