Hacker News Reader

This! Exactly this! Honestly as a CS person I might be completely biased but, I often hear this quote around the office "The hardest part of software engineering is naming things". We spend a lot of time and effort to name things in a way that a non engineer would understand. I wish people in hard sciences would do the same. I often times understand the underlying concepts described by all these Greek letters and symbols but it gets lost in translation. That is why I love efforts like https://betterexplained.com/ where math is made concrete.

Part of this is because most mathematics is written for mathematicians, certainly not for non-engineers. Another hard part is that the concepts in mathematics are so abstract, and so unprecedented, that "reasonable" words that could be interpreted by non-technical people simply don't exist. This is even true in basic calculus. What is a reasonable name for "the function that describes the slope of another function at every point"? Keep in mind that you have to use that word over and over again for the next 1k pages of the thing you're writing, build up 50-100 other definitions recursively on top of it, and make sure it's relevant for all possible uses of the concept in the future of humanity, even uses that we today cannot possibly conceive.

You might reasonably say, "This is all the more reason to spend a lot of time thinking of a good name!" While everyone else actually doing math would say, "I need to get my work done, so let's just pick a name and get on with it." When math is done right, the concept in your head is concrete and ingrained enough that the particular word your using isn't that important.

That being said, having done math research and software engineering, mathematicians do spend about as much time as software engineers naming things. It's just easier for software engineers.

The main part is that math notation was optimized for (and by) people writing: On paper, without the aid of computers.

I'm not sure what you're talking about. The parent comment was not about math notation, but naming mathematical concepts.

The notation is the way you write the name of mathematical concepts.

You mean, with English words? You know, English was also optimized for being written on paper... Doesn't mean it's broken.

> Doesn't mean it's broken.

That is your opinion. I know quite a few people, both natives and otherwise, who'd heartily disagree with it. :)

I was a mathematician and physicist before I went into CS, and when you're doing all your writing on paper and chalkboards, you don't want to write 'code' at all.

To name something well you have to understand it, and maybe that is the hard part of naming.

Naming is the foundational root of languages. (opinion)

This interestingly gets into the common fantasy magic concept of names having power over something. (perhaps this is also a thing in past cultures?)

The idea of names as power comes from pre-unified Ancient Egypt in which (i may have gotten the kingdoms mixed) the upper kingdom's religious rituals included the use of secret and ceremonial names known to only an elite literate cabal. From there the religion developed to include aspects of secret names for anything and everything and religious texts indicated that people believed once they learned something's secret name they would be able to exert control over them.

In fact, most of the concepts one associates with 'magic' (sigils, astronomical connotations, power words) derive from the Ancient Egyptian religion. See Wallace Budge's "Egyptian Magic" for an excellent treatment on the subject. His book has tons of direct primary source examples that are very entertaining (people turning into crocodiles, priests trying to shape the outcome of wars by creating effigies, lots of fun stuff)

The games got it from "past cultures".

This is indeed correct.

Yeah, comment your code! Comment your maths, too!

Of course people comment math. What do you think the thousands of math books are for?

Math books = documentation

>east ones with a certain kind of systems background, have put a lot of work into designing abstract logical structures for human beings to use. They've learned a lot of rules about how to do this well.

This is very arrogant and wrong. The exact opposite is true. Mathematicians have worked hundreds of years and streamlined notations that can express complect things well.

You have to be kidding.

Mathematical and sheet music are both organically grown. They're like C++ for math and music, but with about fifty times more cruft. Our forebears just kept adding on to and expanding purely crap syntax because getting people to change the existing way they do things is nigh impossible. Going on to hail this as "refined" is beyond me.

EDIT: Sometimes, in maths, different disciplines have conflicting syntax. Rather than fixing this, we just resorted to overloading (see i vs. i in maths and physics). If any programmer encountered that kind of thing in a computer language they would describe it as clearly evil.

EDIT: For a funny take on musical notes, see: https://youtu.be/-3WuQxnA7Hg

Mathematics is organically grown but reinvented every few years or so. Look at a mathematics paper from 50 years ago. Look at one now. Look at one 100 years ago.

