3 ms·
> I specifically said that including the boilerplate is a common pitfall, and requires teaching around a bunch of impertinent concepts. And again, I'm saying I
by BoiledCabbage 2y ago
> I specifically said that including the boilerplate is a common pitfall, and requires teaching around a bunch of impertinent concepts.
And again, I'm saying I disagree with this. You are saying don't include the boilerplate at all when teaching. I a saying, do include the boilerplate and don't teach it until students are ready to understand it.
As a separate topic, if the language doesn't need boilerplate to make the program work (like Racket) that's spectacular. But if it does, then I'm explicitly saying "show the boilerplate and explain 'you don't need to focus on it now. You will learn it later'".
It is best give people a fully working program at all times, even if they don't understand all of it. So they can play around with it, rather than just read along while the author writes about what would have happened if it were fully functioning code they could play with.
And to make it very clear, the example I linked to explicitly includes all of the boilerplate, and I explained exactly the best method to teach a student with that specific concrete source code.
> https://www.geeksforgeeks.org/java-hello-world-program/ https://www.geeksforgeeks.org/java-hello-world-program/
Now all of that said - this isn't really important enough to continue arguing on the internet over. I think we both had good intentions but just weren't communicating clearly. I hope you have a great day.
- eyelidlessness 2y agoI understand you better now. I was confused by your Racket example, as it represents exactly the same direction the Java example has gone. As you say, definitely not worth arguing further. But I appreciate your clarification!