Comment by BlackFingolfin

5 years ago

In my experience, any sufficiently deep study of any subject requires introduction of at least some degree of specialized terminology ("jargon") to be able to express things precisely and concisely. Sure, you can try to avoid this and use just "generic" language, but you almost always have to sacrifice one or both of these, at least partially. That can very well be worth it in certain cases (e.g. in an introductory text). But the site being discussed here is a list of specific (counter)examples. It would seem counterproductive to me to "dumb it down" given that it's primary purpose seems to be to discuss very specific situations; indeed, one common feature among many of these examples are subtle differences in what things mean in different parts of a language specification -- i.e., one of the reasons why domain experts invariably start using jargon.

That said, of course jargon often is als abused, or used in cases it doesn't have to be, etc. -- that's s bad! And many papers and books suffer from this and would be improved by using less jargon.

But in general I find this negative stance against formal notation, and the expectation that one should be able to dive into subtle and advanced examples without a need of at least some "studying" (not at all necessarily at a university!) quite odd, and unrealistic.

My main question here is: why is conciseness a good thing? Precision is a must, no argument here, but conciseness, to me, seems like a premature, and harmful, optimization. Is it really that much harder to stay within standard ASCII(EDIT: I mean "stay within the characters that the reader already knows how to read", which on the second thought doesn't have to be ASCII at all...)? Do you really need to express concepts with a single strange character? What does it buy you, given that the downsides for readability are quite obvious? There are arguments that using a full word for something would be confusing due to other/overloaded meanings of the word, but then I go read some papers and I see the same ideograms used in drastically different meanings, too.

Jargon is ok. Jargon is what happens when you want to be precise while re-using brain machinery for reading. The exotic notations are, on the other hand, just jargon put in a form which you have to (re)learn how to read, for the sake of conciseness alone. That conciseness may pay off if you're going to be working with the notation 8h/day for 10 years (or a year, or maybe even half a year), but if you just want to read and understand concepts and learn facts... To paraphrase: you wanted a banana, but what you got was gorilla holding the banana and the whole jungle along with it.

Hence my question: isn't creating exotic, one-character == 2.5 concepts, notations simply optimization which is harmful to the vast majority of potential readers?

  • > My main question here is: why is conciseness a good thing?

    Going through a single line of text to understand a concept is much better than having to go through two or more. I believe you should understand that, if your definition of conciseness matches mine.

    As a programmer, you know first hand that repeating oneself is bad practice: it's better to define a function which will encapsulate this computation you need to repeat rather than using copy and paste. The same goes for any language: having vocabulary to embody reccuring ideas helps us discuss complex ideas more easily.

    > Do you really need to express concepts with a single strange character?

    It is only strange to you because you don't speak greek. Of course many don't: my pedantic point is that Greeks might disagree with you about these characters being strange, and less pedantically, the scientific community will argue that it's not that strange when you belong to their group. There are only a handful of them to remember in the context of type theory.

    I guess you would want these characters, like Gamma (Γ), Delta (Δ), tau (τ) or sigma (σ) to be replaced by their ascii equivalent (eg. G, D, t, s), or perhaps even more evocative names? But even if this would be done, you'd still have to understand the underlying concepts they represent, such as the typechecking context which is usually represented by Gamma.

    These concepts are indeed not easy to understand: you would have to learn to become a Gorilla in order to be able to hold that banana you languish for, or survive in the Jungle that surrounds it.

    One good thing about using a different character set is that they stand out. There's little chance to confuse them with words of vernacular English. Greek mathematicians actually might have a harder time with these notations than you do :)

    • > As a programmer, you know first hand that repeating oneself is bad practice

      Yes, but we're talking about the syntax/notation here, not the underlying concepts. I see it like this: imagine a function which has a single argument, in a dynamic language so that we have no type annotation. Let's say I named the argument "pair_of_ints". Following your logic, I should have named it "i2" instead, because then I wouldn't have to repeat myself by writing all the p,a,r,o,f,n,t,s characters all over the function!

      Another way of saying this: yes, it's good to encapsulate pieces of logic in subroutines/functions/methods/etc. It's not good, however, to name the functions (let's add: in global scope) f, g, h, f2, f3, gh, etc. just to avoid typing more characters. Instead, we choose a name which can be understood with as little additional context as possible.

      > having vocabulary to embody reccuring ideas helps us discuss complex ideas more easily.

      Yes. My problem is when all the entries in the vocabulary are one (Unicode) character long.

      > I guess you would want these characters, like Gamma (Γ), Delta (Δ), tau (τ) or sigma (σ) to be replaced by their ascii equivalent (eg. G, D, t, s), or perhaps even more evocative names?

      The latter, preferably. If something is meant to denote a context, I see little reason to name it "Γ" instead of, I don't know, "context"?

      > But even if this would be done, you'd still have to understand the underlying concepts they represent, such as the typechecking context which is usually represented by Gamma.

      Yes, but then I wouldn't need to work to understand the syntax, making the process of understanding the concepts easier.

      3 replies →

  • This is about programming, but the "theory" part of type theory is an area of mathematics. Mathematics has always operated this way, going back to + and -.

    You could make a case that, in order to be of value to (most ordinary) programmers, type theory needs to present their results in programmer-speak, not in math-speak. But then programmers ask questions like "why is that true", and the answer is the proof which, being a mathematical proof, is in math-speak.

    • > Mathematics has always operated this way, going back to + and -.

      Wikipedia says[1] the earliest use of characters resembling + and - was in 14th century. From what I remember, math books were light on special notation until (at least) 18th century, and another poster here says it could be even newer (beginning of 20th century).

      > and the answer is the proof which, being a mathematical proof, is in math-speak.

      There are many, many proofs in Euclid's elements, and the only unusual (ie. not in plain natural language) notation used there (from what I remember and after a cursory glance now) is using clusters of capital letters to denote line segments.

      Proofs are just logic, and logic was used for millenia (I think?) before someone decided that `∧` is better than "and" and we should all use it.

      What I'm trying to say is that the "math-speak" is (or should be?) defined by what you're talking about, not in what syntax. And if this is true, then using more familiar syntax would be better for lowering the barrier to entry.

      On the other hand, as Twisol notes, the modern terse syntax probably has its merits for experts. I'm a casual user - I won't be writing papers or checking their correctness - so I get all the bad (unfamiliar, strange symbols, context dependent syntax) without any good parts. :(

      [1] https://en.wikipedia.org/wiki/Plus_and_minus_signs

  • > Is it really that much harder to stay within standard ASCII?

    Sorry, I don't follow. What is ASCII? Can you please avoid using computer jargon in your text, it makes my head hurt and it's an unnecessary barrier to entry. Can you please write instead "7-bit encoding of text characters"?

    :)

    • No, that's jargon - and I explicitly said it's ok. You can read the word just fine, and you can also easily search for its meaning. Compare with this:

      > ...that much harder to stay ∋⌞0x21,0x7D⌝

      It may be just me, but I think there's a huge difference between the two, even though both are equally made-up.

      2 replies →

  • > Do you really need to express concepts with a single strange character? What does it buy you, given that the downsides for readability are quite obvious?

    As someone who dabbles in the field, I'll bite. I find that more succinct expressions make their structure more apparent than less succinct expressions. This is critical for identifying (and then demonstrating) the general principles underlying any particular example, which is a great deal of what we do in theoretical research. (It's usually better to describe a whole family of solutions than to describe a single solution; and failing that, to indicate some directions potentially leading to general principles.)

    What do I mean by structure? This is a bit of a dodge, but structure is what you get when you remove all the data, all the aspects that pin an expression to a specific scenario instead of a general pattern. If you can recognize and memorize the pattern, you can apply it to a much broader class of examples than the one you learned it from. Concise notation is one tool for downplaying the concrete data and calling out the common aspects more deliberately.

    As other posters have said, this can be abused. I'd even say it's a very rare paper that uses concise notation appropriately to its fullest extent as an aid to the reader. But the concision does serve an important purpose to experts in the field (who need rather less aid): it makes the newly contributed patterns more visible (and uses existing patterns to effectively de-emphasize parts).

    > but if you just want to read and understand concepts and learn facts...

    Most research papers do not have as a goal for a technical reader to understand concepts and learn facts. (There are certainly visible exceptions, see just about anything written by Simon Peyton Jones.) Research papers are evidence of progress at the forefront of human knowledge; they're shared amongst an expert community to help drive that whole community forward.

    We absolutely need more effort to distill research and collect it into a more cohesive picture. Unfortunately, that responsibility does not (and probably cannot, in the current system) fall on the original researchers themselves. There are a few organized efforts out there for some fields; the one I know of is Distill.pub, for machine learning: https://distill.pub/about/

    >> When we rush papers out the door to meet conference deadlines, something suffers — often it is the readability and clarity of our communication. This can add severe drag to the entire community as our readers struggle to understand our ideas. We think this "research debt" can be avoided.

    But I don't think the concision of notation is at fault. It's just the most obvious roadblock to a (relatively) lay reader. The truth is simply that the paper wasn't written with you in mind.