[still_grokking]

We should stop the ASCII madness at some point. The world speaks Unicode. Only programming languages are mostly stuck in the 7-bit era. That sucks.

People even use extra keyboards to input their emojis, but we "can't" input math or programming symbols? Really?

An "international" keyboard layout gives you already a shitload of "special" signs.

Using the compose key you can input even more.

When this isn't enough it's trivial to add something to ~/.XCompose

I'm not advocating to have a pure symbolic programming language. But things that are better expressed through symbols just should be.

It has reasons why you use symbols in math instead of writing everything out in some human language.

Programming is evidently symbolic, just like math: We know that as we let professionals read code while in a MRI scanner and we could look on their brain activity. The brain activity correlates with the one seen when reading (and understanding) math, not with the one seen while processing human language.

We should design programming languages accordingly!

[al2o3cr]

    People even use extra keyboards to input their emojis,
    but we "can't" input math or programming symbols? Really?

Your usage of emojis may be different from mine, but personally I'd estimate they appear in text about once per sentence (or even couple sentences) at the absolute most. That's quite a bit lower than the symbol density in most code.

    An "international" keyboard layout gives you already a
    shitload of "special" signs.

Unfortunately not always the _same_ shitload - for instance, the OS X layout for Norwegian has the seemingly-ordinary ( and ) on Option-Shift-8 and Option-Shift-9!

[still_grokking]

> Your usage of emojis may be different from mine, but personally I'd estimate they appear in text about once per sentence (or even couple sentences) at the absolute most. That's quite a bit lower than the symbol density in most code.

That's completely past my point.

The point is: People are using special keyboards to input their emojis. (You can even buy those as hardware gadgets!)

So there shouldn't be any issue with the requirement to use some special keyboard (layout) to input code if even causal people mange to use such special keyboard (layouts) for very mundane purposes.

> > An "international" keyboard layout gives you already a shitload of "special" signs.

> Unfortunately not always the _same_ shitload - for instance, the OS X layout for Norwegian has the seemingly-ordinary ( and ) on Option-Shift-8 and Option-Shift-9!

I was talking especially about a so called "international layout", not some country specific one.

https://dry.sailingissues.com/us-international-keyboard-layo...

http://arjenvankol.com/dvorak.php

Also for billions of people there is no direct correspondence between keys on the keyboard and the symbols they're trying to type. Just think about Asiatic languages.

There is just no valid reason to limit the symbols used in programming to the ASCII set, as in every day use ASCII was already replaced by much richer symbol sets, which are perfectly fine to use for even less techy people. Only programming languages are caught in the "tradition" of drawing some "ASCII-art" instead of just using some proper Unicode symbols. That's laughable.

Changing this would make in the end programming languages even simpler to read as, like I said, programming is symbolic by it's pure nature.

Of course there is still a kind of balance needed: Using symbols for just everything wouldn't be helpful, as nobody wants to learn hundreds or even thousands of symbols just to read code (I'm not proposing to mimic an Asiatic language, as this wouldn't be accessible). But using a health mixture of symbols and words would be beneficial. Language level features would be better encoded as proper symbols (instead of the "written out symbols" we mostly use today, like e.g. "keywords"), but most user level code like APIs in libs should still remain word-based.

APL got this almost right. Only that the code is too dense, imho, so it's hard to parse (for humans).

But a modern language that would replace for example keywords with symbols would be a step forward again.

[michaelmrose]

Edit: This example actually contains the symbol for a clock which in an unintentional illustration of the point renders just fine in editor and terminal but not here.

Lots of languages support using special characters in symbols.

Clojure for example.

   user=> (defn [x](+ 1 x))
   #'user/
   user=> ( 7)
   8

In most cases this is going to be spurious a textual description of the operation is easier to type, more descriptive, more memorable.

Your symbol of choice may have multiple look alike characters, may not be present in a different users font. Your fellow user may not know how to enter the characters you choose.

The text labels inc or increase are both more memorable, understandable, trivial to disambiguate and easy to work with and your fellow user will not be cursing you as they scan your code for the right character to cut and paste especially if it looks like a square with a hex number in it because they can't render it.