Mathematicians aren't dumb. There's some element of tradition (that's a small part of the reason why many mathematicians prefer chalkboards to whiteboards) but most of the reason we use the notation we use is because it's the best way anyone has ever found to express rigorous, technical, creative, abstract thought cleanly and efficiently. Mathematicians routinely do completely /new/ work which requires us to invent entirely new notation out of wholecloth on the spot. The techniques we use are suited to this need. When we find something that's better, we use it. There isn't anything better yet.

Sheet music is terrible until you try to design a better system.

It's easy to design a better toy system. It's very, very hard to design a non-toy system that encapsulates all of the information in a full orchestral score and makes it readable for players of all instruments.

Don't the different namespaces conflict with the idea of burdensome cruft?

Just as finding a complete and consistent set of axioms for all mathematics is impossible, a universal syntax without namespaces sounds inefficient.

This is dead on, IMHO. I mean, we joke about some language, company, or product being fetishistically backwards compatible, but we've got nothing on music, which is somehow backwards compatability obsessed, but also not actually backwards compatable, because note frequencies have slipped, and most people only know a tiny subset of the actual notation.

Math is even worse. It's syntax piled on top of syntax. It's actually evil.

> note frequencies have slipped

Surely you're not talking about modern tuning standards.

Old tuning frequencies varied: The actual frequencies of the notes weren't standardized for centuries.

I am a mathematics student working as a systems software engineer. I find mathematical notation excessively dense and tedious to interpret.

Given the expression:

{f ∈ [1..N ⟶ 1..N] : ∀ y ∈ 1..N : ∃ x ∈ 1..N : f[x]=y}

I can instantly read it in my head as:

The set of all f where f is a function mapping 1..N to 1..N such that for all Y in 1..N there exists an X in 1..N such that f[x] = y.

One might argue that the ability to express such a long definition in such a compact form is a benefit, but I don't think so. In this particular case the definition is so trivial that it's easy to understand what is being talked about. Anything more complicated than this quickly becomes tedious and boring. I would prefer that mathematicians simply used longer, more verbose, but more clear and explanatory names for quantities and concepts. Just my opinion, though.

I studied math and computer science at university. My personal experience was that if you wrote a long string with quantifiers in your vector spaces or analysis homework or whatever, the professor would ask you why you were acting like you were still in your 'Intro to Proofs and Logic' course and to please rewrite your homework in English. It was assumed that you could translate between quantifier predicate stuff and English, and that you should just therefore stick to English so your professor can actually read it. The CS faculty members were much more fond of writing stuff out in such formal terms like that (especially in the CS-oriented math classes like a general discrete math course, or an automata course) possibly because they thought the CS kids needed more practice with the notation.

My math profs emphasized juggling multiple layers of logical abstraction and omitting all unneeded explanations, while the CS guys wanted everything in excruciating detail and extremely formal language.

I graduated in 1989 with a math degree. For 24 years I didn't look at mathematical notation. Now in grad school for CS I'm seeing a lot of notation like you wrote. Some of it is coming back. But, it has become exceedingly difficult to remember a single Greek letter, embodying a concept, a page or so after it has been defined. The concepts are not especially difficult, but remembering symbols has become frustratingly so.

My current course is Programming Language Semantics. It's all relations, functions, states, predicates, induction, etc. Greek letters are used all over the place. The topic is interesting and I love implementing semantics in Prolog, but the mathematical notation is painful.

What's so hard about Greek letters? There's only 24 of them.

The problem is they are used as shorthand for complex ideas that the student is assumed to already know and be aware of. And don't forget upper and lowercase refer to different ideas, and if you are a physicist they will means entirely different things.

If mathematicians used longer notation then "the obscure symbol defined 5 pages back that I totally would remember if it was spelled out" would be more like 30 pages back. Brevity and standard notation are critical for understanding.

> Brevity and standard notation are critical for understanding.

Totally! That's why Perl has taken over the field of software engineering, vanquishing all who came before it.

And for the handful of people who find Perl hard to read and understand: choose another career because brevity and standard notation are critical for understanding, and Perl has that in more abundance than any other language. The problem, as it were, is you.

There's nothing standard about perl (parameter passing via lists, DIY OO, references in a scripting language, and there has to be more that I don't remember anymore - IMO these are the true reasons perl lost its popularity while ruby and python remain lively), nor is perl compact compared to other scripting languages. The parameter passing stuff especially made perl a verbose language.

> IMO these are the true reasons perl lost its popularity while ruby and python remain lively

As a perl cum python developer, no. It's that I had to spend time reverse engineering the code I wrote last week, because of the hundreds of obscure symbols I cleverly used to reduce thirty lines of clear code to five lines of compact code.

Python and Ruby both have to deal with references (though much more indirectly via the concept of mutable objects), as well as arguments coming in as parameter lists (and dicts).

So what in perl made it conductive to that kind of coding? I never worked with perl much but back then I got the impression perl being line-nose or whatever was more legend than reality. Perl's not a different paradigm like APL.

And by references I meant exactly that perl is not pass by reference, unlike just about any other scripting language. R is the only other popular one I can think of that's not. There's shell too but it doesn't count.

> So what in perl made it conductive to that kind of coding?

"Because I could"

More specifically, in very short programs, the shortcut values were actually valuable, and the mental overhead for interpreting them in short subroutines or programs was minimal. The problem is that programs don't stay static, and that single time-saving shortcut becomes two, then four, then eight, then...

