Comments

(newest first)

  • John Mark Isaac Madison | Mon, 04 Sep 2017 05:16:52 UTC 

    Can you guess what a:
HeatTreatedMilledOatsWaterAndSweetCrystalineSubstanceMixture is?

It's a revolutionary program that made "cake" before people knew
what cake, ovens, flour, and sugar were.

Or, you could just call that variable a ß.
ß == "Meal" in Japanese. You can then document in the class what ß is composed of.

People might say this "isn't clean code".
I disagree. It's very concise and what it is can be described in the
class file comments.

The only thing naming it: HeatTreatedMilledOatsWaterAndSweetCrystalineSubstanceMixture 
will do for you is:
1. Take up too much column space.
2. Allow people to make mis-guided assumptions as to what the class is.
Which could lead to coding without reading the source.

  • Zorba | Mon, 23 Jan 2012 23:27:34 UTC 

    Nuts. I'd be happy if we could get rid of ALGOL's stupid syntax altogether with its trailing semi-colons and (often) case sensitivity. Of all the languages that had to spawn the modern crop, why did it have to be ALGOL? While you're at it; it should be a law that zeros are slashed in all character sets, under_scores are outlawed, and keyboards have the control key next to the 'A' key where it belongs!

As for ASCII, why not code in Baudot?

  • clive | Sat, 19 Feb 2011 17:54:15 UTC 

    Poul-Henning - very compelling article.  And very amusing in parts, especially the bit about "the world's second write-only programming language, after APL".  It would be great to use all the variety of expression allowed with unicode, but what you're forgetting is the keyboard.  Until we speak into our computers to program them - keyboard is king.  And on a keyboard with typically 102 keys it's not possible to do much beyond ASCII.  (At least I don't want to be holding down 4 keys at once!!)

  • Mikel | Sat, 06 Nov 2010 05:10:50 UTC 

    Turns out Dragon NaturallySpeaking doesn't support Unicode, so voice recognition is no solution to OmegaZero yet either.

  • Christophe de Dinechin | Fri, 05 Nov 2010 08:25:22 UTC 

    I've looked up this entire page, and the word "semantics" is not written once. I've stopped counting "syntax". But the problem is not the syntax, it's the semantics that makes a language more or less expressive.

The steps forward in programming happened when functions, or objects, or distributed programming, or operator overloading, or exceptions, or concurrency became usable by programmers. It doesn't really change much if you describe "task" with a chinese glyph or the four ASCII characters t-a-s-k, what matters is what it means, not how it looks.

In my own programming language, XL, the syntax is all ASCII, because there's a single "built-in" operator, ->. But you can use it to invent your own notation, as in:

    if true then X:code else Y:code  -> X
    if false then X:code else Y:code -> Y

See http://xlr.sourceforge.net/Concept%20Programming%20Presentation.pdf for a more in-depth discussion of this "concepts come first" approach, which I called, obviously enough, "concept programming".

  • KB | Tue, 02 Nov 2010 19:59:23 UTC 

    "It could have used just or and bitor, but | and || saved one and three characters, which on an ASR-33 teletype amounts to 1/10 and 3/10 second, respectively."
You reversed the tokens for or and bitor voiding much of your "speed" argument -- you do not gain anything by using "||" over "or".

  • fotis | Tue, 02 Nov 2010 19:26:16 UTC 

    Here was some good punching on "modern" computer languages deficiencies. After having used nearly any form of programming environment (imperative, OO, functional, "logical", RPN breeds included) the one thing that strikes me is how much inclined I still am on using humble shell scripting to prototype the first ideas, mostly due to the freely available pipelining mechanism, which has certain performance advantages, despite the difficulty in maintaining shell code. Computer languages as we know them need major overhauls both on the front-ends and also on the back-ends. IMHO, GO is not too bad in its front-end aspects, though I would have liked it as a developer to be able to trade the brackets vs indentation business (less LOC => faster r/w)

  • Hans | Tue, 02 Nov 2010 15:26:30 UTC 

    Why mix together the use of characters in a programming language with pure editor features like coloring certain regions of code or floating other regions above/beside the next?

How exactly would unicode characters improve a language syntax? We have the () <> [] {} already right? How many more open/close characters can we actually introduce before they start being too similar and give raise to bugs like the ones related to || that you dscribe in the article? And what would be the gain? We might "free up" {} or whatever for use in some other part of the language. But um lets see you seem to be the only one who thinks that we are running out of characters and that it might be a problem. You argue for using "bitor" over || and at the same time you claim that more characters would improve anything. Its quite rediculous.

But please if you would like to submit patches for eclipse, netbeans or qt creator that colors private variables BE MY GUEST. It probably takes as much time as writing this whole pointless article seing as how the syntax coloring infrastructure is already in there.

  • KPG | Tue, 02 Nov 2010 01:45:56 UTC 

    Amusement.  The system gonked my previous post.  Both line breaks AND the serveral Unicode 'A'-like symbols got mangled.

  • KPG | Tue, 02 Nov 2010 01:42:34 UTC 

    I spent years dealing with EBCDIC and mapping ASCII to/from EBCDIC.  Anyone reading this who experienced Waterloo C tri-glyphs or had to output ASCII via an IBM 1403 print chain knows.

I like ASCII.  Like EBCDIC, it's compact (< 1 byte) and small enough to memorize.  But better, it's contiguous.

ASCII shines brightest in its ordinal arrangement. The simple rules '0' < '9', 'A' < 'Z', and 'a' < 'z' make describing and implementing collations trivial.  Implementing a comparison is far more straightforward with while (*string1++ == *string2++);

Adding more symbols makes a mess.  In what order shall we put 'A', '', '', 'Ä', 'Â', 'À', 'Â', 'Å', '&', ':', '†', '‘', and 'Â'?  Is it language dependent?  In which countries?  In what dialects?

Once, pre-Unicode days, I had to manage CJK card catalog entries in an ASCII-only text engine.  The solution mapped CJK glyphs onto four-character strings during input/output.  Using 0-9 and A-Z, the code space was 1.6MM, large enough.  It worked.  Perhaps P-H K prefer this more general solution?

  • Hans Kruse | Tue, 02 Nov 2010 00:17:45 UTC 

    Please let us break the terror of the typewriter. In daily life we use symbols in many places because plain text does not work. 

Symbols are a more succinct(less verbose) in expressing, Numbers(0,1,2..9), Math, Music, Chemistry, Religion, army ranks, marketing, smilies, and many other uses. It allow you to see the forest for the trees and not cluttering your  work with common knowledge that can be easily expressed using a symbol, E.g. using ForEach or Sigma symbol instead of using ForEach and Sigma in text over and over again in a formula.  
 
Road signs exist for a reason. In traffic you need to evaluate them in a short amount of time. Road signs mainly express a message using  shape, size, colour orientation and location. 

Imagine the overnight change of all road signs with plain square white signs with black four word texts. People are no longer able to instantly see the more important signs. As a side effect the economy would grind down to a halt  because people are driving slower due to all the sign reading...  What If I change the road sign texts from English to Chinese.
  
In Software Engineering the use of Design Pattern is (getting) common knowledge. Patterns such as Iterator do not need to be explained/defined over and over again because software engineers were trained in using them.

Using ASCII to express symbols is often very inefficient, e.g.: ManagerSatisfactionBonusRateFactorReasonerEnum. When literally translated to Chinese using a translation service this gets reduced to fifteen(15) characters.  A lot of people in the world speak Chinese. Maybe for programming in general it may be useful to learn Chinese because it is more expressive characterwise. 

Once taught the symbols of the examples mentioned above allow for a more efficient expression in the domain these symbols are meant for. The question should be what can be gained in expressiveness using symbols versus the effort to teach people/adapt tools to deal with (unicode) symbols? 

Choosing identifier names wisely regarding common practice and the problem domain comes first. Using unicode may be a useful tool in reducing the clutter when education and tooling is taken care of.

  • Peter Wone | Tue, 02 Nov 2010 00:05:13 UTC 

    Alphabetisation was the single most important advance in the history of writing. Without the reduced character set made possible by this nested-combination approach to writing, moveable type would not have been economic and the world-changing boom in the availability of books would not have happened. Keyboards are the most effective input device as a direct result of alphabetisation. A regression to ideogrammatic writing does not represent an improvement -- ever seen a Chinese keyboard? As for colour, so many people have colour-defective vision that this suggestion can only be regarded as fatuous.

  • Wayne Christopher | Mon, 01 Nov 2010 20:47:05 UTC 

    I agree with you - Unicode should not have different characters that look the same and this is a problem for multiple disciplines.  This is a significant flaw in its design (and maybe unfixable, given that characters may look the same in some fonts and different in others).  Isn't this an argument to not use it for both programming languages *and* legal documents?  You can't argue that "it sucks for everybody so we can't complain"...

  • Poul-Henning Kamp | Mon, 01 Nov 2010 20:36:44 UTC 

    Legal texts, contracts, law texts also have maintenance issues.  Lawmakers and their spindoctors have already started to frustrate searches by playing unicode games.

If you tell me it was a mistake to include identical looking glyphs in Unicode, I am very inclined to agree with you.  But we cannot credibly claim that this is perfectly OK for the rest of the world, but totally unacceptable for computer people, that would be very high grade hypocracy.

Poul-Henning

  • Wayne Christopher | Mon, 01 Nov 2010 20:26:47 UTC 

    In natural language text, if I see an A, I don't care if it's the Greek or Roman version.  I just can't think of an example where it would cause actual ambiguity in my understanding of the document.  However, I can very easily think of a case where one programmer is entering some formulas and uses a Greek A (maybe there are lower-case Greek alphas elsewhere in the formula and he thinks "capital alpha") and some other programmer reads it as a Roman A.  This would be a huge pain to debug.  I would never use a language that allowed this, or at least never trust another programmer's code in this language, and I think most real-world programmers will agree.

  • samwyse | Mon, 01 Nov 2010 20:19:10 UTC 

    Hmmm, the comment system dropped the Unicode characters from my last comment.  Bah!  As for those who think that allowing multiple versions of "A" would allow various hard-to-find bugs, you obviously never had to debug anything that used "O" and "l" as variable names.

  • samwyse | Mon, 01 Nov 2010 20:16:07 UTC 

    I'm old enough to have had APL "inflicted" on me as a student, and I've missed its economy of expression ever since.  I would go so far as to advocate the adoption of a keyword-free language that allows the full use of Unicde "Letters" and "Marks" for variable names and Unicode Symbols and Puncuation for functions, operators and flow control.

IIRC, Snobol was developed on IBM hardware, meaning it had the full EBCDIC character set available to it.  The designers took advantage of this by allowing box-drawing characters (such as, and ) as comment delimiters.

Finally, look at this:  http://snook.ca/archives/html_and_css/unicode_for_css_class_names

  • Poul-Henning Kamp | Mon, 01 Nov 2010 20:14:20 UTC 

    I have a hard time seeing how this could be a bigger problem in source code than in say, legal documents or even law texts ?  Poul-Henning

  • Wayne Christoher | Mon, 01 Nov 2010 20:11:55 UTC 

    I think a lot of the objections could be summarized as follows: for a programming language, it's a very bad idea to have characters that look the same but mean different things.  Two identifiers that look like A but are different make a program unmaintainable.  Thus, if you allow unicode characters in the syntax definition (except maybe for quoted strings) you MUST prevent this from happening.

That suggests a language would have to pick a handful of non-ASCII characters, like arrows, that (1) enhance the readability of the syntax in some way, and (2) cannot be mistaken for other characters.  If you added, say, a single-character -> to C++, I bet there would be a lot fewer objections than if you allowed A (greek) to be a different variable from A (roman).

  • Poul-Henning Kamp | Mon, 01 Nov 2010 20:08:47 UTC 

    So the computer people who came up with Unicode think it is too hard to enter into a computer, so they don't use it, but to the rest of the world they say "Live with it!" ?   Maybe computer people should eat more of their own dogfood and come up with a sensible input method for unicode ? Poul-Henning

  • hauptmech | Mon, 01 Nov 2010 19:01:39 UTC 

    Lack of easy entry of unicode characters is a good argument against using them in a programming language. However I definately agree with using unicode in programming languages. 'pure' is a langage that uses this. 

vi does unicode just fine...

http://en.wikipedia.org/wiki/Unicode_input
http://eyegene.ophthy.med.umich.edu/unicode/#vim

  • Don Viszneki | Mon, 01 Nov 2010 17:43:23 UTC 

    The argument is weak because a thin layer between the programmer and the toolchain would in most cases work to give you the full unicode gamut, just how my C++ compiler mangles my C++ function prototypes into a string of non-whitespace characters.

  • Fred in IT | Mon, 01 Nov 2010 16:56:13 UTC 

    One last thought...

At the end of the day, when everyone is tired and has to go home, someone needs to maintain the system.  If you can find a way to do what you are proposing that still allows another developer to follow and fix after being woken up at 2:00am local time the world will beat a path to your door.

Where the rubber meets the road is not with what new whizzbang language, theory, or method you come up with.  We need those to find out what doesn't work.  The rubber meets the road at 2:00am when the server is down due to a bug in the code.  Your code, my code, doesn't matter.  Someone needs to read that code, trace that bug and implement a fix.  And if the fix is to replace an 'A' (0x0041, Latin A) with an 'A' (0x0391 (Greek Alpha) , or 0x0410, Cyrillic A)) the path that will be beaten to your door will be with pitchforks and torches.  Hurm, why is the compiler giving me an undefined variable error on A=A+1 (bang head), because it's actually 0x0041 = 0x0391 + 0x0031 Duh!  That was so obvious!