Math is an extremely dense formation of a an idea full of useless single character labels that make sense only to initiates. This isn't a great feature for code to emulate.

[still_grokking]

> Lots of languages support using special characters in symbols.

Most don't.

> In most cases this is going to be spurious a textual description of the operation is easier to type, more descriptive, more memorable.

"easier to type": depends on you keyboard layout…

"more descriptive": depends on the operation; a lot of math symbols for example need pages long descriptions when written out…

"more memorable": depends on your native language, and the language the text description is written in…

So to summarize: No, no, and no. ;-)

> Your symbol of choice may have multiple look alike characters, may not be present in a different users font.

This is also true for any text description. Who says ASCII symbols are universal?

Like it's completely possible to not have for example symbols for an African language installed, it's also completely possible to not have any ASCII font installed!

The solution is trivial: Just install the font needed to display the language you want to read.

"Look alike" symbols are irrelevant in this context. (And by the way one of the many things that Unicode got very, very wrong; the need for Unicode normalization is just brain dead; especially as there's more than one normalization mode, and they yield completely different and incompatible results; but let's not criticize Unicode here as this would become to long for this post).

> Your fellow user may not know how to enter the characters you choose.

Well, that's the point of keyboard layouts, and the mentioned extensions like the compose key…

That's nothing that should be a barrier for someone who likes to program a computer.

If you're unable to cope with switching the keyboard layout you'll be likely unable to cope with anything related to programing. So I see no issue here.

> The text labels inc or increase are both more memorable, understandable, trivial to disambiguate

Again: Please don't assume that everybody on earth is an English native speaker! In case you didn't know: Most people aren't. (Yeah, I know, especially US people don't recognize anything beyond their borders; but there's actually quite a lot, like most of the world, for example ;-)).

Also the given example is funny, as quite a lot of languages use a symbol for "increase"… Ever seen a `++` somewhere?

Abbreviations by the way are symbols! (And they share all the understandably / discoverability issues of symbols).

Symbols need of course some written out form, at least for lookup / search.

But abbreviations aren't just aliases (like well used symbols), which makes them even worse than proper symbol usage.

> easy to work with

What do you mean with that?

> your fellow user will not be cursing you as they scan your code for the right character to cut and paste especially if it looks like a square with a hex number in it because they can't render it

You need to install fonts…

But that's a solved "problem" since decades! Most systems come with preinstalled fonts for all of Unicode, since "forever".

> Math is an extremely dense formation of a an idea […]

Which is exactly what people wanted. Because it fits the use-case extremely well.

And like I've pointed out already: Code is like math. Reading (and understanding) code activates the same brain centers as reading (and understanding) math.

> […] full of useless single character labels that make sense only to initiates.

The "single character labels" are symbols, too.

They're not useless by the way. ;-)

And when we're at it: Calling math "useless" is ridiculous.

That one needs to understand the domain one works in is nothing unexpected. Code in general also doesn't make sense to outside people. No mater whether the symbols are written out or not. I could simply show you ADA or COBOL code to prove that. ;-)

> This isn't a great feature for code to emulate.

I don't argue to use only symbols; as I stated already before.

But common "language level" syntax would be better expressed in a symbolic way. Long words are only noise. They don't provide any benefit in reading (or understanding!). Quite the contrary as our brain needs more time and capacity to recognize them. That's one of the reasons why mathematicians prefer symbols. Symbols are just way simpler to read and understand quickly!

Of course you need to learn the symbols. But that's equally true for the written out forms! Code doesn't become "intuitively" understandable when written out in human language.

It becomes actually less understandable as you need to parse (and remember!) much larger chunks to get the meaning. A human brain has only max. 5 seconds of working memory (most people have less). Long words use up this capacity much more quickly than short symbols. That's a fact. (Just look up who can do better mental arithmetic on average, and how this correlates with the length of word used for numbers in the native language of those people).

Of course not everything should be abbreviated. Only things where it makes sense.

