3 ms·

I see you claim that, but unless I misunderstanding that completely contradicts our claim here: > A very common example is the historically necessary boilerpla

I see you claim that, but unless I misunderstanding that completely contradicts our claim here: > A very common example is the historically necessary boilerplate in Java’s Hello World, where quite a few concepts are present but handwaved away as you don’t need to worry about this now. What I'm saying is exactly that. Handwave past all of the boilerplate like the static declaration and only focus on the most important to learn up front (ex what a string is). Could you explain how your statement of initially teching the boilerplate is the same as my statement of ignoring it? In my example, the entire time they are working with strings or readline/writeline method calls they are entirely ignoring what a static/class/args all mean and they are just boiler plate they have to type until they get to that stage in later lessons.

eyelidlessness 2y ago
> Could you explain how your statement of initially teching the boilerplate is the same as my statement of ignoring it? I specifically said that including the boilerplate is a common pitfall, and requires teaching around a bunch of impertinent concepts. I also chose the example for a reason very close to your example with Racket: later versions of Java have similarly aimed to reduce the necessary boilerplate. And if I’m not mistaken, the learning experience is a motivating factor for that as well. If emphatically agreeing with you in so many words isn’t enough to convince you that I agree with you, maybe you’re just looking for something to argue about?
- 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 ago
    I 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!

eyelidlessness 2y ago

> Could you explain how your statement of initially teching the boilerplate is the same as my statement of ignoring it? I specifically said that including the boilerplate is a common pitfall, and requires teaching around a bunch of impertinent concepts. I also chose the example for a reason very close to your example with Racket: later versions of Java have similarly aimed to reduce the necessary boilerplate. And if I’m not mistaken, the learning experience is a motivating factor for that as well. If emphatically agreeing with you in so many words isn’t enough to convince you that I agree with you, maybe you’re just looking for something to argue about?

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 ago
  I 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!