4 ms·
> then there’s no need to remember punctuation rules. The visual layout of the code is the notation. This is hardly a compelling reason to switch to a visual l
by kwhitefoot 5y ago
> then there’s no need to remember punctuation rules. The visual layout of the code is the notation.
This is hardly a compelling reason to switch to a visual layout.
One could just change the syntax rules to eliminate the semicolon and require new line or end of file instead.
Then the code looks remarkably like the visual layout with the advantage that simple tools can search it and edit it.
- xscott 5y agoI think maybe you're missing some subtlety here. In Scratch, the type of a parameter or expression is denoted by it's shape. Strings are square, numbers are round, booleans are angled, and statements are shaped like puzzle pieces. You don't need quotation marks and escape characters for strings. So new users can be oblivious to types for a little while - just tell them they can't put a square peg into a round hole. I think it falls apart pretty quickly as they add more features in Snap. For instance, are lists always lists of strings? And list themselves are rounded rectangles? Sprites and procedures are rounded rectangles? I guess they ran out of easily distinguished shapes, but maybe that's ok by the time new programmers start needing these features.
- zozbot234 5y agoThe thing about shape is that it's a feature of visual syntax. A visual language where shapes are used to distinguish different primitive types is structurally no different from a toy BASIC where each type is given its own sigil character (!#$& etc.). We moved away from this use of sigils because it made it harder to abstract away from primitive types. I can see Snap! developers making the same choice.
- xscott 5y agoI agree with everything you said, and I still think it's a clever/useful idea for new programmers.
- wizzwizz4 5y ago> Strings are square, numbers are round, All variables are round. The only thing that's square is a text input box. (The background colour, white, is the thing denoting that you can put any variable in the box.)
- xscott 5y agoIf we're being pedantic, I should've used the word "parameter" instead of "variable", but surely you know what I meant. If not, see the "What's in a shape?" section of https://nostarch.com/download/samples/Learn-Scratch-05.pdf https://nostarch.com/download/samples/Learn-Scratch-05.pdf It starts at the bottom of page 92.
- wizzwizz4 5y ago> Blocks for cloud variables have a small square in front of them to distinguish them from regular variables, like this: That's supposed to be a cloud icon. :-p
- zozbot234 5y agoThe nice thing about a language like Scheme is that it can potentially support both views seamlessly. Just add it as a rendering option to your IDE, and use it when appropriate - perhaps for coding on a non-standard interface such as a touchscreen, where this kind of input might be preferred. (Of course the flip side is that any Snap program can also have an isomorphic Scheme representation, for easy editing with a keyboard and mouse.)
- codetrotter 5y agoI don’t understand why Scheme would be any more suited for that than any other language exactly.
- elcomet 5y agoBecause it's a lisp, code is a data structure
- disconcision 5y agousing a lisp here simplifies things from implementation and interaction model perspectives. you already have a simple, canonical AST out of the box, which in-principle suffices to support the entire language, not just a toy version. so it makes sense lisps are attractive targets for getting something rolling in this space, though it's certainly debatable whether it's long-term the best choice. (my own efforts in this space (a structured editor in racket), which i was able to get going as a novice programmer: https://www.youtube.com/watch?v=CnbVCNIh1NA https://www.youtube.com/watch?v=CnbVCNIh1NA)
- benrbray 5y agoCan you give an example of a language that does not have an AST?? Homoiconicity may be slightly more convenient but it is certainly not necessary.
- disconcision 5y agoit depends what you mean by 'have'. any language in-principle probably has something describable as an AST but it's not necessarily something particularly well-specified. you can derive a CST from a presentation of the grammar, but it's not necessarily easy to work with in an editing context. in general, intermediary data structures are often left entirely to the discretion of the compiler implementer. likely various tree-like structures exist implicitly or explicitly during compilation, which may or may not be ideally suited for editing interactions. for example, if they are heavily nested with intermediary productions or discard surface style choices. sexps offer a simple (debatably too simple) shortcut here.