[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.