I'm sorry, I want less obfuscation and complexity.  Not more.  I do want full UNICODE capability in string handling and the data that can reside in my structures.  With easy ways to check that the symbol at double-byte position 1242 is 0x0391.  I do want to intermix Greek, Thai, Traditional Chinese, Russian, Hebrew and Arabic in my data.  But I sure as heck don't need it in my code.

Yes, the same Fred in IT in prev. post.

  • Blub | Mon, 01 Nov 2010 16:19:02 UTC 

    "Why not make color part of the syntax?"

So many reasons, where to start?

-Because I want to choose what color I see the code in, white on a black screen, black on a white screen, whatever I want
-Because I want to configure the syntax coloring myself
-Because syntax coloring cannot work anymore if the color has meaning to the programming language; the editor can't display syntax coloring anymore because it has to use colors of the language already
-Because adding color to the text requires more advanced editors. This increases the requirement for proprietary editors
-Because giving colors to the font while coding would be annoying
-Because you can't use a regular plain text file format to store the code anymore, it requires color in the format, requiring proprietary formats (please don't tell me you'd find the MS Word .doc format a good idea for storing source code)
-Because color information gets lost as soon as you copypaste the code somewhere, say, in this text box right here for example
-Because code is a language. The English language also doesn't enforce colors on its syntax.

  • rdm | Mon, 01 Nov 2010 15:14:09 UTC 

    I have to wonder, why is an article criticizing people that use ascii written entirely in ascii characters?  Why not show us how we should be doing it better?

  • Robin | Mon, 01 Nov 2010 15:12:49 UTC 

    Huh? Pike's Go language *DOES* have Unicode support for identifiers and literals.

