I'm colorblind, please never do that. Syntax highlighting is fine since it's another way to help, but color having some kind of importance so that pink code and violet code run differently would be hell for me.

Edit: something else: color looks different depending on your computer. Consider how many complaints I already see here about people developing UI for extra wide monitors while most people are on 15 inches screen, that would be terrible. Don't even get me started about arguments on "is this blue, blueish green or green?". Colors are way more subjective than what people seem to think.

> For some reason computer people are so conservative that 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.

And no new letters have been added to English or French lately. They seem to be doing just fine. Typing those new symbols would be hell if keyboards are not designed for it.

I see negative value in representing code as anything other than text. Every time I've seen an entity try to do this, I've seen programmers come up with a text-based alternative that compiles to whatever janky format the other party thinks is clever this month.

I like having my code coloured, but if the colour was part of the code I'd lose the control I currently have. I'm not against that in principle, but if it was done in a way I didn't like it would really put me off.

The best uses, imho, like rainbow brackets, are applied after the fact. It would be a nightmare to have to match red brackets to red etc.

The current way, plain text with everyone free to use syntax highlighters that change the color, font, or anything of the text is fine and works very well. I've heard about AST-based source of truth, and I think this could fix syntax mistakes while still allowing people to edit plain text as they wish (and could also simplify visual programming tools. Maybe unlock a smooth transition from low-code tools to regular code?).

It's not a colorblind thing; that's just a terrible idea even if you nominally can distinguish the colors. (Citation: personal experience.)

Counterpoint: €

So, in practice, you need to support it and it is a relatively new addition. Most other symbols are 200+ years old.

https://www.unisonweb.org

Unison’s core idea is that code is immutable and identified by its content. This lets us reimagine many aspects of how a programming language works. We simplify codebase management — Unison has no builds, no dependency conflicts, and renaming things is trivial.

Some blog posts by the author of the language describing a bit of background

https://pchiusano.github.io/2013-05-22/future-of-software.ht...

https://pchiusano.github.io/2013-09-10/type-systems-and-ux-e...

I guess built-in things get fixed names / hashes, and the hashes of everything else follow from that.

They need a mapping from content/hashes to human-friendly names, obviously. Not sure if they gained anything here, but they seem to think so, so might be worth checking this out.

This does appear to pose a small issue for types, since isomorphic types are identical regardless of their names, but I believe they have a way to attach a unique id to enforce a distinction.

It's actually quite a clever idea.

Well, one of the underlying reasons for the lack of imagination might be... keyboards. If keyboard keys were small e-ink displays, easily configurable and accessible by programs, programmers would have come up with a lot of interesting stuff already. We do it with function icons in regular interfaces. If we could intergrate with keyboards, we'd definitely take advantage of it.

Now, there might be many more reasons. The article also mentions subroutines displayed horizontally and other stuff. That could definitely be done too, but... while we aren't there yet, many interfaces definitely make good use of horizontal screen space.

The main problem is that to do any of these, you kinda require coordination beyond the scope of solving a single technical problem. Unless the right hardware is available to enough people, custom symbols and keys and whatever would only work experimentally. And it would be a worthy experiment, but developing a language is already enough work to also have to add a custom revolutionary IDE to the mix, in the context of experimentation. In the current economic system, when the path to market is long and unclear most good ideas die anonymously.

From my own personal experience this is extremely true. A while back I made myself a custom keyboard [0] which can enter lots of characters, mostly for linguistic tasks. I didn’t intend to start using it for things outside linguistics, but before long I was using it everywhere — and my inventory of available characters expanded correspondingly. I started to use curvy quotes and em/en-dashes in all my writings (even in this post!), and — more topically — I started using Unicode symbols in my programming, when possible. I don’t use them too much, mostly because there’s little need for them, but in scientific tasks it’s really useful to be able to type e.g. ‘λ’ instead of ‘wavelength’. I predict that as Unicode symbols become easier to input, programming languages will indeed start to utilise them more — the limiting factor is keyboard layout. (Indeed we can already see the start of this process in Julia, Raku and Haskell.)

[0] https://github.com/bradrn/Conkey

