Lambda the Ultimate

I didn't think Fortress provided rich typography as part of the programming process; it was just used in post-programming pretty printing.

It was intended for the user to use a clever editor rather than typing in the ascii backward compatibility text manually.

They had an emacs extension, at least.

https://code.google.com/p/fortress-mode/source/browse/trunk/trunk/fortress-mode.el

(The Davies & Kiczales paper seems to be unavailable.)
Intentional software
Expressive programs through presentation extension

The second link is broken.

Thanks, it was missing it's "http://". (Works in the address bar because the browser adds it, but in a link it ends up a relative link.)

Something like ActorScript is what I'm looking for, which seems to have features similar to what Abrahams' described. But it still doesn't look great; did someone who was experienced in typography, layout, and color ever give any input into the design?

Choosing Unicode for programming language constructs remains a work in progress. Do you have any suggestions for improvement?

I was actually just wondering if anyone had ever worked with a graphic designer in this area. There might be a lot of theory in visual chunking, prominence, font mixing, and layout that can be applied here that is way out of our field of expertise.

Are bold and italic sufficiently distinguishable to be semantically significant?

I don't have a problem recognizing an italic word as opposed to a regular word, but I do have a problem recognizing an italic character as opposed to a regular character when using single-character identifiers, or noticing that one letter in a word is italic/regular when the rest of the word is regular/italic.

Bold and italic are easily distinguished in most fonts, even for single characters. I agree that mixing in bold and italic is a single name is very dubious.

Eg. a bolded letter for a vector with unbolded equivalent for magnitude. I think it works quite well...the provisos being (a) the two symbols should refer to related concepts; and (b) you'd want a reasonably heavy bold typeface.

