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.
I don't agree. I think there are two things conflated here and trying to unpick them both in the same system is a recipe for disaster. The two things are: (1) programming should be an exercise in linear-text 1970s ASCII art (arguably) and (2) programming should be easy and the hard decisions programmers have to make are all just intentional obfuscation to keep their jobs (not true).
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.
Looking at it from the other direction, we can start with the premise that applications like Excel, Max, Nuke, and Blender are already visual DSLs. The users are "programmers" of a sort, but not "coders" because they don't type code. Then the question is whether such a DSL can be extended to general-purpose computation with any advantages over text-based coding languages.
I mean programming is already ASCII art. That's why we indent as opposed to directly writing minified JS and why { and } are mirrors of each other. Self-limiting beliefs like those expressed in the comment you are responding to are more a function of what timespan the author was born in than anything else.
Its not my belief. I am trying to explain the false psychological hangup that is preventing us from accepting non-textual programming environments like projectional editors. No one ever agrees with me or admits it. Thats how I know I am right after seeing dozens of amazing tools over the years and this discussion repeated over and over.
I think #2 has been achieved a few times in specific domains, it's just that people don't really think of it as programming any more (spreadsheets, for example)
I found myself pondering what it is that makes spreadsheets approachable. And i suspect it is because the state is up front, and one do not have to track variable names, scopes, and so on, in one's head.
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.
This is pretty much correct. Spreadsheets have two powerful ideas: (1) the show the data (one the Learnable Programming principles) and (2) they are inherently live.
The greatest horror I have ever witnessed in my life is Ladder Logic, a GUI-based language for industrial control. Lured in by the sweet scent of (supposedly) not having to learn anything new, thousands upon thousands of EEs were tricked into inflicting upon themselves one acyclic directed cuthulu-beard after another, as they amassed screenfulls and screenfulls of white boxes implementing one operation apiece. One of my colleagues was tasked with supporting such a system, and like the weary Atlas he shoulders the burden to this day.
Beware, you all, the siren song of squares labled "concatenate." They will only add to your troubles.
Most ladder logic editors allow you to see the code in structured text format. As a former PLC programmer I think you or your friend just didn't know it well... it's pretty good for what it does: control industrial machines.
Programmers doesn't use text-based programming language because it gives them elite feeling. They use it because it is the currently best tool possible.
- 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, text editors are aplenty and every programmer can choose the editor they like best. With a WYSIWYG editor, you're likely locked into using that particular editor and all its design decisions.
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.
Similarly, the hard part of Mathematics is the math itself. It's not because we don't have WYSIWYG math equation editor, that people can't understand advance calculus.
On the contrary, we've been trying to simplify programming since a programmers job was to string wires between transistors, we hit the local maximum in the 70's and every single attempt since then to simplify things or point and clickify things has been an abject failure.
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.
> 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
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.
How sane were the non-programmers creations? I've sometimes wondered, if we did have an effective way to visualize code, how would people react when they see the horrors we sometimes create - or they make us create ;) ?
Pretty sane! The first view you get is a visual representation of the architecture, which is a really nice way to get to know someone else's code.
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.
Examine this thread and you will see my point perhaps. The degree that it became more accessible (due to not using cryptic text) made it more a tool for non-programmers.
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.
> 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.
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.
But are those people programmers? I mean if you show a 'real' programmer those people doing their job, will they really think they are doing programming or software engineers?
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?
> But are those people programmers? I mean if you show a 'real' programmer those people doing their job, will they really think they are doing programming or software engineers?
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.
I never thought that, just trying to explain the false psychological hangup. Luna is cool but there have been lots of tools like it that didn't become super popular for programmers.
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.
For the curious: that software is alive: https://www.abinitio.com/en. Aside: that's a surprisingly pleasant page for a tool aimed at the enterprise (you have to contact sales to get a price quote)
The fastest way to cure that idea as a programmer is to pick up one of the environments that was designed to make it "easy to program" in and try to work with it for a while.
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.
On the contrary, if you come up with a non-text tool that is really good, people will snap it up.
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.
If that were true we wouldn't have spent so much time, money, and effort on making programming more accessible.
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.
I know someone who programs in LabVIEW for 15 years, and is horrified by the idea that he could be forced to write in a different language, because visual programming is so much better (in his opinion).
To that point why, does no-one ever suggest that a WYSIWYG text editor (MS Word for example) is for non-writers to use? why is it totally reasonable for other professions to have tools that help them see what they're doing but so many geeks seem to cling to the idea that only non-programmers would want a tool that makes it easier to visualize the outcome of their work?
> To that point why, does no-one ever suggest that a WYSIWYG text editor (MS Word for example) is for non-writers to use?
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.
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.
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:
There you go. That just needs a very light syntactic sugar and it's there. The elements of the lists are constants, so you want to use a literal, and the quoting of that can all be hidden. The (list ...) around the incoming expressions can be trivially hidden also.
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.
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. :)
Folks over at JetBrains built a whole big tool to handle things like this[0], so there is some non-joke motivation. Still, it's nice that Racket can handle this perfectly well in plaintext.
Templates coupled with abusing operator overloading and escaping rules.
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.
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...
I feel like most of these complicated if else statements can generally be written much better for example.
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])
Which better expresses the intention of the code and is more flexible.
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.
Makes sense - but I should note that this syntax is from at least Mar 2016[1], so I'm guessing people haven't been clamoring for editor support if it's not available.
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.
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.