5 ms·

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 t

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.
  - vorpalhex 5y ago
    > 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 I agree with this point > was referring to your defense of textual programming as inherently superior, This is inaccurate of my views. It's not that "visual programming is bad" it's that everything we call visual programming is not actually visual! Scratch is not visual. It's just text programming with more steps. > 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 I'm sympathetic to the concerns here, eg users needing to work in multiple dimensions. I still don't think this is a visual language, but it is maybe more visual than traditional visual languages. A spreadsheet is something like a visual layout on top of a program. > relying less in pure abstraction and running the program in your head as requirements Even with a true visual language I don't think the need for a mental model can be removed.
    - TuringTest 5y ago
      > This is inaccurate of my views. It's not that "visual programming is bad" it's that everything we call visual programming is not actually visual! Scratch is not visual. It's just text programming with more steps. Certainly "Visual" is a spectrum, not an on/off switch. Adding syntax coloring to a textual program is a step towards adding visual cues that improve recognition of its parts. Scratch adds over an imperative language a more detailed visual syntax that conveys the types of control structures and the relations between actions and parameters, and allows filling them in by interactive recognition rather than pure recall; so it's a step further in transforming a classic language into a visual one. Further steps in that direction include changing paradigms to functional or logic programs, that more explicitly represent changes in state through visual cues, relieving you from having to work them out in your short-term memory. Everything about visual languages is built towards adding expressiveness to the actual representation to convey as much information about the running program as possible. > I still don't think this is a visual language, but it is maybe more visual than traditional visual languages. A spreadsheet is something like a visual layout on top of a program. Programs are visual entities - they have a very concrete physical structure of a tree. That's why good indentation is essential even when the parser doesn't care about it at all. A program Abstract Syntax Tree is composed of very, well, abstract components; a program keywords represent objects quite separated of their final form during runtime, i.e. their actual values, but their connections can be often understood in terms of their spatial relations. Our brain is really very good at that, even for textual representations. > Even with a true visual language I don't think the need for a mental model can be removed. Completely agree. But building a mental model is way easier when working at several levels of abstraction at the same time, i.e. both concrete values and the abstractions that tie together those values in a concept encompassing them (see the concept of the Ladder of Abstraction).[1] And being able to actually see the values of variables and the connections between processes that change them, instead of having to imagine all those by running the program in your head, is a large advantage. The debugger is the quintessential visual tool, letting you inspect the true relations and processes of a running program through interactive manipulation, even for languages that otherwise lack any visual cues while being built. [1] http://worrydream.com/LadderOfAbstraction/ http://worrydream.com/LadderOfAbstraction/
