7 ms·

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 o

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.
      - vorpalhex 5y ago
        Do you actually program in scratch? Take a moment if you haven't and boot it up. I think there are web versions available now. Give it a go. Build a (simple) program. There's a reason it keeps not really taking off. I'm not saying text entry is free. I'm saying that the palette concept is more expensive - even for visual learners. Obviously languages (block based or text) can be easier or harder, eg python is less fussy than assembly. What visual/block based languages do you use currently?
        TuringTest 5y ago
        I'm not saying that Blocks is a good programming language, nor defending it as a go-to tool; I know it is quite cumbersome to build programs in it - but I think it's largely because it's imitating classic imperative languages instead of being designed from the bottom up to take advantage of visual representation and interactive development. Still, it may be a very good introductory tool for learning classic-style programming (certainly better than Python for a primary school classroom; direct manipulation is just so superior for the first impression, when getting the students motivation is make-or-break). I was referring to your defense of textual programming as inherently superior, which I don't see as justified. Classical languages have a refinement over decades that visual languages lack, but I think it is possible, and I think we are getting to a point where building such languages is starting to become viable. > I'm not saying text entry is free. I'm saying that the palette concept is more expensive - even for visual learners This is simply not true. Recognition is easier than recall, even for textual learners; so even if toolbars require more steps, those are way easier steps. Even if you're talking about expensive in time and not actual effort, physically entering code is the task that less actual time takes of programming: thinking what code you need to include takes much more time, so anything that reduces that time will accelerate development. Programmers usually are not aware of this fact because they are distracted by all the thinking, but the actual input method is usually not that relevant except for people with disabilities. (Btw visual vs word learners is largely a myth; the best style is usually to the task you're doing, and we are all able to do both styles. When I say I have a preferred style, I do find visual tasks easier than those requiring word recall skills). Also, nothing prevents visual languages from incorporating fast introduction tools other than palettes, like keyboard accelerators and contextual search - i.e. you type the name of a component and it appears at the cursor point; this would make them work with identical interactions as pure text programs. (BTW, I consider intellisense-autocomplete to be a visual tool; it favors recognition over recall by showing you the list of available options). What I consider a programming language is somewhat different from what think of as visual languages (which are primarly the flow-based block graphs; they have their place, but are too highly oriented to bulk data processing). For me, the ultimate visual language is the spreadsheet - a functional reactive environment where the user can freely position information and transformations in more than one dimension, and manually decorate them with as many cues, reminder text and color codes as needed. Some new development environments are growing a modern style, highly evolved with respect to the classic IDE, which is still based on the batch model of the mainframes in the 60s: * Jupyter-like notebooks bring some of the spreadsheet benefits to classic languages; * relational models that show data together with structure, like Airtable, is an example of these breed of visual tools for building data-transforming automations; * wikis work as visual storage that makes it easier to structure and organize hierarchical content; and so on. Modern development environments will start incorporating all these models, relying less in pure abstraction and running the program in your head as requirements to build programs.
