Why is it that code is always viewed as ASCII text? APL insanity aside, it would seem useful to replace appropriate function names with ≡, ¬, λ, and ≠ in an IDE (and have the language understand it). This would cut out some of the insanity with people arguing over (not ) versus (no ).
More generally, is there a particular reason language creators see IDE design as beyond their scope of work? It seems to me the two should be interwoven.
Precisely! Now, just make emacs replace "no" and "not" functions also, and you'll have what I was asking for.
However, my point is also that doing this kind of thing should be within the scope of PG's work - providing a "reference IDE" to show how he intends Arc code to be interacted with.
andreyf, I completely agree with you. How people write code in a language is -- from a user experience perspective -- part of the language in a very real sense. I've written about this before. http://plpatterns.com/post/37655849/1-2-n
Using symbols like ¬ and λ is a start. Paredit is even better. But I think programmers are stuck in the mindset that source code has to come from an ASCII text file. If you truly get the idea that code is just data, there's no reason why your "IDE" shouldn't be integrated with the language and provide a higher-level representation of the data you're editing. Also, depending on the task, you may want to view different aspects of your code. You can think of your source as the model in an MVC where multiple views and editing styles for the same data-structure are possible.
Once you view your code simply as data, all sorts of possibilities open up. The so-called Source Code In Database site has tons of examples of these features. http://mindprod.com/project/scid.html
I think the answer is simple: If you allow non-ascii characters in a lisp, it would only "feel" right if the characters were fully programmable, as opposed to just adding a handful of extra characters. Lisp users don't like new features if they aren't fully programmable- You should be able to declare a new symbol in lisp code somehow and then be able to use it, IMHO. This, however, is non-trivial to implement (though I've had some ideas about this that I've been wanting to code up for years but haven't had time to do yet...)
By that I mean if you define a table library, you should be able to write code that allows the data of a table appear like a table, with a grid and everything, right within your code editor. That's what I would mean with "fully programmable"
When you say you want "characters to be fully programmable" does this mean that if you had "fully programmable characters" you'd be able to edit tables in your code editor as you describe, or are you making an analogy saying that you'd want characters to be fully programmable like these tables are fully programmable?
The former- I'm saying that if you're going to allow more characters, I'd want to go all the way and have an editor that is part of the "language definition" that supports arbitrary graphics and ui elements that is controllable through the language in a "lisp like" way and would allow code appearance to be 100% customizable right inside the code.
No, I think what people are getting at is... why does program source have to be represented by only ASCII text? After all, if code is data, an IDE is just a data editor, where that data happens to be code.
I think it has been shown many times throughout history that notation matters. In fact, the entire concept of Arc is based on this principle. Otherwise, Common Lisp would be suitable.
Why does it have to be ASCII? No reason, The simplest answer may just be that the language writer feels that adding UTF-8, or UTF-16, support would be a waste of their time, or is below them. As for programming IN the language, it becomes a matter of what is easy for the programmer to type. In a way, this whole thing is a matter of deciding what is the lowest common denominator that one wants to support.
Certainly not, any symbol can be translated into code or another symbol. A 3D language in a virtual haptic programming environment with dynamic force feedback... that bug is represented by... a bug, your world shakes when the code crashes!
There are bits of library calls I always seem to need to lookup, I'm sure if I found it by reaching way back to the left and twisting, it would always be 'at hand'. I want to dance my code!
Pragmatically tho, the significant convenience of the common denominator of common keyboard symbols trumps most attempts so far.
Another example: Mathematica is well integrated with its environment and uses much more than plain ASCII. Not only does it have all kinds of mathematical symbols but you can even paste pictures into Mathematica code to do image processing.
Something like that for a Lisp language would be very cool.
Interesting. Code as data -> Data as Code. Pictures as data; pictures as code? That reminds me of some "graphical" programming language I saw a while ago. It used blocks of color to control the interpreter much like a Turing tape. The head would "move" up down, left or right depending on color, and perform various other operations.
