
WysiScript: Programming via Direct Syntax Highlighting (2017) - logicallee
http://www.zifyoip.com/wysiscript/sigbovik.html
======
gwern
This is droll but I think it inadvertently makes a good point: we _should_ be
using more aids like syntax highlighting for natural language.

Natural language is at least as hard to understand as artificial programming
languages, and humans have (reluctantly) regularly improved the syntax
highlighting of natural languages, by adding consonants, spaces, scores of
punctuation marks, cases, and variant typefaces. (Consider trying to read
something like ancient Hebrew in the original, written without spaces,
consonants, punctuation, or lower vs uppercase - never mind italics or bolds!)
Why don't we add more? Surely we did not invent the ultimate way of writing
English around 1500 AD?

The primary distinction seems to be that computer languages are regular enough
to be machine-annotated. If you had to hand-typeset every line of code, syntax
highlighting would be used only in the rarest of CS publications. (Sort of
like color-coding in equations: incredibly useful pedagogically, but also so
difficult to do in HTML or TeX on top of actually writing the equations that
only the occasional enthusiast or particularly-determined teacher will
bother.) Natural language is such a major challenge to annotate simply by
part-of-speech that you need to be a linguist to do so reliably. So naturally,
no one ever does, and anyone who might want to is deterred by the fact that no
one else does so readers won't understand or like it. (Beginning programmers
are often confused or distracted by syntax highlighting as well.)

However, when you look at the best grammar/style checkers, or deep learning
results on parsing natural language, it seems plausible that they've gotten
good enough that something useful could be done with them...

