2D Syntax
docs.racket-lang.org
docs.racket-lang.org
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.
I think a system build along lines to violate assumption #1 will fail if it has the goal of making assumption #2 go away as well. The complexity of many things we manage in text will either appear somewhere else, or bubble up in even worse ways (missing functionality or a system that is broken by design). I would really like to see work that is focused on attacking assumption #1. I'm not going to try to dictate that no-one should work on #2, I just think it's been tried without much success so many times.
But yeah we gotta keep doing it until we can't, and leave a breadcrumb trail for others to continue.
Inputs are named based on what cells they are entered in, and the results are named from the cells the expression is housed in.
Never mind that the scope is by default the sheet, though one can access those in other sheets with a bit extra effort.
On top of this one get instant feedback when something is awry.
not entirely sure if it is possible to expand something like this into a more general purpose IDE though.
Many people have tried to "make programming easy". It turns out to be a fundamentally difficult problem.
Of course, if you believe that all attempts were stopped by the Programmer Complexity Mafia, feel free to try yourself. It would certainly be a lucrative product if you can solve the problem.
Every programmer will at some point try to build a system that allows users to add their own fields, rules, etc. We try to program ourselves out of a job and fail.
Disagree. My first job trained non-programmers to be proficient in Ab Initio, whose first layer was visual directed graphs. It was a data processing tool, and yes you could click into the "cryptic text", but more often, due to the visual first layer that generalized basic data operations, the code beneath was quite understandable.
It is still Turing complete and an efficient language, just a little more accessible and easier for non-developers to pick up.
Plus, there isn't much code with this setup because it's easier to add another block to the graph than it is to add code to do the same task. Here's an example of a graph [1]. You can click into each block to see its parameters [2]. Once you click into the code, it's usually just one or a few line definitions of what each output item should be.
It runs in CPU-parallel by default without any adjustments from the developer, so pretty efficient. Also it was made by the guys who started Thinking Machines in the 80s, which was the hot AI company at the time.
At the time, Ab Initio was considered a Data Warehousing or ETL tool. The most conceptually similar modern tool I've seen is Luna [3], though I don't think that's considered "Data Warehousing" per-se. Anyway, I always felt it was a cool way to write software, having a visual layer on top to describe data flow.
[1] http://1.bp.blogspot.com/_FwFkbVFfnGQ/S_V4l062fNI/AAAAAAAABO...
[2] http://1.bp.blogspot.com/_FwFkbVFfnGQ/S_V1P_C64TI/AAAAAAAABN...
I am not trying to say this is my ideal definition of programming -- I think its a pretty stupid limitation. But after having discussed and researched this stuff for years and in the context of at least 8 or 10 tools, there is some psychological issue holding us back rather than a practical one. Which is not to say there are no practical issues -- its just that numerous tools have shown that they aren't insurmountable.
I think the benefits of graph-based programming are pretty clear. Having used such a tool already, I see the benefits of being able to visualize code at the top level. In fact, everyone does, we just don't have the time or willpower to recreate the visual layer for all our code. When that visual layer is built into the language, it saves everyone time, both in building and understanding.
I don't think plain code is going away anytime soon, and it will always be an option, but I'd like to see more done in the visual top layer space, like Luna.
It has a level of conciseness like fuctional programming that I enjoy. Almost like bringing back (Turing's?) finite state machines at a higher level.
I suspect the problem to which you allude, the lack of pervasiveness of visual-based programming, has more to do with how many folks have implemented it successfully.
You may not be aware, but Ab Initio runs in a lot of big enterprise software stacks. People trained in that software are proficient in building solutions quickly with little or no CS background. Jobs in that tool remain high salaried to this day. The company is quite secretive and only licenses/trains with certain consultancies.
Are you sure that things like graphical ETL such as SSIS, graphical or automated reporting, and more generally database-oriented RAD tools are not actually fairly common?
I don't know. I guess some programmers might turn their noses up at a graphical interface at the top level. But it doesn't matter. The result was always a working, maintainable, fast tool that achieved the desired goal.
If I built a machine using sticks and stones that could accurately predict the week's weather, how many people would care that I didn't use satellites? Probably the people in the satellite industry, but, if I demonstrate my solution is better, those folks will need to adapt or face loss of wages.
I was a CS major and went to work for an Ab Initio consultancy, not realizing they also hired non-programmers and trained them. It worked fine and we replaced Java consultants all the time because their code wasn't as maintainable or as fast as ours.
I'm not claiming that graphical tools will surpass Python, but based on my experience, I think they deserve a seat at the table.
> Are you sure that things like graphical ETL such as SSIS, graphical or automated reporting, and more generally database-oriented RAD tools are not actually fairly common?
I think they are common in enterprise, but the languages are often proprietary or don't have the level of open source support that traditional programming languages have had. I'm looking forward to seeing what will come of Luna lang [1] and stuff like 2D Syntax in the future.
You previously stated,
> 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.
But, graphical boxes on the screen can be thought of as libraries. We don't consider libraries to be tools for lowly users, just as we don't consider calculators or computers lowly. Things that make our job simpler aren't lowly, they're empowering.
Just take a screencast of yourself doing programming in Ab Initio for some things that involve little to no textual code input. Then find three or four programmers and ask them if they think you are a good coder/programmer/software engineer. If you get an honest answer they will say you are a good Ab Initio expert but do not believe you are doing programming. I dont think that is correct but I think this dumb perceptual issue where programming is tied to cryptic text is the reason those tools are not more popular for people who call themselves programmers.
That was actually a frequent complaint (along with the, research-backed, complaint that WYSIWYG editors make people, whether pros or not, worse writers) in the 1980s through early 1990s. You still sometimes hear it from pros that hold to archaic word processors, long-hand, or typewriting for manuscripts, or the TeX crowd.
It wasn't effective at stopping WYSIWYG from taking over virtually everything, but it wasn't an uncommon complaint.
Beware, you all, the siren song of squares labled "concatenate." They will only add to your troubles.
Ladder logic predates PLCS though- essentially the same notation was used when relays were used to implement it, and EEs were fine with that.
That said, a complicating element is that PLCs can extend the basic diagram with custom blocks...
None of the graphical tools integrate well with the programmers existing editors, vcs or anything else very well.
They need to be represented by a textual format, carefully planned so that it is easy to manipulate in an ordinary editor with understandable diffs in version control.
- It's concise, clear and unambiguous. - It's easily extensible. `def foo() ...` is all you need to define new word. What do you need to do to define new block in WYSIWYG that is still meaningful to the user? - It can be diff and search. Can you meaningfully diff visual graphic? And then merge it automatically? - It's stable. Do you think source code in WYSIWYG today will be usable in the editor 5 years from now?
Typing "cryptic text" is the easiest part in programming. "Thinking clearly" is the most important part, and most people are not specifying clear instruction to be made into program. It has nothing to do with programmer's identity crisis.
Also, when you're designing a text-based programming language, you can focus on the compiler, and users of your language can just use their existing text editor. When you're designing a language with a WYSIWYG editor, you just put the burden on yourself of also implementing that editor. Potentially on many different platforms, if you want to reach a wide audience.
No, the unfortunate truth is that making a general purpose visual language is hard and that so far text is still the best we've managed to come up with.
Consider: The spreadsheet is a limited-domain example. Spreadsheets are great and they caught on like crazy. They were the killer app of PCs before the Internet. And they are an easy to use not-very-textual programming tool.
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.
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....
[0] https://github.com/racket/2d/blob/master/2d-lib/private/read... [1] https://docs.racket-lang.org/guide/hash-reader.html
at-exp adds support for S-expressions based on braces, and is the foundation of the Scribble markup language.
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!
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)
(> x y) (stringp foo) (oddp n)
#t #t (whatever)
#t #t (other-thing)
#t #f (etc)
This could be worked into a straightforward S-exp syntax without any diagramming shennanigans:
(table-cond
(> x y) (stringp foo) (oddp n)
#t () #t (let [...]
(whatever))
() #t #t (other-thing)
#t #f () (etc))
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.
(match
(list (> x y) (stringp foo) (oddp n))
[(list #t _ #t ) (whatever)]
[(list _ #t _ ) (other-thing)]
[(list #t #f _ ) (etc)])
The one thing I suspect match probably doesn't do is feature a fall-through mechanism that I alluded to; say we want (other-thing) for its side-effect, and then still evaluate (etc) if (> x y).
(Under no circumstances do we want fall-through to be opt-out, like in the C switch statement with its forgotten break bugs, but opt-in.)
Also, this mechanism could be optimized. Since the pattern lists must only contain #t, #f and _, they can be validated to contain nothing else. Accordingly, they can be arithmetically encoded (two bits per symbol), and subject to a numeric dispatch. '(#f _ #t) is a six bit number; '(_ #f #f) is another six-bit number and so on. Arguably, match itself could do that, but it's rather specialized.
Different but similar joke for C++: http://www.eelis.net/C++/analogliterals.xhtml
Basically, the layout is a red herring to an extent. E.g. the "\" in the shapes is only there for visuals - it's allowed because it's escaping the following linefeed, but not necessary.
If you strip out the "filler" it boils down to constructing an expression, using types and overloaded operators to represent an expression tree that is then evaluated by the C++ template processing to satisfy type constraints.
The "asserts" of sorts works by using templates to create a type that accepts only the corresponding type generated by the "literal" shapes as argument to the constructor.
It looks harder than it is because it's hard to "see" operators. Consider that e.g. "o---o" is "(o--) - o". and a rectangle boils down to "((o--) - o) | (!(!(!((o--)-o))))" or so (hope I got the parentheses right).
Sort-of. I've not bothered deciphering the exact details of how it's processed. The overall mechanism of using types and operator overloading to represent expressions is pretty well established in C++ template meta-programming, though, and is also used elsewhere. E.g. a lot of Ruby ORM query building and other DSLs is often using similar methods.
Personally, the Racket idea is good except for the hassle of typing in the borders (emacs-orgmode could help with that though).
The Racket one is definitely more towards the "practical" side than the C++ one (C++ is more constrained when it comes to how it can embed DSLs) but for me it falls into a similar bucket with the label "interesting and quirky DSLs that probably aren't practically useful but make me very happy". You may disagree regarding practicality and that's okay by me but please don't take offense. :)
--
https://stackoverflow.com/questions/5508110/why-is-this-prog...
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.
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.
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.
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...
SUPERTYPES = {'Real': ['Integer'],
'Complex': ['Real'],
'Integer': []}
def is_subtype(a, b):
if a == b:
return True
return any(is_subtype(x, b) for x in SUPERTYPES[a])
“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)
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)
EDIT: incidentally, the documentation for the syntax also refers to the built-in support for it in DrRacket.
[1]https://web.archive.org/web/20160316083925/https://docs.rack...
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...
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
> 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.
Looking forward to 3D syntax for functions of 3 arguments.
⎛if ⎛> (+ a b)⎞ ⎛case x ⎞ ⎛cond ⎞⎞
⎜ ⎝ (- c d)⎠ ⎜ (1 'foo)⎟ ⎜ ((> y 2) 'quux) ⎟⎟
⎜ ⎜ (2 'bar)⎟ ⎝ (t 'error)⎠⎟
⎝ ⎝ (3 'baz)⎠ ⎠