edit: sorry, you already said you find it hard to read. *shrug* I guess it depends on the reader (ideally, you'd like to be able to control concrete syntax with something like a user stylesheet, so a programmer could tweak any syntax they found difficult to read.)

Font size matters along with font smoothing technology. But with the advent of high-resolution displays like that on the Macbook Retina Pro, the, the definition of "hard to read" is changing.

I wouldn't use italics/bold to distinguish between different things. In document typography, italics and bold have special meaning: italics often means an introduction and bold often means emphasis (so do italics). From Wiki:

By contrast, bold font weight makes text darker than the surrounding text. With this technique, the emphasized text strongly stands out from the rest; it should therefore be used to highlight certain keywords that are important to the subject of the text, for easy visual scanning of text. For example, printed dictionaries often use boldface for their keywords, and the names of entries can conventionally be marked in bold.

I would hope that these two concepts could be adapted to programming in a similar manner. We could come up with a bunch of rules on how to apply typographic styles to code, but I don't think they should be based on semantic differentiation.

The whole reason that Unicode has bold and italic letters (and Old English and double-struck and other stuff) is for mathematical uses, where bold vs. non-bold and italic vs. non-italic is a semantic difference. Thus sin is s times i times n, whereas sin (in roman) is the sine function. In physics, bold variables are vectors, italic variables are scalars. Likewise, script H is the Hamiltonian, but if you use a Roman H, you get an integral equation instead. See "Unicode Support for Mathematics" section 2.2, Mathematical Alphabets.

First, understanding that there WERE separate versions of characters that meant different things, and second, figuring out how to distinguish them and rewrite the equations, held me back for a year in mathematics.

I was the guy in the back row with the laboriously-made flash cards that had specimens of various characters in different fonts, going through equations one character at a time and comparing, to figure out which 'n' I was looking at, before I could even start work on the problem.

I really don't want to repeat that horrible experience in programming.

Horrible for you, useful for practitioners. Same thing with macros, types, and most other things -- they get abused, but are useful in scenarios.

like being color blind and dealing with traffic lights.... except nobody's bothered to position code them so they can be easily distinguished.

Using those alphabets will mean I can't work on code unless I whomp up a name mangler to render all the names lexically distinct. Although I could do that. In programming it would be a lot easier than it was in math classes where you didn't even necessarily get the problems in a useful electronic form so a script could distinguish them.

But then it would render printed books about programming that used such a language (and the math-focused side of programming which produces the best books would, immediately) completely useless.

By using an appropriate IDE (Integrated Development Environment), a name mangler is not required for bold, itallic, etc.

An "appropriate IDE" will not fix whatever it is in my head that makes me effectively blind to the differences between italicized, standard, and bold letters.

An IDE could have have a mode in which the reserved word let is rendered by underlining or by any other decoration of your choice.

They already do. They look like `\\`.

Yes! This is exactly what I wanted, thanks!

I think we are getting way hung up on using typography to distinguish between different identifiers (Abrahams' proposal to be sure) and not enough on to make code more readable, chunkable, and scannable.

The video ends way too quickly though. All I can find out more is that the talk was done by David Durkee. Previous reddit discussion.

This is a nice start, but I'm sad there was no follow up. Is there any feasible way to break the chains of dumb text? (without going full-on structured/graphical, of course)

λ, ¬, etc.

Baecker and Marcus published an expanded version of this paper as a book: "Human factors and typography for more readable programs", Addison-Wesley, 1990.

It's been a long time since I've read it, but I rember that the book felt a lot like a published version of someone (I assume Marcus's) thesis. Using a small C program as the input, they start with the "standard" printed view of the code and then present various combinations of formatting options (layout, whitespace, type style and font selection, "links" to called procedures) that they then tried out in experiments. I can't remember the details of the experiments, but the "best" performing option is then presented at the end of the book as a set of formatting guidelines.

It was great work, and I'm amazed that it's been completely forgotten. It would be really nice if LaTeX modes for setting program text had an option to follow their recommended style.

Amazon link
Google Books

Unicode is fairly easy to render after the fact; e.g. rendering -> as an left arrow rather than as typed (and converting it back to -> during relexing so you can type ->>-). The main problem I have with unicode symbols is that it is often ugly; our fonts are not designed to organically include unicode symbols. This is easy enough to solve with some font design, but chicken meets egg!

Edit: forgot that the lt symbol was poison.

On a side-note, Smalltalk-80 used a single "<-" left arrow glyph for assignment in the UI, but this was represented as an underscore '_' in the ascii source code interchange format, which looked really weird. [Incidentally, remember to use < for the less-than character in LtU's markdown.]

If you find a free copy of the paper, I'll read it. All I've seen so far is the abstract offered freely, which you quoted above. It notes a pure ascii interchange representation is assumed always present:

... a language has three representations: a visual representation that describes its displayed form, an internal representation defined for each implementation, and an interchange representation, expressed in pure ASCII, that is defined across all implementations.

So presumably you can always type an ascii representation when desired, unless a UI dev has an obstructionist attitude about what lowly users are permitted to do.

Rendering code in different ways is an interesting idea. Unicode glyph options might be too narrow a focus, when you can also think about showing code in graphical form too, which strikes me as useful. But maybe it's not a whole lot different from an IDE that suddenly puts UML in your face. Some things would would be easier to grasp as diagrams than as text. (At work I manually turn FSM tables into ascii art drawings to really grasp what they do.)

There's a user accessibility issue involved, not terribly unlike that in web page presentation, where one wants to let end users override how things are rendered by changing defaults and preferences to avoid being stuck with fonts and sizes problematic for any given individual. Ray might be representative of a large constituency anticipating a need to tune how things render.

... older versions of ASCII, where it was the glyph corresponding to the modern _ character. ASR-33's, indeed, printed left arrows.

Pascal used an up-arrow glyph for dereferencing pointers, in pretty much the same way that C'ish languages use ->.

Later versions of ASCII (and therefore Pascal) replaced the up-arrow with ^.

What's interesting here is that the appearance of code changed but not the underlying representation or meaning. Thus, if you had a hardcopy printout, and were ignorant of the history, you might not figure out what representation would give you valid code. I can picture someone in the next generation with an ancient dusty greenbar printout, working their way through all of the unicode up-arrow glyphs, trying to figure out what the heck the compiler wants....

IIRC, there were four arrow glyphs in early ASCII. I don't remember where they all were now; just the two I used in coding.

I'm just using character names between backslashes as a method for entering the corresponding unicode character. For example, if I type \lambda\ I get λ, which my lexer regards as a name.

I definitely feel the pain though; Unicode was not designed to fit our puny keyboards. I've already assigned names to over 300 'useful' characters, and even though they are mostly XML entity codes and existing practice from other familiar sources, it's hard to keep all of those names in my head. And I'm going to want at least a hundred more (mostly mathematical symbols) before I'm done.

It's a semi-extravagant use of keystrokes but does render code in an admirably compact visible form onscreen when you can just use the one-character mathematical symbol for an operation or predicate instead of making up some more-verbose ascii name.

Do you keep all the definitions in the lexer or the grammar? Or do you have a syntactic form for introducing new aliases like this?

Seems the latter would be nice because library authors could add new ones if they came up with a good use for another character.

Tradeoff is it might be too confusing, I guess. Similar to how naming your own entities in your DTD didn't really catch on very much (AFAIK).

An object of the 'escapist' class, which manages all the aliases and lookups, is one of the arguments to the lexer's constructor.

It has a public method for adding a new name/character alias, but I haven't (yet) hooked it up to a routine callable from the language. There'd be nothing particularly difficult about doing so, though.

The 'escapist' constructor creates an empty escapist (no character/name aliases at all). There is a public method for adding the "standard" set of 300-odd aliases. which, so far, I'm just calling immediately after the ctor.

If you're interested, I can email C++ code for the escapist class, or put it up on a blog. It has a dependency on the STL, but aside from the list of aliases at one per line, it's fairly compact.

I'd be interested mostly to look at the list of aliases and steal the good ones. If you're OK with that and have time to put it up on one of the code hosting sites or somewhere that would be awesome. :)

Edit:
And also to see how you deal with the age-old subset vs. proper subset symbology question: ⊂⊆⊊⫋.

I don't know whether you meant specifically the set relations symbols or the fact that some symbol aliases are proper substrings of others. The link you gave is an example of both.

The latter problem is simply dealt with by having the trailing backslash. Because aliases in the input stream are delimited by backslashes there's never ambiguity about where an alias ends.

The former, I haven't dealt with very much yet; remember I said I was about to import another hundred symbols from the 'math' section? Well, set relations are some of them. I'm very likely to define aliases for all of those characters, and will later decide which of them (or which few) will be used as the names of standard predicates.

I meant the set relations specifically; espectially whether ⊂ is permitted as an operator and whether it is bound to subset semantics or to proper subset semantics.

Oh, heck; steal as many as you want. I did. Most of these are stolen, very self-consciously, from XML, LaTEX, and ASCII character tables. I decided to go for complete coverage of ASCII, which may be unnecessary or even fugly, but enables some things. I also pretty much took everything users might be familiar with from XML, with the exception of one that XML got blatantly wrong. In some cases I've added things I think will be easier to remember or easier to interpret when discovered an ascii-converted program dump, and made them the default form.

Here is the permalink to the source code for the escapist class on my blog: Unicode, some more .

The title refers to the fact that the previous post on the blog was also about Unicode in programming languages, so that may be of interest here too. So here is that permalink.

Critiques welcome; I don't use c++ very often, and I'm getting back up to speed with it as I wrestle with this language implementation. That said, it's a very simple class. The only really obvious thing I couldn't remember/figure out how to do reliably was using the I/O library to read a formatted escape sequence using a hex number. So I did it the brutal way.

Menues are often used for Unicode Characters, but you would want to have some way to organize them if you have a lot of characters.

When I learn Chinese writing, I don't remember the strokes for the character, but how it is pronounced since I'm used to pinyin input methods anyways (as are most people in China!). Something similar applies here.

Emacs has something very similar in the TeX input method (activate once with C-x RET C-\ tex RET, then use C-\ to toggle). Since the names are the same as in LaTeX, many of the names are likely already known to the user.

I would have preferred a modern space cadet keyboard though.

We read code more often than we write or edit it, so having it pretty to read might work out better overall. But I do understand not wanting to write unicode by hand on a modern keyboard.

Keyboard macros could probably help quite a bit, though. And there may be new input devices that - e.g. based on sketching or gestures (or gestures) - that could enable a wider variety of characters and symbols. When I think about input devices I'd want to tweak code in an augmented reality system or smart home, I think keyboards won't make it. But there will always be a role for symbolic representation of code.

I think a reasonable compromise is to have keyboard friendly string aliases for the Unicode symbols, which you set up once at definition sites. As in, replace "pi" with the symbol after it's typed.

I use Emacs "LaTeX" input method that allows to write the LaTeX names and get them replaced on the fly by the matching unicode character: \pi, \forall, etc. In my experience, writing this way is as convenient as the existing plain-ASCII syntaxes when they exists.

One downside of those mappins is that there is a learning cuve (when you fall outside the character set that you're familiar with from LaTeX), and not all LaTeX symbols map conveniently to unicode characters. Agda-mode has something similar that might be more principled.

I'd rather create programs with a gaming controller, making atomic refactor moves between consistent code states and navigating intelligent picklists. This paper's move towards model-view division of program representation is a great step away from archaic punchcard-looking editors and even more archaic everywhere-serialized representation of code. I would love to discard vim and git for an immersive visual interface over a relational database.

Intelligent pick lists or menus are problematic in their own ways: an option you're seeking tends move around based on context in difficult-for-humans-to-predict manners, thus requiring developers actually read the lists each time. Intelligent menus only pay for themselves if the option selected is almost always among the first three in the list.

Though, something like that may work if you can somehow narrow down the options in a consistent, high-level manner, e.g. based on buttons or pi-menu directions. But I'm not sure what high-level concepts could be applied across a broad range of code snippets. Maybe something library-specific could be achieved.

In the age of touch, why would the option have to be one of the first....three?

Touch is among the worst interfaces for pick lists, intelligent or otherwise. The hand easily covers half the list, interfering with the reading thereof. The list covers a portion of the screen, interfering with contextual knowledge of where you're applying the option. The human visual focus is much smaller than the human hand at arm's length, so we inevitably end up covering with our hands exactly the things we're trying to read or influence. IMO, touching the same screen used for visual feedback isn't the brightest of HCI concepts, though it works well enough for low rate human-to-computer communication. (If we added some extra haptic feedback, e.g. touch screens that raise fluid buttons, this could be mitigated.)

Assuming you have abundant visual and haptic space for presenting as many options as you could ever want (e.g. using Oculus Rift for AR plus Myo or Leap for gestures) the remaining issue with 'intelligent options' is that they're intelligent. To a human, they're unpredictably located, and therefore inaccessible to muscle memory, and therefore require extra use of sensory organs (usually the eyes) to scan among the options available.

Scanning options costs time and mental fatigue. And these costs grow super-linearly with the amount scanned before making a choice. (The super-linear nature is due to making more comparisons between choices.)

Meanwhile, humans have excellent spatial memories and spatial processing abilities. With spatial memory, we can handle a stable 'organized chaos' quite well. With spatial processing abilities, we can handle 'automatic layout' fairly well (so long as it's simple). These work well with the sense of proprioception and the so-called 'muscle memory', which are both internal to the human and thus don't require scanning the environment. The mental fatigue of muscle memory is quite low, and largely subconscious.

Ultimately we must weigh the alleged benefits of 'intelligent' options against the benefits of 'dumb but predictably spaced' options. I've explored this some in my day job, albeit in terms of 'context-dependent' options. My informal user-studies suggested that context-dependent options are okay for 3-5 options, fewer if the options are relatively complex (require more time to scan and grok). This isn't to say that ALL hits must be within the first three, but the vast majority should be.

There are ways to mitigate issues with intelligent lists. E.g. if you can rapidly narrow down the list based on another input that doesn't involve looking at the options (perhaps voice or a secondary touch model) then it becomes easier to reduce the options to just a few for active scanning. OTOH, the same methods can work for narrowing items in a predictable automatic layout.

I do not like the idea of having to search through lists to find items or, for that matter, relying on an "intelligent" system to guess for me what it thinks I might want; I, being a touch typist, much prefer being able to directly type what I want, where I do not even have to think much about the individual keys I am pressing. (In editors like Eclipse, I do not appreciate the menus they pop up, because searching through those menus is more of a hassle than simply typing, and the menus themselves often cover parts of the screen that I am trying to read as I type.)

This even applies to editors that attempt to be "intelligent" and make my life easier by adding extra characters ahead of time for me or dynamically changing what individual key-presses actually do, such as Eclipse. I often find myself deleting extra characters and reordering characters with such editors, and trying to read ahead of my typing to see just how the editor is going to try to "help" me is an unnecessary hassle; if I actually wanted what the editor thought I wanted I would have typed it in the first place! I want my editor to only handle indentation and syntax highlighting for me, and to let me type what I want rather than guessing for me what it thinks I might want ahead of time.

Touch typing has a lot of nice properties, but it also has a few disadvantages - e.g. it's hard to touch type without also having a place to sit and a rather bulky keyboard. And for component-based programming, grabbing from a list is often more convenient than rewriting the component or memorizing a GUID or similar.

Even though picking from a list is an awful interface for tablets and smartphones, it is often more convenient than hauling around a keyboard.

In an augmented reality setting, we might be able to project a keyboard whenever we need one, but component-based visual programming is also more feasible (due to larger virtual workspaces and more readily accessible component inventories).

Anyhow, if I were limited to the traditional desktop setup and relatively free-form text, then I agree with your observations. I've experienced similar troubles with auto-completion.

I got one of these:
http://www.amazon.com/Bluetooth-Wireless-Keyboard-Android-Smartphone/dp/B0043862N4/ref=sr_1_2?ie=UTF8&qid=1374970254&sr=8-2&keywords=mini+bluetooth+keyboard

It fits in your pocket with the phone, and it's far less miserable than typing on a touchscreen. Being a thumbboard, it isn't as nice as a full-size keyboard, but it's good enough to make typing into a non-problem for most purposes.

I would far rather use a device like this than trying to program by picking stuff from lists. I can thumb text in without thinking (or while thinking about the next problem), so being slower than a regular keyboard isn't a problem unless my hands fall far behind my mind, which with programming doesn't happen all that often.

Bear

I'd rather create programs with a gaming controller,

Back when the 6502 was king...

http://www.flickr.com/photos/25885309@N02/sets/72157604661612578/