[return0]

I would be very hesitant to use this. It's not "more intuitive" as the author would like to think. In fact , our visual system has been trained to instantly recognize a!=b in code, and I read code a lot more often than Math formulas. Plus code is not math (e.g. 1+(a>0)), confusing = with == will lead to lots of errors etc.

If I get used to this font on my machine, i will have a real problem when parsing code in another terminal/editor. Unless all the programmers in the world decide to switch to it simultaneously, this introduces a mental translation that's counterproductive.

[al452]

I had every one of those concerns too. In spades. And then I actually tried using it for real, and none of the concerns turned out to cause any problem in practice.

(Why would I try using something I was confident would make me less productive? Because I felt was in a rut, and was trying out disruptive changes to my workflow. For example the same day, I switched all my calculator tools to RPN. That's not gone badly either.)

[zamalek]

What now causes a problem for me is working on code without ligatures, that's after only a few months of working with them. I also find Fira Code extremely legible as a dyslexic.

[coldtea]

>In fact , our visual system has been trained to instantly recognize a!=b in code

Citation needed.

>confusing = with == will lead to lots of errors etc

This is more about NOT confusing == with = -- and several similar characters than the opposite.

Sounds like you have thought of all kinds of arguments to not actually try it and see whether it's any good in practice -- which is how anything should be judged (unless it involves some huge risk). In other words, a priori rationalization.

>If I get used to this font on my machine, i will have a real problem when parsing code in another terminal/editor.

The above argument advices to forever stick to a lowest common denominator coding toolset, lest one has to ever try to work in other environment.

How about maximizing the performance one gets from their own, and most frequently used, environment, instead of "what-ifing" for foreign systems they might have to use 1/10 of the time or less?

Plus, having a tool at our disposal and getting used to it doesn't mean we can't also do without if needed. Especially if it's a small improvement, like the one proposed by the ligatures here, and not some totally different notion that we can't ever go back to how it was without it...

[carterehsmith]

The thing is, in general, if you are promoting some change, you need to show that it brings benefits.

So the onus is on promoter - to show benefits.

The onus is _not_ on everyone in the world to show whether the idea works or not.

[coldtea]

Promoters (or, to be more precise, creator) might really not care to prove anything. And I wouldn't trust their arguments either.

If the change is harmless enough to try, one can just see for themselves.

And for things that work for some people but not for others, some general proof doesn't make sense anyway.

Nobody came and proved me how vim can work better for my editing than Emacs. I tried both myself and found out. Several for tons of other things that I adopted or not.

[return0]

I admit that the >= and <= looked quite more readable, but i don't see how = and == wouldnt get more easily confused. Also i do spend a lot more than 1/10th of time in different environments.

I don't understand why ppl upvoted my comment. You should try it first and report back.

Also, http://www.pallier.org/papers/Chang.Reading.2015.pdf

[fineline]

If you give it a try, you may find your brain more adaptable than you think. Mine seems able to parse the same code in my editor (with this font) and in web-based repository viewers (with some other monospaced font) without problem.