Comment by WarmWash
9 hours ago
Math has some of the most insanely dense and impenetrable nomenclature. I can generally keep my head mostly above water or at least near the surface reading from most STEM fields, perhaps leaning on google/wikipedia a bit, but man, mathematics just so quickly decouples from all common tractable understanding it's insane.
Sorry it's a bit of an aside, but I imagine many other otherwise "technical" folks feel the same unfamiliar sense of total loss like when encountering hard mathematics.
This is also true for almost every other field, even within computer science. The only difference is that a lot of people operate at a very surface level without realizing just how much background knowledge they have accumulated. Think about the number of keywords your average SWE is expected to know. It is rather insane.
Cache, stack, heap, process, thread, socket, file, tcp, http, tls, websocks, socks, soc2???, deadlock, stack, queue, race, atomic, event loop, coroutine, async, database, transaction, index, replication, sharding, consistency, serialization, DNS, load balancer, container, namespace, and so on.
Every sub fields (web/kernel/backend/etc.) has a million/bazillion weird words used in a dozen different contexts and if you read a paragraph of even semi technical software text you will feel like an over stuffed turkey.
Even cache could mean the CPU caches, the page cache, a browser cache, a CDN cache, a Redis cache, or imagine the flurry of words we have that have real world meaning. Session, handle, pool, buffer, stream, channel, event, task, worker, or queue. Generally there is some overlapping meaning but often there isn't.
>https://en.wikipedia.org/wiki/Transmission_Control_Protocol
compare to
>https://en.wikipedia.org/wiki/Rees_algebra
Most people, especially non-tech technical people, could crash through the TCP article and come out the other side with at least a high level understanding of it.
Most people, even technical ones, could not even get through the first line of the rees article, heck the first statement of the article. And then if they try, they need to know about algebraic rings. And digging into rings becomes totally intractable. None of the words or symbols in any of the articles track to anything even many technical people can grab onto. And this pattern is all over the place in mathematics.
It's not about mastering the difficulty of a topic or it's relative depth, it's about how abstract and removed from anything tangible it is. Anything with math it is always seemingly impossible to get a foothold on the idea anywhere within 10 degrees of explanation. Hell you cannot even clearly understand the problem that is being solved, or anything within 10 degrees of that.
Definitely agreed. I have a bachelor's in math and took an abstract algebra course as part of it. I also took a couple computer science courses in college and work as a data engineer. My only real exposure to networking is from an AWS cert I did years ago.
I can tease apart the Rees Algebra article one bit of half remembered terminology at a time and come out of it feeling like I just barely understand what the topic even is.
I can read the TCP article and feel like I have a thorough overview of the topic and could explain it at a high level to someone else.
This is perhaps more a comment on Wikipedia's coverage of mathematics. They have some general guidelines in their manual of style, but it's really hard to write math articles in a way such that something like the Rees algebra without defining 1000 thinks beforehand.
To understand the definition of the Rees algebra, you would need to define, mostly in order: sets, groups, abelian groups, rings, ideals of rings, algebras over rings, direct sums of rings, adjoining things to rings, etc.
This is just to understand the definition; to understand its significance in algebraic geometry (which I have no idea of), there are a thousand more definitions.
The issue with trying to understand a concept in math is there is a massive directed acyclic graph of prerequisites leading to these concepts, and one needs to traverse this graph in the right order. Unfortunately, knowing the right order is almost tantamount to understanding the concept itself.
> Most people, especially non-tech technical people, could crash through the TCP article and come out the other side with at least a high level understanding of it.
Careful, I think you might be committing an https://xkcd.com/2501/ error.
What even is a protocol? What is a host? What is a ‘stream of octets’? Wiki helpfully tells you octets are also known as ‘bytes’.
5 replies →
"The Rees algebra is an algebra over Z[t^−1]"
Such a small sentence and yet it means very little to me. I understand some constituent pieces, but I don't understand what Z is here other than a 'ring' and I don't really grasp how t^-1 converts this into a generalized family of algebra. It would take me a lot of effort to understand this and use it practically. I find that fascinating because it really is such a small statement that seems perfectly cromulent, but there's a lot packed in there that someone like me is totally missing.
I suppose there may be similar concepts in computer science, but nothing comes to mind that ever stumped me. To be frank, the field has been relatively accessible to me because it hasn't been too challenging. Not sure if that's a personal aptitude thing or it is genuinely simpler.
14 replies →
You are comparing TCP a relatively basic topic in the grand scheme of computing with Rees_algebra which is fairly specialized, we could take a simpler topic more foundational and clearer to understand and compare them.
I can understand that this feels like one is so much more complicated part of it is also how the articles were written, wikipedia is not known for quality maths explanations.
But beyond that this comparison to me feels unfair.
Let's take Euclidean algorithm or just modular arthimetic for example what a lot of computing even is based on I feel like that's a fairer comparison. No?
Perhaps that's too easy but I just find this specific comparison very unfair to both Math's intuitive-ness and Computing's complexity. Perhaps I am the one being delusional.
5 replies →
No, the problem with mathematics is that it is basically its own language separate from your native tongue. You have to learn dozens of symbols and greek letters and such and memorize what their meaning is in the context of mathematics in order to "follow" a mathematical conversation.
Mathematics would be much more approachable if it just used plain English like `sum(0, Infinity, my_func)` instead of a big Greek sigma with nested function nomenclature. But on the flip side, mathematics being its own language means that a mathematician from any country can read and understand mathematics from a different country without needing to translate words such as "sum" and "infinity"
Mathematics would be much more approachable if it just used plain English like `sum(0, Infinity, my_func)` instead of a big Greek sigma with nested function nomenclature
First of all, no, mathematics would be far less approachable if it did that. Most of the Greek letters used in mathematics don't have a universal meaning, they're context-specific and defined by convention or just prior to use.
Second of all, mathematics is optimized for hand calculation on paper, not long-term programming and code maintenance. Writing out long names over and over on a whiteboard gets tiring extremely quickly, so mathematicians prefer to stick to single-letter symbols.
1 reply →
Your translation only makes intuitive sense to you because you are well versed in programming.
I suspect if I showed a non-technical person with no background in either math or programming they would think both are nonsense until you explained it to them
6 replies →
Capital sigma doesn't always mean sum and certainly lowercase sigma never means sum.
If mathematics used plain language, the ability to meaningfully manipulate and understand would go way down. Proofs would become massively tedius.
Of course, notation is hard. Any good mathematician should put a lot of work into it.
None of what you listed is even 1% as intense as the mathematics in the link.
Learning anything in maths requires weeks of hard effort, learning enough to be broadly comfortable in how an 8086 CPU works can be done in a weekend.
"tcp" can take roughly 3-4 weeks of heads-down dedicated study to have some reasonable familiarity with. Same is true with most of the other concepts. Being able to speak with expertise on that list of topics is 3-4 years of really focused study and work.
I think what happens is that people often have passing familiarity with a word or topic and presume knowledge, and years (decades) later they realize they knew almost nothing.
I will say that Mathematics is different (for me at least) because unlike the infrastructure computing concepts (IETF type, not IEEE)- which mostly require studying, lab work, and some coding to get your hands dirty - advanced math is just ... really hard. There are IQ issues at play.
Obviously a lot of computing turns out to be mathematics - so there is clearly convergence/overlap as well...
5 replies →
I second this and would add that it's really easy to catastrophically forget things in math. I'm pretty sure that most CS knowledge I have I will retain at a level where I won't forget the general ideas and re-reading materials can quickly refresh the details. This is not true for advanced math. I did a pure math PhD and my own thesis is impenetrable to me 20 years later. It would take months, if not years, of focused effort for me to regain the understanding.
I think one of the key differences is that math is abstract whereas CS is relatively concrete.
CS examples are often easy to picture and understand the motivation for. You can use tools to visualize or play around with them and test them.
Math gets abstract so fast you have to spend a week of research to even understand the problem statement. The the motivations themselves can be completely unclear until you have a lot of context.
I majored in math (B.S.) and upper level math is completely foreign to me.
1 reply →
As a counterpoint, i've worked with enough math PhD's over my career who couldn't wrap their head intuitively around many concepts from software engineering, while others had no problems in doing so even from folks without any stem background. We often undererstimate how much field knowledge we aquire over the years and overestimate how easy it is for others to catch up.
Again, you are underestimating how much effort it takes to understand how an 8086 CPU works. There are a lot of foundational concepts that you are simply assuming the person already understands. That may be a reasonable assumption for a CS undergraduate, but the average person does not understand binary arithmetic, registers, memory addressing, instruction execution, calling conventions, or even what a CPU is doing at a meaningful level to even start to understand 8086.
Also, understanding an 8086 CPU is not even remotely comparable to the level of mathematics Terence Tao was discussing above. The 8086 is a relatively basic and concrete topic. You can build a workable mental model of it from a finite instruction set, a handful of registers, and a reasonably straightforward memory model.
From my perspective folks here on HN and in CS often think they should somehow be able to understand advanced mathematics papers at a glance, merely because they are good at basics of programming or computer science (8086). That is not how it works. Most mathematics is not inherently much harder than computer science; both fields require you to accumulate a large amount of foundational knowledge before advanced material becomes comprehensible.
There is an enormous amount of computer science that most programmers are completely unfamiliar with, especially within academic CS: programming-language theory, type theory, formal semantics, compiler theory, algorithmic research, complexity theory, distributed computing theory, verification, cryptography, computational geometry, numerical methods, and so on. Being proficient in one narrow area does not automatically give you the prerequisites for another.
A web developer would not be expected to casually understand a research paper on type theory or approximation algorithms without first learning the relevant notation, terminology, and foundational results. Mathematics is no different. The feeling that mathematical writing is uniquely impenetrable mostly comes from encountering it without the years of accumulated context that mathematicians have silently built-up.
I can show you a paper about an advanced algorithms or chip design, that is large made up of fundamental cs concepts and general physics and even you likely someone with pretty in-depth understanding of CS would find hard. There are orthogonal subjects, for instance my mathematician friends things I am insane reading so much about weird computing topics, and I find his research in some weird number theory thing completely mind-bending.
Try and explain to a lay friend how registers & isa works in-depth with all the details not a hypothetical higher level model so that they can understand the nuance of looking at assembly, limit it to 8086 perhaps, it will take significantly longer than a weekend.
Ofc Terence Tao and his level of intelligence is beyond me, I wouldn't compare but general advanced mathematics is not something folks here couldn't pick up if they actually tried to work on it, just give it a shot (though I would recommend don't start with advanced topics build up slowly I think most people can understand most maths papers even the bleeding edge ones within a few months of serious self-study, and won't even feel that it's after a few years, compare that to the time spent learning software and computing 6-8 hours a days for several years)...
3 replies →
I was amused and irritated in equal measure when a senior manager at $LAST_JOB demanded that documents include "no jargon", then went on to use many terms like those you've listed here with no indication of awareness of the contradiction.
Just like the famous observation that "anyone driving slower than me is an idiot, and anyone driving faster than me is a maniac" - "jargon" is just any term-of-art that you're not currently familiar with. Attempting to communicate like Up Goer Five is inefficient. The solution is not to ban jargon - it's to:
* Cultivate a glossary for any terms that were introduced _within_ the domain/company, which are not in common usage outside
* Normalize a culture that does not shame asking what something means
> I was amused and irritated in equal measure when a senior manager at $LAST_JOB demanded that documents include "no jargon", then went on to use many terms like those you've listed here with no indication of awareness of the contradiction.
"No jargon" is alwys in reference to some assumed knowledge model.
For example, when I claim that my own math texts include "no jargon", this assumes the knowledge of a person who has studied, say, mathematics, physics or computer science.
Computer science is not a great example for this. I could ELI5 most of the terms you listed (and I actually have done so for many of them!) This is because it's pretty easy to map these concepts to everyday physical objects. Once a child understands any of those objects in their lives, it's pretty easy to explain in those terms.
Like, just the concept of "books" gets you very far. E.g. a file is a like a book, a folder is like a shelf to keep books, a stack is literally a stack of books, a heap is just a place you can pile books in willy-nilly, a database is like a library, a cache is books on your desk versus books in the library, replication is having multiple copies of a book so we can afford to lose some copies, indexing/sharding is like arranging books alphabetically, and so on.
Others are trickier but not much: a process is an app that is running on your device, a socket / tcp / http / websocks is a way to exchange information between devices, a namespace is how the name "Tom" in Tom Sawyer is different from "Tom" in Tom & Jerry, DNS is a way to get an address from a name, etc. etc.
You'll also notice that many of the terms you mentioned are already derived from well-known real-world concepts like pool, stream, channel, stack, queue, worker, transactions. You can mix those with other everyday concepts to make useful analogies.
But I could not even begin making analogies for most topics in Mathematics. I guess this is because advanced topics in Mathematics are just too abstract to map to everyday things.
Exactly. Everyone should experience having to teach something they're so used to doing that they don't even consciously think about it anymore. It makes it very visible how much we rely on unconscious models of the systems we deal with and how difficult it can be to convey that model.
It's why less experienced devs are sometimes mystified seeing a seasoned dev, given a vague description of a bug, guess the cause in code they didn't even write.
Yeah. In math at least it's clear that you don't know what's going on. In other fields, it's very easy to think you understand without knowing how much you're missing.
I studied math through college before learning to program as an adult and becoming a software engineer, and I strongly disagree.
I don't know how to say this in a way that won't sound insulting, but I don't mean it to be insulting. Programming, even systems engineering, is a surprisingly shallow field.
I don't mean that it's easy--it's not, it can be incredibly difficult. Difficult and deep are just different concepts. Difficult refers to how challenged you are. Depth, at least as it appears in math, is closer to a structure where concepts build on each other so that if you don't understand one concept, you can't understand further ones.
Programming can be difficult, and it can be intricate, but it is rarely deep in this fashion. Being deep in this way isn't the most important thing.
If I go into an area of programming that I don't have a lot of experience in (graphics, or the linux desktop environment), I will not be particularly useful, and it will not be easy. But I'll not experience the same type of impenetrability I experience when I try to read a paper on topos theory.
One more way of putting it: people are giving the example of TCP. You can spend a decade learning about TCP (or SQL semantics, or web standards). But what is happening is that you're filling in gaps in your knowledge. Meanwhile, in math, you do four years of undergrad, and even if you're a strong student at a typical university, there are topics that are still years away from you being able to touch them.
Computer science is a mix. Parts are deep, parts are shallow. Parts just are math. The odds that I can read a dissertation in computer science are decent. For math, they're much much much worse.
> Programming, even systems engineering, is a surprisingly shallow field.
I agree, and I don't think we should be at all ashamed of this.
The beauty of programming is that we can produce incredibly complex and powerful things by manipulating a small set of simple constructs together. There are only a few core tools--iteration, conditionals, etc.--but they can be snapped together into much more capable configurations.
Good programming is the art of deconstructing complex behaviour into these few constructs, and that's really fascinating.
I agree, and I don't even know math.
Most of things that are impenetrable in programming aren't about... programming. They are about some actually complex field like math being applied to programming.
For example, a library that does stuff with geometry. You need to know geometry to understand the program, but the program itself will never be complicated. It's the geometry that is complicated.
In cryptography, it's not the program that is complicated, it's the field of cryptography. In AI, it's statistics.
In graphics programming, math is the most impenetrable part, not programming anything. You can be a very good programmer in the sense that you know how to architect information systems and still fail to write a shader because shader programming requires you to know what a "dot" product is and you haven't heard about that since high school.
1 reply →
[dead]
Just be thankful that we don't share the penchant for giving credit to discoverers. Imagine calling a cache a "Murphy/Steinman/Sokolov structure" (made-up names).
I mean, we do for some things, especially algorithms (Boyer-Moore). Probably for the same reason the mathematicians do -- there aren't readily available real-world analogies.
And I won't even mention the branded future, with its "Google HyperZipper String Search" and "OpenAI/Red Bull speedmaxx distributed consensus algorithm"...
Huffman Coding, Turing Machines, Knuth Devices, Bayesian networks, B-tree (named after Bayer), AVL Trees, so many data structures and algorithms, even relatively new ones like Timsort, Jaccard similarity, MapReduce (thankfully but I have seen people call it Dean-Ghemawatt MapReduce in literature).
Well people even name stuff after themselves as well, Fil-C, raylib, etc (I like both Filip and Ray just pointing it out).
Aside: If I butchered some spellings I am sorry. :3
If we take amateur level of understanding as a threshold, a sum of all of these concepts is not even a fraction of complexity required to understand a single non-trivial concept in mathematics.
> if you read a paragraph of even semi technical software text you will feel like an over stuffed turkey.
That's me when I try reading a trendy computer graphics paper.
Also a lot of those are common words that take on a different persona and depth within the field, which can add to confusion.
This is also true for almost every other field, even within computer science. The only difference is that a lot of people operate at a very surface level without realizing just how much background knowledge they have accumulated. Think about the number of keywords your average SWE is expected to know. It is rather insane.
Nah, math is much harder because there is not just the lingo, but also all the math machinery behind it. Each math definition represents some long process behind it, which builds on another process, etc. The knowledge builds on itself , too much more so than computer science.
old.reddit.com/r/vxjunkies
>> Cache, stack, heap, process, thread, socket, file, tcp, http, tls, websocks, socks, soc2???, deadlock, stack, queue, race, atomic, event loop, coroutine, async, database, transaction, index, replication, sharding, consistency, serialization, DNS, load balancer, container, namespace, and so on.
... communication protocol, method signatures, web components, ssh, CSS media queries, HTTP headers, WebSockets, timeouts, ETag, iterables, async iterables, middleware, CI/CD, build, consistent hashing, signatures, JWT, SSO, OAuth, SAML, XML, YAML, JSON, block cipher, ETL pipeline, SQL, SQL transactions (atomic), relational databases, foreign keys, schema normalization, referential integrity, 1-to-1, 1-to-n, n-to-n, document databases, compound indexes, idempotency, offset-based pagination, cursor-based pagination, P2P, Kademlia, structured vs unstructured network topology, message routing, frontend router, message storm, reconnect storm, locality, encapsulation, cohesion, coupling, design patterns, modularity, Big O notation, raytracing, shaders, VPN, VPC, data schema, schema validation, CORS, preflight-requests, CSRF, ASCII, UFT8, CSP, CPU context-switching, BIOS, bootloader, interrupt controller, ports, BIND protocol, BGP protocol, assembly language, big endian, little endian, register, signals, embarrassingly parallel, serial processing, event loop, binary trees, tree rebalancing, graph traversal algorithms, sorting algorithms, string character escaping and encoding, blob, base64, UUID, timestamp, CLI, Bash, unit tests, integration tests, e2e tests, TDD, stateful, stateless, proxy, nginx, haproxy, config, helm file, k8s, staging, git, push, commit, merge, rebase, cherry-pick, pub/sub, diff, honeypot, buffer overflow, pointer, file descriptor, authentication, certificates, TLS certificates, DNS Zone files, A record, CNAME, TXT record, SMTP, POP3, SOCKS5, Sha256, HMAC, Merkle trees, Merkle Signature Trees, Lamport OTS, Winternitz OTS, SPHINCS, lattice-based cryptography, pg-vector, vector embeddings, API, rate limiting, cookies, sameSite, httpOnly, localStorage, XSS attack, SQL injection, fetch API, module preloading, bundling...
Barely scratching the surface. I think I could probably keep typing all the technical terms I know for at least 24 hours straight. For most of the topics above, I could probably give a 1 or 2 hour lecture on each one from memory. Some I could give a day-long lecture each.
To explain all the terms I know to a basic degree, I would probably need to give a whole year of lectures back-to-back from 9am to 5pm. And I'm just a rank-and-file senior engineer with 15 years of experience.
It's also why the vast majority of software systems are insecure. The average senior software engineer doesn't know everything that they need to know to build secure software. Last time I poked around Coinbase APIs on HackerOne, I found a DoS vulnerability in less than 30 minutes. That's Coinbase, not some startup built by a bunch of recent graduates.
AI cannot avoid vulnerabilities either since it is trained on average engineer code. There's not enough high quality code available on the entire internet to train AI to implement secure code IMO. As impressive as Mythos may be, it's not enough. I don't even think formal verification would provide protection since sometimes issues with the spec itself can provide an opening for a vulnerability.
Nice list. I like it how you also included some made up terms. For completeness, those are not real:
ETag, SAML, CSP, BGP, haproxy, helm file, k8s, SOCKS5, Lamport OTS, Winternitz OTS, SPHINCS, lattice-based, pg-vector, sameSite, httpOnly. (Or, at least, i have no idea what those are ::)
1 reply →
Coinbase not a startup built by recent graduates...
You overestimate Coinbase's engineering rigor.
But yes security in modern software systems is a joke. I don't even get paid to fix security bugs everytime I raise them the answer is to slap a sandbox and proxy and call it done.
a janitor could do the same though
1 reply →
[dead]
At least a lot of those are common words that allow some level of meaning inference with a little bit of adjacent knowledge, like cache and queue make sense with the barest of explanations because their everyday definitions are still applicable. Many of these terms aren’t entirely opaque until you drill down into specific niches.
I had a few moments of this in the past. For example, in my quantum class the teacher wrote "H Psi = E Psi" on the board, we all laughed, "just cancel the psi" but it turns out one was a multiplcation and the other was a matrix multiplication (operator) and so we had to learn all new nomenclature.
Similarly, at some point somebody pointed out to me "the reason you're confused is that the bold on that variable means it's a matrix"
That is why Iverson invented APL. As a notation to get rid of all those inconsistencies in math notation. And for years he taught math classes with APL on the blackboard without computers.
whether he succeeded, is debatable. But APL is definitely powerful, succinct and "regular".
In APL you don't infer the operation from the types at all. × is elementwise, +.× is inner product /always/, on scalars, vectors, matrices, whatever. The glyph tells you what happens. Nothing is bold, nothing is inferred, nothing depends on what your professor assumed you'd absorbed.
I've been trying to get into Iversonian languages myself with the book: Calculous on J
hi, would you mind linking to the book?
https://www.jsoftware.com/help/learning/23.htm is the closest i've found, but wondering if i'm missing something perhaps, Julia?
tyvm
For something like APL modulo the Unicode symbols:
https://t3x.org/klong/
I mean, unfortunately being completely explicit and pedantic does not scale.
Imagine that instead of being able to use high-level programming languages, you had to write in assembly everywhere, all the time.
That's what software engineers and computer scientists' suggestions of redoing mathematical notation fee like to mathematicians.
These efforts also don't go anywhere because research mathematics moves beyond elementary arithmetic very quickly, and once you're there, "descriptive" notation becomes as incomprehensible as whatever mathematicians use.
My favorite moment of this kind was when the teacher said 'Ok, and for the rest of the course we will look at a completely different problem', and the equation he wrote down was exactly the same as before. Except that the letters referred to vectors/matrices now.
Aye.
A decade or so ago I wondered if the reason maths was hard was the names being optimised for writing by hand. Everything's single letters if they can get away with it, so when mathematicians run out of Latin alphabet, they use Greek, bold, etc.
Even integration's ∫ is a fancy elongated s.
CS version would be e.g. integral(function=some_named_function, from=a, to=b, with_respect_to=argument_of_function), which may be longer, but is less opaque, especially when you get in so deep there's 3 other people in the world who've looked into this specific problem and you had to invent your own operations.
But that's all an outsider's perspective. I stopped with two A-levels in maths and further maths.
Nope, math notations are optimized for reading, not writing (consider that people still use symbols on computers despite it being quite a bit more tedious to type). The conciseness makes it easier for you to see structural patterns and do symbolic manipulation in your mind's eye. Even something basic like the wave equation would become completely illegible with an expanded notation like that.
Same reason why we write 5-3, not subtract(minuend=five, subtrahend=three).
2 replies →
At some point though, the speed of reading/writing is limiting what you can understand. Think of "not fitting the needed formulas/theorems in cache".
1 reply →
Look up "APL" and "J".
1 reply →
yes! I really find when computer science ppl start using math notation to describe algorithm very pretentious. we have programming languages in comp sci, we don't need it!
I was reading about Tao's efforts to get more people to use Lean and apparently a big roadblock for people is that Lean uses very specific static typing.
e.g. to use a very simple example on a white board "3" is "overloaded" as:
- the integer 3
- the rational number 3
- the whole number 3
- etc
When you write a proof in Lean, you have to specify the the type of "3" you mean.
Having using Python/Perl and Java over the years, I get that some math folks found handling this daunting or at a minimum friction to getting into using Lean.
LLMs seem to have been a big help here just for the "translate my math notation into a proof" feature.
To get the hang of this, I used Leanstral (Mistral’s LEAN agent) to vibe-code things like “the game of bridge” and then read the LEAN code.
Sometimes I wonder if mathematics would have been significantly more improved if they hadn't insisted on notating their variables as single letters and also indicated variable types out-of-line (or at all)...
but then I take a look at literally anything the Haskell people do and realize that it probably wouldn't have helped.
>For example, in my quantum class the teacher wrote "H Psi = E Psi" on the board, we all laughed, "just cancel the psi" but it turns out one was a multiplcation and the other was a matrix multiplication (operator) and so we had to learn all new nomenclature.
This is one of the great things about Lean becoming used for more and more mathematics: understanding exactly how an operator/function is defined is just an IDE click or few away. It completely removes the ambiguity present in hand-written proofs, although it still can require a lot of reading to actually meaningfully understand the definitions.
I would expand on this. AI is great for me because it can read the equations I don't understand and turn it into code I can understand. I've worked in science for decades and it's still like pulling teeth to replicate a competitor's paper when they are vague and sloppy with their description (often intentionally).
ugh, I had some text book that used R for a scalar value and (edit: \u{MATHEMATICAL BOLD FRAKTUR CAPITAL R} here) for a matrix that was related to the scalar and I had to go back and re-learn a month of material once I figured out that the font was being used with intent
For what it's worth, it's not a problem with multiple kinds of multiplication (multiplication by a scalar can be viewed as multiplication by a specific kind of matrix), but with the idea that one can cancel in a multiplication. Since you can't cancel in matrix multiplication, you run into unexpected trouble when you try to do so, even if that's the only multiplication in sight. (In fact, you can't cancel in scalar multiplication either unless you've checked that you aren't multiplying by 0 …. Also, I'll note that surely no young mathematician has encountered the P = NP problem without thinking for a sophomoric moment that the solution is N = 1.)
P = NP is actually one of the worst abuses of symbology I've seen in math.
"""During his own Google interview, Jeff Dean was asked the implications if P=NP were true. He said "P = 0 or N = 1." Then, before the interviewer had even finished laughing, Jeff examined Google's public certificate and wrote the private key on the whiteboard."""
A term that gets tossed around in math is "mathematical maturity." It's similar to what you see in other fields - e.g. learning how to program, learning how to make music, learning how to cook - that involves many "aha" moments and reshapes your perspective. Math is full of such steps, moreso than most other endeavors, probably because the main limit is the abstract reasoning itself.
Math is full of such steps, moreso than most other endeavors, probably because the main limit is the abstract reasoning itself.
That, as well as how long we've been doing it (thousands of years!) and so how much of the more accessible parts we've explored very thoroughly.
The abstraction is by necessity. Our puny brains have only a very small working memory. The only way we can reason about many problems is by creating multiple levels of hierarchy. That is actually the essence of what mathematics is.
Math strives to minimize ambiguity, which other fields don't do as much. Non-math fields tend to reuse regular words as jargon (i.e. with specificity of meaning that may fly over the laymen's heads). Social sciences and humanities are most notorious for this, often resulting in non-practitioners not realizing they are out of their depth because they are not looking at symbols from non-Roman alphabets.
That's something only someone who's never studied advanced math could say. Math notation and jargon can be extremely ambiguous and overloaded. "Normal" has about 20 different meanings.
Certainly overloaded but rarely ambiguous. Context will determine which notion of “normal” applies.
3 replies →
Strives to minimize =/= completely eliminates
1 reply →
> Non-math fields tend to reuse regular words as jargon
Isn’t this the field with a “closed” “set”, an “open” “set”, oh and also a “clopen” “set” for some reason?
Yeah it is a lot of simple ideas stacked one on top of the other, but the edifice is so large from some vantages that the building blocks aren't visible, or tractable to think about independently. And sometimes the ideas are very subtle, so you can only develop fluency partly by spending lots of time playing with those blocks by building your own little structures. You also develop fluency by talking to other mathematicians
I like to emphasize that the ideas are usually very simple at their core. Sometimes they map to kinds of objects or reasoning that non-mathematicians use implicitly all the time in their daily lives, mathematicians just have words for them and so are able to use them explicitly.
And I suspect the density of the language/terminology may give the wrong impression about how mathematicians think about the math they are working on. I mean, different people think / experience / practice math differently of course but IME the underlying thought about a particular problem tends to be much looser and concrete than formal math writing would imply.
That more formal language is needed of course because at the end of the day, it is how we communicate our thoughts in the way that other mathematicians can understand them, not to mention how we can check our own thinking
Yeah this is pretty much where I am at. Take the phrase from one of the responses
"The special fiber is the associated graded ring.....and that the filtration admits sufficiently simple homogeneous lifts of the three generators, then one might prove"
In any other context I would at least have some degree of intuition about what is being discussed, but in in math? Absolutely no idea. And usually if I start digging and turning over stones to uncover meaning, I'm just met with even more totally dense code-word language. Unlike other fields were digging is usually quick to relieve ignorance, somehow in math it tends to get worse.
I'm sure I am capable of grasping this if I took the time, and perhaps even what is being discussed it rather intuitive, but the incredibly density of the nomenclatic swamp you have to trudge through for math is totally unrivaled.
The basic problem is that to get to the objects you mention here is at least 3 or 4 years of full-time study away from the kind of math people learn for a typical college degree in science or engineering. If you really want to understand them, to make your "digging" efficient you should probably just get a pure math degree, but setting aside several years to satisfy occasional curiosity is not feasible for most people for various reasons.
One unfortunate feature of published pure math research is that often the ideas are quite accessible and straightforward and don't really require special abstractions or terminology, but those get used anyway because for someone who already has a math PhD it saves a bit of effort.
I agree, the nomenclature is impenetrable, it's like reading software that is not well commented. Perhaps LLMs are very good at "challenging" mathematics because what we perceive as challenging is primarily the language component and not the conceptualization.
Is there something that translates math formula into code? There are many (comparatively) "simple" algorithms I simply cannot make heads or tails when they are described via math prose or math formula, but when it's code I basically instantly know how to rewrite it into any other language I know, at least, and sometimes that's a starting point for poking at it to understand it a bit better, if not the same way would if you understood all the underlying math.
For poor old me, too many wikipedia articles on algorithms useful mostly or only for programming are described in formulas rather than simply code with detailed comments. Scrap the whole page and just gimme the code :( Not even to copy and paste, because that's a language I can understand, and enjoy learning.
I agree. I think the distance in capabilities between great mathematicians can be so much more vast than other fields as well. Some of them need every step to be derived, while others can skip ten in their head.
Isn't it just what you studied in depth? I am not in this area but can understand what's going on "at a high level" here. But I studied no other science formally since the age of 15 (this is possible in the UK school system). So physics and biology just go over my head unless they are sufficiently mathematical.
There is a lot of verbal commonality between the classic sciences, classic engineering disciplines, and everyday life. I suppose they all share the common substrate of working in/with mother nature all day. A molecular biologist, civil engineer, and oceanographer can mostly keep pace with each other at least for a while in discussing what they are working on. These "mother nature" systems have tons and tons of overlap, and the nomenclature generally tracks this, or is one or two steps away from it.
Computer science/engineering strays from this, binary systems don't really track nature much, and hence a lot of their own unrelateable nomenclature arises, and then there is math, which is just way far out there on it's own plane of existance.
I once didn't understand the task given in an exercise sheet for a CS logic lecture, so I googled the topic, and all Google did was send me back to that exact exercise sheet.
But somehow the conversation is still enthralling. Just seeing the first few words of each response gives you a feel for the level they’re on.
It can't be one language, and that's the big problem. It's inescapably a bunch of tiny DSLs. Once you see both the inconsistency and the necessity for inconsistency, it becomes much easier to just roll with it.
Yes, the nomenclature in math is atrocious. It isn’t much better in physics or biology however. As a species, we suck at naming and classification, and keep starting new trends atop old ones. There is certainly need for the many abstractions of math to be as complex and well specified as they are. There’s no reason for their nomenclature to be so bad. The end result is a substantial portion of the population, which can certainly hold and manipulate abstractions, fails to even contend with pure math. I do think visualization tools will help in the future, to demystify some of this. But as with all sciences, the need for personal glory/mentor deification often conflicts with broader explainability.
This is a very notorious area for dense definitions and concepts that interrelate closely and have to be memorized. Mathematicians from other areas are going to have difficulty but may have some idea of what the concepts try to capture.
Some areas are hard in different ways. I could never quite wrap my head around the way logicians have to think. A clever combinatorial bijection is a work of art you probably can explain to a undergrad class easily but good luck coming up with it. And number theorists will throw the kitchen sink at their problems: no area of math is safe from getting used by them.
People who do this have spent years of their life thinking in this language and studying it, so it is going to be hard. We're also not good at communicating the intuition which for algebraic geometry often comes from other fields.
Mathematicians emphasize definitions not labels/names.
It doesn't matter if natural numbers include 0 or not, what matters is how you define them, not how you call them.
This makes them also bad at naming things because...there's a definition anyway.
Most other fields do not have or can't have the same luxury, so naming might be more thoughtful.
That is one of the things that fascinates me most about mathematics compared with other fields, and it led me to discuss the subject with professional mathematicians. The funny thing is that they admitted it is the same for them...stray even slightly outside their own specialized area, and within two or three lemmas, they also feel completely lost.
IMO, it's just the notation. Something I've actually found ChatGPT useful for is to create mathematics lessons for me in the form of computer programs. When broken down into a series of readable almost-plain-English steps, it's so much easier to understand. And it's easy to tinker with programs and get a hands-on feel for things quickly.
I'm sure having a compact notation is absolutely invaluable for people who dedicate their lives to maths, but for someone with just a passing interest, I find it more obscuring than helpful. I feel the same way about music notation.
I mentioned this in a sibling comment but even for mathematicians, the intimidating notation and the more formal language might give the wrong impression about how we think about math. Actual thinking and even discussions with other mathematicians tend to be looser and more concrete and tactile, but the notation and language are there in part to act as a sort of lingua franca to help everyone stay on the same page, since everyone thinks at least a little bit differently. It also helps to keep you honest and catch situations where your thinking was muddied, since this language is so specific and writing things down has a funny way of catching things. And good notation goes a long way towards making the simplicity of an idea clear, or completely muddy in the case of bad notation.
Many mathematicians do what you do as well!
Yes, math is hard.
People in their second year of graduate school only get to about the early 20th century in terms of understanding. Third year is getting to about the mid-century. Fourth and fifth years get kind of to modern times but with increasingly smaller breadth.
You develop a set of heuristics for skimming it in the same way you do with code.
Big wrapping operations like sums, integrals, and matrices, then what's nearby them, give you a very good idea of where things are going context wise.
Progress in scientific fields is limited by how fast you can perform experiments. Most areas of math are limited only by the number of practitioners.
It's just language. Mathematicians don't invent notation for fun, they do it because they naturally start thinking at a higher level of abstraction. If you're not thinking at that level then, well, it will be all Greek to you.
Sometimes they do. There's nothing divine or necessarily rational about notational standards, which can vary greatly even within the same field.
Yes exactly
Math isn’t necessarily hard, but it’s incredibly dense
A simple statement like let f(x) be a continuous function can carry a lot of definitions
In that statement, if you missed the day in class where they covered continuous functions it might not even register that it’s a well defined term
And that’s the most over simplistic example I could think of
As a math major, I remember that being one of the first lessons I learned, that every single word could be carrying a lot of weight so to look things up in detail if I was ever struggling on a problem. One of the oldest entries in my memory.md file