I just love this. For some reason, our ways of specifying what we want a computer to do (I don't want to say 'language') remain mired the same territory we started in with punched cards (which I actually got to use as a 10 year old, which was fun).
I'm not sure if this particular cut is the right idea, but it's good to see experimentation. A bias I have here is that I think these ideas should be rigorously separated from the concept that some sort of WYSIWYG editor will allow non-programmers to code.
That touches on the reason these type of ideas haven't gone further. Programming is definitionally limited to cryptic text. Anything that deviates from that, especially if it makes it non-cryptic or easy, is no longer a programming tool; it becomes a tool for lowly users. This detracts from the identity of programmers because that is tied to producing and consuming cryptic text.
Microsoft Dynamics / Salesforce allow you to set up a data model without any code.
Turns out you still have to be able to model things, and understand the mental model for programming which is why people end up with hell on these systems.
Also, if you've gotten this far, plain text is actually a far more easy and convenient way to specify things.
Further, if you need to run such a system yourself, you'd still need to deal with the rest of it, which is just hidden to users, which we're developing tools for all the time.
Very neat, I really appreciate the Racket community's willingness to experiment with syntax.
Looking at the examples reminds me of Julian Noble's "Elegant Finite State Machine" in Forth[0], which takes a different approach to the same problem of creating a language to better specify a problem (in both cases graphically).
It looks like this (e.g. `#2dcond`) implements a way to directly embed other languages in a racket file [0] and avoids the problems encountered when trying to do it using the `#reader` syntax [1] in a source file. Essentially letting you have multiple readtables in a file (probably not nestable though). I could be wrong about this (need to look more carefully when I have more time), but nonetheless could allow direct embedding of completely alternate syntax with the right setup.
I find this extremely interesting! In the last weeks one of my colleagues had to work to some legacy application that was developed using National Instrument's LabView [1]. For those who do not know it, it is a visual language to develop interfaces to scientific instruments. Everything is done visually, including «if»s and «for» loops.
My colleague, which has large experience with languages like C# and Assembly, is extremely frustrated by this way of working. Everything must be done using a mouse, and even the simplest tasks require some thought in order to be implemented properly. (Although I must say that he praises LabView's hardware support and its Visual Basic-like easiness in developing GUIs.)
I find Racket's 2D syntax to be far more promising than LabView's approach:
1. You can code it using a text editor: unlike LabView, no mouse is required;
2. Only a few classes of statements are affected by this (LabView forces you to do everything visually, even function definitions and mathematical operations);
3. You use this feature only if you think it helps; otherwise, plain text syntax is always available.
As a side note, I would like to give kudos to the Racket developers for this kind of gems. Racket really seems to be a language which makes language experiments easy to implement and try!
I have some reservations about how this is designed.
All we need are columns labeled with conditions. We don't need rows. And the matrix can just have true/false/don't-care entries, with code assigned to rows.
Concretely, say we have these conditions:
(> x y) (stringp foo) (oddp n)
Right? Okay, so now we can identify the combinations of these and assign them to code like this:
There could be a way to mark some of the rows as having "fall through" behavior. If they match, the expression is evaluated (for its side effects, obviously), but then subsequent rows can still match.
This could be worked into a straightforward S-exp syntax without any diagramming shennanigans:
While I appreciate and respect Racket's willingness to experiment and innovate, I'm a bit puzzled by this.
Tables are neat to read but pretty annoying to write, especially in ASCII form. It's true that code is read much more often than written, but still, I wonder how useful this really is.
> Tables are neat to read but pretty annoying to write, especially in ASCII form
They sure are annoying to write in a text editor, but the article does mention built-in support for them in the Dr. Racket IDE/repl.
Dr. Racket does seem like a very nice educational environment to learn some fundamentals of programming. In addition to text it can show images and tables, etc.
I'm under the impression that it is used in some universities in conjunction with SICP or HTDP.
The reason why I think that this will not thrive, as other projects have not thrived, is because (at least initially) it adds to the mental burden. Scanning a cond for me is almost instantaneous. It took me a couple of very long seconds for me to figure out what was happening within that table, and even though I recognized it as a truth table, it was not easy to read. The information was too separate on screen to easily compare.
I think that were programming initially presented as such, this would not be a problem, but I expect that many developers are so finely attuned and specialized to text that other methods will not take off purely because of the learning curve.
"Scanning a cond for me is almost instantaneous." This is a very subjective concern though. Consider the subtype example. For me, reading that 3x3 table, especially with the grouping of blocks, was a lot easier than mentally parsing a big pile of 'and/or' expressions, or nested switches, etc. And my impression is that a lot of programmers do initially visualise some parts of their work as tables or diagrams.
Our tools on the other hand are indeed 'so finely attuned and specialised to text' that other methods of representation have and will struggle to get traction...
Nobody has mentioned the dependently type prog-lang Epigram† yet?
“Epigram uses a two-dimensional, natural deduction style syntax, with a LaTeX version and an ASCII version. Here are some examples from The Epigram Tutorial:
Examples
The natural numbers
The following declaration defines the natural numbers:”
( ! ( ! ( n : Nat !
data !---------! where !----------! ; !-----------!
! Nat : * ) !zero : Nat) !suc n : Nat)
“The declaration says that Nat is a type with kind * (i.e., it is a simple type) and two constructors: zero and suc. The constructor suc takes a single Nat argument and returns a Nat. This is equivalent to the Haskell declaration "data Nat = Zero | Suc Nat".”
What editor do racketeers commonly use? I like the idea, but this seems like a burden for code editing in most normal editors except for perhaps emacs picture mode.
It's good for reading (certain) code. Without the syntax actually be functional, there's no reason to build editor support for it; editor support that makes it cobvenient to write should be expected to be a trailing, rather than leading, feature.
EDIT: incidentally, the documentation for the syntax also refers to the built-in support for it in DrRacket.
Reminds me (again) of Jonathan Edwards research. He did many editors with tables as first class so that you can avoid boolean nestings, and simplify verification / closure of your boolean mappings.
I love attempts at visual programming. As a kid I used to pour over the then-fashionable ads for CASE (Compater-Aided Software-Engineering) tools in DDJ and elsewhere and imagined them to do far more than they actually did... Also attempts like Amiga Vision [1]
One of the software engineers I like to go a bit fanboy-ish about is Wouter van Oortmerssen, who I first got familiar with because of Amiga E, but who has a number of interesting language experiments [2], one of which includes a visual language named Aardappel [3] that also used to fascinate me.
There are a number of problems with these that have proven incredibly hard to solve (that this Racket example does tolerably well on, probably because it doesn't go very far):
1. Reproduction. Note how the Amiga Vision example is presented as a video - there is not even a simple way of representing a program in screenshots, like what you see for the examples of Aardappel, which at least has a linear, 2D representation. That made Amiga Vision work as a tool, but totally fail as a language. This is even a problem for more conventional languages on the fringe, like APL, which uses extra symbols that most people won't know how to type. The Racket example does much better in that it can be reproduced in normal text easily.
2. Communication. We talk (and write) about code all the time. Turns out it's really hard to effectively communicate about code if you can't read it out loud easily, or if drawing is necessary to communicate the concepts. Ironically, if you can't read the code out easily, it becomes hard for people to visualise it too, even if the original representation is entirely visual. This example does ok in that respect - communicating a grid is on the easier end of the spectrum.
3. Tools. If it needs special tools for you to be effective, it's a non-starter. This Racket example is right on the fringes of that. You could do it, but it might get tedious to draw without tooling (be it macros or more). On the other hand the "tool" you'd need to be effective is limited enough that you could probably implement it as macros for most decent editors.
I spent years experimenting with ways around these, and the "best" I achieved was a few principles to make it easier to design around those constraints:
A visual language needs a concise, readable textual representation. You need to be able to round-trip between the textual representation and whatever visual representation you prefer. This is a severe limitation - it's easy to create a textual representation (I had prototypes serialising to XML; my excuse is it was at the height of the XML hype train; I'm glad I gave that up), but far easier to make one that is readable enough, as people need to be able to use it as a "fallback" when visual tools are unavailable, or in contexts where they don't work (e.g. imagine trying to read diffs on Github while your new language is fringe enough for Github to have no interest in writing custom code to visualise it; which also brings up the issue of ensuring the language can easily be diffed).
To do that in a way people will be willing to work with, I think you need to specify the language down to how comments "attaches" to
language constructs, because you'll need to be able to "round-trip" comments between a visual and textual representation reliably.
It also needs to be transparent how the visual representation maps to the textual representation in all other aspects, so that you can pick one or the other and switch between the two reasonably seamlessly, so that you are able to edit the code when you do not have access to the visual tool, without surprises. This makes e.g. storing additional information, such as e.g. allowing manual tweaks to visual layout that'd require lots of state in the textual representation that people can't easily visualise very tricky.
Ideally, a visual tool like this will not be language specific (or programming specific) - one of the challenges we face with visual programming, or even languages like APL that uses extra symbols, is that the communications aspect is hard if we can not e.g. quickly outline a piece of code in an e-mail, for example.
While having a purely textual representation would help with that, it's a crutch. To "fix" that, we need better ways of embedding augmented, not-purely-textual content in text without resorting to images. But that in itself is an incredibly hard problem, to the extent that e.g. vector graphics supports in terminals was largely "forgotten" for many years before people started experimenting with it again, and it's still an oddity that you can't depend on being supported.
Note that the one successful example in visually augmenting programming languages over the last 20-30 years, has been a success not by changing the languages, but by working within these constraints and partially extracting visual cues by incremental parsing: syntax highlighting.
I think that is a lesson for visual language experiments - even if you change or design a language with visual programming in mind, it needs to be sort-of like syntax highlighting, in that all the necessary semantic information is there even when tool support is stripped away. We can try to improve the tools, but then we need to lift the entire toolchain starting with basic terminal applications.
> This notation works in two stages: reading, and parsing (just as in Racket in general). The reading stage converts anything that begins with #2d into a parenthesized expression (possibly signaling errors if the ═ and ║ and ╬ characters do not line up in the right places).
Adding tabular display to Lisp is useful, IMHO. I was thinking about using something similar, but mostly where code looks like data or specifically for Lisp data. I would not be very interested to use tables for control structures, but would like more support for auto-aligned layout for control structures.
[+] [-] glangdale|8 years ago|reply
I'm not sure if this particular cut is the right idea, but it's good to see experimentation. A bias I have here is that I think these ideas should be rigorously separated from the concept that some sort of WYSIWYG editor will allow non-programmers to code.
[+] [-] ilaksh|8 years ago|reply
That touches on the reason these type of ideas haven't gone further. Programming is definitionally limited to cryptic text. Anything that deviates from that, especially if it makes it non-cryptic or easy, is no longer a programming tool; it becomes a tool for lowly users. This detracts from the identity of programmers because that is tied to producing and consuming cryptic text.
[+] [-] naiveattack|8 years ago|reply
Turns out you still have to be able to model things, and understand the mental model for programming which is why people end up with hell on these systems.
Also, if you've gotten this far, plain text is actually a far more easy and convenient way to specify things.
Further, if you need to run such a system yourself, you'd still need to deal with the rest of it, which is just hidden to users, which we're developing tools for all the time.
[+] [-] nprescott|8 years ago|reply
Looking at the examples reminds me of Julian Noble's "Elegant Finite State Machine" in Forth[0], which takes a different approach to the same problem of creating a language to better specify a problem (in both cases graphically).
[0]: http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm....
[+] [-] hyperion2010|8 years ago|reply
[0] https://github.com/racket/2d/blob/master/2d-lib/private/read... [1] https://docs.racket-lang.org/guide/hash-reader.html
[+] [-] gcr|8 years ago|reply
at-exp adds support for S-expressions based on braces, and is the foundation of the Scribble markup language.
[+] [-] ziotom78|8 years ago|reply
My colleague, which has large experience with languages like C# and Assembly, is extremely frustrated by this way of working. Everything must be done using a mouse, and even the simplest tasks require some thought in order to be implemented properly. (Although I must say that he praises LabView's hardware support and its Visual Basic-like easiness in developing GUIs.)
I find Racket's 2D syntax to be far more promising than LabView's approach:
1. You can code it using a text editor: unlike LabView, no mouse is required;
2. Only a few classes of statements are affected by this (LabView forces you to do everything visually, even function definitions and mathematical operations);
3. You use this feature only if you think it helps; otherwise, plain text syntax is always available.
As a side note, I would like to give kudos to the Racket developers for this kind of gems. Racket really seems to be a language which makes language experiments easy to implement and try!
[1] http://www.ni.com/en-us/shop/labview.html
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] kazinator|8 years ago|reply
All we need are columns labeled with conditions. We don't need rows. And the matrix can just have true/false/don't-care entries, with code assigned to rows.
Concretely, say we have these conditions:
Right? Okay, so now we can identify the combinations of these and assign them to code like this: There could be a way to mark some of the rows as having "fall through" behavior. If they match, the expression is evaluated (for its side effects, obviously), but then subsequent rows can still match.This could be worked into a straightforward S-exp syntax without any diagramming shennanigans:
Here, don't cares are denoted using (). Something else could be chosen.A #f entry means "must be explicitly false". A blank column entry is a "don't care"; that condition is not taken into account for that row.
[+] [-] porges|8 years ago|reply
[+] [-] jacobparker|8 years ago|reply
Different but similar joke for C++: http://www.eelis.net/C++/analogliterals.xhtml
[+] [-] fizixer|8 years ago|reply
Personally, the Racket idea is good except for the hassle of typing in the borders (emacs-orgmode could help with that though).
[+] [-] 0xcde4c3db|8 years ago|reply
https://stackoverflow.com/questions/5508110/why-is-this-prog...
[+] [-] tobyhinloopen|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] hota_mazi|8 years ago|reply
Tables are neat to read but pretty annoying to write, especially in ASCII form. It's true that code is read much more often than written, but still, I wonder how useful this really is.
[+] [-] exDM69|8 years ago|reply
They sure are annoying to write in a text editor, but the article does mention built-in support for them in the Dr. Racket IDE/repl.
Dr. Racket does seem like a very nice educational environment to learn some fundamentals of programming. In addition to text it can show images and tables, etc.
I'm under the impression that it is used in some universities in conjunction with SICP or HTDP.
[+] [-] rrobukef|8 years ago|reply
[+] [-] fao_|8 years ago|reply
I think that were programming initially presented as such, this would not be a problem, but I expect that many developers are so finely attuned and specialized to text that other methods will not take off purely because of the learning curve.
[+] [-] ppog|8 years ago|reply
Our tools on the other hand are indeed 'so finely attuned and specialised to text' that other methods of representation have and will struggle to get traction...
[+] [-] lallysingh|8 years ago|reply
[+] [-] sharpercoder|8 years ago|reply
[+] [-] b123400|8 years ago|reply
[+] [-] ooqr|8 years ago|reply
[+] [-] igravious|8 years ago|reply
“Epigram uses a two-dimensional, natural deduction style syntax, with a LaTeX version and an ASCII version. Here are some examples from The Epigram Tutorial:
Examples
The natural numbers
The following declaration defines the natural numbers:”
“The declaration says that Nat is a type with kind * (i.e., it is a simple type) and two constructors: zero and suc. The constructor suc takes a single Nat argument and returns a Nat. This is equivalent to the Haskell declaration "data Nat = Zero | Suc Nat".”Project lives here: https://code.google.com/archive/p/epigram/ and the last commit on https://github.com/mietek/epigram2 is five years ago which leads me to believe that the project is abandon-ware.
† https://en.wikipedia.org/wiki/Epigram_(programming_language)
[+] [-] oh_sigh|8 years ago|reply
[+] [-] dragonwriter|8 years ago|reply
EDIT: incidentally, the documentation for the syntax also refers to the built-in support for it in DrRacket.
[+] [-] ez_white|8 years ago|reply
[+] [-] ez_white|8 years ago|reply
[deleted]
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] joshlemer|8 years ago|reply
[+] [-] agumonkey|8 years ago|reply
He published a video, sadly in flash http://www.subtext-lang.org/subtext2.html
Here's an article about "schematic tables" http://aigamedev.com/open/review/schematic-table-conditional...
[+] [-] vidarh|8 years ago|reply
One of the software engineers I like to go a bit fanboy-ish about is Wouter van Oortmerssen, who I first got familiar with because of Amiga E, but who has a number of interesting language experiments [2], one of which includes a visual language named Aardappel [3] that also used to fascinate me.
There are a number of problems with these that have proven incredibly hard to solve (that this Racket example does tolerably well on, probably because it doesn't go very far):
1. Reproduction. Note how the Amiga Vision example is presented as a video - there is not even a simple way of representing a program in screenshots, like what you see for the examples of Aardappel, which at least has a linear, 2D representation. That made Amiga Vision work as a tool, but totally fail as a language. This is even a problem for more conventional languages on the fringe, like APL, which uses extra symbols that most people won't know how to type. The Racket example does much better in that it can be reproduced in normal text easily.
2. Communication. We talk (and write) about code all the time. Turns out it's really hard to effectively communicate about code if you can't read it out loud easily, or if drawing is necessary to communicate the concepts. Ironically, if you can't read the code out easily, it becomes hard for people to visualise it too, even if the original representation is entirely visual. This example does ok in that respect - communicating a grid is on the easier end of the spectrum.
3. Tools. If it needs special tools for you to be effective, it's a non-starter. This Racket example is right on the fringes of that. You could do it, but it might get tedious to draw without tooling (be it macros or more). On the other hand the "tool" you'd need to be effective is limited enough that you could probably implement it as macros for most decent editors.
I spent years experimenting with ways around these, and the "best" I achieved was a few principles to make it easier to design around those constraints:
A visual language needs a concise, readable textual representation. You need to be able to round-trip between the textual representation and whatever visual representation you prefer. This is a severe limitation - it's easy to create a textual representation (I had prototypes serialising to XML; my excuse is it was at the height of the XML hype train; I'm glad I gave that up), but far easier to make one that is readable enough, as people need to be able to use it as a "fallback" when visual tools are unavailable, or in contexts where they don't work (e.g. imagine trying to read diffs on Github while your new language is fringe enough for Github to have no interest in writing custom code to visualise it; which also brings up the issue of ensuring the language can easily be diffed).
To do that in a way people will be willing to work with, I think you need to specify the language down to how comments "attaches" to language constructs, because you'll need to be able to "round-trip" comments between a visual and textual representation reliably.
It also needs to be transparent how the visual representation maps to the textual representation in all other aspects, so that you can pick one or the other and switch between the two reasonably seamlessly, so that you are able to edit the code when you do not have access to the visual tool, without surprises. This makes e.g. storing additional information, such as e.g. allowing manual tweaks to visual layout that'd require lots of state in the textual representation that people can't easily visualise very tricky.
Ideally, a visual tool like this will not be language specific (or programming specific) - one of the challenges we face with visual programming, or even languages like APL that uses extra symbols, is that the communications aspect is hard if we can not e.g. quickly outline a piece of code in an e-mail, for example.
While having a purely textual representation would help with that, it's a crutch. To "fix" that, we need better ways of embedding augmented, not-purely-textual content in text without resorting to images. But that in itself is an incredibly hard problem, to the extent that e.g. vector graphics supports in terminals was largely "forgotten" for many years before people started experimenting with it again, and it's still an oddity that you can't depend on being supported.
Note that the one successful example in visually augmenting programming languages over the last 20-30 years, has been a success not by changing the languages, but by working within these constraints and partially extracting visual cues by incremental parsing: syntax highlighting.
I think that is a lesson for visual language experiments - even if you change or design a language with visual programming in mind, it needs to be sort-of like syntax highlighting, in that all the necessary semantic information is there even when tool support is stripped away. We can try to improve the tools, but then we need to lift the entire toolchain starting with basic terminal applications.
[1] https://www.youtube.com/watch?v=u7KIZQzYSls
[2] http://strlen.com/programming-languages/
[3] http://strlen.com/aardappel-language/
[+] [-] kovek|8 years ago|reply
[+] [-] niuzeta|8 years ago|reply
> This notation works in two stages: reading, and parsing (just as in Racket in general). The reading stage converts anything that begins with #2d into a parenthesized expression (possibly signaling errors if the ═ and ║ and ╬ characters do not line up in the right places).
I'm cracking up, oh my god.
[+] [-] lispm|8 years ago|reply