We convert () into a box for viewing, but de-convert it back to () when the line is selected for editing.
Unicode (and non-uncide special characters) is used as a rendering for ascii based operators. So >= is rendered as "≥"; however, for editing to work, we add a dot at the end so the character count remains the same, so its actually "≥∙", if you delete the dot, you are basically deleting the ascii "=" so the character becomes ">".
I thought about colors and graphics, but they create huge real estate issues, and they aren't widely applicable. Also, people get what "red" is while the literal color red is quite ambiguous.
Rather than find a new symbol for multiplication, it probably makes more sense to render the single x variable differently (as well as other single variable identifiers like i and j). I haven't implemented this yet, but its on my list.
If you look at the videos, you'll see that static and run-time errors are rendered underneath the tokens they are related to. The idea is to keep the feedback as close to the code as possible.
Isn't this really just clever syntax highlighting? Emacs, for instance, can already draw boxes around things. I spent about 5 minutes and got close[1]. If you had something like "pretty-symbols" installed [2] then you could probably make the quotes characters themselves not even show up at all. You could probably also do it with some font-lock code.
If it's more than syntax highlighting, then how do you make the "quoted" text? What keypress to you use to start and end the markup that signifies quotes? Maybe the quote key ;-)?
I agree with this (the second part). You HAVE to somehow make that string a string. So maybe you will only hit one key rather than 2 (quote, and quote again), but honestly you have macros that allow you to hit it only once.
I think one big part of all of this is speed of execution: both maximum speed, but also the learning curve. And I'm not at all sure that we can do better than typing text. Hell we've been trying to get rid of the keyboard for years, and yet nothing is faster than a VIM ninja
If the source file format for the language is not stored as plain text but it's already in a tree like file format then no, it's not just syntax highlighting but the natural way to handle this file.
I could imagine a source file format where the nodes have different types for different literals. There would be much less parsing problem than parsing plain text, of course it would need a special editor.
Needing a special editor is probably an insurmountable problem. There's a reason why textual representation of source code is so convenient.
Also, there must be a better example than quotes and strings for this "visual" representation to make sense. There is nothing hard about either reading or typing them. It's not even a particularly nerdy concept; readers and writers everywhere know how to handle quotes.
Quotes are already visual by the way. They simply aren't color-based. Which probably makes colorblind readers glad.
Already in a tree format like lisp? Or some binary structure? Even if it's some fancy binary format, it's still going to have to be parsed by the compiler and the editor (and thoroughly checked for syntax errors), making it no better than what we already have now (just different).
And unless those node types are "green round-rectangle", then I posit that it's still syntax highlighting, since the editor is deciding how to display "string node".
User-created syntax errors, possibly. But it can't completely eliminate them:
5 ↤ "hello"
Now you could argue that the editor might detect that and not allow it, but if your abstract syntax tree data structure can support it, then you will be handed it at some point and so you should detect it.
But more importantly, the abstract tree itself has to be stored. Whatever the format (binary or otherwise), that has to be checked, too (unless you want buffer overflows or code execution exploits in your compiler/editor).
All in all, it sounds like the same stuff compilers already have to deal with, so I don't think it wouldn't be a win there.
In seriousness, I think this kind of extreme highlighting could be an important step in making programming more accessible. There are only so many characters like ,;:.()[]{}<> available to use in code, and often most of them indicate completely different things in different places.
Done the right way, and combined with live evaluation á la Bret Victor or the Swift playground, I think this has the potential to be the next paradigm of accessible programming, after Excel.
Mathematica/Wolfram Language enables this with quite a bit of success, but it's by no means a silver bullet. The reality is this does not change semantics.
There are definitely things like LISPs with AST editors, or Squeak and the blocks, but the closest to what you're on about would be http://colorforth.com/ which is "niche" but has a strong heritage.
APL uses/used non-ascii characters. I don't think most people think of that was one of it's strong points.
What seems to have caught on instead is editors that use syntax highlighting/formatting to show ascii source code in not-pure-ascii ways. It would be interesting to take this further.
JavaScript also supports non-ascii characters in variables. You can make some pretty beautiful code involving mathematics (if the formula happens to be simple enough, that is). E.g.:
I believe these visual cues work against thinking in code and delay learning, though the concept has use as a debugging layer, or transitory programming aid. That said, truly visual and/or AI assisted programming, well executed, could blows the doors off programming productivity and accessibility.
There's a link inside to their paper on Language Boxes, which formalize the whole idea. It uses an incremental parser where nodes of the syntax tree can be opaque "boxes" which could contain any other nested AST, as the languages are parsed separately. It does a nice job of tackling the syntax composition problems, of which the proposals seem like a special case.
As Tratt points out though, the ideas are not particularly novel - they've been around for decades, but are usually met with resistance as they break existing workflows or programmer expectations. The design philosophy behind Eco, their prototype editor for language boxes, is that it should look and behave almost exactly like a traditional text editor. It does support highlighting of inner languages when they're selected, but the highlighting is usually not visible. I'm pretty sure we could turn them always on and get the kind of appearance this post is looking for.
Am I completely wrong in thinking that this isn't really e.g. "removing delimeters", but effectively changing the delimeters into invisible markup?.. It seems to me kind of an arbitrary distinction whether the way you represent a string to a compiler is with quotes or markup that renders a green box.
As far as the concatenation thing surely that's solvable by a grammar that interprets a single line list of expressions as an implicit concatenation. It doesn't seem like something that requires a particularly smart compiler - or a new IDE. Maybe I'm overlooking something inherently hard about the problem though.
I think the deeper point is not about the highlighting, but the ability to interact with the code semantically. If your editor was completely aware of the semantic structure of your code, it could provide very powerful refactorings that respected line-associated comments and things like that.
For example, it you would type a string, and wouldn't need to worry about whether it is represented as multi-line string or not or how to properly escape newlines and special characters. Your editor would know that you are typing a string and do the appropriate thing.
That said, many advanced IDEs do have very sophisticated syntax parsers which can do many of these things already. Light Table and Lisps evolve this even further. I would imagine that a language designed with this use case in mind would enable even tighter integration with the development environment though.
The languages that first became popular were restricted to the inflexible orthography of pre-computer punched-card accounting systems, but they aren't the whole story. Other early programming languages took advantage teletypewriter I/O, and used features like two-color ribbons (e.g. with comments in red) and half-line motions for superscripts (exponentiation) and subscripts. Some, like COLASL, MADCAP, and Klerer-May system, even accepted expressions typed in two-dimensional form.
It's definitely an idea I've thought about a lot (and would gladly work on). I really think strictly using plain-text as the interface to the compiler is a dead-end for language design. Language designers base features around what's symbols are available in ASCII... What would be needed of course would be library support for extending this interface. For example, an image library, and a complementary IDE plugin for managing image resources.
One huge thing plain text representation has going for it is the diversity of text editors, and the fact they can be trivially swapped. In my opinion, "visual" source code representations will also be a dead-end if it means propietary, mutually incompatible IDEs.
It might be nice to read code like this, but what is the big idea? I had to use labview and out of comfort opted for the script engine to implement as much as it could, because the graphical building blocks still represent the same syntax.
Not particularly hard to implement a code viewer for the specific examples and the parser is one of the less complicated parts of a compiler, i suppose. Instead of quotes as delimiters you get e.g. xml tags, that the editor generates.
Seems like everyone who spends 20 minutes designing a programming language comes up with this idea or similar. Yawn. Syntax isn't what makes programming hard.
The shallower the problem you're solving, the more important UX issues will be, relatively. When you're writing complex software, putting the text in boxes instead of quotes matters approximately not at all.
Programming language designers are basically UX designers for the task of programming. It's all very important, or Lisp would be much more popular than it is.
I'm kind of disappointed (but not surprised) that you didn't try a proportional font for code...it is my mission in life to banish fixed-width fonts from the earth.
In my mind, the ideal way to accomplish this would be:
- Encode the program in a data format like JSON or XML. Ideally, this should be readable (though verbose) on its own.
- Create an IDE that renders the JSON/XML using the typographical stylistic flourishes, and that possibly allows the definition of new styled "blocks". This could even be done with CSS.
Creating a language that is sufficiently connected to its IDE that it can define new syntax highlighting, autocompletion, etc. in the code itself would go a long way toward making something like this practical. DrRacket (http://racket-lang.org/) sort of does this already; it even has image literals!
Why use JSON or XML instead of storing it as code? The IDE can parse it even if it's normal code. In fact, all IDEs already parse and understand the code to a degree.
I believe these ideas are separate. I don't think the author is proposing that format be a part of language semantics, just that we should format better.
This blog post misunderstands the concept of "sufficiently smart compiler". He even links to the c2 wiki page for it, yet if he actually read it he would realize it has nothing to do with what he is writing about...
At the end of the article the author mentions IDEs, but also says "if only our compilers were sufficiently smart". Why? What do compilers have to do with the pretty-fied visual representation of the code, and corresponding input methods? Isn't this all about the IDE?
Also, what's the big deal with removing quotes? I didn't know they were hard to read or understand. Are we removing them from books as well?
I'd welcome a nice rendering of mathematical formulas, sure. But that's merely presentation.
Still completely unnecessary. The editor can display the string minus the escape characters with whatever color, highlighting etc. you like, and still keep the escape characters in the code as stored on disk for the compiler's benefit.
Basically, if you want an editor that displays code with colors and boxes instead of delimiters, that's fine; writing one would be a practical project. It is neither necessary nor desirable to attempt to design a new language, write a new compiler, version control system and half a dozen other ancillary tools at the same time as part of the same project.
I like the idea of an intermediary step between textual programming and visual programming. However the author only discusses how the symbols are rendered. What about input methods? I can think of a few options: use keyboard shortcuts, use the mouse, implement some kind of modal editor (vim-like) or a use special keyboard (APL keyboard comes to mind)?
That's simple... to start a string literal, you type a ", and as you type the green box will continue to expand to contain what you're typing until you type another " to end the literal. This is, somehow, better...
Simply render "xxxx" differently and you are about done; e.g. render it as ˹xxxx˼ with some background highlight.
Incremental text input is a different problem. If you only have to deal with a batch renderer, then no change is needed; if you have an interactive IDE, you might want to complete the closing " so feedback remains sane.
I am skeptical, it is yet another level of indirection. You write ascii code with control sequences that is compiled to this semi graphical representation, and then that is compiled to running code. You can't write the semi graphical code directly anyway.
It would make more sense is with a custom keyboard perhaps, like apl.
Re. units, see the dimensional library in Haskell. It encodes units at the type level.
Re. encoding data like images at the program level; this is not suitable for general purpose languages (IMHO) because it forces an implementation on the programmer. It's fine for relatively narrow-purpose languages like Mathematica.
I normally hate visual programming languages, but I really like this idea. Still symbolic, but adding a representation where you can... it makes a lot of sense to me.
I could imagine an IDE where it still serializes/deserializes to normal text, but you edit it in a mode like this.
I don't think that's all that horrible. If specialist tools require some training to use and have user interfaces that are extremely productive nobody bats an eye. A specialist keyboard for a programming language with very high productivity would make good sense.
Remember that when APL was created these things were not set in stone and what seems wrong to you in retrospect made perfectly good sense at the time (and in fact still makes perfectly good sense today, it's just that the world has moved on from APL to languages that are more verbose and/or that do not require symbols like these).
Math is another such language, and there is no keyboard suitable for entering mathematical expressions so we use software like LaTeX instead.
At least with the APL keyboard the link between input and display was very direct, with LaTeX much less so.
You would need new input methods, because with ascii, the src code shows what you need to input. But how do you input a colour? There's no standardised method. Also all the other text based channels need to be upgraded at the same time.
Backslash-hell can be solved in ASCII-based languages too. E.g. in ruby there are several ways to have a string literal:
"hello world"
"hello, #{name}!" # interpolation
%{hello world}
%{hello, #{name}!} # interpolation
%{hello, "#{name}"} # interpolation with quotes
%|hello, "#{name}"| # you can use other kinds of surrounding "brackets" if you don't like curly ones
Mathematica has a few of these features. If you paste in an image from a previous operation, then the image is shown inline in the piece of code you're typing.
That's why it wasn't presented as a solution, rather as an inspiration. IMO it makes more sense to read code like this, editing it can still be done with the usual delimiters. I'd see an editor that by default shows the formatted code but for lines with an active cursor, it switches to plaintext.
I was thinking in terms of say do a diff between previous versions of the files stored in svn, p4, git, etc. - and then keep in mind that these might be diffed/merged/viewed/reviewed in tons of different ways - from automatic tools checking certain coding rules, or expanding $fields$ (perforce/rcs), or reviewing online (ReviewBoard), or who knows what.
so far TEXT files (ASCII, utf-8, utf-16, etc.) have made most sense for source code, when comes to huge group of people (100+).
A few notes:
We convert () into a box for viewing, but de-convert it back to () when the line is selected for editing.
Unicode (and non-uncide special characters) is used as a rendering for ascii based operators. So >= is rendered as "≥"; however, for editing to work, we add a dot at the end so the character count remains the same, so its actually "≥∙", if you delete the dot, you are basically deleting the ascii "=" so the character becomes ">".
I thought about colors and graphics, but they create huge real estate issues, and they aren't widely applicable. Also, people get what "red" is while the literal color red is quite ambiguous.
Rather than find a new symbol for multiplication, it probably makes more sense to render the single x variable differently (as well as other single variable identifiers like i and j). I haven't implemented this yet, but its on my list.
If you look at the videos, you'll see that static and run-time errors are rendered underneath the tokens they are related to. The idea is to keep the feedback as close to the code as possible.