Slashdot Mirror
Why Haven't Special Character Sets Caught On?
theodp asks: "Almost forty years after Kenneth Iverson's APL\360 employed neat Selectric hacks to implement Special Character Sets to express operators with a single symbol, we're still using clunky notation like '<>', '^=', or 'NE' to represent inequality and cryptic escape sequences like '\n' to denote a new line, even though the Mac brought GUI's to the masses more than twenty years ago. Why?"
Now sonny, sit down a second and listen to grandpa rant about the good old days. The truth is, when I talk about the good old days, it's not because the days were actually good. It's because I have a sucky memory and questionable taste.
Now it is TRUE that I once did do programming in APL. This was on an old Zenith 8088 based PC clone with 640K of memory, a CGI display, and a 20 meg hard drive. The system itself worked rather well. If you could work a line editor, the development environment was all you could want. The problem was all the little stickers that went on the keys. Every key mapped to about three other symbols besides the normal ones, and just about every key had a little sticker on it. It was NOT fun. Just because your computers can display characters that look like Chinese doesn't mean that it's a good idea.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
Now, really APL is just functional programming in disguise, with a pathetic lack of flow control constructs. Now, if you're familiar with Scheme or LISP, you end up wondering just what the hell the point is of doing a bizarre sequence of keystrokes to produce a strange glyph, when you could instead just type out "reduce" or "map" or whatever it is you wanted to do.
That said, if you're a Linux/X user and want to input oddball characters occasionally, I highly recommend getting familiar with xkeycaps/xmodmap. You can turn one of the more useless keys into Multi_key. You hit that key and do something like "e'" for é, "ss" for ß, "L=" for £ and so on.
What might be interesting is if you can have your keyboard switch modes.
I could put the keyboard in math notation and automatically the keys on the keyboard display math symbols in a standardised pattern (like QWERTY is for letters but for math). Other modes could be added later.
On slashdot a few months back there was a keyboard in which the labels on the keys are dynamic. I think that is going in the interesting direction.
It reminds me of maybe how the computers in Star Trek Next Gen might behave. Where the terminal/key layout is specific to what you are doing (Engineering, medical, etc).
Basically instead of having a stupid windows dialogs where you click on stuff, you can use the keyboard designed to do your task.
It also amazes me seeing asian languages being typed in a computer.
fewer bugs?
i think you remember what happened when "they" introduced extended characters in the DNS: the only people who really used them were the phishers who could now create domain names with the new characters that looked very much the same as the names they were trying to imitate so browsers had to make a 180 for security reasons.
source code is a slightly different environment, but there it can already be different enough to visually distinguish between l and 1 in many fonts, or the various variations of an empty circle (oO0). You may argue that nobody willingly uses variable names like ll1O0, l1100 and lllOO, but rare those bugs _will_ happen more often once people start using exotic characters in source. source code has to be as unambigous as possible on every level.
ps: and while standard encondings exist it is still commonly seen that nonstandard characters get lost for example in cvs, "why waste time on configuring when only some umlauts in comments get lost?", but well, there are "standards", not "one standard", that makes great difference.
[i have an opinion and i am not afraid to use it]
The concept that APL code is "hard to maintain" is correct to first approximation, but it's more myth than reality when one digs deeper into the question. Most of the densest lines of code I once concocted in APL were 100% maintenance free: efficient and correct over the entire usable operand range. The density of the code squeezed out many degrees of freedom for making stupid errors even before you began.
There were other factors, having little to do with code density, that made APL systems hard to maintain. One was the psychological feeling that written twenty lines of comments to describe one line of code was somehow ungainly. I overcame this feeling within myself rather early. In fact, I wrote so many lines of comments for each line of code that my first work-term supervisor wrote a program to crawl through all the functions in one of my workspaces to *remove* every line of comment I had written, because he somehow thought he would understand my code better if he could fit it all onto the screen at once. His problem was that he didn't understand the *concepts* in my code. One of the things about raw APL code is that there are few surface markers that distinguish necessary manipulations from deep concepts. In my C language code, the necessary manipulations are largely gathered together in the initialization statements for local variables. Well, how much a language design should be based on protecting the programming team from supreme idiocy?
The second factor that made APL hard to maintain is that that it tried to force every concept to become a nail. The array primitive was surprisingly powerful, but it just didn't handle certain kinds of data aggregates at all well. And neither could you push this structure in the lexical direction, because there was no regex facility either.
And finally, the notion of a "workspace" was itself suspect. Every function was it's own text. There was no text anywhere that declared or described or controlled all the global variables that the workspace would necessarily include. There was no textual grouping of related functions into a higher-order interface or language facility. These decisions were made because APL originated in the teletype era. It had nothing to do with expressive density.
I think there is also an illusion at work that if you spend the day performing a maintenance task by visiting twenty source files and pawing through several thousand lines of code, that you are working with some greater efficiency than the guy who spent the whole day staring at single screenful of starkly beautiful APL scratchings. That's not so obvious to me having been there.
OK, here's the thing. In APL if a programmer decided to cut corners and forsake the "stark beauty" that made APL a workable language, there was precious little left behind on the surface to betray the sloppy work standard. Take one look at a C program written by a programming in a sloppy mindset, you know right away you are maintaining the droolings of an idiot. In APL, it could take you an hour to parse beneath the surface to find that same incompetence leaping out. The C language has far more expressive scope for the droolings of idiots and I guess those markers are worth a lot at the end of the day.