One thing that bugs me about this symbolic fetishism is that it really is cargo culting to an almost literal degree.
First of all, mathematicians don't really care that much about notation and notation isn't very fixed. There are some broad conventions, but fashions change all the time within a relatively short time span (relative to the history of mathematics). It wasn't that long ago that "_|" instead of "!" was used for the factorial, and you can find 20th century texts that use that notation.
Second of all, most mathematicians really really do not care about notation that much. Notation isn't what makes mathematics, because it's dictated by fashions, whims, and very often, even by jokes. It's completely incidental, to the point that we did mathematics for thousands of years with very little expressions that we would recognise today as "notation".
If you're writing computer code, I say it makes more sense to follow the fashions of code than to try to squeeze them into the fashions of mathematics. Too often I see programmers trying to emulate the style but not the substance of mathematical writing, in an attempt to invoke the favour of the ghosts of Euler and Gauss (who, by the way, would not recognise much of the notation that we use today).
I think good notation is pretty important in mathematics. See for example the difference it makes in calculus. Good notation can make complicated things tractable.
Sure, I'm not saying it's not important at all. It's very helpful to be able to have some shorthand instead of using Latin abbreviations for everything like they did in the fifteenth century.
It's just that people that are relative outsiders to the mathematical community give it way more importance than mathematicians do. This is particularly true of computer people, I think, because compilers and interpreters are very rigid about the syntax that they accept. Computer people pass these expectations into mathematics and assume that mathematical writing has some strict, rigid syntax that if not religiously followed nothing makes sense.
Terry Tao has something to say about these "compiler errors":
Notation is created to encode information - the intent here. A silly example: replacing self with a snowman unicode. There is no reason to do so - but now when you look at a buffer, you will be able to see all instances of self instantly. Its about parsing semantics, not making things pretty (despite the package names).
The use of \mathbb{R} for floats acts to obscure things for me I'm afraid. It loads up dusty old stuff in my brain about the reals that is not true of floats from the slow tape archive storage in my skull, and _doesn't_ load up stuff in my brain about floats like, say, where the first integer gap occurs[1]. A side note is that \mathbb{Q} would be a closer match to float.
I think we should view them as what we are trying to represent, not what they really are. Besides, with the same logic int32 or int64 isn't really an integer in a sense that it can't represent 2^64.
It's still 'an integer'^, it's just that the set {i | i \in int64} is a proper subset of \mathbb{Z}; so using the latter to denote the former is inappropriate.
Hi, author here. Most of your points are addressable by two observations:
1. Context and readibility are user dependent.
2. Choices were made for semantic parsing first and correctness second.
The returns symbol was chosen as right arrow since I can set yield to left arrow.
I agree the def symbol can be jarring. But I have found it beneficial for nested functions and class methods - it takes up less space. I do note that some choices were 'aggressive', this being perhaps the most aggressive.
The times one writes set() vs None influenced the choice. The semantics are close enough.
The blackboards were again chosen for parsing semantics, not correctness. Unicode symbols stand out and take less space. I do agree on the dissonance and have since standardized use of blackboard/script/etc..
The mypy changes have benefited me immensely, it's so verbose otherwise.
Readability is to the eye of the beholder, where this approach excels since customization is dead-simple and the changes are entirely visual.
If one values an exact correspondence to mathematics, then just configure the symbols in that way. The post is indeed hyperbolic to illustrate the choices availible.
I do admit that being liberal with the notation makes cross-language configuration challenging. For other languages I only use the basic, correct symbols.
"In mathematics, the word null (from German: null meaning "zero", which is from Latin: nullus meaning "none")[1] means of or related to having zero members in a set or a value of zero. Sometimes the symbol ∅ is used to distinguish "null" from 0."
I guess symbols only exist in a context, anyway, right? They aren't immutable beings with a true meaning.
Prettifying an Emacs buffer does not change the text written to a file, so the user can also have a context for himself independent of whether he is collaborating with someone else or not.
I agree with you. Specially because ∅ looks a lot like crossed 0, depending on your font.
My point is that symbols only have meaning for those who see them. With Emacs pretty-mode, symbols are substituted visually and not ever saved to file.
It doesn't have to be exactly mathematically correct to improve readability. Most of your points are basically "it doesn't look right to me", which is fine, you probably shouldn't use this, but that doesn't mean it isn't useful to other people.
>Don't be fooled. Just because you can make your editor look kinda-sorta like math, doesn't mean it actually is math.
So what? Doesn't make it wrong... this is just window dressing, which can be very helpful sometimes.
> Most of your points are basically "it doesn't look right to me"
The objection was "the mathematical symbols are not being used correctly", not "it doesn't look right to me". Which makes a big difference if the point of putting math symbols into your code is to make it read like an equation , as the author is attempting to do.
Besides, python list comprehension isn't that far from the mathematical version. Compare:
{ x^2 : x in Z, x^2 > 10 }
with
[ x^2 for x in Z if x^2 > 10 ]
The main problem is that you can't have a list of all positive integers, so you're kind of forced to make it a generator instead. And the standard set notation clashes a bit with the notation of dictionaries, but on the whole it's not that bad.
I think it looks great. Elegant and concise. Programming was never mathematics, anyway. That hasn't stopped the butchering of notation ("=" for assignment, functions with side effects), why is everyone suddenly a mathematical purist, now?
Nothing wrong as personal shorthand - but the multiplier effect of understandable notation should not be underestimated.
Non-conventional notation strips away the benefit of shorthand notation in collaborative environment - nobody actually can tell what the meaning is just by looking at it without learning it first. If applied generally to software development, using an exotic notation just because it looks nice is risky and of questionable value. New notation is always a huge burden and should be taken into use only if there is some actual benefit other than aesthetics.
Unless I'm missing something, this is just an emacs style, equivalent to a syntax coloring theme. Collaborative environments have nothing to do with it - it will be checked into SCM in the normal way, and the guy running this emacs plugin is the only person who will see the symbols.
This looks nice but, as others have pointed out, it's mostly wrong to a mathematician. Yes, programming languages are already wrong (assignment should be <-, equality should be =, functions should be called subroutines etc.), but at least they're mostly all wrong in the same ways.
The main problem I have with it is I want to edit the text, not some pretty rendering. I use some display rendering in emacs, in org-mode to be specific, but none at all in programming modes, even in Lisp where one doesn't need to edit S-expressions directly. I guess I've been bitten by software where the display doesn't equal the underlying data too many times.
Note that if you use a variable width font (and so you don't care much if >= has different width than ≥ ) you can simply use font-lock-add-keywords and map what you need. For example in JS you could use
As strange as it may sound, yes. It took some time to get used to it, but now I find the code easier to read.
There are a number instances where the missing vertical alignment is a drawback, for example ASCII art, boxed comments or comments on the right of the code, but since I don't make use of them it is not an issue for me.
I'm not sure I could ever write code in a non-fixed-width font. Maybe if I wrote every line perfectly and never had to navigate back a few lines to make adjustments. But then again, I spend a non-trivial amount of time lining code/variables up and making things just right before moving on that a variable-width font would probabky drive my OCD (Obsessive Code Disorder) levels up to 11.
I don't even want to see what happens when you mark a region and call M-x align in a variable width font.
Better idea: since Python accepts UTF-8 input, let me actually enter the Greek letter lambda in place of the word "lambda". On a Mac it's close to trivially easy to switch between Greek and English keyboard layouts.
I find this an interesting diversion back down the path of cweb. Specifically to introduce some more notations for things such as Null, and the boolean operations.
* "returns" being |--> is awkward and out-of-line with the meaning of that symbol. |--> is usually read as a transitive verb "maps to".
* Using the calligraphic F for "def" is extremely weird and unhelpful.
* Having None be the empty set symbol, which is not set(), is strange.
* Blackboard bold F for False is weird, usually that means a finite field.
* Blackboard bold S for string?
* The dissonance between what the blackboard bold characters mean is jarring. Sometimes it's a type, somethings it's a particular object.
* Whatever the notation is for list and dict types (fraktur) is extremely non-standard and overly frilly.
The Greek/AND/OR/comparisons/not-equal/etc stuff is pretty OK. It's actually truly in-line with their meaning in math.
I am only saying this because the author points out at the end in a serious fashion that it's a useful thing to do for readability.
Don't be fooled. Just because you can make your editor look kinda-sorta like math, doesn't mean it actually is math.