3 ms·

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.

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.