~~~
Konohamaru
> (Consider trying to read something like ancient Hebrew in the original,
> written without spaces, consonants, punctuation, or lower vs uppercase -
> never mind italics or bolds!

Semitic languages are legible without vowels. Modern Hebrew... not so much,
due to its great influence from Standard Average European. This is a major
problem in Israel today (people often depend on the English [really I should
say Latin] transliteration to read Hebrew place names) and many Israeli
linguists are advocating just switching to the Latin script. Which as a former
student of Hebrew I support.

------
wanderingstan
As someone who loves coding and design, this was a very fun read.

But in all seriousness, the visual design of code these days feels archaic.
The only real "innovations" in the last 50 years of on-screen coding have been
block indenting and syntax highlighting. (And arguably coding ligatures.)

Coders of the future might find our source code as clumsy and impenetrable as
ancient writing before the inventions of punctuation, headings, spaces, arabic
numerals, footnotes, etc...

I'm working on some ideas and playing with some prototypes. If anyone else is
interested in the subject, give me a shout. <my username>@gmail.com.

------
hjek
> This is why plain text is not executable—it lacks formatting. (This also
> explains the lack of functionality in Microsoft Excel.)

The author is not alone in that observation. There's an incredibly high demand
for _programming via formatting_ functionality in spreadsheets[0][1][2][3].
One can only wonder why no one has yet tapped into the huge market opportunity
of supporting WysiScript in Excel or LO Calc.

[0] [https://ask.libreoffice.org/en/question/4477/sort-by-
color/](https://ask.libreoffice.org/en/question/4477/sort-by-color/)

[1] [https://ask.libreoffice.org/en/question/46352/how-to-
filter-...](https://ask.libreoffice.org/en/question/46352/how-to-filter-rows-
using-row-color-in-libre-calc/)

[2] [https://ask.libreoffice.org/en/question/98321/need-to-
sort-d...](https://ask.libreoffice.org/en/question/98321/need-to-sort-data-by-
background-color-in-calc/)

[3] [https://ask.libreoffice.org/en/question/136705/hi-is-
there-a...](https://ask.libreoffice.org/en/question/136705/hi-is-there-a-
function-sort-or-filter-by-color-in-libreoffice-calc-if-not-is-there-a-hack-
to-filter-cell-by-color-thanks/)

------
abathur
There are some gems in the conclusion :)

> In this paper we introduced WysiScript, a formatting-based programming
> language that streamlines the programming process by removing the awkward
> necessity of writing text. We gave an overview of its main ideas and a tour
> of its built-in features, demonstrated its simplicity and ease of use with
> several examples, and proved rigorously that it is equally as powerful as
> other languages and significantly more colorful.

> In particular, we believe it will appeal to many types of students who may
> not have an interest in traditional text-based programming, including
> painters, graphic designers, and the illiterate.

> An obvious limitation of WysiScript in its current form is the restriction,
> imposed by the RGB color model, that a single program can have at most
> 16,777,216 different user-defined variables and functions. This hinders the
> use of WysiScript for census-taking in the Netherlands, for example, because
> the Dutch population is 16,979,729. Future versions of the language may
> relax this restriction by adding support for additional colors not
> representable in RGB, such as ultraviolet, infrared, and plaid.

> In order to support quantum computing, which makes use of value
> superposition and probabilistic algorithms, future versions of WysiScript
> may make use of the alpha channel in color specifications.

------
zokier
While this is obvious joke, I think there is speckle of a idea there too. For
example string literals and comments could easily be distinguished only by
formatting in the editor and do away with delimiters and especially escaping.
Or it could allow more natural formatting of snake-case identifiers by having
single continuous underline for the identifier.

I know rich text for code is not widely accepted concept, but I think there is
potential there and not just for laughs.

~~~
Syzygies
The obvious middle ground is syntax that is clear to the compiler, easy for a
user to write but harder for a reader to parse at a glance, aided by syntax
coloring to make all obvious.

Many programming languages use indentation-based parsing, yet no language
adopts the convention that left-justified is a comment, indented is code. I've
used preprocessors for years that provide this for me, in languages such as
Haskell. I only gave up to more quickly use other people's tools as I switched
editors.

Despite using dozens of languages since, the bulk of my lifetime has been C.
There's an increasingly lame argument justifying its awful use of punctuation
to avoid whitespace significance: Code can be sent through pipes that poorly
respect whitespace. My memories of C punctuation are ground glass in my eyes,
yet many new languages try to look like C to better attract programmers
suspicious of the unfamiliar.

Comment characters in any language are ground glass in my eyes. Syntax
coloring can mute these characters, but they're still there. They don't need
to be there; syntax coloring can instead emphasize what's a comment, what's
not, after inferring from more subtle programmer cues.

I also removed parentheses from Lisp. I tried everything to wean myself from
this, believing the experienced Lisp programmer's creed that "you'll get used
to how the water tastes in this city!" Fonts where the parentheses are
lighter, syntax highlighting where the parentheses largely disappear. Then I'd
look back at my parenthesis-light Lisp code, and I'd realize I love reading it
more than code in any other language I've ever seen. The truth is that
parentheses are just the dumbest, most dated way to indicate trees to the
compiler. Editor tools do just fine with far more subtle cues. Lisps have been
on the wane for decades, and this is a profound intellectual loss. Lisp
programmers insisting on talking an Algherese dialect of Catalan is one
factor.

We need to recognize that our norms for programming language syntax predate
the prevalence of modern editors, language servers, syntax highlighting. I'm
64, and it's profoundly embarrassing that we're not further along than I
dreamed we'd be as a grad student in 1980. We all thought the future would
come a lot faster. Tree editors that only create grammatically correct code,
aided with machine learning prediction? We're creeping up on this, it should
have been the norm decades ago.

Joke or not, designing languages with syntax coloring in mind is a great idea.

~~~
hhas01
I expect you’re familiar with Knuth’s literate programming and notebook-style
programming interfaces of Jupyter and Mathematica.

[https://en.wikipedia.org/wiki/Literate_programming](https://en.wikipedia.org/wiki/Literate_programming)

[https://jupyter.org/](https://jupyter.org/)

Re. Lispy langs, agree about improving readability of the actual words by
visually deemphasising punctuation. So many key presses to say so little; only
traditional C syntax beats it out.

(Alas, nothing can ameliorate C’s swathes of needless line noise, except to
stop making languages with C-style syntax. Baby steps.)

I don’t quite agree about structure editors—if there’s one thing 10,000 years
of the written word should tell us it’s that the writing part needs to be
flexible. Better to beg forgiveness than ask permission. It makes more sense
for a code authoring tool to accept (and execute, within limits) the initial
imperfectly constructed text, and from there negotiate edits and corrections
with the author—a literal editor, if you like.

Another thing I’d like to see syntax highlighting do: provide multiple
semantic views onto code beyond just crude grammatical categorization of
words. Why can’t I have a view that colors words according to the library they
came from, or any other high-level categorization? e.g. Show me all the words
that have side-effects or perform “dangerous” operations. Or distinguish all
the words relating to string manipulation, or accounting, or UI.

Embarrassing? Honestly, it’s painful the lack of innovation going on. While
I’m gradually exploring some of this stuff in my own work, I really wish
others would step up to the plate. I’m lazy and very slow, and would far
rather smarter people do all the work so I can just enjoy the results.

~~~
hjek
> Why can’t I have a view that colors words according to the library they came
> from, or any other high-level categorization? e.g. Show me all the words
> that have side-effects or perform “dangerous” operations.

This. Highlighting side-effects would be especially helpful in language where
this isn't clear, like JavaScript. »`sort()` is red so it must be
destructive.«

------
throwaway_pdp09
Joke as it is, to me it makes an self-contradicting point. If you look at the
top highlighted code, there's a l0t of stuff there that I don't think adds any
value. I certainly know of no work that suggests the 'excesses' (my words) of
colouring help.

My experience is that comment highlighting really do help, especially for
commented-out code so you know it's dead, I'm much less sure about the rest.

#include is red - it's graphically visual enough for that not to help, plus
#inbcludes almost always live at the top.

int and void are coloured another red, does that help? return is blue - does
that help? Does colourising string literals help? I don't think so. Code ends
up looking slightly gaudy, I don't feel that beyond a limited point it adds
much.

Opinions?

------
hhas01
While I think that “paper” was probably funnier in its authors’ heads, there
is some actual precedence: Atlas Autocode used underlining to distinguish
user-defined identifiers from the language’s own keywords.

[https://en.wikipedia.org/wiki/Atlas_Autocode](https://en.wikipedia.org/wiki/Atlas_Autocode)

------
tutfbhuf
[https://xkcd.com/2309/](https://xkcd.com/2309/)

~~~
jagged-chisel
Mobile-friendly, accessible alt-text
[https://m.xkcd.com/2309/](https://m.xkcd.com/2309/)

~~~
larodi
which came first - the xkcd or the HN post :D besides the original paper is
with date 31 March, so was scheduled for april 1 release ...

------
kalium-xyz
Is this in any way different from colorforth?
[https://colorforth.github.io/](https://colorforth.github.io/)

~~~
one-more-minute
See also Piet:
[https://esolangs.org/wiki/Piet](https://esolangs.org/wiki/Piet)

~~~
compressedgas
Definitely closer to Piet than ColorForth. ColorForth only uses color to
replace what would in Forth require the use of compiler meta words. Piet is a
2D language that uses the difference in color between two cells to encode its
instructions.

------
boygobbo
cf. ColorForth:
[https://www.youtube.com/watch?v=LJoRyxRcj4A](https://www.youtube.com/watch?v=LJoRyxRcj4A)

------
neonate
(Dated one day before April 1)

------
chadcmulligan
gave me a chuckle

