The first program to be converted to UTF was the C Compiler. There are two levels of conversion. On the syntactic level, input to the C compiler is UTF; on the semantic level, the C language needs to define how compiled programs manipulate the UTF set.
What is everyone's opinion of LabView. Clearly it was never designed as a server-side language, but it has a very not "linear" approach to designing.
I used to mock LabView (arguing speed and complexity), but now that I work with a colleague that exclusively uses it--we are a medical research engineering group--I really start to respect its utility.
So the question becomes: Would an opensource cross platform scripting language, modeled after LabView, fit this bill?
However, they tend to fall down for many general programming paradigms. LabView is probably the furthest along that I know of in attacking more general problems, but ultimately they are designed around building a pipeline: datain->do something->data out.
LabView also builds in interesting levels of instrumentation and interactive components that can make it seem more general purpose like.
In that sense, the old UNIX tools (simple, single function tools you can pipe together to create complex systems) are the same thing.
But there are other graphical programming environments that aren't focused around pure dataflow.
Is actually a very interesting experiment in using graphical components to build up a program. But ultimately it's just a nice wrapper around a regular old programming language, and in playing with it a bit, I found that it was simply faster to just type things in a regular old language.
One of the more interesting things about graphical programming systems, is that you can often coax people into learning to use them who otherwise would have no interest or inclination towards writing code. I think there's probably a huge untapped market for a fully graphical system that can compile and perform like native code...
Exactly, basing the assumption that computers are only about data in->do something->data out, is a bit of an old-fashioned way of thinking. These days, the vast majority of computation involves execution loops:
1 - Display something (perhaps put some data out)
2 - Receive input
3 - do something (perhaps combine input with data in)
4 - goto 1
This is true of everything from video games to operating systems.
Dataflow models are simply a subset of the models of computation we deal with these days...they are extraordinarily useful models, but still limited in what they do.
I've used labview and it's awful. It takes hundreds of clicks to get a couple of function calls in place. I'm not saying that something like labview couldn't work well, but the implementation in labview requires far too much clicking work to build a program.
Totally agree, this has made me cry working on any app that has been sustained for years. This is why I think for any "graphical" language approach to be adopted by seasoned programmers should be fully keyboard accessible (think vim, but you can manipulate things across files and objects.
I've been thinking a lot about this, since I have needed to use LabView at my job the past few years. While I hate labview for the sake of writing applications that need to be continuously refactored and scaled, it's immensely useful for non-programmers to create a working program quickly.
So far I've been wondering if a graphical interface a la labview could work if it translated down into say, erlang code. It all depends highly on who the target audience is...a test engineer, or someone wanting an easier way to write scalable distributed applications. If the latter, I'd expect the interface to be a very well thought out interface that lets you effortlessly flow between drilling down into functions and seeing the greater view of all the code in your application.
Syntax-coloring editors are the default. Why not make color part of the syntax?
Chuck Moore, of course, has done this with Colorforth. I read him somewhere saying that by encoding some of the program in color, a visual part of the brain not normally involved in programming was engaged, freeing up other cognitive resources to think about the problem at hand. He didn't put it that dogmatically; it was more of a speculation about he found this use of color so helpful.
The obvious reason not to make color part of the syntax is that it precludes me from having different colors from whoever designed the language. In my case this is just inconvenient, but for color blind programmers, it could actually be a serious impediment to doing their job.
Of course, the solution to this would be to instead provide a UI (presumably in your editor) to change which colors are associated with which syntax bits... which is exactly what we have in any reasonable editor. So... what's the problem?
you dont need it to be displayed in color to work. you can use other text attributes or tags. the blind programmers prefer black on black color schemes i hear...
I don't consider this a serious objection. One could just as easily argue that symbolic text "keeps out" the blind programmers. The obvious solution is to provide an alternate representation.
Steele is taking a very pragmatic approach: his target audience with Fortress is mainly scientists and people with scientific programming backgrounds, and they would love to have their programs look more like what they write on a blackboard. So Fortress comes along with a fancy Unicode syntax that trivially maps to an ASCII syntax underneath.
"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?"
Because it is simple and everyone can read it. I don't want to see code that is "greek to me."
Cool idea, but the real question is how would you make something like this happen? Someone would need to invent a new programming language with support for all the Unicode characters and syntax coloring mechanisms, along with making a totally innovative IDE for it.
Who's gonna do that? And how is it going to compete against C++, Java, ObjC and the rest out there? When you come up with an idea, that radically changes the programming landscape, you need to have a vector to introduce it to the world.
The only way I can see that happen is, when someone like Apple declares this its new iPhone language, or Microsoft's new .NET language, but yeah .. the odds for that happening.. exactly.
> Why do we still have to name variables OmegaZero when our computers now know how to render 0x03a9+0x2080 properly?
Isn't this obvious? What keyboard has 'Ω' or '₀' easily accessible? I'd be pretty upset refactoring or reusing any code that forced me to copy-pasta or type some crazed key combination just to render a character. It might not look perfect, but the lowest common denominator (ASCII char set) for programming works because every keyboard layout on the planet can enter those characters in (mostly) one keystroke.
I couldn't agree more, and I really don't understand the author's argument. He refers to APL, a language that's legendary for its use of wild symbols, as "write only," but then seems to be complaining that newer languages aren't doing the same thing.
I think Go actually gets this right: its syntax doesn't require any wacky characters, but it allows identifiers to consist of any Unicode characters classified as letters or numbers. The syntax caters to the lowest common denominator, but if I really want to name my variables in Greek, I can.
That's the fundamental question worth repeating three times. Numerous languages support Unicode in the syntax and it doesn't matter because nobody can use them because who wants to use a language where the 'or' operator is a textual copy and paste operation for a new user?
You can incrementally stuff more symbols onto a keyboard but I'd want to see some science that shows that people are able and willing to deal with a keyboard that contains a their local language, a full suite of mathematical symbols including Greek, Hebrew, and the various mangled Latin characters that mathematics uses, plus logic, set notation, plus the useful not-necessarily-mathematical operators that language designers either want or in some cases already use/permit such as arrows, boxes, and all the other things. And we still need our full editor keyboard shortcuts and if you're a power user (and we're talking programmers...) our keyboard shortcuts for the window manager.
So, you want to predicate learning your language on me learning all that? I'm the kind of fruitcake that learned Haskell but I still laugh at the idea of learning something like that. No sale. (And I don't use the Unicode Haskell permits because while I'm actually very comfortable remapping my own keyboard, for instance I actually have interrobang bound to a key because I found myself using it so much, why would I do that to anybody else who ever tries to read or use my code‽)
I did that on a Mac using the option key and a few custom key bindings.
The real question is how do you READ it. The problem is that unless you are very selective about your fonts and which characters you use, it can become impossible to read because many unicode characters are visually indistinguishable.
But can you quickly and easily distinguish between Ͱ and ͱ, or even Ω and Ω? The last two really are different Unicode characters, the first is Greek capital Omega, the second is the Ohm symbol...
That's another very interesting difficulty: the symbol for ohm is supposed to be the Greek capital omega. Resolving such ambiguities (where applicable, of course) would probably add a lot of complicated code, and I'm not 100% sure it's trivial for all similar cases.
Unicode is a superset of numerous other encodings, usually the national standards of the countries whose written languages they want to encode. For example, the sections for the Greek and Cyrillic alphabets have identical layouts to existing Greek-only and Russian-only encodings.
The exceptions to this policy are usually writing systems that didn't have standardized encodings at the time they were incorporated into Unicode. Also, the rather notorious CJK unification project resulted in several new overlapping layouts as Unicode policy changed over time with respect to Chinese characters.
I see why that's a problem for domain names, but not for programming languages. You just define that one character has meaning and all its homoglyphs are syntax errors (even in identifier names).
With all due respect, I fairly clearly indicated that I am aware of such things. I even typed a unicode character that for me is one keystroke: ‽. I've got that mapped to backspace, since I moved that to Caps Lock (and just discarded Caps Lock).
But that's not the actual point. Learning a new language is a challenge. Learning a new language when you haven't already learned 10 is an even bigger challenge. Learning your first language is very difficult, which most of us have probably forgotten. Now, to the list of things you have to learn to do so, we want to add learning several dozen brand new keystrokes that nobody knows offhand? It may not seem like much compared to everything else one has to learn to program, but having to learn a lot of stuff is annoying; having to fight your input devices is like being rendered mute. Try switching your keyboard map for a few days to see how you like it. This is not a level of frustration worth pursuing.
Yeah yeah yeah... every l33t Mac hax0r knows how to use the option key. Great! But guess what? People program on Linux and Windows too, and the fact is that it's a hell of a lot easier to type "fn" than it is to type ∑Ò™£‹˙√«»ç◊... where the hell is the key for lambda?
And that sigma that you led off with is the mathematical summation sigma and not the Greek letter. This gets really really hard cross-platform. (On Windows, your best bet for typing summation sigma requires a registry hack.)
I absolutely agree! There are about 104/5 keys on a keyboard, and the most accessible are within the alphanumeric range, around 48 + the main control keys. This is basically the effective writing area, with a core areas of the baseline and the alphabetic rows. Even the general ASCII characters are hard to fit in that, let alone the unicode palette.
Another reason this makes no sense is, that programming languages are actually little about syntax and much about paradigms (proc, func, oop, etc.) with technical details, like garbage collection and runtime features like interpretation. That's the important part, not the character set.
Yes, I'm one of the geeks that use Dvorak, vim and just got me a mechanical keyboard with tactile feedback. I care a lot about my typing, and I sure as hell don't want to type in unicode.
Really, I actually live in Germany, and have the extra 3 umlauts on my secondary layout, and that's already a royal pain in the ass. I also did some CJK text input (Japanese is a hobby of mine). well, don't get me started.
No, more than the ASCII character set is defiantly the very last thing you might want, eclipsed only by syntax highlighted critical path display. He could at least have taken the time to imagine what the result of that would have been, or make a mockup, then he would not post this crap!
Well yeah, maybe syntax isn't the most important thing, but for the question of which character set is better for syntax, syntax is important. That's like saying that we shouldn't be discussing programming languages at all because preventing nuclear war/ecological catastrophe/whatever is more important. I would also argue that syntax is important for the clarity and usability of those semantic and runtime/performance characteristics (as programming languages may somehow help in alleviating, or exacerbating, those bigger problems ...)
That's actually really nice. There's no reason an editor couldn't just do it behind the scenes, like how Emacs' org-mode handles dates and links in a plain text file.
That's your reply? Your keyboard is too limited? Your made in China, costs about 1/1000th of an annual programmer salary, trivially replacable hunk of plastic KEYBOARD is your rationale for waving goodbye to the potential productivity benefits of new glyphs? Amazing.
Yes, if only developers could devise some way of remapping keyboard keys, affixing new labels or even creating entirely new alternative layouts and devices. But that sort of rocket science is at least, what, three decades out?
Two problems with your post, not counting your tone: Your reading comprehension fails, I already mentioned I know how to remap keys. In fact what happens when you type on my keyboard bears only a passing resemblance to what is on the keycaps.
Second, what "productivity benefits"? Are you such an astonishing programmer than your primary bottleneck is typing your symbols? It's too slow to type -> instead of Alt-Gr->, or whatever? Or maybe the agony of having to read -> instead of →? I find it hard to believe that's much more than a rounding error.
Typing is not such a big issue. I mean, many languages require many more symbols than keys on a keyboard, and are used every day by millions of people who are not programmers and without any particular technical skill (think Japanese and Chinese).
Practically, having to regularly deal with Japanese encoding, a big issue is interoperability. Granted, a lot of issues are caused by not using unicode (unix vs windows encodings which sadly are still pervasive), and those could be mitigated by enforcing unicode.
I am not so much concerned about readability: mathematics go away with tons and tons of symbols, and it is not really ambiguous - certainly less so than most programming language syntaxes I know.
Mathematics, like most languages meant for humans, is ambiguous -- maybe less than most, though. Programming languages are so unambiguous, on the other hand, that not only people but even computers can understand them!
Well, what does a + b means in C++ ? You are playing with the work meaning here. Of course, the syntax of a language is well defined - because it needs to be parsed, hopefully somewhat unambiguously by compiler/interpreter.
But that's not very interesting, because that's not really how we program, at least not anymore: you write something to be read by other people more than something to be understood by computer, and two equivalent programs are often not equivalent at all in readability. So maybe my choice of words was not optimal, and I should have chosen readability instead of ambiguity.
I think the focus on being executable by the computer is the wrong one. That's the trivial part.
I type it with a custom iPad app that acts like a
wireless keyboard (over wi-fi). ASCII is at the top (and of that's all you need, fine); however, if you swipe up, the board scrolls to reveal (and snap to) another full pane of keys. You can have as many boards as you want, all fully configurable (using the "server" app on the computer the keyboard is sending key events to.)
Right now, I'm learning APL using it; it's pretty comfortable for that. An important point, though, is that APL has a finite number of extra keys. Every symbol you insert in a source file is a symbol other developers have to have a way of typing—so, while this system can work for APL or arbitrary-symbol-lang-with-a-keyboard-conf-file-in-the-installer, it won't let you just define whatever symbols you please on a file-by-file basis.[1]
[1] ...for now. I'm thinking about writing an IDE hook that scans your project for symbols your keyboard can't type given your board-set, then dumps them into a temporary "project keyboard palette", that you get to by swiping to the left/right. This would let you go beyond Unicode to use arbitrary pictorial symbols (i.e. SVG images) as characters. If you could drag keys off your palette and onto your personal boards, keyboard symbology would then become a memetic process, spreading from project to project when the symbol is useful to the reader, much like words spread in conversation.
I think the issue here is input methods. Ω isn't so bad (option-z on my Mac) but there's really only a few dozen additional symbols available via such relatively easy shortcuts: mostly accented characters, Greek letters and punctuation. As a Smalltalk hacker I'd like to use ← for assignment, and ↑ for return, but AFAIK the only way to enter them is via the CharacterViewer utility. It might be easier on Windows or Linux, but I doubt it. Alt+8592 or whatever is still going to be too difficult to type frequently.
Mr. Kamp slags syntax designers as putting compatibility with the ASR-33 above expressiveness, but I dont' see a way around it with today's standard hardware.
+1, +1, +1. Mathematica's fabulous in this regard- its InputForm -> FullForm -> StandardForm/OutputForm pipeline is The Right Way to handle this problem, IMHO. You can use its ESC-shorthand-ESC/etc. syntax to enter your code in StandardForm, or you can type it longhand using InputForm- and it all gets represented internally the same way.
It's sort of telling that the manual page has a lengthy explanation about what to do if you can't see the symbol, and a vim macro that you need to install so you can type the symbol. And it's just one symbol saving 2 characters (and no keypresses) :-(
In particular, the case-of-first-character-in-identifier rule breaks foreign character sets, so they have to prefix public members with an X or something.
The rationale to add non-ascii identifiers to Python:
Python code is written by many people in the world who are not familiar with the English language, or even well-acquainted with the Latin writing system. Such developers often desire to define classes and functions with names in their native languages, rather than having to come up with an (often incorrect) English translation of the concept they want to name. By using identifiers in their native language, code clarity and maintainability of the code among speakers of that language improves. </quote> http://www.python.org/dev/peps/pep-3131/
$ python3 -c '水=1; print(水)'
1
But I also don't know anyone who is actually using them.
In this example, i.e. 'print(水)', the Unicode symbol is being used within a syntax designed specifically for an Ascii vocabulary.
If the syntax is changed to allow '打水' instead of 'print(水)', where the language parser knows the single CJK token 打 has a standalone semantic, then needless spaces can be removed.
Right now computer programs written in common languages are internationally readable. It's bad enough having a language barrier in normal human communication. Why do we want to extend the language barrier to code, too? I don't care if it's not English, but there needs to be an internationally-accepted base character set and language for selecting programming language keywords, and that character set needs to be roughly the size of ASCII.
An even more radical argument is that programming languages have to break free from the tyranny of text. That is, they should be represented by a internal structure that can be edited through a variety of representations (graphical or textual). Various visual programming languages take this approach, but most don't scale to large, complex programs. See subtextual.org for some interesting work in this direction (not mine).
I'll have to play the ubiquitous "abstractions leak" card.
Moving to this sort of setup will result in a) conflicting representations, b) significantly slower code, or c) epic frameworks on the order of all-of-CPAN with tens of thousands of things you must know to be even remotely efficient.
Barring a Sufficiently Advanced Compiler, of course, but until one exists (and puts all of us out of a job) optimization is still frequently important.
The pain/payoff slope is very steep once you try to go beyond plain text.
Let's say you want to express hints to the compiler about what paths are common. And you like the idea of expressing that with tinted blocks. Here's what you have to do to make that work:
- rejigger your editor to input and save such tint blocks in the code;
- convince everyone else using your language to use your editor, or make similar modifications to their editor;
- ignore the cases where you don't have a particular editor available, such as SSH'ing into a minimally configured machine;
- exclude color-blind and blind programmers;
- abandon the convenience of being able to view your source code in pagers like less, diff tools, revision control tools, web browsers, IRC, instant messaging, and web services that allow you to paste snippets of code.
Or, you could:
- add a new keyword to your language.
- add a new syntax coloring rule / code folding rule to your editor, and get almost exactly the same effect.
We have a basic information science problem here. Every feature of the programming language is going to have some concrete representation as a stream of bytes anyway. As long as we use multiple tools and environments to manipulate and view that stream of bytes, it makes sense for the representation and the serialization to be identical -- that is: plain text.
However, there's no reason why we can't have the odd unicode character in source code, as long as there were some well-known shortcuts for typing. A lambda symbol would be wonderful for many languages. Similarly, a Chinese programmer ought to be able to define variable names and strings directly in Chinese.
I'm wondering what the author would make of Perl 6, which both embraces Unicode and allows the programmer to create new operators from arbitrary collections of Unicode symbols. It seems like his fondest dream and his worst nightmare at the exact same time -- which makes me think he may be less than perfectly clear on what he wants.
I've never understood the arguments against operator overloading. Yeah, you can create unreadable programs that way. But it's equally easy to create a function named "sort" that erases your hard drive. If you apply the same disciple to naming your operators that you do to naming your functions, it's not hard to understand. And it's a huge boon if you happen to be (for instance) defining a new numeric type.
I once defined a class of 3-D vectors and overloaded operators to them, but I agree with the problem.
The problem is that redefining core symbols creates a larger communication problem than defining new symbols: if I see sort(), then I'll go look up the definition of the function. But if I see (-a + b || c) in some languages, I have to check that you didn't overload - to your sort() function and || to transpose.
Redefining language is one characteristic of cults (http://www.orange-papers.org/orange-cult_a0.html#ca_cult_spe...). I say this not to cast aspersions, just to communicate the damage that can be done when symbols are redefined. Better to invent a new symbol for a new idea.
I don't know what people have against overloading either. Nevertheless, "delimited overloading" is like overloading, but safer, since the overloading is limited to some scope, and readers can easily see where overloading is allowed. In OCaml you can now write something like:
Big_int.( 23 567 mod 45 + "123456789123456789123456789")
where only the operators in the parentheses are overloaded.
I think it's a terrible idea to adopt more arcane glyphs merely to keep code more terse. Just because code is short doesn't mean it's readable. If anything, I think programming languages should use less arcane glyphs. Not to mention it would be annoying and uncomfortable to memorize how to enter those arcane glyphs with our current keyboards.
I also think it's a terrible idea to use color. Not only are a lot of people color blind, but what happens if you need to print your source code on a black and white laser printer? Those are still heavily used.
I don't think the author of the article thought these issues through very carefully.
Most of the comments seem a bit critical. I don't think the author is naively suggesting "this needs to be better@#!!!". Not all ideas have to be practical or even feasible; it's beneficial to at least consider everything. The payoff on a truly new / useful abstraction could be huge. Think of C with / without the preprocessor.
Or take a language like Scala, which I happen to like a lot, but has one hellaciously complex type system: how much would it benefit from an additional syntax abstraction? This question is worth asking!
I like the columns of code idea a lot, and it's something I've thought about for a long time. But my conclusion so far is that this is actually better done with IDE functionality. Just establish a common annotation for metadata which IDEs interpret as a display configuration. Or have the IDE open a .src file and a .doc file in the same directory, displayed side by side. The doc file has the same line count as the .src file, and there are conventions / macros / etc. that make use of the second column, etc. (Of course the .doc could be compressed into some kind of metadata file when stored.)
To bring it back to the topic, aren't we all REALLY interested in something that makes coding... just, better?
Sorry to reply to self, but as many others have pointed out, one may not want to type a large subset of code in unicode, but real example from tcllib aycock parser where this ability is nice is for mathematic symbols:
lset newrhs $position ${sym}\{Ø}
which lets one's code read like the printed algorithms in a book.
1995: More characters were made available on SAIL and later
on the Lisp machines. Alas, the world went back to inferior
character sets again—though not as far back as when this
paper was written in early 1959.
Footnote from John McCarthy's Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I
I find it amusing that the article doesn't contain examples of the unicode characters he mentions. For example, he brings up "Dentistry symbol light down and horizontal with wave" ⏇. I sorely wanted to see this printed next to the description, but it's not. ACM portal limitation?
I didn't see a real argument that this is necessary or would be better. And having non-textual aspects of the code, like the color or a green tint? That would be interesting for some novel programming language but, really, this is why we need to break from of the "tyranny" of ASCII to make everything more complicated?
Based on the title I was expecting him to talk about escaping the tyranny of text but he was very specific about ASCII. I think we can make the learning curve for programming languages much easier to scale with some graphical interfaces. Think command line prompt versus a GUI. Once learned a command line is awesome, but damn is it hard to learn.
I'm surprised nobody so far has mentioned Agda (http://wiki.portal.chalmers.se/agda). Not only does it allow the use of unicode in identifiers, but it uses them extensively throughout its standard library. After using Agda for a while, one quickly realises that most of the issues raised in this thread are rather unimportant. Having extra brackets, more equality symbols and greek letters available really does make code nicer to read when used judiciously.
118 comments
[ 5.1 ms ] story [ 179 ms ] threadThe first program to be converted to UTF was the C Compiler. There are two levels of conversion. On the syntactic level, input to the C compiler is UTF; on the semantic level, the C language needs to define how compiled programs manipulate the UTF set.
http://plan9.bell-labs.com/sys/doc/utf.html
Plan9, what Unix did next.
I used to mock LabView (arguing speed and complexity), but now that I work with a colleague that exclusively uses it--we are a medical research engineering group--I really start to respect its utility.
So the question becomes: Would an opensource cross platform scripting language, modeled after LabView, fit this bill?
However, they tend to fall down for many general programming paradigms. LabView is probably the furthest along that I know of in attacking more general problems, but ultimately they are designed around building a pipeline: datain->do something->data out.
LabView also builds in interesting levels of instrumentation and interactive components that can make it seem more general purpose like.
In that sense, the old UNIX tools (simple, single function tools you can pipe together to create complex systems) are the same thing.
But there are other graphical programming environments that aren't focused around pure dataflow.
http://scratch.mit.edu/
Is actually a very interesting experiment in using graphical components to build up a program. But ultimately it's just a nice wrapper around a regular old programming language, and in playing with it a bit, I found that it was simply faster to just type things in a regular old language.
One of the more interesting things about graphical programming systems, is that you can often coax people into learning to use them who otherwise would have no interest or inclination towards writing code. I think there's probably a huge untapped market for a fully graphical system that can compile and perform like native code...
Isn't that what computing is all about?
1 - Display something (perhaps put some data out) 2 - Receive input 3 - do something (perhaps combine input with data in) 4 - goto 1
This is true of everything from video games to operating systems.
Dataflow models are simply a subset of the models of computation we deal with these days...they are extraordinarily useful models, but still limited in what they do.
So far I've been wondering if a graphical interface a la labview could work if it translated down into say, erlang code. It all depends highly on who the target audience is...a test engineer, or someone wanting an easier way to write scalable distributed applications. If the latter, I'd expect the interface to be a very well thought out interface that lets you effortlessly flow between drilling down into functions and seeing the greater view of all the code in your application.
Chuck Moore, of course, has done this with Colorforth. I read him somewhere saying that by encoding some of the program in color, a visual part of the brain not normally involved in programming was engaged, freeing up other cognitive resources to think about the problem at hand. He didn't put it that dogmatically; it was more of a speculation about he found this use of color so helpful.
Of course, the solution to this would be to instead provide a UI (presumably in your editor) to change which colors are associated with which syntax bits... which is exactly what we have in any reasonable editor. So... what's the problem?
Ω is a valid variable name in C#. (But Ω₀ isn't).
Because it is simple and everyone can read it. I don't want to see code that is "greek to me."
Who's gonna do that? And how is it going to compete against C++, Java, ObjC and the rest out there? When you come up with an idea, that radically changes the programming landscape, you need to have a vector to introduce it to the world.
The only way I can see that happen is, when someone like Apple declares this its new iPhone language, or Microsoft's new .NET language, but yeah .. the odds for that happening.. exactly.
Isn't this obvious? What keyboard has 'Ω' or '₀' easily accessible? I'd be pretty upset refactoring or reusing any code that forced me to copy-pasta or type some crazed key combination just to render a character. It might not look perfect, but the lowest common denominator (ASCII char set) for programming works because every keyboard layout on the planet can enter those characters in (mostly) one keystroke.
Am I missing the joke?
I think Go actually gets this right: its syntax doesn't require any wacky characters, but it allows identifiers to consist of any Unicode characters classified as letters or numbers. The syntax caters to the lowest common denominator, but if I really want to name my variables in Greek, I can.
How do I type it?
How do I type it?
That's the fundamental question worth repeating three times. Numerous languages support Unicode in the syntax and it doesn't matter because nobody can use them because who wants to use a language where the 'or' operator is a textual copy and paste operation for a new user?
You can incrementally stuff more symbols onto a keyboard but I'd want to see some science that shows that people are able and willing to deal with a keyboard that contains a their local language, a full suite of mathematical symbols including Greek, Hebrew, and the various mangled Latin characters that mathematics uses, plus logic, set notation, plus the useful not-necessarily-mathematical operators that language designers either want or in some cases already use/permit such as arrows, boxes, and all the other things. And we still need our full editor keyboard shortcuts and if you're a power user (and we're talking programmers...) our keyboard shortcuts for the window manager.
So, you want to predicate learning your language on me learning all that? I'm the kind of fruitcake that learned Haskell but I still laugh at the idea of learning something like that. No sale. (And I don't use the Unicode Haskell permits because while I'm actually very comfortable remapping my own keyboard, for instance I actually have interrobang bound to a key because I found myself using it so much, why would I do that to anybody else who ever tries to read or use my code‽)
I did that on a Mac using the option key and a few custom key bindings.
The real question is how do you READ it. The problem is that unless you are very selective about your fonts and which characters you use, it can become impossible to read because many unicode characters are visually indistinguishable.
The exceptions to this policy are usually writing systems that didn't have standardized encodings at the time they were incorporated into Unicode. Also, the rather notorious CJK unification project resulted in several new overlapping layouts as Unicode policy changed over time with respect to Chinese characters.
Added - they did; here is an older version (3.0) of the standard online http://www.unicode.org/book/u2.html
But that's not the actual point. Learning a new language is a challenge. Learning a new language when you haven't already learned 10 is an even bigger challenge. Learning your first language is very difficult, which most of us have probably forgotten. Now, to the list of things you have to learn to do so, we want to add learning several dozen brand new keystrokes that nobody knows offhand? It may not seem like much compared to everything else one has to learn to program, but having to learn a lot of stuff is annoying; having to fight your input devices is like being rendered mute. Try switching your keyboard map for a few days to see how you like it. This is not a level of frustration worth pursuing.
http://pqrs.org/macosx/keyremap4macbook/extra.html
I'm prepared to be corrected but ..
Greek capital sigma is the mathematical "sum" symbol just as capital pi is the product symbol.
Another reason this makes no sense is, that programming languages are actually little about syntax and much about paradigms (proc, func, oop, etc.) with technical details, like garbage collection and runtime features like interpretation. That's the important part, not the character set.
Yes, I'm one of the geeks that use Dvorak, vim and just got me a mechanical keyboard with tactile feedback. I care a lot about my typing, and I sure as hell don't want to type in unicode.
Really, I actually live in Germany, and have the extra 3 umlauts on my secondary layout, and that's already a royal pain in the ass. I also did some CJK text input (Japanese is a hobby of mine). well, don't get me started.
No, more than the ASCII character set is defiantly the very last thing you might want, eclipsed only by syntax highlighted critical path display. He could at least have taken the time to imagine what the result of that would have been, or make a mockup, then he would not post this crap!
http://projectfortress.sun.com/Projects/Community/wiki/MathS... http://projectfortress.sun.com/Projects/Community/wiki/Fortr...
Yes, if only developers could devise some way of remapping keyboard keys, affixing new labels or even creating entirely new alternative layouts and devices. But that sort of rocket science is at least, what, three decades out?
Second, what "productivity benefits"? Are you such an astonishing programmer than your primary bottleneck is typing your symbols? It's too slow to type -> instead of Alt-Gr->, or whatever? Or maybe the agony of having to read -> instead of →? I find it hard to believe that's much more than a rounding error.
I guess that mathematical notation is often easier to read and comprehend. I'd rather see something like this http://upload.wikimedia.org/math/9/6/9/9695855b7c5869aad99fa... than something like
on the other hand, without an IDE that's capable of translating between both notations, editing would be rather painfulPractically, having to regularly deal with Japanese encoding, a big issue is interoperability. Granted, a lot of issues are caused by not using unicode (unix vs windows encodings which sadly are still pervasive), and those could be mitigated by enforcing unicode.
I am not so much concerned about readability: mathematics go away with tons and tons of symbols, and it is not really ambiguous - certainly less so than most programming language syntaxes I know.
Meaning?
But that's not very interesting, because that's not really how we program, at least not anymore: you write something to be read by other people more than something to be understood by computer, and two equivalent programs are often not equivalent at all in readability. So maybe my choice of words was not optimal, and I should have chosen readability instead of ambiguity.
I think the focus on being executable by the computer is the wrong one. That's the trivial part.
Soft keyboards and composing-entry are the future.
Right now, I'm learning APL using it; it's pretty comfortable for that. An important point, though, is that APL has a finite number of extra keys. Every symbol you insert in a source file is a symbol other developers have to have a way of typing—so, while this system can work for APL or arbitrary-symbol-lang-with-a-keyboard-conf-file-in-the-installer, it won't let you just define whatever symbols you please on a file-by-file basis.[1]
[1] ...for now. I'm thinking about writing an IDE hook that scans your project for symbols your keyboard can't type given your board-set, then dumps them into a temporary "project keyboard palette", that you get to by swiping to the left/right. This would let you go beyond Unicode to use arbitrary pictorial symbols (i.e. SVG images) as characters. If you could drag keys off your palette and onto your personal boards, keyboard symbology would then become a memetic process, spreading from project to project when the symbol is useful to the reader, much like words spread in conversation.
Mr. Kamp slags syntax designers as putting compatibility with the ASR-33 above expressiveness, but I dont' see a way around it with today's standard hardware.
http://search.cpan.org/~ewilhelm/lambda-v0.0.1/lib/lambda.pm
It's sort of telling that the manual page has a lengthy explanation about what to do if you can't see the symbol, and a vim macro that you need to install so you can type the symbol. And it's just one symbol saving 2 characters (and no keypresses) :-(
Just as you mentioned of perl, very few people use it.
Python code is written by many people in the world who are not familiar with the English language, or even well-acquainted with the Latin writing system. Such developers often desire to define classes and functions with names in their native languages, rather than having to come up with an (often incorrect) English translation of the concept they want to name. By using identifiers in their native language, code clarity and maintainability of the code among speakers of that language improves. </quote> http://www.python.org/dev/peps/pep-3131/
But I also don't know anyone who is actually using them.If the syntax is changed to allow '打水' instead of 'print(水)', where the language parser knows the single CJK token 打 has a standalone semantic, then needless spaces can be removed.
Moving to this sort of setup will result in a) conflicting representations, b) significantly slower code, or c) epic frameworks on the order of all-of-CPAN with tens of thousands of things you must know to be even remotely efficient.
Barring a Sufficiently Advanced Compiler, of course, but until one exists (and puts all of us out of a job) optimization is still frequently important.
The main hurdle is actually a UI problem: How do you make a structure editor with the ease of use of a text editor?
Let's say you want to express hints to the compiler about what paths are common. And you like the idea of expressing that with tinted blocks. Here's what you have to do to make that work:
- rejigger your editor to input and save such tint blocks in the code;
- convince everyone else using your language to use your editor, or make similar modifications to their editor;
- ignore the cases where you don't have a particular editor available, such as SSH'ing into a minimally configured machine;
- exclude color-blind and blind programmers;
- abandon the convenience of being able to view your source code in pagers like less, diff tools, revision control tools, web browsers, IRC, instant messaging, and web services that allow you to paste snippets of code.
Or, you could:
- add a new keyword to your language.
- add a new syntax coloring rule / code folding rule to your editor, and get almost exactly the same effect.
We have a basic information science problem here. Every feature of the programming language is going to have some concrete representation as a stream of bytes anyway. As long as we use multiple tools and environments to manipulate and view that stream of bytes, it makes sense for the representation and the serialization to be identical -- that is: plain text.
However, there's no reason why we can't have the odd unicode character in source code, as long as there were some well-known shortcuts for typing. A lambda symbol would be wonderful for many languages. Similarly, a Chinese programmer ought to be able to define variable names and strings directly in Chinese.
I've never understood the arguments against operator overloading. Yeah, you can create unreadable programs that way. But it's equally easy to create a function named "sort" that erases your hard drive. If you apply the same disciple to naming your operators that you do to naming your functions, it's not hard to understand. And it's a huge boon if you happen to be (for instance) defining a new numeric type.
The problem is that redefining core symbols creates a larger communication problem than defining new symbols: if I see sort(), then I'll go look up the definition of the function. But if I see (-a + b || c) in some languages, I have to check that you didn't overload - to your sort() function and || to transpose.
Redefining language is one characteristic of cults (http://www.orange-papers.org/orange-cult_a0.html#ca_cult_spe...). I say this not to cast aspersions, just to communicate the damage that can be done when symbols are redefined. Better to invent a new symbol for a new idea.
(for a non-programming example of redefining
Big_int.( 23 567 mod 45 + "123456789123456789123456789")
where only the operators in the parentheses are overloaded.
http://pa-do.forge.ocamlcore.org/
I also think it's a terrible idea to use color. Not only are a lot of people color blind, but what happens if you need to print your source code on a black and white laser printer? Those are still heavily used.
I don't think the author of the article thought these issues through very carefully.
Or take a language like Scala, which I happen to like a lot, but has one hellaciously complex type system: how much would it benefit from an additional syntax abstraction? This question is worth asking!
I like the columns of code idea a lot, and it's something I've thought about for a long time. But my conclusion so far is that this is actually better done with IDE functionality. Just establish a common annotation for metadata which IDEs interpret as a display configuration. Or have the IDE open a .src file and a .doc file in the same directory, displayed side by side. The doc file has the same line count as the .src file, and there are conventions / macros / etc. that make use of the second column, etc. (Of course the .doc could be compressed into some kind of metadata file when stored.)
To bring it back to the topic, aren't we all REALLY interested in something that makes coding... just, better?
#!/usr/pkg/bin/tclsh8.6
proc გამარჯობა {} {
};# call above proc
გამარჯობა
;# I can eat glass, Georgian, via http://www.columbia.edu/kermit/utf8.html
set მ "მინას ვჭამ და არა მტკივა."
puts ${მ}
lset newrhs $position ${sym}\{Ø}
which lets one's code read like the printed algorithms in a book.
Footnote from John McCarthy's Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I
http://www-formal.stanford.edu/jmc/recursive.pdf