First, thanks for your feedback on this – I appreciate your perspective, and I know you’ve done radically more both with respect to Julia itself and the teaching of it than I have! A few comments:
I may be missing something… consider the trade-offs of maintaining that vs just referring to selected chapters of the manual.
I agree that – excluding some things like choosing a specific plotting package, having a loose theme connecting the examples we work through, and a few general remarks at the end of the chapters – the information content is pretty much a strict subset of what’s in the manual. I also agree that there is a non-negligible cost to not just pointing directly to the manual for most things (and one might reasonably complain that with the big green “this guide is not a substitute for reading the manual” disclaimer at the top of page 1 that I’m trying to have it both ways).
On the other hand, I don’t really believe that the manual is the perfect pedagogical structuring of information for most students who are new to the language, and I think that’s a tension which almost always exists for something striving to be both authoritative and comprehensive. Certainly when I’ve been trying to learn the language recently I’ve always had the manual open on one tile of my screen, but frequently while simultaneously reading through a different tutorial, or watching one of the playlists on the julialang channel, or… So, yes, there is a cost to maintaining a guide vs referring to sections of the manual, but I also think there can be a real benefit from having a somewhat expanded introductory guide that tries to synthesize a lot of that information. (I hope I don’t need to say this, but to be clear: obviously I don’t think what I wrote is “a perfect pedagogical structuring” either! But I do hope I can eventually get it into a shape where it’s a positive and non-zero contribution.)
The animal type hierarchy reminds me of C++ textbook examples…
I guess my own education is showing through too much (and so much for the BigInt
joke)! But this is a good point – the text illustrates that you can build that kind of abstract type hierarchy, but it might also accidentally emphasize that you should think of organizing your code this way (even if you aren’t going to use it for dispatch).
Similarly, perhaps the type tree in B.1 reinforces the idea of “think of everything in terms of its “is-a” classification” rather than “think about what common interfaces we want to define for dispatch”. I’ll think about how to better work through these concepts.
When I teach Julia, I just tell students about good practices so that you don’t ever have to think about corner cases.
I agree that, given the stage the students will be at by the time they get to the section on scope in E.2.1, just a few words plus a pointer to the manual might be all that I need to do. Out of (legitimate) curiosity – does the quoted advice above work? In my limited experience (and not in the context of this specific example, of course), students will (a) know about good practices but (b) get themselves into trouble anyway by selectively ignoring them.
Appendix D is great…
Thanks for ending on a positive note, and more importantly thanks for taking the time to look through what I did and share your perspective!