Hacker News new | past | comments | ask | show | jobs | submit login

I'm strong believer, even if that belief doesn't come up often, in structured editing[1] which sort of bridges the gap and makes writing invalid programs impossible, at least syntatically but I don't think adding type level checking is a big jump and I haven't kept up with research so that might already be there. Unfortunately I don't know any successful examples of that beyond research projects that I could point out. I remember hearing rumors that some of the LISP machines might have veered to that direction, but idk

Even more I don't believe in plain monospaced ASCII being the ultimate format for code. Luckily there I know one example that goes at least a bit further: Fortress[2], a language from Sun that had richer rendering format available (although the underlying form was still afaik textual). And of course APL is another example, albeit bit less easily approachable. Raku also has some cute tricks (of course it does) with unicode characters[3], but they are more really just tricks that radical revolution in design.

There are also lots of other interesting ideas on how to format and layout code in the research, just one random example is "code bubbles"/"debugger canvas"[4]

While I think all this and so much more has great potential, there is huge cultural entrenchment around simple text based programming that seems unlikely to be overcome any time soon. As for graphical programming, I think the common failure there is being often also heavily mouse-driven, while keyboard is really powerful input device.

[1] https://en.wikipedia.org/wiki/Structure_editor also known as projectional editor

[2] https://web.archive.org/web/20060819201513/http://research.s... has some examples, slide 33

[3] https://docs.raku.org/language/unicode_ascii for example "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously.

[4] https://www.microsoft.com/en-us/research/publication/debugge... paper has few screenshots




Re: "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously."

Except for the short-circuiting operators (such as || and &&) and the assignment operator, all operators in Raku are just subs with a special name. Adding your own operator to the language is as simple as adding a subroutine, e.g.:

    sub prefix:<√>($value) { sqrt($value) }
    say √9;   # 3




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: