6 ms·

> Doing it the other way is a common pitfall in teaching programming concepts. 100% disagree If someone is brand new to programming and you're expecting to te

> Doing it the other way is a common pitfall in teaching programming concepts. 100% disagree If someone is brand new to programming and you're expecting to teach them the following concepts: A class, methods, static methods, data types, method return types, void return type, arrays, and namespaces just to be able to write a simple "Hello World" app [1] I think your approach is the one that's misguided. The most common mistaken people make in teching is teaching things in the order the were discovered historically. Not always, but very often that is a distraction. The second most common is teaching from the outside in. The best way to teach is to explain what your tyring to accomplish and start with a very simple example for people to play with. Then pick on concept and modify it so they can see the results of those changes. Then pick the next concet and modify that so they can see tangibly what that means. In the hello world example, it would be starting with the program in [1] and focusing just on the constant string "Hello World!". Change it see what that means, understand what's going on. Then move out to the Console.WriteLine. Make a copy of that line have two lines of it then 3 to understand the method call. Then swap to Console.ReadLine to see what a different method call can do. Continue exploring out from that core concept. The "static" identifier on a method class is not where to start teaching someone programming. It's also why Racket removed a lot of the boiler plate from thier core teaching langauges for students. For them to not even have to see the things that are unnecessary at that point in their learning.[2] [1] https://www.geeksforgeeks.org/java-hello-world-program/ https://www.geeksforgeeks.org/java-hello-world-program/ [2] https://docs.racket-lang.org/drracket/htdp-langs.html https://docs.racket-lang.org/drracket/htdp-langs.html

eyelidlessness 2y ago
You say 100% disagree, but then everything you say seems to agree with my points. I would even go so far as to endorse your response as a longer form elaboration of exactly what I was trying to get across.
- BoiledCabbage 2y ago
  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

You say 100% disagree, but then everything you say seems to agree with my points. I would even go so far as to endorse your response as a longer form elaboration of exactly what I was trying to get across.

BoiledCabbage 2y ago
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!