6 ms·

Curiously, not all minds are alike or equal so perhaps there's scope for using tools such as Scratch to teach coding principles to kids who might not be wired t

Curiously, not all minds are alike or equal so perhaps there's scope for using tools such as Scratch to teach coding principles to kids who might not be wired to so easily Get It as you evidently are.

vorpalhex 5y ago
I think you are misinterpreting the point. Scratch is actually harder. Scratch relies on making sense of these big blocks with little blocks and these UI patterns that don't make sense and aren't seen elsewhere. It relies on finding blocks from a palette. Something like QuickBasic or TurboPascal or Wiring (Arduino) doesn't. You write the program from top to bottom using magic words (syntax) and you press f5 and the computer follows the incantation.
- detaro 5y ago
  If this is universally true as you claim, then why does practice show that Scratch works better for some kids, especially young ones?
- detritus 5y ago
  I think it is you who misinterpret the point. As a counter - are there things in life other people were better at compared to you? Perhaps painting or writing or cooking? That 'easier to parse syntax' of yours might actually be trickier for other minds to work with, where they instead benefit from big blocks, little blocks and coloured abstractions that might be like so much fluff to you.
  - vorpalhex 5y ago
    I understand people have different ways of learning and comprehending. No way of learning or comprehending makes 5+ discrete tasks easier than 1. There is no mental model that changes the actual bitrate flow of comprehension. Yes, visual learners are a thing. No, visual learners do not prefer doing more work nor does it help them learn "faster". Recognizing and discriminating colors/shapes/sizes is always more work (and more abstraction! "Blue blocks are conditional statements" is learned behavior!)
    - detritus 5y ago
      I think you're mistaking easier for quicker, but I can see that neither of us are going to agree with the other here.
      - vorpalhex 5y ago
        Be careful here and don't assume what I mean. Take a moment and write out the steps. The direct text entry programmer has to: 1. Decide what they want to happen next 2. Figure out the syntax to make that happen 3. Write out the syntax Our visual programmer: 1. Decide what they want to happen next 2. Figure out the syntax (now "big green two pronged if block" instead of "if") 3. Look over the palette and visually identify the block (expensive! non-facial discrimination is tiring) 4. Drag the block from the palette to the code section (weird UI interaction, also requires both fine + gross movement, also expensive) Notice that our "visual" programmer still has to execute all the same non-visual steps! We haven't made the actual work visual, we just made the UI really annoying and added a discrimination task to it - which is tiring even for our visual learner. Text _is_ visual, but it's visually expensive to consume. Brightly colored complex little blocks are also.. well basically just as visually expensive. We didn't make programming visual. We didn't make the skill threshold lower or easier or even _different_. We just added more work.
        TuringTest 5y ago
        The part you're utterly missing is that, depending on the brain, steps 3 and 4 in for the visual tool may be immensely easier than step 3 in the text tool, so that they are performed as a simple no-think direct-manipulation operation that requires no effort at all, while the "write out the syntax" step may be a slow, painful and error-prone process of trial and error until you put in all the right characters in the correct order and get the damn parser to stop complaining. You seem to be wired to accept the later as trivial and the former as hard, but some of us are really exactly the opposite. I know for certain that this is how I see writing programs in pure text, to the point that I stopped programming in traditional languages; my brain is too high-level oriented to remember all the pesky little details that APIs and formal syntax require; give me high-level programming blocks that you just invoke and place with a few gestures any time. Unfortunately there are very few general-purpose visual languages, so my options at building automated systems are limited; although fortunately this is starting to change, and a new breed of powerful no-code and low-code tools is appearing that shows promise, so I'll be able to build complex systems again by using high-level concepts as building blocks, without being slowed down by bloody trivial syntax errors.
  - zozbot234 5y ago
    I wonder why we can't have a unified tool that supports both access modes. A syntax that's "easy to parse" should also be easy to render into visual snap-blocks.
    - dagw 5y ago
      That was the big thing 20ish years ago. Programs where you could 'draw' your application and have code (most often Java) generated on the fly. Or you could feed it Java code and it would generate the diagrams for you and then you could edit the diagrams and get updated code. Lots of companies spent huge amounts of money both buying and developing those types of solutions. It turns out that creating a 1-to-1 mapping between code and diagrams was basically impossible and you ended up with unreadable code and unusable diagrams.
      - zozbot234 5y ago
        True, but Scratch is not design-level diagrams; it's just a structured syntax made of "blocks" that snap together, it represents actual code. I'd also argue that simple diagram-generating tools are quite viable when used to make sense of a large code base at the highest level, even though I agree that the theorized "edit and generate code" workflows don't work nearly as well in practice.