You are barking up the wrong language :-)

  • Ethan | Mon, 01 Nov 2010 15:02:33 UTC 

    Hear hear, I also wonder why our editors are so primitive that we as an industry still waste time arguing over practices like space vs. tab indentation (tab FTW) or 80 column limits (wtf).  It would be nice to have proper arrows (’) instead of ASCII art (->), as well as innovations like intelligent wrapping and indentation at your preferred width, tabbed alignment that doesn't require fixed-width fonts and fragile spaces... I want http://nickgravgaard.com/elastictabstops/

  • foljs | Mon, 01 Nov 2010 14:49:09 UTC 

    @@@ Expressiveness is a matter of constructs and flexibility of the language, not of available symbols. English has 24 letters and a few punctuation symbols and we have expressed anything from Shakespeare to Justin Bieber lyrics. 

@@@ We could possibly use a few more symbols, but in order to do even that (not the magical total unicode land you propose) you have to think and alter the whole ecosystem, from the new language, to editors, keyboards and such. Thats why when you get on the defensive in the comments here, you mention magical new keyboards that we will "improve them to our purposes" etc. Should we expect them with our flying cars and server robots?

@@@ What about hard proof? Since you are asking for a massive, costly and unfamiliar change, the burben of proof is on you. Have you implemented any such language? Have you shown in AB tests that it is more productive that existing ones instead of more confused? I didn't think so. 

@@@ You also talk a lot about "syntax", but you only give examples of lexical changes, not syntactic. Haven't thought this through, eh?

@@@ Please, stop defending your idea with even more moronic replies to comments here as if it was defense-worthy. Let this post die in the silence and shame it deserves.

@@@ """we still find it more uncompromisingly important for our source code to be compatible with a Teletype ASR-33 terminal and its 1963-vintage ASCII table than it is for us to be able to express our intentions clearly""" --- Sure, adding a whole bunch of symbols will make our intentions CLEARER, not more obscure and opaque.

  • Robert Woodhead | Mon, 01 Nov 2010 13:49:59 UTC 

    PLATO had a non-standard keyboard (great keys like NEXT, BACK, HELP) and a non-standard character set (6-bit characters with several shift-codes). IIRC (>30 years since I wrote any TUTOR code), only a few of the special characters (those without ASCII equivalents) were actually used in TUTOR code, the most notable being the assignment operator, which looked like an arrow, conditionals, and the SUPer and SUBscript shifts, which made the exponentiation operation very visual. Also, backspace and delete had different meanings.

Amusingly, the lineprinters used to get printouts did not have the special characters on the chains, so most of them were created by overprinting characters.

As for the OP, anyone who has had APL inflicted upon him (as I did, in my youth; I still have the scars) will beg to differ with his conclusions.

  • Alec Cawley | Mon, 01 Nov 2010 12:48:00 UTC 

    Desperately unambitious. You should be editing the parse tree directly, then leaving it to the editing system to paint it on the screen in a style of your own choosing (syntax colouring to the power N). No more arguments about separators vs terminators, bracket types, indentation etc: choose your own representation. Different representations for the same object in different languages. Instant, totally safe, variable name refactoring. An end to the tyranny of English-based keywords. Use colour to your taste, while not imposing burdens on the colour-blind. Ready for new concepts such as 3D or tactile. Display call parameters in the order that makes sense in your language. Allow right-to-left languages (or any other orientation including bostrodephonic, spiral or even helical if they make sense).

  • Tim | Mon, 01 Nov 2010 11:45:04 UTC 

    Poul-Henning Kamp quipped :
"You are clearly not european. If you were, you would know what a pain in the ass it already is to get the usual [{|\}] characters by some contorted CTRL-ALT-STICK-SHIFT sequence on non-US keyboards."

I am European, and use a european layout QWERTY keyboard, and have no problem entering the characters - all without any enter/meta/alt/control/shift weirdness. Three of the key strokes are directly made by my little finger and the others with the same fingers but with a shift added. Not so onerous really, is it ?

I can only guess that this comment, along with parts of the articles, were either deliberate trolling or just very poorly thought out. I would kindly suggest that gross exaggeration to the point of utter nonsense does your argument little good. T

  • Required Name | Mon, 01 Nov 2010 10:59:03 UTC 

    Colour has been in use for a while. "colorForth".

  • Required Name | Mon, 01 Nov 2010 10:57:15 UTC 

    Yes, sounds like a wonderful idea. Replace the tyranny of ASCII with the freedom to obfuscate in APL. Let's explode our parsers to handle the full wonder of UNICODE. Maybe they'll gain sentience as a free boon, out of sheer necessity. With clinical insanity as the cherry on top. Let's empower every programmer to write completely incomprehensibly to everyone else *with justification*. Let's call the result "Babylon".

Foot in mouth much, PHK?

  • Bernhard Stadler | Mon, 01 Nov 2010 10:53:16 UTC 

    Color is actually being researched as a part of syntax.
The CIDE research project http://wwwiti.cs.uni-magdeburg.de/iti_db/forschung/cide/ (A research paper: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.143.2730 ) uses it for Software Product Lines in order to denote which elements of the source code belong to which feature.
That is similar to C preprocessor #ifdefs, but doesn't clutter the program code that badly.

  • Luuk | Mon, 01 Nov 2010 10:38:00 UTC 

    Check out the front page of golang.org for what the Hello world _really_ looks like.

Go has unicode string literals and identifiers from the ground up.

To call out Go as an example of ascii tyranny seems... not entirely appropriate.

  • PierreG | Mon, 01 Nov 2010 09:11:04 UTC 

    Injecting unecessary complexity in the CORE of a programming language is a HUGE mistake. Leave unicode to libraries. Don't slow-down the World with BLOAT: http://gwan.ch/ is 5 MILLION TIMES faster than IIS 7.0 + C# for a reason...

  • Thom | Mon, 01 Nov 2010 08:57:40 UTC 

    Actually, using the full Unicode codeset in source code is such a bad idea it prompted Stroustrup to write up a proposal for C++. Of course, it was an Aprils 1 joke.

Show-stoppers:

1. Nobody would adopt it because it would mean "everyone" (at least a critical mass) got the proper input devices at the same time. Also, keyboards already have enough keys, and I'm sick of Alt+Ctrl+Shift combos to pull out symbols.