I started using a Compose key under Linux five or six years ago. I have progressively accumulated fairly extensive customisation in my ~/.XCompose. (e.g. Compose+;+; = ‘, Compose+"+" = ”, Compose+"+` = ″, Compose+z+Space = ZWSP, Compose+Space+' = NARROW NO-BREAK SPACE, Compose+++1 = THUMBS UP SIGN), Compose+-+-+= = −, Compose+l+* = λ.) Some are of my own division, and some (like Greek letters) are copied from Vim’s digraphs which I had used commonly before setting up a Compose key. I consistently type exactly what I mean. (If I type a straight quote, I meant a straight quote.)

My last laptop ended up being a Surface Book; had WinCompose not existed, I wouldn’t have been willing to shift to Windows.

If your audience is mostly programmers then just use `*`

If your audience is physicists or mathematicians then `×` or `·` may be a better fit.

When turning a math expression into code, it is often handy if the code looks a lot like the expression. Even better if you can just copy and paste it. It's hard to translate an expression wrong if you aren't translating it at all.

I have a QMK based keyboard. The most interesting thing I did was to have an APL layer on my keyboard. I wouldn't say it's "a lot of interesting stuff"

That and the fact that it would probably take me longer to search for whatever obscure mathematical symbol is supposed to represent <whatever> than it would take to just type out its name.

And ASCII is just easier to deal with.

Then there are the Unicode symbols that convey semantic information rather than just the appearance. These are an abomination and should never have been put in Unicode, but here we are anyway.

The touchbar on my M1 Macbook Pro does this. It makes using Emojis a lot easier. I incorporate emojis into my languages more and more nowadays.

*Also I don't think Go is better than modern C++, though it might be better than C++99 which was the main standard when the article was written.

If you don't do math it's difficult to understand, but try writing without the alphabet and expressing the same concepts. Possible but clunky

Suppose you write a function that uses a variable ω_0, and somebody else wants to change it. Unless they have the same keyboard setup as you, they will have to just copy-past it everywhere. And what if you have several variable with special names?

You should dream bigger. A better world is possible but only if people really want to throw out all the shitty designs from the ancient past

How should we do this?

I am imagining that we have a "char-bank" that lives on a little touch display at the left of my keyboard. I can add chars to my bank by highlighting them and pressing a 'yank' key. I can scroll up and down through my charbank and type the chars with a tap or rearrange them with touch-and-hold similarly to apps on a phone's homepage.

If I want to map a char to my keyboard, I can press and hold a "map" key, tap the char, and press the key I want to map it to. If I want to map the char directly from the screen I highlight it and press the map and yank keys together.

Vim/Kakoune users could have their help menu _be_ the keyboard. Every action changes all of your keys to whatever is possible. Sort of mind blowing.

Come to think of it, i bet someone has done this with Vim & LED Keycaps. Huh

Wow, this is an amazing idea. Think of all the other unimagined possibilities if we had real innovation in human-computer interface tech

May be instead of arguing for Unicode, community needs to come up with a unambiguous smaller set of symbols languages should support.

Tell me what does ":" mean?

Now if I tell you the language is Typescript, what does "?" mean?

I personally believe semantic overloading causes a lot of problems, but we are so steeped in the existing limitations that we don't recognise it is a problem.

We are so short of semantic operators that languages start to use single letters like "s", "q", " u" as operators or modifiers - which I find ugly (although the best compromise).

I have experienced how the wrong Unicode character can ruin my day - but that is what tooling and editors and best practice are there to help with.

Keyboards are the main problem now I think (in the past it was your OS, your editor, and your tooling). I regularly type Unicode characters from my handheld devices, but hardly ever from my qwerty entry devices (I can't easily find ¡, ∆, ↑ or ç as examples).

So...I don't see how this changes my point. The list of symbols that is a program will have many of those symbols in need of context to understand. Do you really think programming can escape that?

Edit: I am sympathetic. I like lisp for having fewer signifiers than other languages.

Ill-considered backward 'compatibility' with block-drawing character sets for mathematical typesetting. (Fucked if I know which character set, but presumably the same one they found U+23B2 '⎲' and U+23B3 '⎳' in.)

I can not effectively use my computer for anything without customizing the keyboard a little. I need to make the capslock key into an extra control key. I need to set up a compose key so I can type accents when writing in Spanish (even if I didn’t do that, what about writing people's names?). Even sticking with English, I need to type curly quotes and apostrophes, and em- and en- dashes, plus, now and then, symbols like ™ or ©. And I need to be able to type Greek letters when talking about physics or math. So, since my keyboard is already set up to handle all this, and it is easy to do so, for me it is delightful that I can use ω in my Julia code. The math looks more like math, equations take more familiar forms (which makes it easier to spot errors), and the code can be made more expressive. So, for me (but clearly not for everyone) this is not a “special” setup.

Current solution for most people is google + clipboard

For example, to type the word "cliché" here, I googled it, then copied it, then pasted it.

I personally find it also helpful to make the distinction between the maths and its implementation, though I accept that others would vehemently disagree iwth me.

As they say, it's already way too easier to write code than to read it. A programmer should make every effort to make code more readable.

An editor should make it relatively easy to enter special symbols (especially if you can specify a limited set); it is totally solvable problem.

An editor can only help you so far with reading code...

    (a*(1+exp(1i*theta[0,:]))+foo(x))/((b-cosh(bar(x))+(b+sinh(y[:,-1])). 

Another example where I think ASCII actually _is_ limiting is for entries of matrices directly. I mean, we try, but I'm not convinced we succeed. For an example (picked at random), hands up if you think this is a nice Euler angle transformation, where cphi/sphi etc are the cosine and sine of phi? No matter how you write it, it's going to be ugly.

   alpha = [cpsi*cphi-ctheta*sphi*spsi   cpsi*sphi+ctheta*cphi*spsi  spsi*stheta;
            -spsi*cphi-ctheta*sphi*cpsi  -spsi*sphi+ctheta*cphi*cpsi cpsi*stheta;
            stheta*sphi                  -stheta*cphi                ctheta];

I'd probably go with something like:

  double cf = cos(phi),sf = sin(phi);
  double cp = cos(psi),sp = sin(psi);
  double ct = cos(theta),st = sin(theta);
  alpha = [ cp*cf-ct*sf*sp   cp*sf+ct*cf*sp   sp*st;
           -sp*cf-ct*sf*cp  -sp*sf+ct*cf*cp   cp*st;
            st*sf           -st*cf            ct];

  alpha = [ cψ*cϕ-cθ*sϕ*sψ   cψ*sϕ+cθ*cϕ*sψ   sψ*sθ;
           -sψ*cϕ-cθ*sϕ*cψ  -sψ*sϕ+cθ*cϕ*cψ   cψ*sθ;
            sθ*sϕ           -sθ*cϕ            cθ];

    # this assumes that ϕ, ψ, and θ have already been set

    my \cϕ = ϕ.cos; my \sϕ = ϕ.sin;
    my \cψ = ψ.cos; my \sψ = ψ.sin;
    my \cθ = θ.cos; my \sθ = θ.sin;

    my \alpha = [ cψ×cϕ−cθ×sϕ×sψ,   cψ×sϕ+cθ×cϕ×sψ,   sψ×sθ;
               −sψ×cϕ−cθ×sϕ×cψ,  −sψ×sϕ+cθ×cϕ×cψ,   cψ×sθ;
                sθ×sϕ,           −sθ×cϕ,            cθ];

These all work because Unicode defines ϕψθ as "Letter lowercase"

    say "ϕψθ".uniprops;
    # (Ll Ll Ll)

I would like to note that I used the Unicode "Minus Sign" "−" U+2212 so that it wouldn't complain about not being able to find a routine named "cϕ-cθ". (A space next to the "-" would have also sufficed.)

Blech; looks like a letter and normalizes cross products. Better to use "·" (U+B7)[0]:

  alpha = [ cψ·cϕ−cθ·sϕ·sψ,  cψ·sϕ+cθ·cϕ·sψ,  sψ·sθ;
           −sψ·cϕ−cθ·sϕ·cψ, −sψ·sϕ+cθ·cϕ·cψ,  cψ·sθ;
            sθ·sϕ,          −sθ·cϕ,           cθ];

0: Also "∧" (U+2227, wedge), the real other vector product[1], but that doesn't matter for scalar multiplication.

1: http://en.wikipedia.org/wiki/Wedge_product

  my &infix:< · > = &infix:< × >;

If you need more control you can write it out

  sub infix:< · > (+@vals)
    is equiv(&[×])       # uses the same precedence level etc.
    is assoc<chaining>   # may not be necessary given previous line
  {
    [×] @vals            # reduction using infix operator
  }

---

I don't know enough about the topic to know how to properly write `∧`.

It looks like it may be useful to write it using multis.

  # I don't know what precedence level it is supposed to be
  proto infix:< ∧ > (|) is tighter(&[×]) {*}

  multi infix:< ∧ > (
    Numeric $l,
    Numeric $r,
  ) {
    $l × $r
  }

  multi infix:< ∧ > (
    Vector $l, # need to define this somewhere, or use List/Array
    Vector $r,
  ) {
    …
  }

  [[1,2,3],[4,5,6]] »×« [[10,20,30],[40,50,60]]
  # [[10,40,90],[160,250,360]]

  # generate a synthetic `»×«` operator, and give it an alias
  my &infix:< ∧ > = &infix:< »×« >;

  [[1,2,3],[4,5,6]] ∧ [[10,20,30],[40,50,60]]
  # [[10,40,90],[160,250,360]]

The use of greek letters in academic writing has a single purpose: Compact notation. It has nothing to do with abstract readability.

The compactness of the notation is a major factor in overall readability. Long variable names make it harder to see the overall structure of an expression. When operators, numerical constants and parentheses mostly are represented with one or two characters each but variable names are all much longer, then the only thing you can tell about a long line of code at first glance is what variables it uses as inputs. Mathematical pretty printing can help with some operators (eg. fractions) and make it more visually apparent what's being grouped together by parentheses, but even then long variable names will still detract from the ability recognize the structure of an expression.

I don't often write complicated formulae, but I do find it easier to use the original symbols if possible. Its one less thing to think about when comparing the source code with a mathematical description of the algorithm.

for some reason the entire Unicode "No" (Number, other) category is not included in the admissible character list for identifiers

Using these one letter variables forces the reader of the code to either be already familiar with the concept, which that letter refers to, or keep the whole calculation in their head, until the final result, to hope, that they then can make sense of it. It is implicitly requiring outside knowledge. It is shutting out many potential readers of the code.

It might still be saved/helped though, if good prose comments are given, that help the reader understand the meaning of the one letter symbols. Whenever I have seen this one letter code salad, I have seen few if any comments, as if the author of the code expects me to magically know, what each symbol stands for.

Lets say omega was a vector of weights. Why not name it "weights"? That is much better naming than "omega" or that character, that most cannot easily input and need to copy paste from somewhere.

When you're writing code for physics, then yes - absolutely: It is intended for other physicists, and the prerequisite is precisely that you have outside knowledge. When they use a symbol like ℏ in a journal article, it is expected that the reader knows it is Planck's constant[1]. Why should they have a different expectation when writing code? To a physicist, -ℏ^2/(2 * m) is a lot more recognizable than -planck^2/(2 * mass).

To be clear: The chances that a person who doesn't recognize these symbols will need to read and understand your code are virtually nil.

Within a context, single character symbols are very useful. To take a different example, what if I insisted that people should write:

2 add 3 add 7

instead of:

2 + 3 + 7

Would anyone reasonably argue that the former is more readable? We all accept that it's OK that a reader is familiar with the '+' sign. While ℏ is not readable to most, it is likely readable to anyone who is expected to read the code.

The thing that really is annoying when writing physics code is the need to explicitly write * for multiplication, and not being able to write fractions the way you would on paper.

[1] divided by 2π

For example, suppose we have a function whose job is to calculate two vectors of weights and do something unless they are equal but opposite. Personally, I would rather read something like

    v = someCalculation()
    w = someOtherCalculation()
    if (v ≠ -w) {
        doSomething()
    }

    weights1 = someCalculation()
    weights2 = someOtherCalculation()
    if (not(vector.equals(weights1, vector.negate(weights2)))) {
        doSomething()
    }

In general, I think there could be advantages to using a broader but still selective symbol set for coding, as long as we also had good tool and font support to type and display all of the required symbols. I would be hesitant about including Greek letters in that symbol set, but that’s because several letters in the Greek alphabet look similar to other common letters or symbols, not because I think calling a value ω_0 is a bad idea if that’s how practitioners in the field would all write it mathematically.

  G_{ab} = 8 \pi T_{ab}

  einstein_tensor[index1][index2] = 8 * PI * stress_energy_tensor[index1][index2]

That being said, formulae would benefit greatly from editors that allow the formula to be visualized next to the code. Sort of like compiling latex; if IntelliJ or some other IDE would actually render the code as a formula in some pane next to the code, that would be the greatest benefit to comprehension of a formula.

You can do that in a general function, where the general concept is expressed, where it would still help me to understand your code and search for concepts and terms online, in case I do not understand what is going on.

However, in many contexts it wont be merely an "einstein_tensor", but something that has a meaning in the specific context. Ask yourself what you are doing with that einstein_tensor. What is it used for? Is there a real-world equivalent to the thing you are looking at in the code? Those are the names you should choose in a non-general context and that is why naming things is hard.

Here is a more appropriate example, spot the bug in this Tolman-Oppenheimer-Volkoff equation:

    let radial_derivative_of_pressure = - (pressure + energy_density) * (4. * PI * pressure * radius_squared + mass_potential) / (radius_squared - 2. * mass_potential * radius)

    let dp_dr = - (p + rho) * (4. * PI * p * r2 + m) / (r2 - 2. * m * r);

Your questions are unhelpful. It is merely the radial derivative of pressure. It is going to be used to be passed to a general purpose ODE integrator which just needs the radial derivative of pressure to integrate pressure for some range of radii. There is a real world equivalent: dp/dr; it is a known entity with exactly that symbol. Naming is not at all hard in this case: dp_dr or dpdr even dp_by_dr. Any other choice and you are just creating problems due to uncritical application of the belief that variable names should be descriptive while ignoring the fact that there is a well known ubiquitous language to describe these entities.

The closest thing in other business domains is common acronyms. Nobody is going to spell out GDPR in the implementation of their cookie banner. Nobody spells out HTTP, or JSON, or XML. Spelling them out won't help anyone trying to read the code, it just creates line noise.

(_ < 5)

Instead of this:

(e: Int) => (e < 5)

It’s just a trivial example so I understand if someone wants to have the same comfort. I am not a mathematician so I am not sure what is best here so I’d cut them some slack.

Mathematicians are used to using one letter variables. Using a set of unwritten naming rules, mathematicians almost always know what concepts the variables are referring to (in a mathematical context).

So, I'd say if the code is only to be maintained by mathematicians, one letter variables for mathematical concepts only, would be an advantage.

The danger comes when you start using them for everything.

> Using a set of unwritten naming rules

Simplest being things like using upper case Greek for certain sets and lower case Greek for its elements. Or, in Statistics, using Greek letters for parameters and English equivalents for their estimates.

So, if I were programming something to do something in that realm, I would write:

    for my $ω ($Ω) {

      # ...
    
    }

Then, of course, you get people like one of my former professors who liked to invent notation on the fly and would quickly and up cycling through Greek (π, Π), Hebrew (פ), Blackboard (ℙ), and reach out for Sanskrit (?). (Symbols used here for illustration, this was a long time ago and we didn't even know if he was correct as we had no way of checking with no intarwebs back then.)

A typical program contains thousands and thousands of "named things", so you're naturally going to see a proliferation of names. That just doesn't seem to be that necessary in math once you're working in a particular context (e.g. statistics).

Currently learning some dsp. One of the biggest barriers to entry has been the inscrutable variable names inherited from the field’s math connections.

Artificial limits on language and characters sets might sound simple to you but it introduces a lot of complexity for others. Unicode code solves that problem with not too much overhead.

Also, just to point out, this assumption is exactly why diversity in tech matters so much.

We shouldn't dismiss this as "cultural imperialism". Instead we should use this to our advantage. Currently source code written in China or in Russia can be read by developers in India or in the US. This is amazing. Let's not forsake it!

Already, differences in menus and keyboard shortcuts make the skills of trained office workers less relevant when they immigrate.

We do not need more barriers to trade.

Some related thoughts:

https://www.nu42.com/2013/04/translation-of-programming-term...

and

https://www.nu42.com/2014/08/replacing-hash-keys-with-values...

The proponents of translation tend to believe what they themselves or other translators will be clear to people just learning the concepts. That is most often not true.

> I am willing to bet the sentence “Çözümü SCALAR bağlamda veri döndüren scalar() fonksiyonunu kullanmaktır” does not make any more sense to a Turkish speaker who speaks no English than “The solution is to use the scalar() function that will create SCALAR context for its parameter.”

> Translation and hash-lookup are different things. If you want to convey meaning, you have to have a command of both languages, and the subject matter. Without that, you are only going to add to the word soup. Translating “big event” as “büyük okazyon” helps no one.

The idea that we should all be grateful for the unification that using one language brings is a sentiment that reinforces the idea that this is cultural imperialism. There are definitely benefits to conformity, no doubt, but imposing it unnecessarily is a design decision that should be questioned. Why take away options from people who might value that freedom?

[0] - https://en.wikipedia.org/wiki/Keyboard_layout#Keyboard_layou...

[1] - https://en.wikipedia.org/wiki/Cultural_imperialism

I have seen multiple "foreign" keyboards. They all have ASCII labeled on each key. Using the QWERTY layout demonstrates the dominance of ASCII, which is a valid assumption that modern programming language can reliably rely on.

I don't really care whether you call this cultural imperialism or not. What matters is that a whole industry can use the same standard worldwide. It's the same as metric system. We already have to deal with imperial system, imagine how much more painful would it be if every country used its own measurement system or its one calendar.

Well, some keyboard layouts make it harder though. I have spent a considerable amount of time trying to teach programming constructs over Zoom to budding developers in Japan over the past two years. The placement, access mode, and actual typing of characters such as `{`, `$`, `~`, `|`, `:` etc has been the biggest stumbling block during these sessions.

So, there the subset of ASCII that is equally easy to type on all keyboards is smaller than the full range of non-control characters.

> But "everyone" doesn't have the same keyboard nor does everyone speak the same language.

I like that Vim's digraph feature lets me solve the problem in my editor without having to rely on the keyboard layout or OS level preferences. So, typing these lines:

    my $μ = "İstanbul'da hava çok güzelmiş";
    say uc($μ);

    m y CTRL-K m * = "CTRL-K \ I s t a

SI units like meters and kilograms are also cultural imperialism and we should return to diversity of units, ideally different one for each town. /s

And for what it's worth, I've never talked to a person who doesn't agree that the US using metric would be great, the problem is that getting over the inertia of the existing casual measurements is extremely difficult because even when metric is on the label, imperial is the emphasized one (the entire traffic sign infrastructure, the vast majority of cooking implements, decades of cookbooks, most food packaging, medical records systems, drivers licenses, advertising campaigns, the personal fitness ecosystem, entire product names and trademarks). 60 years ago maybe it could be doable, but at this point it's a bit of a lost cause without very much gain.

The nuances if the states could or should switch are irrelevant, but the response demonstrated the point perfectly.

I don't remember much about the article except it ended with some quip about the width of a car was determined by a couple of horses asses.

I am a monolingual English speaker but I think I should be able to write ÷, ≤ and ≥ in my Go code, and I think I should be able to do maths using π.

If compatibility is not as important to you, privately forking the language is also an option, but that seems fraught with peril of your code dying with you.

But the point is not my preference to use the actual, proper symbols, but rather the technically unnecessary decision forced upon me that says I cannot.

Just call it ISO 646-IRV instead. ;)

    say π ≤ 3+⅘ ≤ τ
    # True

    say π² ÷ 4
    # 2.4674011002723395

Wow, what a claim! I can see how this may have some anecdotal evidence behind it since programming has had such a strong English bias but it's conjecture to say that this is the only path. Not only does that claim lack evidence, it also lacks imagination. The future doesn't have to follow the same patterns of the past.

The technical constraints of ASCII have long been irrelevant and its only the cultural imposition that remains. While this has been the case the size and importance of computing has exploded everywhere (e.g. 4 billion people worldwide use the internet).

Can you really say with confidence that global "widespread engagement" is (and will always be) a desirable property for code projects? Is software produced in this way and at this global scale really likely to be better quality for everyone?

If your argument is "sure, then let them invent/fork $LANGUAGE to suit their needs", just take note that if you're a language designer/developer that wants to see the language widely adopted, it's detrimental to have the attitude that ASCII is enough for everybody. There's no reason to have (for example) "Arabic-python" just because somebody insists on ASCII instead of UTF-8 even though there's little technical reason not to support it.

There is a very visible pattern in most Open Source projects where a small group of core maintainers will do most of the work even if there is a much wider body of causal contributors (see Nadia Eghbal's _Working In Public_). So, what are the economies of scale? Are you perhaps referring to problems experienced in the by-gone age of the early internet?

Economists largely agree that healthy competition is beneficial for improving quality, spurring innovation and reducing costs. I don't see the problem with multiple language/culture specific software projects that all solve the same problem. This could even look like different programmers working on different projects for different audiences.

The only downside I can see for the everyday programmers is the FOMO generated from inaccessible software in a foreign language. Isn't that ironic?

Do you think that every pilot on earth always speaks only English? No.

People should have the choice not to speak English and write their alphabets if they wish.

Enforcing ASCII on code is like enforcing ASCII on URIs, e-mail addresses. Unnecessarily restrictive to the rest of the world outside of the anglosphere. Of which there's a lot.

ASCII is the standard, and programmers already learned to deal with it. What's the problem?

Sometimes identifiers and comments are transliterated into ASCII, sometimes they remain in the original script.

Of course, they won't get many contributions from English speakers. They will get more contributions from speakers of that language. That decision is for the project to make, not others to impose.

Will they?

Imagine a computer class teacher in (for example) China teaching primary school children. Why should they need to learn English before starting to write "Hello world!" (or rather, 「你好世界」)

In an alternate universe the lingua franca of programming languages is Chinese, would you still make the claim that it's better to take away choices and force ALL programmers into using the existing lingua franca regardless of their background?

I'm guessing you'd be crying cultural imperialism because you can't teach your 6 year old kid programming in your native language.

> If the source code is proprietary or for education then it doesn't matter

I'm not forcing you to speak and teach children in English. My country actually was under cultural imperialism and people back then weren't allowed to speak or learn in our native language. And you make it sound like a joke, but whatever.

My keyboard doesn't have a key for NUL, BEL, VT, EOT. What kind of keyboard do you have which has buttons for these?

People from US seems to have a strong fetishes with ASCII.

The US International keyboard has loads of other characters currently not used in programming languages either, whether it's the ¡¿, the ²³ powers, the euro character, guillemets («») or the negation character. If Apple would decide their next Swift project will use the characters only quickly accessible to Apple users, it'll be treated just like that, only accessible to Apple users.

With Apple shipping keyboards that have the £ character where the # character would otherwise be, I wouldn't be so sure if using all the available characters would blow over well.

With ligature support being in every major IDE there's very little reason to step away from the old comparison operators in my opinion.

What OSes make easy to type depends on where you live. It can be quite a challenge to write the Spanish ¿? style operators repeatedly, but there's no reason not to use, for example, ¿expression? instead of parentheses for "if" "switch" statements, or to use ¡expression! as a shorthand for "return". Format strings could just as easily have been written as «string» or „string”, but the characters on the American English keyboard were chosen because they were available on most layouts or out of pure laziness.

I personally prefer US International over Apple's layout. I rarely need to use the paragraph key in normal text processing, and the short shift makes for a very awkward typing experience for me. The vertical enter also just seems like a waste of space to me. I don't really see how Apple's keyboard input is that much better than Windows', their special character set seems just as arbitrary as the rest.

Adding more special characters found in US English only makes the situation worse for people on, for example, Italian keyboards or Polish keyboards, where despite writing in a language based on the Latin alphabet, characters with additional diacritics and such are part of the main layout and deserve separate keys. Cyrillic keyboards are just as bad, lacking most programming characters already because of the larger Cyrillic character set, although they'll have to cope with unaccessibily because of the character set difference anyway.

In my opinion, the amount of special characters used in a programming language should be reduced, not increased. Backticks are already impossible to find on some keyboards, bbut languages like Javascript have gone and used them for format strings anyway. Driving people to learn a special "programmer's" keyboard layout just because the required characters aren't on their native keyboard layouts isn't a good thing. We want more compatibility, not less.

That's not really an Apple thing so much as a non-US thing. The standard PC UK layout also has a £ in that position.

> I personally prefer US International over Apple's layout.

Which Apple layout? Apple has its own US English, International English and British English layouts, as well as myriad other languages.

I called this tool √𝚎𝚍, the rich Unicode text editing suite (RUTED, pronounced ˈruːtɪd) and I use it in vim: https://gitlab.com/ruted/ruted-vim.

I first defined so called modes of ASCII sequences representing Unicode symbols, like "forall" for "∀", and "NN" for "ℕ", and ";o" for "∘". Then I created a very small vim plugin to enable modes and change modes. When in a mode, you can enter the ASCII sequences, and they are replaced by their Unicode equivalent.

It is a bit of a simple hack, but it worked great over the past year. Entering symbols has become very easy for me now.

Anyway, it was fun to build and very useful the past year.

  Compose, T, M.

But it's still three keystrokes instead of one. I wouldn't really look forward to using × instead of *, ÷ instead of /, etc. all the time, even though I can type them here with relative ease the hassle increases the more you use it (I don't tend to bother with fancy “quotes” for example).

I also don't think it really matters all that much. What's wrong with *? Sure, × looks nicer, but * is clearly the pragmatic choice.*

In case of manually written math equations (or LaTeX-ones) operators are easy distinguishable from arguments. They have a different sizes too.

For example, "result = axe" and "result = a×e" in many cases looks the same and, even in my browser, with font larger, than ones usually used by my colleagues, they are very hard to distinguish. Difference between "result a÷n" and "result a-b" can be spot easier, but it depends on two one-pixel dots.

Ok that was only a mumbling of malcontent - in fact we all know that we all have a sharp, young eyes and we never will be tired or distracted, I'm pretty sure of that. ;)

But yeah, I read over the "axe" and "a×e" difference on my first read (and I browse HN at quite a large zoom by default, not because of vision issues, I just like larger text as a matter of personal preference).

Either way, I don't really see the significant advantages in the first place. In spite of the article and some of the strong words of some in this thread ("horrendous", "embarrassing", etc.), I don't see the problem is with just sticking to ASCII. The only case I've seen is where it would have been nice is when «T» was briefly considered for Go generics instead of <T> (later changed to [T]) to avoid overloading the existing meanings of <> and []. I actually would have liked that. But / vs ÷? shrug.

On my phone's keyboard typing the words registered or trademark bring up those options as completions.

Word and libre office have the menu under insert

I actually like the emacs version the best. One could even rig up a deal with emacs client to effectively use it outside of emacs by popping up a floating window then shoving the result into the clipboard.

Charmap must be showing you information from some sort of dictionary entry or similar, but that's not part of the identity or name of the Unicode character, any more than the name of the Unicode character U+0049 "I" is "first person singular pronoun" (it's actually named LATIN CAPITAL LETTER I); that's just what it happens to mean in one particular language.

Even when I enter "4F60" it does not show up. Seems some ranges are missing.

https://github.com/jeremija/unipicker

Can be run with --command="rofi -dmenu" to filter via rofi and piped to xdotool type to insert immediately

Anyway, a year or so ago i contributed it back to xkeyboard. On Linux you can find it in English (US) variants, Drix.

https://cgit.freedesktop.org/xkeyboard-config/tree/symbols/u...

The ™ symbol is AltGR+T. × is AltGR+x.

Was able to do a TM by holding shift and right alt, typing TM and letting go of shift and right alt. ™

Punctuation and vowels result in accents: Û Ü Ä Ö Ô Þ Ŷ Ô ⸘ ⸘ Æ «» ¿¡ ¨ ¯--_ ⋄

e.g. `\subseteq` followed by tab yields `⊆` or `\trademark` for `™`.

You can also do emoji with `\:eyes:` for ``

I think this is very practical and if you read code in Julia you can see that it's led to quite a lot of unicode and emoji in source code.

D is a fully Unicode language - comments can be Unicode, the builtin documentation generator can be Unicode, even Unicode characters in the identifier. I've been tempted to add Unicode characters for operators many times.

The trouble is the keyboard.

I've seen many ways to enter Unicode. I even invented a new way to do it for my text editor. All awkward and unsatisfactory. No way to touch type them, either.

What is needed is a dynamically remappable keyboard, with a configurable display on each keytop so you know which letter it is. Nobody is going to remember what the remapped letters are without it.

APL only really advances from lines of ASCII text to lines of Unicode text. It's still very line-oriented. If Unicode expands toward Tex/LaTeX/&c it could look a lot more like written math. Subscripts are nice, but there's more to it.

Unicode entry is so poorly supported on macOS & Windows it's really not funny. Emacs (C-x 8 ENTER) is my best bet, or Xah Lee's website &c.

If one were to design a new APL, one would be tempted to just use the few characters Apple lets you type with an Option or Command key. (and of course I can't easily type those symbols so I refer to them by six letters each—that's likely not going to change)

All APL needs though (EDIT: and really I mean any language, as long as we have common sequences), is leader key sequences. Rho is `r. To me, it always will be. The interface [1] has this down pat. We should be able to type anything in Unicode with just a few of the 104 keys. Like how T9 allows 12 buttons to type 26, &c.

The world is never going to build a 12,000-key Unicode keyboard. We're going to have to use leader sequences. Just my (beginner's) opinion.

[1] even tryapl.org/ !

Solutions:

a) only use characters in the intersection of the top N most popular keyboard layouts

b) issue programmers' keyboards with an agreed character set

c) issue programmers' keypads with supplementary characters

d) add on-screen supplementary keypads

When working with mathematical modeling it’s honestly just so refreshing and every other symbolic math solution in other languages feels decades behind.

But alas Mathematica is proprietary and expensive enough that it’s always a management decision if you want to use it, so I never use it any more.

Definitely should be able to put functions in the horizontal space, use colors as part of the syntax, use Unicode symbols where it is warranted.

I would go farther and say that we should have at least some ability to edit things in a non-serialized way, like a WYSIWYG math formula for example.

I hope people will also explore structural program editing. https://en.m.wikipedia.org/wiki/Structure_editor

Almost forgot, one more crazy idea: switch to larger instantly reconfigurable touchscreen keyboards to allow more symbols to be entered easily.

> Niklaus Wirth tried to undo some of the damage in Pascal, and the bickering over begin and end would no } take.

"1970 - Niklaus Wirth creates Pascal, a procedural language. Critics immediately denounce Pascal because it uses "x := x + y" syntax instead of the more familiar C-like "x = x + y". This criticism happens in spite of the fact that C has not yet been invented." http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

The irony here is that Python does have an open-scope delimiter. It is the colon. What it lacks is a close-scope delimiter. But you can hack one using the PASS statement and emacs auto-indent, and in my code I do this so that my Python code always auto-indents correctly. Without this you cannot reliably cut-and-paste Python code because you can't count on leading white space being correctly preserved.

Majority of developers are not from Greece; they don’t have the keys on their keyboard. Technically, modern C# supports Unicode just fine, here’s an example.

    using System;
    using System.Collections.Generic;
    using System.Linq;

    static class Program
    {
        static double Σ( this IEnumerable<double> elements ) =>
            elements.Sum();

        static void Main( string[] args )
        {
            double[] α = new double[ 3 ] { 1, 2, 3 };
            Console.WriteLine( α.Σ() );
        }
    }

Similar reason, because input becomes more complicated. You gonna need to either memorize hotkeys, or reach for the mouse. Also copy-pasting UX becomes way too complicated.

Because it must be possible to actually type syntax.

The problem is a physical one: keyboards are limited in space, we need alphabets, punctuation, a bunch of control keys, and finally we have a very small amount of space left to fit some arbitrary symbols - might as well be ASCII ones. The only way to truly break away from the ASCII table would be to start making giant non-standard keyboards... and now you have a huge inclusivity barrier, not to mention the impracticality of physically huge keyboards.

This all seems like a lot of effort and argument over something even more superficial than language syntax - they are only glyphs... how does using more and different glyphs substantially change anything?

>And, yes, me too: I wrote this in vi(1), which is why the article does not have all the fancy Unicode glyphs in the first place.

Maybe vi doesn't but as I said, I've used them in vim. Also, the title calls out terminals but I don't have any VTE software installed that doesn't have Unicode support.

How fast can I read "omega"? Pretty fast. How fast can I read an actual Greek letter omega? I don't read Greek, and my physics classes were decades ago. Yeah, I can figure out that it's an omega. It might take a bit, though...

I thought the article was fascinating and thought-provoking, I hope all the strongly-worded opinions aren't causing you to regret it.

I was also wondering whether tokenizer rules deserve some flak for making it harder to build identifiers and operators? Why is it more important (in C-like languages) for programmers to write without spaces, than to be able to call a variable ready? or define a +++ operator?

I mainly write this kind of stuff to make people think about what they would not otherwise have thought about, with the secondary goal getting at chuckle or two along the way.

This particular one have been discussed on HN previously and every time the "beause ASCII == keyboard" argument have come up.

...and been slapped down by people from the rest of the world, who have two or even three keystroke sequences to reach [\]{|} etc, because more important national characters, like æøåÆØÅ lives on the "usual" keys.

If I managed to get people to think about that, I've done my job.

As for C:

I think the C lanuage has been mismanaged, why did we need yet a threading API, while we still dont have explicit struct packing, including per struct or per field endianess specification ?

The ISO-C Group is incredibly conservative, which is plain wrong: A finite amount of C code have already been written, but there is a potentially infinite amount yet to be written. They should focus on the larger oeuvre.

Seriously, unicode is appallingly messy and heavy-weight. With all that code-point space to burn, a rational design would be very different to what we've got.

That said, given the origins of writing, I dont think there are any much cleaner solutions.

Their biggest mistake is probably not insisting on a mandatory vector representation which could be used to generate a "font-of-last-resort"

My personal pet-peeve is that unicode have not yet assigned 128 code points and two modifiers to cove all possible combinations of 7-segment LEDs :-)

I am not clever enough to comment on the meat of the article but I love that quote :-)

My favorite languages don't even have the _idea_ of operators and in languages with custom operators, with all their crazy ass rules about precedence and content-free representations, I'm always re-translating the code to s-expressions in my mind.

The Scheme way seems fine to me - operator-like functions when the meaning is universally understood and then human-readable names for literally everything else.

> Programmers are a picky bunch when it comes to syntax, and it is a sobering thought that one of the most rapidly adopted programming languages of all time, Perl, barely had one for the longest time. The funny thing is, what syntax designers are really fighting about is not so much the proper and best syntax for the expression of ideas in a machine-understandable programming language as it is the proper and most efficient use of the ASCII table real estate.

“But programs are still decisively vertical, to the point of being horizontally challenged. Why can't we pull minor scopes and subroutines out in that right-hand space and thus make them supportive to the understanding of the main body of code?”

Which made me wonder if there might be some way to make an editor do something along these lines, without changing the programming language. Similarly with his speculations about using color.

The key point here is chunking. Mentally you can process the + as a plus sign. It’s been single concept. It’s association with addition probably means the reader can make useful inferences about what it does.

Now consider the Greek letter ζ (zeta). For anyone unfamiliar with that it would be more than one chunk as you would probably try to remember the shape.

Worse, you may have no idea how to input it.

And to get any of this we’d have to deal with encodings. For what, exactly?

And sure, not everyone is familiar with the Latin script that dominates ASCII but you have to pick something and for better or for worse English is the lingua franca of programming.

And don’t even get me started on the insanity that is Unicode attempting to assign a code point to every symbol ever imagined and then extending that with compound code points and modifiers.

However, I don't think the issue is ASCII but rather consistency. I'm making a C-competetor language and using "c-like syntax" except I'm enforcing consistency. () is always one or more statements, with the last expression returning the value. {} is always representing concrete data like a struct, array or function args/result. []? That's a piece of a type name, allowing the developer to name something Foo[U32; Str]

fn foo: {a: U32, b: Str} -> U32 ( if a > 5 then b + "is greater then 5" else b + "lte 5" ) )

> Why keep trying to cram an expressive syntax into the straitjacket of the 95 glyphs of ASCII when Unicode has been the new black for most of the past decade?

Because I don't have 143,859 keys on my keyboard. Having to type λ would involve either changing my keyboard layout or using some key shortcut. In either case I'd miss the benefit of muscle memory to just type `func`.

I don't see ASCII as a hindrance, but as the lowest common denominator for being expressive in any language, computer or human (Romance ones at least).

> Why not make color part of the syntax? Why not tell the compiler about protected code regions by putting them on a framed light gray background? Or provide hints about likely and unlikely code paths with a green or red background tint?

Why should a compiler be concerned about how errors are displayed? You can already do these things with a program that reads the output and renders it as you wish. We could argue that the information should be available in a machine-readable format to avoid parsing text, but I don't see how a deeper integration of color would help.

The things that I would like to see in the next 20 years of programming are:

- Abandoning text files and filesystems as an abstraction. Most programming languages are fine with handling only "modules", so having to manage files and file paths just feels unnecessarily clunky.

Light Table[1] attempted something like this IIRC, where you only dealt with functions or modules directly, and it was a joy to use. Expanding this to a language would simplify things a lot.

- Speaking of which, code versioning systems should abandon that concept as well. It's 2021 and the state of the art is still diffing pieces of text and doing guesswork at best to try and complete an automatic merge.

Our versioning tools should be smarter, programming language aware and should minimize the amount of interaction they require. I can't imagine the amount of person-hours ~~wasted~~invested on trying to understand and make Git work.

- Maybe just a fantasy and slightly off-topic for this discussion, but I'd like to see more programmer-friendly operating systems. With the way Windows and macOS are going, Linux is becoming more like the last bastion for any general programming work. Using these systems often feels like the computer is controlling me rather than the reverse.

[1]: http://lighttable.com/

Perhaps the text with limited alphabet and fixed-width display is actually optimum both for programmers' mental workload and for computer processing? Why the urge to abandon it?

Many many people tried to "move on" but there's always some catch. I like DRAKON graphical programming editor but it makes diffing harder and merging changes from outside impossible.

Computer language needs to abstract time and space representation. Solving will improve human - computer interfacing problem. Connect two worlds with commonality, humans writing instructions is not that.

MOV command is the single source of truth. It does something with space and involves time. Start there and build upwards.

For entry I have symbols cut-and-pasted faster than most people type. Also the completion feature of the IDE works just fine.

Programming languages have to break free from the tyranny of ASCII - https://news.ycombinator.com/item?id=1850938 - Oct 2010 (116 comments)

Unless, of course, we want to buy the not too generously priced license

Either way, I doubt anyone can claim a copyright on ASCII.

Fun fact: the first commit in the Go repository is from 1972. In B.

https://github.com/golang/go/commit/7d7c6a97f8

Followed by a commit from 1974 to convert it to C, and 1988 to convert it to ANSI C:

https://github.com/golang/go/commit/0bb0b61d6a

https://github.com/golang/go/commit/0744ac9691

https://github.com/golang/go/commit/d82b11e4a4

Imagine if, to change the graph of your Facebook feed, you had to checkout myname.person, add "friend Bob { ... }", and then try to commit it. But far more complex graphs of objects, classes, ASTs of implementation, sure, ASCII is fine for that.

It's embarrassing is what it is. I'm not saying it's not hard to come up with something better, but it's been fifty fucking years now.

Your image computing system isn't better than text files, much like your online file storage system isn't better than emailing things to yourself.