vorpalhex 5y ago

I think you are misinterpreting the point. Scratch is actually harder. Scratch relies on making sense of these big blocks with little blocks and these UI patterns that don't make sense and aren't seen elsewhere. It relies on finding blocks from a palette. Something like QuickBasic or TurboPascal or Wiring (Arduino) doesn't. You write the program from top to bottom using magic words (syntax) and you press f5 and the computer follows the incantation.

detaro 5y ago
If this is universally true as you claim, then why does practice show that Scratch works better for some kids, especially young ones?
detritus 5y ago
I think it is you who misinterpret the point. As a counter - are there things in life other people were better at compared to you? Perhaps painting or writing or cooking? That 'easier to parse syntax' of yours might actually be trickier for other minds to work with, where they instead benefit from big blocks, little blocks and coloured abstractions that might be like so much fluff to you.
- vorpalhex 5y ago
  I understand people have different ways of learning and comprehending. No way of learning or comprehending makes 5+ discrete tasks easier than 1. There is no mental model that changes the actual bitrate flow of comprehension. Yes, visual learners are a thing. No, visual learners do not prefer doing more work nor does it help them learn "faster". Recognizing and discriminating colors/shapes/sizes is always more work (and more abstraction! "Blue blocks are conditional statements" is learned behavior!)
  - detritus 5y ago
    I think you're mistaking easier for quicker, but I can see that neither of us are going to agree with the other here.
    - vorpalhex 5y ago
      Be careful here and don't assume what I mean. Take a moment and write out the steps. The direct text entry programmer has to: 1. Decide what they want to happen next 2. Figure out the syntax to make that happen 3. Write out the syntax Our visual programmer: 1. Decide what they want to happen next 2. Figure out the syntax (now "big green two pronged if block" instead of "if") 3. Look over the palette and visually identify the block (expensive! non-facial discrimination is tiring) 4. Drag the block from the palette to the code section (weird UI interaction, also requires both fine + gross movement, also expensive) Notice that our "visual" programmer still has to execute all the same non-visual steps! We haven't made the actual work visual, we just made the UI really annoying and added a discrimination task to it - which is tiring even for our visual learner. Text _is_ visual, but it's visually expensive to consume. Brightly colored complex little blocks are also.. well basically just as visually expensive. We didn't make programming visual. We didn't make the skill threshold lower or easier or even _different_. We just added more work.
      - TuringTest 5y ago
        The part you're utterly missing is that, depending on the brain, steps 3 and 4 in for the visual tool may be immensely easier than step 3 in the text tool, so that they are performed as a simple no-think direct-manipulation operation that requires no effort at all, while the "write out the syntax" step may be a slow, painful and error-prone process of trial and error until you put in all the right characters in the correct order and get the damn parser to stop complaining. You seem to be wired to accept the later as trivial and the former as hard, but some of us are really exactly the opposite. I know for certain that this is how I see writing programs in pure text, to the point that I stopped programming in traditional languages; my brain is too high-level oriented to remember all the pesky little details that APIs and formal syntax require; give me high-level programming blocks that you just invoke and place with a few gestures any time. Unfortunately there are very few general-purpose visual languages, so my options at building automated systems are limited; although fortunately this is starting to change, and a new breed of powerful no-code and low-code tools is appearing that shows promise, so I'll be able to build complex systems again by using high-level concepts as building blocks, without being slowed down by bloody trivial syntax errors.
- zozbot234 5y ago
  I wonder why we can't have a unified tool that supports both access modes. A syntax that's "easy to parse" should also be easy to render into visual snap-blocks.
  - dagw 5y ago
    That was the big thing 20ish years ago. Programs where you could 'draw' your application and have code (most often Java) generated on the fly. Or you could feed it Java code and it would generate the diagrams for you and then you could edit the diagrams and get updated code. Lots of companies spent huge amounts of money both buying and developing those types of solutions. It turns out that creating a 1-to-1 mapping between code and diagrams was basically impossible and you ended up with unreadable code and unusable diagrams.
    - zozbot234 5y ago
      True, but Scratch is not design-level diagrams; it's just a structured syntax made of "blocks" that snap together, it represents actual code. I'd also argue that simple diagram-generating tools are quite viable when used to make sense of a large code base at the highest level, even though I agree that the theorized "edit and generate code" workflows don't work nearly as well in practice.