2. Unicode is visually ambiguous, as others have pointed out. There's a number of renderings of "a"-ish meaning completely different things. And then all the symbols. When you read a piece of code others have written, what the heck will a given symbol actually mean? It's like operator overloading, just 10 times worse.

3. People love their editor, and a bunch of them are obviously not Unicode ready and never will be.

Sorry, mate. You're on the wrong, uhm, codepage.

  • Charley Carroll | Mon, 01 Nov 2010 08:55:18 UTC 

    I fail to understand why so many are attacking Mr. Kamp for his ideas.  Name calling and downright rudeness is not a civil way to disagree.  Those types of comments come across as nothing more as narrow-mindedness and and very trollish.  There's no call for it.
Ideas are ideas.  Does Mr. Kamp's ideas have some merit?  Abosolutely.  Is there room for improvement of or disagreement with the idea?  Sure.  
But, attacking Mr. Kamp personally or using abusive language is not the way to disagree.
It is true that vast majority of keyboards used by ENGLISH speaking countries do not provide an easy way to use unicode.  Keyboards used in other countries, especially countries which are not strictly latin-based differ quite a bit from english-only countries.  Therefore, thinking in broader terms that one's own language, it stands to reason that greater effort needs to be made to include support for other languages and not just latin-based only languages.
Is it likely to happen?  Probably not.  If only for the simple fact that ASCII is extremely ingrained into the current computer culture.  Does that mean that there shouldn't be any attempt to expand or change? NO!
Any suggestion to do so shouldn't be trampled upon and ridiculed simply because it doesn't fit into any one person's current belief system.  As the article suggests, Mr. Kamp does have plenty of programming experience.  Therefore, his ideas should not be dismissed as purely academic, as some have suggested.  Many years of pratical experience does lend some credence to his ideas.  Using unicode was not his only idea, for those of you who failed to read the entire article without immediately jumping to conclusions and becoming extremely irate.
Using and IDE with color based syntax was another.  A very interesting idea, if I do say so myelf.  IDE's already do color coding for different syntax and is very useful, especially when trying to match up leading and closing quotes, parenthasees, braces, and brackets.
I still find it amusing that one of the reoccuring arguments against using unicode is they keyboards.  Sounds more like someone whining about possible having to learn something new.  Besides, many programmers/gamers have specialized keyboards already.  End users wouldn't need to change their keyboard, just the programmers.  There's nothing with someone in the programming profession having a specialized tool for their trade.
Now, before anyone goes all trollish on me for my comments, I just want to say that I'm not necessarily in favor of using unicode symbols for a programming language.  After all, most everyone has already grown accustomed to the tools they currently use and changing means a learning curve would be involved.
Even with that i mind, I still fail to understand the furor over one article suggesting change.  Maybe that's what everyone is really upset over - change.  In any case, I dare anyone to post an article suggesting some sort of change in the programming world and then accept any and all criticisms that come your way just because you dared suggest something different.

  • Alex | Mon, 01 Nov 2010 08:37:43 UTC 

    Excellent post. When you've spent any time working with tools like Maple, you dread the moment you have to go back to the primitive world of "real" programming languages.

ASCII terminals are dead and buried and they're not coming back.

Get with the program already!

  • Poul-Henning Kamp | Mon, 01 Nov 2010 08:37:13 UTC 

    I find a number of the arguments made her and elsewhere rather confusing.  For instance:  "We cannot use unicode and graphical methods, because we cannot perform proper change control" (paraphrased).  If that is really true, wasn't it hypocritical of us to gladly push those features on the rest of society, if we knew, does that not make us responsible for at least one blown up space-shuttle ?  Second, a whole lot of people seem to mistake their tools for their methodology.   Just because your keyboard looks a particular way today, isn't the same as it couldn't be improved, and just because your editor does not grok unicode, is not the same as it couldn't learn to, or you could change to better editor.  Again: they hypocrisy is repugnant:  People who regularly expound that everybody in the world should change from Word to OpenOffice, insist that they have a God Given Right to use an editor from 1973 and that the world better bend over backwards to let them.  Third, and worst: Given the constant stream of bugfixes that pour out of our discipline, how can anybody with a straight face claim that we do not need to look at how programming can be improved ?  Poul-Henning

  • Eric Hawthorne | Mon, 01 Nov 2010 08:12:11 UTC 

    I disagree. 
Good programming is about the management (via judicious bottlenecking) of complexity, and often, in a formal language for programming, less is more. More uniform is better. Unnecessary, gratuitous variation is dangerous. 

Yes, we're definitely at the stage that string literals should allow (probably require) unicode, and it is no doubt true that program source code should be required to be encoded in UTF-8 (again, to reduce gratuitous difference), but the formal language constructs should continue to use a small alphabet. Programs have to be read exactly, by people, and there is
no good reason to introduce more room for error.

Great art is most often made in a highly constrained medium. 
And unnecessary choice and loose, ambiguous expression are evil, in the land of
programs, which are essentially logic and math.

  • Adam Jorgensen | Mon, 01 Nov 2010 05:30:39 UTC 

    Interesting idea and point that you're making with two sides to the coin:

On one side, Unicode support in languages is a must at the data-handling level and ultimately I don't see any reason why it shouldn't be allowed as part of the coding process either. If we're going unicode then we might as follow it to the logical conclusion. If I get code from someone that uses all kinds of weird non-Latin characters then it's the job my text-editor/ide to help me out in dealing with said characters.

One the other hand, being able to use a zillion extra symbols does not mean that one should use a zillion extra symbols. Less is more in my opinion and I don't see much need to go cluttering up language cores with lots of extra symbols for no reason other than that one can. 
Now sure, if you're programming common lisp with unicode support at the language level it would be nice to be able define macros with pretty much any symbol but on the other hand you really don't want your codes to end up looking like abbreviated MUMPS code because that is just a rotten thing to work with.