- CJefferson 5y ago
  I'm not sure what you mean by "not taking off". I've seen scratch used in dozens of coding sessions for kids, and know it used used in hundreds of schools in the UK. Yes, people only use scratch for a while, almost no-one is writing huge programs in Scratch, but that's not what it is for.
  - TuringTest 5y ago
    There are even attempts to teach textual programming to students who already learned Scratch, by translating blocks to javascript (Scratch-LN, Blockly). I remember someone building a whole environment for making Slack look professional, by providing a text syntax that could nevertheless be programmed like Slack by adding and connecting typed blocks in the text structure (though I can't recall its name).
    - deleted 5y ago
      [deleted]
zozbot234 5y ago
> Unfortunately there are very few general-purpose visual languages This is not surprising, because "general purpose" tools have general, highly-composable, extensible syntax. Endowing, e.g. condition operators with their own block shape makes sense when all you have is a simple tool like Scratch where they just "snap" inside if-then blocks, but not so much when "boolean" is simply one of many interchangeable types that might, e.g. be assigned to a variable. Then a condition operator is simply some expression-like element that just happens to return a boolean. Similar things happen with other program elements, like text strings, numbers etc. Custom types start to be needed, and then you need to add whatever the equivalent of a DATA DIVISION is in your Scratch-alike. At the extreme of generalization, you find things like dependently typed languages where even "values" and "types" are no longer separated by rigid syntax, but are the same kind of program element.
- TuringTest 5y ago
  I don't have a problem with syntax. I have a problem with textual syntax, where abstract concepts are represented with words, with little to no secondary notation[1] and lots of repetition. When the syntax is highly visual, it can convey information through much more bandwidth than flat text, which is limited to a few dozens of repeatedly used symbols. And don't tell me that textual programmers don't realize the benefit of secondary notation and visually-conveyed details. We love when our IDEs full with syntax highlighting for different types of operators, global structure mini-maps and intellisense auto-complete tooltips. All these are visual tools that improve the flow of building a text-based program. [1] https://en.wikipedia.org/wiki/Secondary_notation https://en.wikipedia.org/wiki/Secondary_notation

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.
- vorpalhex 5y ago
  > 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 I agree with this point > was referring to your defense of textual programming as inherently superior, This is inaccurate of my views. It's not that "visual programming is bad" it's that everything we call visual programming is not actually visual! Scratch is not visual. It's just text programming with more steps. > 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 I'm sympathetic to the concerns here, eg users needing to work in multiple dimensions. I still don't think this is a visual language, but it is maybe more visual than traditional visual languages. A spreadsheet is something like a visual layout on top of a program. > relying less in pure abstraction and running the program in your head as requirements Even with a true visual language I don't think the need for a mental model can be removed.
  - TuringTest 5y ago
    > This is inaccurate of my views. It's not that "visual programming is bad" it's that everything we call visual programming is not actually visual! Scratch is not visual. It's just text programming with more steps. Certainly "Visual" is a spectrum, not an on/off switch. Adding syntax coloring to a textual program is a step towards adding visual cues that improve recognition of its parts. Scratch adds over an imperative language a more detailed visual syntax that conveys the types of control structures and the relations between actions and parameters, and allows filling them in by interactive recognition rather than pure recall; so it's a step further in transforming a classic language into a visual one. Further steps in that direction include changing paradigms to functional or logic programs, that more explicitly represent changes in state through visual cues, relieving you from having to work them out in your short-term memory. Everything about visual languages is built towards adding expressiveness to the actual representation to convey as much information about the running program as possible. > I still don't think this is a visual language, but it is maybe more visual than traditional visual languages. A spreadsheet is something like a visual layout on top of a program. Programs are visual entities - they have a very concrete physical structure of a tree. That's why good indentation is essential even when the parser doesn't care about it at all. A program Abstract Syntax Tree is composed of very, well, abstract components; a program keywords represent objects quite separated of their final form during runtime, i.e. their actual values, but their connections can be often understood in terms of their spatial relations. Our brain is really very good at that, even for textual representations. > Even with a true visual language I don't think the need for a mental model can be removed. Completely agree. But building a mental model is way easier when working at several levels of abstraction at the same time, i.e. both concrete values and the abstractions that tie together those values in a concept encompassing them (see the concept of the Ladder of Abstraction).[1] And being able to actually see the values of variables and the connections between processes that change them, instead of having to imagine all those by running the program in your head, is a large advantage. The debugger is the quintessential visual tool, letting you inspect the true relations and processes of a running program through interactive manipulation, even for languages that otherwise lack any visual cues while being built. [1] http://worrydream.com/LadderOfAbstraction/ http://worrydream.com/LadderOfAbstraction/
CJefferson 5y ago
I'm not sure what you mean by "not taking off". I've seen scratch used in dozens of coding sessions for kids, and know it used used in hundreds of schools in the UK. Yes, people only use scratch for a while, almost no-one is writing huge programs in Scratch, but that's not what it is for.
- TuringTest 5y ago
  There are even attempts to teach textual programming to students who already learned Scratch, by translating blocks to javascript (Scratch-LN, Blockly). I remember someone building a whole environment for making Slack look professional, by providing a text syntax that could nevertheless be programmed like Slack by adding and connecting typed blocks in the text structure (though I can't recall its name).
  - deleted 5y ago
    [deleted]

zozbot234 5y ago

> Unfortunately there are very few general-purpose visual languages This is not surprising, because "general purpose" tools have general, highly-composable, extensible syntax. Endowing, e.g. condition operators with their own block shape makes sense when all you have is a simple tool like Scratch where they just "snap" inside if-then blocks, but not so much when "boolean" is simply one of many interchangeable types that might, e.g. be assigned to a variable. Then a condition operator is simply some expression-like element that just happens to return a boolean. Similar things happen with other program elements, like text strings, numbers etc. Custom types start to be needed, and then you need to add whatever the equivalent of a DATA DIVISION is in your Scratch-alike. At the extreme of generalization, you find things like dependently typed languages where even "values" and "types" are no longer separated by rigid syntax, but are the same kind of program element.

TuringTest 5y ago
I don't have a problem with syntax. I have a problem with textual syntax, where abstract concepts are represented with words, with little to no secondary notation[1] and lots of repetition. When the syntax is highly visual, it can convey information through much more bandwidth than flat text, which is limited to a few dozens of repeatedly used symbols. And don't tell me that textual programmers don't realize the benefit of secondary notation and visually-conveyed details. We love when our IDEs full with syntax highlighting for different types of operators, global structure mini-maps and intellisense auto-complete tooltips. All these are visual tools that improve the flow of building a text-based program. [1] https://en.wikipedia.org/wiki/Secondary_notation https://en.wikipedia.org/wiki/Secondary_notation