- detaro 5y ago
  "Writing a program top to bottom" is also not really "1 discrete task". It has similar step-by-step structure, just replacing e.g. "pick/drag visual element" with "remember and correctly type text symbols".
  - vorpalhex 5y ago
    I agree that typing a program is not a single step. I broke the steps down in a sibling comment to yours, but the "visual" programmer still has all the same non-visual work and then a bunch of extra UI to deal with and visual discrimination tasks. We didn't make programming visual. We replaced text entry with a bad UI paradigm. If you want to see visual programming, go look at SpaceChem or Opus Magnum. [video warning] https://youtu.be/FhymQvfjMhY https://youtu.be/FhymQvfjMhY
    - detaro 5y ago
      No, it's not "all the same". What you see as extra and harder visual tasks is actually easier for many. Is it that hard to imagine that when coming up with "I need a loop here I guess" a young kid could find it easier to find the loop bubble than remembering the loop syntax and typing it correctly and not getting frustrated by syntax errors?
      - vorpalhex 5y ago
        1. 'coming up with "I need a loop here I guess"', non-visual 2. "loop" -> "loop block", non-visual (the loop block is a yellow thing with two teeth and says "while" on it, this is a recall task) 3. Either typing the thing or executing a "find the block and drag it" action. This is the first "visual" task. Sure, maybe if the kid genuinely can't type but can do gross + fine drag tasks than scratch is a winner, but this is not "visual programming". All the work is still not visual.
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 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.
    - vorpalhex 5y ago
      Do you actually program in scratch? Take a moment if you haven't and boot it up. I think there are web versions available now. Give it a go. Build a (simple) program. There's a reason it keeps not really taking off. I'm not saying text entry is free. I'm saying that the palette concept is more expensive - even for visual learners. Obviously languages (block based or text) can be easier or harder, eg python is less fussy than assembly. What visual/block based languages do you use currently?
      - TuringTest 5y ago
        I'm not saying that Blocks is a good programming language, nor defending it as a go-to tool; I know it is quite cumbersome to build programs in it - but I think it's largely because it's imitating classic imperative languages instead of being designed from the bottom up to take advantage of visual representation and interactive development. Still, it may be a very good introductory tool for learning classic-style programming (certainly better than Python for a primary school classroom; direct manipulation is just so superior for the first impression, when getting the students motivation is make-or-break). I was referring to your defense of textual programming as inherently superior, which I don't see as justified. Classical languages have a refinement over decades that visual languages lack, but I think it is possible, and I think we are getting to a point where building such languages is starting to become viable. > I'm not saying text entry is free. I'm saying that the palette concept is more expensive - even for visual learners This is simply not true. Recognition is easier than recall, even for textual learners; so even if toolbars require more steps, those are way easier steps. Even if you're talking about expensive in time and not actual effort, physically entering code is the task that less actual time takes of programming: thinking what code you need to include takes much more time, so anything that reduces that time will accelerate development. Programmers usually are not aware of this fact because they are distracted by all the thinking, but the actual input method is usually not that relevant except for people with disabilities. (Btw visual vs word learners is largely a myth; the best style is usually to the task you're doing, and we are all able to do both styles. When I say I have a preferred style, I do find visual tasks easier than those requiring word recall skills). Also, nothing prevents visual languages from incorporating fast introduction tools other than palettes, like keyboard accelerators and contextual search - i.e. you type the name of a component and it appears at the cursor point; this would make them work with identical interactions as pure text programs. (BTW, I consider intellisense-autocomplete to be a visual tool; it favors recognition over recall by showing you the list of available options). What I consider a programming language is somewhat different from what think of as visual languages (which are primarly the flow-based block graphs; they have their place, but are too highly oriented to bulk data processing). For me, the ultimate visual language is the spreadsheet - a functional reactive environment where the user can freely position information and transformations in more than one dimension, and manually decorate them with as many cues, reminder text and color codes as needed. Some new development environments are growing a modern style, highly evolved with respect to the classic IDE, which is still based on the batch model of the mainframes in the 60s: * Jupyter-like notebooks bring some of the spreadsheet benefits to classic languages; * relational models that show data together with structure, like Airtable, is an example of these breed of visual tools for building data-transforming automations; * wikis work as visual storage that makes it easier to structure and organize hierarchical content; and so on. Modern development environments will start incorporating all these models, relying less in pure abstraction and running the program in your head as requirements to build programs.
detaro 5y ago
"Writing a program top to bottom" is also not really "1 discrete task". It has similar step-by-step structure, just replacing e.g. "pick/drag visual element" with "remember and correctly type text symbols".
- vorpalhex 5y ago
  I agree that typing a program is not a single step. I broke the steps down in a sibling comment to yours, but the "visual" programmer still has all the same non-visual work and then a bunch of extra UI to deal with and visual discrimination tasks. We didn't make programming visual. We replaced text entry with a bad UI paradigm. If you want to see visual programming, go look at SpaceChem or Opus Magnum. [video warning] https://youtu.be/FhymQvfjMhY https://youtu.be/FhymQvfjMhY
  - detaro 5y ago
    No, it's not "all the same". What you see as extra and harder visual tasks is actually easier for many. Is it that hard to imagine that when coming up with "I need a loop here I guess" a young kid could find it easier to find the loop bubble than remembering the loop syntax and typing it correctly and not getting frustrated by syntax errors?
    - vorpalhex 5y ago
      1. 'coming up with "I need a loop here I guess"', non-visual 2. "loop" -> "loop block", non-visual (the loop block is a yellow thing with two teeth and says "while" on it, this is a recall task) 3. Either typing the thing or executing a "find the block and drag it" action. This is the first "visual" task. Sure, maybe if the kid genuinely can't type but can do gross + fine drag tasks than scratch is a winner, but this is not "visual programming". All the work is still not visual.

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.