Ultimately, flexibility and simplicity should win out with the option of expansiveness being kept but never discarded.

  • MikeFM | Mon, 01 Nov 2010 05:19:38 UTC 

    Partly in response to growing arthritis, I've gone towards programming in only alphanumeric by making my own languages that can be written with just those 36 characters, excepting when writing strings that include other characters, as it allows me to use a very minimal keyboard without hunting for characters or complex keystrokes.

  • Steve Wolfson | Mon, 01 Nov 2010 05:07:16 UTC 

    Actually the University of Iliinois PLATO (educational learning system) had glyph based characters (PLATO used 512x512 bit mapped graphics and touch screens in the 70's) the course development system was called TUTOR.  But Plato did require a custom keyboard. No color as the original terminals were orange only plasma panels.  You can check out PLATO and TUTOR today on an emulated system at http://www.cyber1.org

  • fred x quimby | Mon, 01 Nov 2010 05:03:30 UTC 

    Just don't make me go back to programming in INTERCAL.

  • Noa | Mon, 01 Nov 2010 04:43:21 UTC 

    Part of the reason this isn't done is because unlike filenames, etc., code is for programmers.  There is little advantage to having it look pretty.

I can give you an example of a non-English language, though.  I worked on a system (made by Cannon I think) that had a mainframe programming language similar to COBOL, but everything was in Japanese.  The only advantage it had was that people who didn't know English could figure it out easily.  On the other hand, they could have just used romanized Japanese instead.  It's not pretty, but for programming it would have been fine.

  • Daniel Beckham | Mon, 01 Nov 2010 04:20:44 UTC 

    This article really smacks of typical academic bullshit and is completely divorced from reality.  I guess I'm being rude, but your ideas are trash.  You spent absolutely no time thinking about actually trying to solve the problem you perceive to exist and instead you write an article about unicorns and rainbows.  

Your ideas require special keyboards, leave out the disabled and require vendor lockdown.  Nearly every modern programming language can be written in nearly every IDE, running on almost all operating systems installed on just about any type of hardware. 

Your ideas can not and for that reason alone are garbage.

  • Bob L | Mon, 01 Nov 2010 03:50:57 UTC 

    What is the actual benefit to doing this? I can think of many cons, but not many pros. First of all, all current keyboards would need to be replaced. Considering your language won't be the only one out there, people will need a new keyboard just to handle your language. That right there is a major put-off. Second, it overly complicates the language to insert "Dentistry symbol light down and horizontal with wave" or even the more conventional ones like Sigma, Omega, what have you. People don't have to know what these things literally mean to use them in their current form. You start inserting the actual glyphs and people will be easily confused. What does it mean? How do they use it? What is the keystroke sequence to insert it? Everyone will need a wall-sized poster of 'HOW TO INSERT X INTO YOUR DOCUMENT". It's an interesting concept but I would never use a system like that. It just doesn't make sense for me to fix what isn't broken. It serves only to complicate.

  • Mike | Mon, 01 Nov 2010 03:37:54 UTC 

    Dear Sir,

Thank you so much for coming up with a new way to make things more difficult and obtuse for programmers. I was deathly afraid that no one could find a way to make programming more ridiculous and error-prone, but you sir, came up with a wonderful way to make things sillier and more difficult for everyone. Bravo! Perhaps next you could develop something useful for campers, like dehydrated water. 

> Why not make color part of the syntax? 

Well, I can think of two reasons: 

1) because that would be stupid, and 
2) it would be an unnecessary burden for anyone who is color-blind.

  • Fred in IT | Mon, 01 Nov 2010 03:36:05 UTC 

    POUL-HENNING,

I am going to be blunt to the point of being rude.  You are being a typical academic clueless mope.

When I type the 'A' character out of UNICODE, which A are you talking about?  Which A is the compiler, symbolic linker on down, ad-nausium, to the underlying machine code referring to?  The machine *DOES* know, but not the person reading the code.  When it prints/displays, it's an 'A' but which A?  Which font do I need to use to map the underlying UNICODE character code to something that can be displayed properly?  What if my font doesn't have the necessary UNICODE value?  What if you use a private area of UNICODE to encode your specific symbology for that one, special, glyph that you need?

There are many, many symbols in a UNICODE character set that look identical, but have different meanings depending upon which underlying language they are being used with.

Also, I am not aware of any machine that is underlying UNICODE aware.  That the code is compiled to a fully-UNICODE aware machine code.

Your solution is worse than the problem.

I agree that the worlds computer languages are massively constrained to the extended ASCII character set.  And, as such, are primarily constrained to being written in English, or at the very least, some language based on the Latin character set.

Having heavily programed in both an IBM zOS (EBCDIC) as well as Windows/UNIX environments I can understand the problems of converting between the two. EBCDIC doesn't support square brackets '[]' - try uploading PostScript.  Have fun.

I would rather the next revolution in computer programming be in the realm of reducing the need to actually type or input code, with all the constrains of regular syntax, BNF and the like.

Yes, at some, low-level, level there will still need to be code, translated into 1's and 0' that eventually flip the state of transistors.  And someone will need to write and maintain that code.  But for what we need to do, as a society or even as a race, the actual act of writing code is archaic.  Think John F. Kennedy, Daniel Barnham, Frederick Law Olmsted/Calvert Vaux. Not Donald Trump.

Truly think of ways to break the bounds of what we do and how we do it.  Not just rehashing the brilliant efforts of Hopper, Wirth and Von Newman.  They are the giants upon whose shoulders we stand.  And as such, we honor them, but do not worship them.

I was hoping for some sort of novel insight into the next wave of Computer Science not some whining about the constraints of ASCII.  That 'I need a symbol for that'.  Why do you need a symbol?  Type a word.  The OED seems to be doing quite well with just 26 characters.  New words, with new meaning, added all the time.  Basic English uses only eight symbols, plus space, to convey all the meaning, emotion and richness needed.  Most other languages, a few more.  Some, even none.  Maybe that's an area ripe for research and investigation. Not in the area of increased obfuscation and complexity.  Make the machine work with us.  The way we normally work.  With, more or less, normal language.

Until C came along, languages (Fortran, COBOL, Pascal, etc.) had a rather basic symbol set and a still extremely expressive capabilities.  C was written to squeeze more performance out of the machine.  There is a reason why it's joked as the language that has all the power of assembler with the ease of assembler.

Let's work on making computers easier to program, not harder.  A language that I can hand to a hair-dresser or a butcher that allows the computer to help them out.  Not one that continues the status-quo.

Thank you for listening.

Fred in IT

  • Revar | Mon, 01 Nov 2010 03:09:17 UTC 

    I'm not even sure what encoding some of the comments on this page are, nor if they are displayed correctly by my browser.  I know even less how to generate those characters without opening some awful glyph picking dialog.  I don't want to play guessing games while coding.  ASCII is pretty expressive, and it doesn't constantly slam the brakes on my coding groove while I try to figure out how to type a word.  I don't mind UTF8 in strings...  It's appropriate for internationalization.  But requiring funky characters for main code is just annoying.  Yes, I would hate APL.

  • batman | Mon, 01 Nov 2010 03:00:39 UTC 

    you reversed or and bitor.

  • Dave Täht | Mon, 01 Nov 2010 02:55:24 UTC 

    I was kvetching about symbol expressiveness fairly recently. To the ubuntu poster who wants ALT-GR to do the right thing for accents - you need to install the US International Alt-GR  layout....

perhaps this will help somewhat: 

http://the-edge.blogspot.com/2010/10/internationalizing-myself.html

  • Daniel Dilts | Mon, 01 Nov 2010 02:21:09 UTC 

    You do miss one very important reason to stick to ASCII characters...most of us can't (directly) enter any other characters from our keyboards.  It makes programming ridiculously slow and tedious if you can't enter the characters, delimiters, etc. that form the programming language.  Yes, you would likely increase expressiveness, but at what cost?

  • Konrad | Mon, 01 Nov 2010 02:20:56 UTC 

    Why are programs written in ascii?
short answer because they are written on keyboards and the majority of keyboards lack a good set of mathametical symbols. I for one am not really interested in a language that I need a special keyboard to use. It would be annoying on a desktop and completely impractically on a laptop. 

As to using colour, and other forms of source code arrangement. On the one hand I agree with you, my favourit tool for Java was IBM's visual Age, which completly hid the file system. CLasses and methods could be browsed in various ways, and you would edit one method at a a time. The down side was that you could do nothing outside of the one particular tool.

