My disappointment with Rob Pike's Go language is that the rest of the world has moved on from ASCII, but he did not. Why keep trying to cram an expressive syntax into the straitjacket of the 95 glyphs of ASCII when Unicode has been the new black for most of the past decade?
Unicode has the entire gamut of Greek letters, mathematical and technical symbols, brackets, brockets, sprockets, and weird and wonderful glyphs such as "Dentistry symbol light down and horizontal with wave" (0x23c7). Why do we still have to name variables OmegaZero when our computers now know how to render 0x03a9+0x2080 properly?
The most recent programming language syntax development that had anything to do with character sets apart from ASCII was when the ISO-C standard committee adopted trigraphs to make it possible to enter C source code on computers that do not even have ASCII's 95 characters available—a bold and decisive step in the wrong direction.
While we are at it, have you noticed that screens are getting wider and wider these days, and that today's text processing programs have absolutely no problem with multiple columns, insert displays, and hanging enclosures being placed in that space?
But programs are still decisively vertical, to the point of being horizontally challenged. Why can't we pull minor scopes and subroutines out in that right-hand space and thus make them supportive to the understanding of the main body of code?
And need I remind anybody that you cannot buy a monochrome screen anymore? Syntax-coloring editors are the default. Why not make color part of the syntax? Why not tell the compiler about protected code regions by putting them on a framed light gray background? Or provide hints about likely and unlikely code paths with a green or red background tint?
via queue.acm.org
I still try to enforce upon myself an 80 character limit in code. This makes it easy to interact with the default terminal size 80x24, which came from early dumb-terminals. Yes, we have wider screens these days, and the capacity to change this, but we also have to consider actually being able to read things, and line length needs to be considered here.
As for color, similar things apply. Piet did this, and it's considered esoteric at best. It, however, works for colorForth but how many people do you know that are using colorForth?
The only argument that he makes that I feel I can stand behind is the unicode one, and even then, I'm hard pressed to agree given the difficulty of entering unicode characters efficiently and effectively. We could definitely see improvements in legibility and meaning for mathematically intense code, but it's unlikely that most programs would make effective use of it, save for list and set comprehensions which certainly would be better expressed:
{ x: x ∈ X } and { {k, x}: k ∈ K ⋀ x ∈ X ⋀ P(x) }
The equivalent in Python: [l for l in L] and
[(k, x) for k in K for x in X if P(x)]
Imagine, executable LaTeX!