Someone who knows some language should be able to read code in that language without "learning Chinese" first. (That's why I actually don't like abbreviations in code: Because you can't understand such code without first learning the—quite often completely random and ad hoc—abbreviations someone who never heard of code-competition introduced for no reason).

But having noisy long written out symbols for language constructs is just not helpful. It's even an obstacle to quick reading of code. (Just go out and try to read larger chunks of ADA. You will realize quickly: Reading such code is actually very exhausting!)

[michaelmrose]

===DIVERSE CHARACTER SETS IN CODE===

Currently a singular set of characters trivially entered on virtually all current developers keyboards is used to create English language keywords and identifiers formed out of ASCII characters that on any decent programming font are trivially distinguishable and identifiable.

Whether or not you think this is ideal or equitable people who natively speak any of thousands of languages and numerous character sets can trivially communicate and write mutually intelligible code with font serving only as a aesthetic choice.

17 people from 17 different places each using their own characters and whatever special characters they please produce code that not one of the 17 should be able to type easily with numerous look alike characters in and it should lift choice of font from a aesthetic choice to a functional that effects not only the font selected in the editor but potentially the editor itself given the need to support interesting things like combined characters. Given this the logical thing to do would be for people to agree not to stick any weird characters in your code...which is what I think most people do even on languages that have such a feature indicating its basically kind of useless.

> "easier to type": depends on you keyboard layout… Yes you would be advised to use an English layout or something which makes it easy to type these characters. You are also going to be using english keywords for example.

> "more descriptive": depends on the operation; a lot of math symbols for example need pages long descriptions when written out…

Such symbols also have an English name. The alternative to the special character isn't a pages long description of the operation its the name.

> "more memorable": depends on your native language, and the language the text description is written in…

A word in a singular small character set is easier to remember than an identifier that could contain thousands of different characters some of which are only found in a fraction of your people's languages and many which look alike. It takes more bits to encode because it is trivially more complicated.

===MATH VS CODE===

I never said that math was useless. I said single character identifiers especially ones which change from context to context are useless. There is no reason to believe that because math has similarity to math that a similar notation is valuable or indeed even that mathematical notation is particularly good.

> It becomes actually less understandable as you need to parse (and remember!) much larger chunks to get the meaning. A human brain has only max. 5 seconds of working memory (most people have less). Long words use up this capacity much more quickly than short symbols. That's a fact. (Just look up who can do better mental arithmetic on average, and how this correlates with the length of word used for numbers in the native language of those people).

My recollection is that its not a certain number of seconds of working memory but how many balls you can keep up in the air and your brain works around this problem by in effect remembering one "chunk" as opposed to its constituent parts which is why you can basically function at all. There is no evidence whatsoever that using symbolic representation of non ascii characters improves programming performance or indeed that any part of that statement is accurate. Seeing as there are several languages in which one can use both entirely ascii text along with whatever unicode you like you ought to be able to back up your assertion with a citation.

[Jtsummers]

I liked how Fortress would transform your ASCII file into LaTeX renderable output. Also the APL input in emacs and many other editors offers a pretty reasonable compromise. `.i` => ι (iota), as an example. It doesn't take much effort to learn. Then there's also the option of letting people type it longhand and having the editor substitute for you: `\iota` (or maybe `\iota<tab>`) => ι. The prefix option is handier for the common symbols, but the the TeX-style work well for less common ones.

https://en.wikipedia.org/wiki/Fortress_(programming_language...

https://web.archive.org/web/20160304052722/https://java.net/...

[still_grokking]

> .i => ι

That's more or less what the compose key does (but works everywhere and not only in EMACS). :-)

Only that there isn't such combination defined by default. But adding it is trivial:

  <Multi_key> <i> <i>                 : "ι"   U03B9    # GREEK SMALL LETTER IOTA

This line in your ~/.XCompose and you can type "ι" by pressing compose-i-i without changing the whole keyboard layout away form your default.

I'm using the compose key the whole time to input "special symbols"™. It's very intuitive. (Like, for example you get the "™" when pressing compose-t-m).

I have the compose key on the otherwise useless CAPS-LOCK (and CAPS-LOCK on/off by pressing left and right space simultaneously). Both options are only ticking a check-mark away when using Linux.