If you add significant colour and complex layout you end up with a language that can't be used outside of its specific development environment because no other tool is able to correctly render all of the necessary information.  And its not as if this hasn't been done many times. There is a very large number of such languages and not one of them has managed to break into the mainstream.  Heck even significant colour has been done: http://www.colorforth.com/cf.htm

  • Jason Ozolins | Mon, 01 Nov 2010 02:19:15 UTC 

    Correction - the detection of the inserted Linux wait4 root backdoor was courtesy of tight source tree version control, rather than by inspection of the actual changed code - my apologies for not expressing this well.  But as a sysadmin who has had to deal with hidden files and directories with odd names full of nonprinting characters created by rootkits, I'm less concerned with the extra expressive power given by allowing unusual characters in filenames than by the opportunities they offer to confuse or distract; until now, source code has been relatively free from similar hijinks.

  • Robert Melton | Mon, 01 Nov 2010 02:11:13 UTC 

    What an odd combination of criticisms... first and foremost, I think you already hit on the correct solution... custom syntax and creation mechanisms are best explored as layers on top of existing tools, not a fundamental part of a new tool. 

I believe to try to integrate your ideas would have crippled Go, and given it nearly no advantages, at the cost of a huge degree of developer mind share.  Bootstrapping a language is hard enough without giving yourself new disadvantages.  

I have never seen Guido van Rossum claim anything other the "readability" and that it was the natural flow as foreseen by Knuth (1974).  Can you please site a source, else it seems like you are just making stuff up.  

As for pulling minor scopes and subroutines out to a separate vertical space... lots of editors with folding and vertical splits already allow exactly what you describe, requiring no new language features.

As for embedded colors, I can't think of anything as nightmarish, and the amount of fudging you would have to do with text editors would be just terrible.  I don't want my text editor to be tightly bound to my programming language. 

Also,  speaking of things which should "take an afternoon" is silly and pointless... it doesn't add anything to the conversation and trivializes other peoples work, why don't you take an afternoon and add it, so we all can see how it works out?

  • Abdul Alhazred | Mon, 01 Nov 2010 02:07:40 UTC 

    Eh, I don't think text is the problem. I mean we have things like interceptors and join points in J2EE (and other environments too) that allow cross-cutting concerns to be abstracted away from the core problem logic. I think you'll find that to be a more robust approach than some kind of fancier and less textual syntax. The virtues of text are legion. It is easy to compose on keyboards and that IS an important factor. Every environment in existence can render the basic symbol repertoire encompassed by ASCII. This could be a historical accident, but it is an accomplished fact at this point. Programming languages are useful to the extent that they are flexible and can be bent to a variety of purposes and integrated into a variety of different tool chains. Text fits that bill remarkably well. Rather than attempting to make source do things source is not good at the more productive line of development seems to be enhancing the tools SURROUNDING the basic textual source representation. When I am developing in Eclipse I have a wide variety of options for ways to view and analyze the system being developed, including round-trip UML and various outline and other view types. In any case ultimately is Unicode PI symbol really that much different from naming your variable 'pi'? Is it really a big improvement? I just don't see it.

  • Jason Ozolins | Mon, 01 Nov 2010 02:06:19 UTC 

    I think the problems with open slather Unicode, and two dimensional layouts are similar to problems with visual programming languages:
1) Version control/detecting and accurately perceiving changes in source: Browser security problems have resulted from Unicode's multiple ways to compose characters, and the existence of characters which look very similar to each other at casual glance.  Both make it harder to spot deliberate attempts to subvert source code, or accidental finger fumbles.  Remember the root escalation backdoor that was hacked onto the CVS mirror of the Linux kernel source? (google for linux backdoor wait4)  The added code used an idiom that looked almost like an error check, but I believe it was spotted partly because it's quite hard to completely obscure what you're trying to do when you use plain, dumb, straightforward ASCII as your source medium.   Has anybody got a good handle on version control for diagrams that doesn't make you have to flip back and forth between versions?  Try convincing people in charge of a large distributed project that they have to use a blink comparator (google it) to work out what has changed in a visual program.  Try making sense of diffs that express changes in terms of 2-D Cartesian coordinates rather than 1-D source lines.

2) cognitive overhead.  Source is not poetry, and the form of the source should not have subtle layers of meaning that need to be teased apart, or deliberate obscurity to convey some mood.  I don't want to read source that looks like one of Ezra Pound's Cantos - it is hard enough for me to keep various bits of structure in my head as I read plain old ASCII, without remembering what somebody decided to make "Dentistry symbol light down and horizontal with wave" mean in this scope.  It could be that this greater expressive power could somehow produce a radical improvement in programming, but remember that great quote about debugging: it's harder than programming, so if you program to the limits of your ability, you won't be able to debug the resulting program...

3) Is this just maths envy?  The language of mathematics has evolved over centuries to meet the needs of mathematicians, and it allows them to make beautiful proofs (albeit usually in conjunction with English text to justify and explain the mathematical formulae); but pouring some maths symbols over source code will not suddenly make our C programs provably correct.  I'd rather program in a functional language in ASCII than an imperative language in Unicode&

4) Accessibility issues - I would expect that ASCII or restricted character sets and linear, scroll-like source code is probably easier for people with limited physical dexterity or vision to work in than a Unicode-heavy, 2-D source code style would be.  This belief does just come from me trying to imagine how I would go about my work under a sensory or physical constraint, though, so I'd be glad to know more from people who deal with this as a real issue.
  - Jason

  • Guest | Mon, 01 Nov 2010 01:57:34 UTC 

    Perl6 uses Unicode operators, but also allows multi-character ASCII equivalents. You can, however, define new, multi-character Unicode operators. So Perl6 has taken your suggestion to heart, and at the same time might serve as a counter-argument!

  • Chris Jillings | Mon, 01 Nov 2010 01:26:20 UTC 

    I think LabView and most industrial process-control languages are almost entirely graphical. And yes this stuff is used alot. Spend some time in a petrochemical plant. They will use something like DeltaV. Now these are probably not languages in their own right but rather "graphical macros" of C or some such thing. If you have a billion dollar plant, your code is written graphically.

  • Andrew | Mon, 01 Nov 2010 00:43:34 UTC 

    Poul: I disagree that handling unicode correctly is a matter of an afternoon's work. A great deal of care was put into Go's handling of unicode strings. As to your overall point: it's my opinion that syntax is relatively unimportant compared to the actual language features, which are more than adequately expressed in ASCII. You may disagree, but the onus is on you to provide a compelling argument as to how color or non-ASCII characters would make programming languages better. Your message so far seems to be "It is no longer impractical, therefore it should be done." IMO, these things would only serve to complicate, and unnecessary complexity is antithetical to Go's stated goals.

  • Poul-Henning Kamp | Sun, 31 Oct 2010 10:58:30 UTC 

    Andrew, that is exactly why I am so disappointed with Rob Pike's effort on the Go language:  It allows you to move Unicode data and it allows you to decorate your identifiers with Unicode, two bits of minor surgery that should not take more than an afternoon to carry out on any language/compiler.  Why no pushing of boundaries to use modern technologies like color and Unicode to move us closer to intentional programming ?  Poul-Henning

  • Andrew | Sun, 31 Oct 2010 01:19:43 UTC 

    Calling out Go here is a strange thing to do; Go supports unicode from the ground up. Strings are UTF-8, and any identifier can include unicode characters - you can name your Pi constant with the greek letter.