Soon, it's an absolute mess.

Even once I realized the cost, I had to follow the coding conventions of those who had come before, at the cost of increasing the cognitive overhead even further. A self-reinforcing loop.

> not pass by reference, unlike just about any other scripting language

As Smaug says, Python is pass by value. The trick is that the value is always a reference to an object, or more specifically “pass-by-object-reference” (“Object references are passed by value.").

This causes a few subtle behavioral inconsistencies, such as the dreaded `def a(b=[]):` bug.

I'm way late to reply, but I never really understood what would qualify as pass by reference according to that logic :D you do have to pass a value eventually, it can't be references all the way

Python's not pass-by-reference either!

Verbose identifiers in program code are most useful near the top level, where the ideas they give a name to are very specific, while mathematical formulae often concern generalities, so verbose names are not always applicable (or at least not always helpful - even in code, identifiers that try to be too descriptive can make it hard to read, though people rarely err in this direction.)

One of the uses of the notation is to serve as a map for a more long-winded description, as you can lose your place in verbose explanations when they begin to get complicated.

More importantly, perhaps, is their use when you are applying formal manipulations to them. I think author's point is that many computer scientists apparently lack the background to follow or evaluate some of the important current developments in their field.

The notation and its meaning are both pretty clear, but I don't see how it converts to "the set of all permutations from 1 to N". And permutations of what? The integers 1 to N?

Permutations of the integers 1 to N, yes.

You can look at each permutation as a (unique, one-to-one and onto) function from the set [1,2,3,...N] to positions labeled also [1,2,3,...N]. For it to be a permutation, each position needs to contain a single value, and each value needs to be at one single location. Since the domain and range of the function have the same (finite) number of elements, either of these properties implies the other.

I guess that's why he talks about applications and not functions, so that guarantees there is a single x for each y.

I think he was just clarifying a point about the notation.

Given that each f is a function, mapping each member of its domain to one member of its range, and that for each member of the range, there is a member of the domain that the given function maps to it, and that the domain and range are the same size, then there can be no member of the domain not mapped to some member of the range, and each member of the domain must be mapped to a distinct member of the range (or else there would not be enough members of the domain to cover all the members of the range), so, with the domain and range being the same set, each of the given functions is a permutation of the domain, and collectively they must be all of them.

This is a verbose version of the argument for this being the set the author says it is. Arguably, it would be easier to read if I had used x for 'member of the domain', y for 'member of the range' and f for 'the given function'.

F(x)=y, s.t. x,y in [1,N]

There are so many ways to write the same idea in less symbols.

I don't really know what you just wrote, but it's not "F is a surjection", which is what the post is capturing. If you're not quantifying somehow, even implicitly, then you're just not giving the same definition.

It can be written with fewer symbols: `f: [N]->[N] s.t. x != y => f(x) != f(y)` is an equivalent formulation, for instance (since f from a finite set to itself is surjective iff it is bijective iff it is injective). The quantification is now implicit in the "implies" symbol. Not sure how standard `[n]` is to refer to {1,2,…,n}; it was used commonly in my undergrad courses.

What you wrote is very ambiguous

Math notation was optimized over hundreds of years to serve Latin-literate men with large working memories whose adversary was the pen and paper.

But what has it optimized for? I feel like it has optimized for writing, so it is very terse.

Programmers have moved away from single letter variable names to make things understandable, but mathematics, even in CS has not.

It conveys ideas well in the level you need to think about them. It's not accurate syntax in CS sense but it conveys ideas well from mind to mind.

I think many CS students have problem with mathematical notation because it can be both accurate and syntactically very sloppy and informal at the same time. It's human language and notation, it's not for computers.

There are bad notations in mathematics, and I think there may well be some truth in the idea that designing for usability is more important in CS.

Your comment is needlessly rude and you don't give any evidence to support your contention.

I was insulting his argument, not the person.

If his argument is offended, I apologize. I don't think it's possible.

> But computer scientists, at least ones with a certain kind of systems background, have put a lot of work into designing abstract logical structures for human beings to use. They've learned a lot of rules about how to do this well.

You say this like mathematicians haven't been doing this for thousands of years.

They didn't build their system for it to work with computers.

> designing abstract logical structures for human beings to use

Moreover, you do realize that computers were invented by mathematicians, right?

Of course, the alternative hypothesis is that they weren't lying and they did forget it. As someone who majored in math quite successfully within the last decade, I can honestly tell you I didn't remember what ":" meant and therefore had trouble parsing the expression. I don't think I forgot intentionally or was lying.

As someone currently majoring in mathamatics, I can honestly say this is the first time I have seen ":" used in this way. The "standard" way I would expect to see that would be for the first ":" to be replaced with a "|", and the second one to be replaced with a "," (or omitted entirely). The third ":" does not look out of place, although I would probably omit it, or right it as "st".

EDIT: for clarity, I would right the set as:

"{f : [1..N ⟶ 1..N] | ∀ y ∈ 1..N , ∃ x ∈ 1..N st f[x]=y}"

The ":" in this case indicates that f has the indicated type.

As long as I am commenting on my sense of "standard" notation, I should also note that the "[1..N ⟶ 1..N]" notation also seems weird (as in, I have never seen it before). I would expect it to be written as [1..N] ⟶ [1..N]. Perhaps replacing [1..N] with Z_n for the appropriate audience; however the speaker seems to be aware that this is a strange notation, as he commented about it in the beginning.

In this particular case, I would probably also omit the entire predicate in favor of writing "onto" above "⟶", which I can do because the particular property being described is common enough to have a name; however this would defeat the point of showing the notion. Once I have entirely omitted the predicate like this, I would probably omit naming f entirely, giving the notation {[1..N] ⟶ [1..N]} (again, with "onto" written above the arrow).

Actually, depending on audience, in this particular case I would replace the entire set with either "The symmetric group of order n", "The symmetric group S_n", or just "S_n".

The f[x] notation looks a bit weird out of context, but does come up when the distinction between a function and a function application is important (often times f(x) is used as a convention to remind the reader that f is a function)

Lamport wrote it the way he did because that's the TLA+ notation, and the talk was about TLA+. That formula is actually parsed by the TLA+ tools. Unlike paper math, TLA+ needs to have a precise grammar. I'm really not sure why `|` isn't used in set comprehensions, but I'm guessing that he wanted to keep `:` as "such that" everywhere. `f[x]` is used b/c round parentheses are reserved for operator arguments, and functions aren't operators (the whole thing is based on axiomatic set theory, and in formal math "function" must be something very specific).

This is hilarious to me. I have always found notation used outside of math hideous.

Compare any math notation to the notation used in operational semantics or proving things about type environments.

Compare any math notation to the logic notation used in philosophy.

Hideous, all hideous, I say!

> Compare any math notation to the logic notation used in philosophy.

Aren't they the same? I assume that by "logic notation used in philosophy" you mean the kind that's used by Carnap, Kripke, etc.

Logic in philosophy is used in a lot of fields of humanities and social sciences too. When you have inductions and deductions based on qualitative axioms what you write is going to take a lot of brainpower to understand. A lot of the academic work in those fields takes thousands of words to explain all the thinking behind something that could be broadly explained in a paragraph.

No, I don't think this is what eximius was talking about. I think the kind you're talking about does not use any symbolic notation.

Admittedly, my exposure was brief and I certainly don't know the notation by any name, but the logic courses used drastically different notation from what I was used to in my math classes. Some of the symbols were the same, sometimes they had the same meanings, sometimes not. Often there were different symbols entirely.

> they intentionally forgot it.

I'm not sure intentionally forgetting something is even possible, but, who would intentionally forget something foundational? Most computer scientists do study math and generally wish they knew more, not less.

Yes, agreed! You'd think most of the CS people in a room listening to a Lamport lecture, of all things, would've at some point in their education taken a theory of computation or similar course. The notation Lamport was asking about is already taught by page 7 of chapter 0 in Sipser [1].

[1. https://www.amazon.com/Introduction-Theory-Computation-Micha...]

As a mathematician/(ex?-)computer scientist whose area of research is category theory, let me ask: What makes category theory not seem like very good CS?

Apparently, the first thing is the difficulties it presents for typing. I think that is about all we need to know about this argument.

For what it's worth, it does bother me how much standard CS tooling and the mindset bred from it is stuck in the paradigm of exclusively textual user interfaces. Linear text has its advantages and value, of course, but, like, we know well by now that not everything is best thought of or manipulated this way; that diagrams and other modes of communication and interaction can be useful.

(This has nothing to do with why I'm interested in category theory [it's not that my motivating goal in life was to draw commutative diagrams…], but it's a somewhat relevant thought to the discussion I've had all the same. We as computer scientists talk a lot about trees, and graphs, and this structure, and that structure, and also about human computer interaction, and the importance of design, and yet the only structure we allow ourselves expression via at the end of the day is text, text, text.)

A lot of people draw informal sketches while thinking things through, and there have been waves of enthusiasm for formalizing such things, but except in a few specialized cases (e.g. state transition diagrams) nothing so far seems to have proved useful enough to really take off.

I do wonder sometimes if we are too focused on computer languages, to the detriment of tools (see also Animat's comment.)

God yes. Text and lack of imagination are the two curses of CS.