6 ms·

WysiScript: Programming via Direct Syntax Highlighting (2017)

59 points by logicallee 6y ago

chadcmulligan 6y ago
gave me a chuckle
tutfbhuf 6y ago
https://xkcd.com/2309/ https://xkcd.com/2309/
- jagged-chisel 6y ago
  Mobile-friendly, accessible alt-text https://m.xkcd.com/2309/ https://m.xkcd.com/2309/
  - larodi 6y ago
    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 ...
boygobbo 6y ago
cf. ColorForth: https://www.youtube.com/watch?v=LJoRyxRcj4A https://www.youtube.com/watch?v=LJoRyxRcj4A
kalium-xyz 6y ago
Is this in any way different from colorforth? https://colorforth.github.io/ https://colorforth.github.io/
- one-more-minute 6y ago
  See also Piet: https://esolangs.org/wiki/Piet https://esolangs.org/wiki/Piet
  - compressedgas 6y ago
    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.
wanderingstan 6y ago
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.
gwern 6y ago
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...
- contravariant 6y ago
  Are you sure you're not reinventing HTML+CSS? Besides I think we shouldn't ignore the possibility that programming is highlighted too much. I'm not entirely convinced using many coloured syntax highlighting is any clearer than just well use white-space and highlighting keywords comments and strings (the latter two because they aren't part of the regular flow, the former because they heavily influences the flow of the program).
- Konohamaru 6y ago
  > (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.
zokier 6y ago
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 6y ago
  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.
hjek 6y ago
> 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-rows-using-row-color-in-libre-calc/ https://ask.libreoffice.org/en/question/46352/how-to-filter-... [2] https://ask.libreoffice.org/en/question/98321/need-to-sort-data-by-background-color-in-calc/ https://ask.libreoffice.org/en/question/98321/need-to-sort-d... [3] 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/ https://ask.libreoffice.org/en/question/136705/hi-is-there-a...
hhas01 6y ago
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
abathur 6y ago
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.
throwaway_pdp09 6y ago
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?
neonate 6y ago
(Dated one day before April 1)

59 points by logicallee 6y ago

chadcmulligan 6y ago

gave me a chuckle

tutfbhuf 6y ago

https://xkcd.com/2309/ https://xkcd.com/2309/

jagged-chisel 6y ago
Mobile-friendly, accessible alt-text https://m.xkcd.com/2309/ https://m.xkcd.com/2309/
- larodi 6y ago
  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 ...

boygobbo 6y ago

cf. ColorForth: https://www.youtube.com/watch?v=LJoRyxRcj4A https://www.youtube.com/watch?v=LJoRyxRcj4A

kalium-xyz 6y ago

Is this in any way different from colorforth? https://colorforth.github.io/ https://colorforth.github.io/

one-more-minute 6y ago
See also Piet: https://esolangs.org/wiki/Piet https://esolangs.org/wiki/Piet
- compressedgas 6y ago
  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.

wanderingstan 6y ago

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.

gwern 6y ago

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...

contravariant 6y ago
Are you sure you're not reinventing HTML+CSS? Besides I think we shouldn't ignore the possibility that programming is highlighted too much. I'm not entirely convinced using many coloured syntax highlighting is any clearer than just well use white-space and highlighting keywords comments and strings (the latter two because they aren't part of the regular flow, the former because they heavily influences the flow of the program).
Konohamaru 6y ago
> (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.

zokier 6y ago

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 6y ago
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.

hjek 6y ago

> 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-rows-using-row-color-in-libre-calc/ https://ask.libreoffice.org/en/question/46352/how-to-filter-... [2] https://ask.libreoffice.org/en/question/98321/need-to-sort-data-by-background-color-in-calc/ https://ask.libreoffice.org/en/question/98321/need-to-sort-d... [3] 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/ https://ask.libreoffice.org/en/question/136705/hi-is-there-a...

hhas01 6y ago

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

abathur 6y ago

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.

throwaway_pdp09 6y ago

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?

neonate 6y ago

(Dated one day before April 1)