Not only that, but we actually debated using the unicode characters for !=, >=, etc instead of the standard multi-character ASCII equivalents. In the end it was decided that it would be a gratuitous change for little benefit.

So it's a shame that he levelled his criticism at Rob Pike, a guy who clearly knows a lot about unicode (he co-authored UTF-8 with Ken), built the first Operating System with unicode support in its foundations (Plan 9), and has taken great care to support unicode in Go.

  • James Cash | Sun, 31 Oct 2010 01:02:25 UTC 

    Mathematica allows you to input various mathematical characters by typing escape around a phrase  e.g. int gives you an integral sign, omega gives you a lower-case omega, etc.

  • Mikel Ward | Sat, 30 Oct 2010 23:07:45 UTC 

    Entering symbols can be done using the compose key.  For example, compose x x = times sign.  If you're on Gnome or KDE, you can make any key the compose key, e.g. Control, Caps Lock, or Shift+AltGr.  For details on setting it up, see
http://canonical.org/~kragen/setting-up-keyboard.html.

Unfortunately there is no standard for entering Greek letters, but kragen's xcompose mappings add that, e.g.
compose * O = Omega 
http://github.com/kragen/xcompose.

Windows systems can use AllChars to do the same http://sourceforge.net/projects/allchars/

  • CoffeeZombie | Sat, 30 Oct 2010 21:33:32 UTC 

    Hello; I came across this comment via the Hacker News feed, so, being new here, please forgive my presumption later in the comment. 

First, I'd note that many fields seem to have elements that don't make sense when you really look at them, and when you ask, "Why do you do it that way?" the answer is pretty much, "Well, it's just a historical thing; someone started doing it that way at one point, and other people adopted it, and eventually so many people did it that way, it didn't make sense to do it any other way." For example, if I remember correctly, diagrams of electrical circuits (and, I believe, even some of the math) are backwards; they indicate the current flowing in the *opposite* direction of what really happens. Now, maybe I'm misremembering at the real reason for it is that the math just works better that way, but it seems to me this is a case of, "Well, we always did things that way, and when we realized it was backward, it was easier to just say, 'we draw it backward' than to change our diagramming." Maybe the reason for this is that there are some things that are so deeply entrenched that the benefits gleaned from changing them are outweighed by the difficulties with doing so. 

Secondly, aside from the questions of whether existing user interfaces make it easy or prohibitively difficult to work in a Unicode-dependent language (and here is where I, perhaps, am a bit too forward), has anyone here actually made the attempt to design and implement a Unicode-based language, even just a small "toy" language? At the very least, it would be an interesting exercise. At the most, it would either serve 1) as a demonstration of why it's not done (say, the tools on which the language depends are ASCII dependent, or at least perform optimally with ASCII), or 2) as a demonstration that it *can* be done, and perhaps an encouragement for more people to do it.

  • James Dunne | Sat, 30 Oct 2010 19:57:20 UTC 

    Personally, I think that it's not exactly the keyboards. If we are talking about keyboards as a limitation to using non-ASCII characters then I have to say it is simply a top-level UI problem - it's not actually the hardware itself. For example, by using the 'Alt Gr' key in conjunction with the letter 'a', it will produce 'á'. However, here's the catch: this only worked for me on Windows but not on Ubuntu. Having said that, and this is obvious, you should and can use software to extend the keyboard with new symbols.

Basically, the accessibility of these characters is not a REAL issue here. It's as simple as learning to use  mandatory hot-keys so you can use the language. Emacs and Vi are still popular text editors and you can't get away with not using hot-keys when using them.

The real issue, which is me saying I agree with the Poul-Henning Kamp, is to do with language designers trying to solve a puzzle that doesn't need solving. There are countless opportunities for extending syntax in ways outside of ASCII.

  • Bradley C. Harder | Sat, 30 Oct 2010 17:52:09 UTC 

    Speaking of Tcl, how about this example?

#!/usr/pkg/bin/tclsh8.6

proc Ò?Û?àï?Ñ? {} {
    # Georgian "hello", via Emacs.
    puts "Oh hi!"
}

Ò?Û?àï?Ñ?

;# I can eat glass, georgian, via http://www.columbia.edu/kermit/utf8.html
set Û "ÛØÜ?á Õí?Û Ó? ?à? ÛâÙØÕ?."
puts ${Û}

  • Pierre | Sat, 30 Oct 2010 17:44:44 UTC 

    I would dearly love to be able to enter table characters to make beautiful comments.

I mean the lines that, joined together, form the boundaries of a table: horizontal line, vertical, corners, centre cross, T-junctions, etc. These characters go right to the edge of the character cell, and join up seamlessly.

