8 ms·

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 withou

by minraws 3mo ago

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.

sfink 3mo ago
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"...
- deleted 3mo ago
  [deleted]
- minraws 3mo ago
  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
cosmic_cheese 3mo ago
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.
paulpauper 3mo ago
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.
scrapcode 3mo ago
Also a lot of those are common words that take on a different persona and depth within the field, which can add to confusion.
Jtarii 3mo ago
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.
- ghshephard 3mo ago
  "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...
  - minraws 3mo ago
    Definitely a lot of people have very surface level understanding of tcp and computer science concepts. I have had folks tell me cache is just cache in actual interviews. When I have asked them to explain the concept to me, but even beyond that I feel like we tend to think less of our own knowledge of topics once we have acquired it. Especially ones acquired over years, alongside other work.
  - Jtarii 3mo ago
    You could get a surface level understanding of TCP, or 99% of topic areas in computing, in less than 4 weeks of study. You could not get a surface level understanding of literally any of the maths in the link in less than 4 weeks of study. The vast majority of what computers do just isn't that complex. I'm not saying it isn't "complex" just that any reasonably smart person can understand how a computer works and still have other hobbies, basically no one can understand phd level mathematics without dedicating their entire lives to it.
stymaar 3mo ago
> 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.
redsocksfan45 3mo ago
[dead]
WarmWash 3mo ago
>https://en.wikipedia.org/wiki/Transmission_Control_Protocol https://en.wikipedia.org/wiki/Transmission_Control_Protocol compare to >https://en.wikipedia.org/wiki/Rees_algebra 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.
- minraws 3mo ago
  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.
  - WarmWash 3mo ago
    I think you are snagging on thinking this is an observation about difficulty, time-to-mastery, or mental firepower requirements. It's not. It's a plain observation that math exists on mostly it's own path with little to zero overlap with our lived experiences. If mathematics was a vector, it would have similar magnitude to other vectors, but it's direction would be much more removed from the typical knowledge pack, forcing you to get really close to the origin before you can "hop" over to that math vector. Other "knowledge" vectors, by virtue of being more bunched up, are closer together much further up, if that poor analogy at all makes sense.
Razengan 3mo ago
old.reddit.com/r/vxjunkies
umvi 3mo ago
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"
- mrpf1ster 3mo ago
  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
  - umvi 3mo ago
    My example was contrived, I'm sure some smart people could come up with a SQL-esque language that is even more readable to non-technical folks than programming syntax. At a certain point though, your layman has to know the "atomic" (as in, you can't break them down further) mathematical concepts like "functions" and "infinity": `sum function(x) from x=0 to x=infinity`
    - BlackFingolfin 3mo ago
      I am a research mathematician. In my field (abstract algebra, computational group theory), a sum or some such notation is like the most trivial of trivial things in terms of notation. There are a few things like sums that could in theory be made to "look more like what a computer programmer would expect", but that'd be just a tiny corner of it. And if you think about how summation would look in Lisp or APL (which some smart people use to this day), I am not even convinced your argument for the "sum function" notation being superior holds in general.
vovavili 3mo ago
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.
hyperpape 3mo ago
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.
- Planktonne 3mo ago
  > 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.
- AlienRobot 3mo ago
  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.
keeda 3mo ago
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.
auntienomen 3mo ago
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.
jongjong 3mo ago
>> 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.
scubbo 3mo ago
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
- aleph_minus_one 3mo ago
  > 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.
  - scubbo 3mo ago
    Yep, exactly.
hgoel 3mo ago
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.

by minraws 3mo ago

sfink 3mo ago

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"...

deleted 3mo ago
[deleted]
minraws 3mo ago
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

cosmic_cheese 3mo ago

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.

paulpauper 3mo ago

scrapcode 3mo ago

Also a lot of those are common words that take on a different persona and depth within the field, which can add to confusion.

Jtarii 3mo ago

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.

ghshephard 3mo ago
"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...
- minraws 3mo ago
  Definitely a lot of people have very surface level understanding of tcp and computer science concepts. I have had folks tell me cache is just cache in actual interviews. When I have asked them to explain the concept to me, but even beyond that I feel like we tend to think less of our own knowledge of topics once we have acquired it. Especially ones acquired over years, alongside other work.
- Jtarii 3mo ago
  You could get a surface level understanding of TCP, or 99% of topic areas in computing, in less than 4 weeks of study. You could not get a surface level understanding of literally any of the maths in the link in less than 4 weeks of study. The vast majority of what computers do just isn't that complex. I'm not saying it isn't "complex" just that any reasonably smart person can understand how a computer works and still have other hobbies, basically no one can understand phd level mathematics without dedicating their entire lives to it.

stymaar 3mo ago

> 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.

redsocksfan45 3mo ago

[dead]

WarmWash 3mo ago

>https://en.wikipedia.org/wiki/Transmission_Control_Protocol https://en.wikipedia.org/wiki/Transmission_Control_Protocol compare to >https://en.wikipedia.org/wiki/Rees_algebra 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.

minraws 3mo ago
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.
- WarmWash 3mo ago
  I think you are snagging on thinking this is an observation about difficulty, time-to-mastery, or mental firepower requirements. It's not. It's a plain observation that math exists on mostly it's own path with little to zero overlap with our lived experiences. If mathematics was a vector, it would have similar magnitude to other vectors, but it's direction would be much more removed from the typical knowledge pack, forcing you to get really close to the origin before you can "hop" over to that math vector. Other "knowledge" vectors, by virtue of being more bunched up, are closer together much further up, if that poor analogy at all makes sense.

Razengan 3mo ago

old.reddit.com/r/vxjunkies

umvi 3mo ago

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"

mrpf1ster 3mo ago
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
- umvi 3mo ago
  My example was contrived, I'm sure some smart people could come up with a SQL-esque language that is even more readable to non-technical folks than programming syntax. At a certain point though, your layman has to know the "atomic" (as in, you can't break them down further) mathematical concepts like "functions" and "infinity": `sum function(x) from x=0 to x=infinity`
  - BlackFingolfin 3mo ago
    I am a research mathematician. In my field (abstract algebra, computational group theory), a sum or some such notation is like the most trivial of trivial things in terms of notation. There are a few things like sums that could in theory be made to "look more like what a computer programmer would expect", but that'd be just a tiny corner of it. And if you think about how summation would look in Lisp or APL (which some smart people use to this day), I am not even convinced your argument for the "sum function" notation being superior holds in general.

vovavili 3mo ago

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.

hyperpape 3mo ago

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.

Planktonne 3mo ago
> 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.
AlienRobot 3mo ago
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.

keeda 3mo ago

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.

auntienomen 3mo ago

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.

jongjong 3mo ago

>> 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.

scubbo 3mo ago

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

aleph_minus_one 3mo ago
> 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.
- scubbo 3mo ago
  Yep, exactly.

hgoel 3mo ago

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.