The simple ASCCI characters used for erzatz lines (dash, '+') just don't cut it.

  • linux2.6.27 | Sat, 30 Oct 2010 17:28:44 UTC 

    Hey Ethan! vim's support for unicode is poor. It can even correctly render many unicode ranges.

  • Ethan | Sat, 30 Oct 2010 16:41:19 UTC 

    vim supports Unicode just fine, by the way, so you could have put the characters in (unless you really meant that you were using Bill Joy's original creation, of course.)

:help unicode
^Vu203d

Many compilers handle Unicode variable/class/struct/member/function names as well. However, I can do without Zalgo-fied source code, thanks.

As for manually using color as a third dimension of syntax for the compiler (first dimension is legal syntax itself, second dimension is scope) NO NO NO!

How do you "change color" on the fly? Interrupt your thoughts, move your hand to the mouse, highlight a function, find the palette in the toolbar, set it to chartreuse or whatever, then resume programming? Why is it so hard to just type "protected" in front of your method when your hands are on the keyboard already? Set your IDE to highlight it for you automatically if you like, but I guarantee if you require the programmer to do it you'll hate your IDE within 3 hours or less. Also, how do you accommodate reading code in editors that don't understand your markup? An then how do you compile outside of your IDE?

Showing related methods/objects/subroutines/whatever in a floating window near the code you're looking at could be useful, but that's a function of the IDE, not the language.

  • Zeljko Vrba | Fri, 29 Oct 2010 14:14:21 UTC 

    I AM European, and I use US keyboard for programming; any other layout is a PITA. Besides, a standard, mass-produced keyboard costs $20. Newly developed keyboard would probably be significantly more expensive.

  • Poul-Henning Kamp | Fri, 29 Oct 2010 13:12:14 UTC 

    Really ?  Keyboards are why we are not doing it ?  You are clearly not european.  If you were, you would know what a pain in the ass it already is to get the usual [{|\}] characters by some contorted CTRL-ALT-STICK-SHIFT sequence on non-US keyboards.   A keyboard costs USD20 these days, I simply don't buy the argument that we cannot afford to improve them to our purposes.
Poul-Henning

  • Zeljko Vrba | Fri, 29 Oct 2010 08:00:00 UTC 

    You have forgotten that our keyboards are ASCII. I have NO idea how to input unicode characters on Win7 (according to wikipedia, I have to edit some registry entries to enable hex input), I have NO idea what unicode characters are available and even less desire to learn their hex codes. Finding appropriate characters in an on-screen character map is dog-slow and not usable.

Re. color: sometimes I want to print out a piece of code for review. Color printers are not as widespread as BW printers, and the ink is way more expensive.

I vote for sticking to ASCII.

  • Jim White | Thu, 28 Oct 2010 07:23:46 UTC 

    colorForth by Charles Moore (who created FORTH starting in 1968) has been around since 1996.  Not saying it's my cup o' tea, but he used it to write his own VLSI design tools to design his own processors (that directly execute FORTH) using his own ideas (the patents for which have been licensed by all the big companies whose names you know).

http://www.colorforth.com/cf.htm

  • Ed Kimball | Wed, 27 Oct 2010 13:36:41 UTC 

    One caveat about using color to indicate meaning: roughly 10% of the male population (including yours truly) and a much smaller percentage of the female population have some degree of color-blindness. Using color can obscure meaning for these people.

  • Johan Kotlinski | Wed, 27 Oct 2010 10:31:34 UTC 

    "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?"

colorForth has color as part of the syntax. http://www.colorforth.com/cf.htm

  • ctrucza | Tue, 26 Oct 2010 20:45:58 UTC 

    Too bad the comments won't handle unicode :)

  • ctrucza | Tue, 26 Oct 2010 20:44:16 UTC 

    "Why do we still have to name variables OmegaZero..."

We don't have to:


#include 

typedef void !H;

class 
{
public:
	!H I2()
	{
		std::wcout << "`}L" << std::endl;
	}
};

!H ª›À¼()
{
	 robPike;
	robPike.I2();
}

int main()
{
	ª›À¼();
}

  • Justin James | Tue, 26 Oct 2010 18:55:57 UTC 

    Speaking of text processing, this is the worst commenting form in the world. Not only does it strip out the newline characters, but it has no way to subscribe to the comments, so I have to keep refreshing the page to look for responses. Not a good reflection on the ACM at all!

J.Ja

  • Justin James | Tue, 26 Oct 2010 18:41:27 UTC 

    Poul -

Yes, 4GLs. I am well aware what a mess they were in the 1980's, the 1990's, and event he 2000's. The current crop is decent. And, quite frankly, for the "typical business developer" they make code just as good, if not better, than anything they can hand roll. Would I recommend it for someone working on specialized algorithms? Absolutely not. Would I recommend it as a replacement for the "typical data driven business application"? 100%. Your impressions of 4GLs, while accurate, also could use a refresh based on the current crop of products.

I've also looked at the "Intentional Software" stuff; unfortunately, they have made very little public. Not enough for me to form an opinion on it one way or the other. I've talked to their PR people who are equally tight lipped about it. It reminds me of the Segway before it was released. There's this quiet, subtle hype about it, no one can really explain what it does, but based on the people involved, you expect something really big.

The fundamental issue is that the overwhelming majority of the development work out there is not being done by skilled professionals. It's obvious, because the vast majority of "developers" are not skilled at their jobs, they are good at using the tools, at best. So the *real* question is, "what do we need to do to provide them with better tools?" Currently, the trend lately has been to introduce high end academic concepts into mainstream development (look at C#, with LINQ, lambdas, dynamics, etc. created a mix of declarative, functional, and dynamic development in one package). The problem is, folks without the right background (experience and/or education) don't know how to leverage these things and get anything out of it. Microsoft has done a real favor for the kind of "nerd" developers, but the average developer doesn't understand these things nor wants to learn these things. And the people writing the checks don't care about these things.

We need a better way of developing code, period.

J.Ja

  • Gordon Tisher | Tue, 26 Oct 2010 17:51:49 UTC 

    Go allows Unicode in identifiers: http://golang.org/doc/go_spec.html#Identifiers

  • Craig Overend | Tue, 26 Oct 2010 17:27:08 UTC 

    It's not ASCII that dictates what glyphs language designers gravitate to, it's the most efficient use of practical common and conceptual keyboard mappings they look for. If they were free to use any ASCII or Unicode glyphs they liked, they would be including all kinds of ASCII double-line borders, pixelated squares, upside down question marks or Unicode Chinese glyphs. But they're not, they stick to the subset keyboards, through common evolution, have been mapped to. Only when it's common for the keys themselves to display mappings and dynamically change for applications do I see the evolution of language glyphs changing at rate. And even then barrier to entry may prevent large adoption just as customised keyboard applications have encountered. We're only now seeing touch screens and the per application customisation interfaces they afford. Those per application touch keyboards are only now beginning to go custom gestures or tile mapping and developers revel in their new found freedom of the physical interface.

FWIW, colorForth uses colour and there are complaints from colour blind people as a result. Not every one has the same network of rods and cones. I've found colour also increases the barrier to entry in learning the language.

  • Poul-Henning Kamp | Tue, 26 Oct 2010 16:46:58 UTC 

    First of all, "4GLs" ?  Really ?  Those happened in the late 1980-ies, and were a total fiasco.

I think that you are setting yourself up for an even tougher row to hoe.

First: I generally find that graphical expressions seldom if ever have a single unmistakable meaning, which we require to instruct computers.  Are we ready to pay different amounts of income tax, depending on the IRS' computer being in an impressionistic mood rather than as usual taking a cubistic view of the graphs in the tax code ? :-)

Second: Do we even know how to do something like that in the first place ?  Last I heard of graphical approaches, it was from Charles Simonyi's company "Intentional Software" and quite honestly, it did not look very impressive to me.

But yes, eventually we need to explore stuff more expressive than text as source code, but in light of how conservative programmers are with their ASCII text, I don't expect to see it happen any other way than as part of generational shift.

In the meantime, we could take some baby steps

Poul-Henning

  • Justin James | Tue, 26 Oct 2010 15:49:27 UTC 

    You need to go one step further... why are programs still being represented as text at all? The fact is, textual source code mandates the understanding in a top-down level at some point in the process. Even things like OOP eventually become imperative code at some point, and concepts like parallel processing are hard to work with because we are so adapted to top-down thinking when we see text.

Some of the new 4GLs are great steps in fixing this. I've been using "The Agile Platform" lately, and I love it. Why? Because everything is handled in a truly visual manner like Visio or a similar flowcharting tool. It is nearly impossible to make "write only" apps because it is obvious what everything does. Is the tool perfect? Absolutely not. But I literally get furious at the idea of doing Web development (it only does Web apps) with any other tool now. I can focus on solutions, not problems. There are a number of other tools out there too which I haven't had the chance to try.

Here's a good example: error handling. In textual languages, error handling, by necessity, either applied to a single line of code (for example, "dosomething || die" in Perl) or a block of code (the standard try/catch block). If you want to re-use exception handling logic... well... good luck with that. And if you want granular cascading of error handling... again... good luck. At best, you'll be able to handle it somewhere in the call stack, or at a global level (for example, global.asax in the ASP.NET model). In the Agile Platform, error handling is a piece of *metadata*. It is trivial to reuse error handling logic, or to apply it granularly throughout the application.

Again, the point is that you need to not be arguing against ASCII in favor of Unicode. You need to be arguing against *text*.

J.Ja
Leave this field empty

Post a Comment:

(Required)
(Required)
(Required - 4,000 character limit - HTML syntax is not allowed and will be removed)