> Most coding doesn't need much of any math past boolean logic and very basic set operations
Coding IS math.Not "coding uses math", I mean it is math.
Mathematicians do not deal in objects, but in relations among objects; they are free to replace some object by others so long as the relations remain unchanged. Content to them is irrelevant; they are interested in form only.
- Poincare[0]
I don't know how you code, but I don't think I'm aware of code that can't be reasonably explained as forming relationships between objects. The face we can trace a program seems to necessitate this.[0] https://philosophy.stackexchange.com/questions/22440/what-di...
But I'll refer you to a longer conversation if it helps https://news.ycombinator.com/item?id=43872687
Coding used to be very close to pure math (many early computer science classes were taught in the Math Department in universities) but it has been so far abstracted from that to the point that it is its own thing and is as close to math as any other subject is.
> By that same logic you could also say that language is math
Not quite, but the inverse is true. The language to math direction doesn't work because a lack of formalism. I can state incomprehensible sentences or words. (There's an advantage to that in some cases!) but when you do that with code you get errors and even you do it with math its just that there's no compiler or interpreter that tells at yousince you can express paradoxes with match, perhaps not that different.
The contradiction is used in proof formulation, specifically to invalidate some claim. I don't think this is what you're implying.
The latter is what it contextually sounds like you're stating; things like the Banach-Tarksi Paradox. There's no self-contradiction in that, but it is an unexpected result and points to the need to refine certain things like the ZFC set theory.
I'd also stress that there are true statements which cannot be proven through axiomatic systems. The Halting Problem is an example of what Godel proved. But that's not contradictory, even if unexpected or frustrating.
> coding and math being equivalent
Please see lambda calculus. I mean equivalent in the way mathematicians do: that we can uniquely map everything from one set to another> I mean equivalent in the way mathematicians do
That sounds like you're backing off from your original claim, probably because it is impossible to defend.
That you can use mathematics to describe code doesn't seem very different from using math to describe gravity, or the projected winner in an election, or how sound waves propagate.
Isn't the primary purpose of math to describe the world around us?
Then it shouldn't be surprising that it can also be used to describe programming.
In the real world, however, software engineering has nothing to do with mathematical abstractions 99% of the time
Though interpreting a CRUD app as a theorem (or collection of theorems) doesn’t result in an interesting theorem, and interpreting a typical theorem as a program… well, sometimes the result would be a useful program, but often it wouldn’t be.
It's not the type of thing that gets mathematicians excited, but from an engineering perspective, such theorems are great. You can often blindly code your way through things by just following the type signatures and having a vague sense of what you want to accomplish.
It's actually the halting problem that I find is not relevant to practical programming; in practice, CRUD apps are basically a trivial loop around a dispatcher into a bunch of simple functions operating on bounded data. The hard parts have been neatly tidied away into databases and operating systems (which for practical purposes, you can usually import as "axioms").
> It's not the type of thing that gets mathematicians excited
Says who? I've certainly seen mathematicians get excited about these kinds of things. Frequently they study Programming Languages and will talk your ear off about Category Theory. > You can often blindly code your way through things by just following the type signatures and having a vague sense of what you want to accomplish.
Sounds like math to me. A simple and imprecise math, but still math via Poincare's description. > in practice, CRUD apps are basically a trivial loop around a dispatcher into a bunch of simple functions operating on bounded data
In common settings. But those settings also change. You may see those uncommon settings as not practical or useful but I'd say that studying those uncommon settings is necessary for them to become practical and useful (presumably with additional benefits that the current paradigm doesn't have). > Isn't the primary purpose of math to describe the world around us?
No, that's Physics[0]. I joke that "Physics is the subset of mathematics that reflects the observable world." This is also a jab at String Theorists[1].Physicists use math, but that doesn't mean it is math. It's not the only language at their disposal nor do they use all of math.
> software engineering has nothing to do with mathematical abstractions 99% of the time
I'd argue that 100% of the time it has to do with mathematical abstractions. Please read the Poincare quote again. Take a moment to digest his meaning. Determine what an "object" means. What he means by "[content] is irrelevant" and why only form matters. I'll give you a lead: a class object isn't the only type of object in programming, nor is a type object. :)[0] Technically a specific (class of) physics, but the physics that any reasonable reader knows I'm referencing. But hey, I'll be a tad pedantic.
[1] String Theory is untestable, therefore doesn't really reflect the observable world. Even if all observable consequences could be explained through this theory it would still be indistinguishable from any other alternative theory which could do so. But we're getting too meta and this joke is rarely enjoyed outside mathematician and physicist communities.
Going on a total tangent, if you'll forgive me, and I ask purely as a curious outsider: do you think math could have ever come into being if it weren't to fill the human need of describing and categorizing the world?
What would have been the very beginning of math, the first human thought, or word or action, that could be called "math"? Are you able to picture this?
> do you think math could have ever come into being if it weren't to fill the human need of describing and categorizing the world?
I'm a bit confused. What exactly is the counterfactual[0] here? If it is hyper-specific to categorizing and describing then I think yes, those creatures could still invent math.But my confusion is because I'm having a difficult time thinking where such things aren't also necessary consequences of just being a living being in general. I cannot think of a single creature that does not also have some world model, even if that model is very poor. My cat understands physics and math, even though her understandings are quite naive (also Wittgenstein[1] is quite wrong. I can understand my cat, even if not completely and even though she has a much harder time understanding me). More naive than say the Greeks, but they were also significantly more naive than your average math undergrad and I wouldn't say the Greeks "didn't do math".
It necessitates a threshold value and I'm not sure that this is useful framing. At least until we have a mutual understanding of what threshold we're concerned with. Frankly, we often place these contrived thresholds/barriers in continuous processes. They can be helpful but they also lead to a lot of confusion.
> What would have been the very beginning of math
This too is hard to describe. Mull over the Poincare quote a bit. There's many thresholds we could pick from.I could say when the some of the Greeks got tired of arguing with people who were just pulling shit out of their asses, but that'd ignore many times other civilizations independently did the same.
I could say when the first conscious creature arose (I don't know when this was). It needed to understand itself (an object) and its relationship to others. Other creatures, other things, other... objects.
I could also say the first living creature. As I said above, even a bad world model has some understanding that there are objects and relationships between them.
I could also say it always was. But then we get into a "tree falls in a forest and no one is around to hear it" type of thing (also with the prior one). Acoustic vibrations is a fine definition, but so is "what one hears".
I'd more put the line closer to "Greeks" (and probably conscious). The reason for this is formalization, and I think this is a sufficient point where there's near universal agreement. In quotes because I'll accept any point in time that can qualify with the intended distinction, which is really hard to pin-point. I'm certainly not a historian nor remotely qualified to point to a reasonable time lol. But this also seems to be a point in history often referenced as being near "the birth" and frankly I'm more interested in other questions/topics than really getting to the bottom of this one. It also seems unprovable, and I'm okay with that. I'm not so certain it matters when that happened.
To clarify, I do not think life itself necessitates this type of formalization though. I'm unsure what conditions are necessary for this to happen (as an ML researcher I am concerned with this question though), but it does seem the be a natural consequence of a sufficient level of intelligence.
I'll put it this way, if we meet an alien creature I would be astonished if they did not have math. I have no reason to believe that their math would look remotely similar to ours, and I do think there would be difficulties in communicating, but if we both understand Poincare's meaning then it'll surely make that process easier.
Sorry, I know that was long and probably confusing. I just don't have a great answer. Certainly I don't know the answer either. So all I can give are some of my thoughts.
[0] https://www.inference.vc/causal-inference-3-counterfactuals/
That's not unique, all quantitative theories allow small modifications. Then you select parsimonious theory.
We didn't:
bring up the Strong Church-Turing Thesis in discussions of programming languages meant for use by humans.Mathematics is a very extensive field, and covers a vast amount of subjects.
For the same reason it can't be said that mathematics is equivalent to coding, as there are many things in mathematics that are not relevant for coding.
However, by far the most interesting parts of coding are definitely related to mathematics.
Math is about abstractions and relations. See the Poincare quote again.
Plus, the Programming Languages people would like to have a word with you. Two actually: Category Theory. But really, if you get them started they won't shut up. That's either a great time or a terrible time, but I think for most it is the latter.
Wheeler is arguing that if a tree falls in the forest, and there is nobody to hear it, that it still makes a sound because there are things that interact with the sound. But if the tree fell in a forest and there was nothing else in the universe then there is no sound because there is no observation.
It helps to read the whole thing[0] and to understand the context of the discussion. This is meta-physics and a deep discussion into what the nature of reality is. Ian Hacker has a good introduction to the subject but I find develop grave misunderstandings when they also do not have the strong math and physics background necessary to parse the words. Even people who understand the silliness of "The Secret" and that an observer need not be human often believe that this necessitates a multi-verse. A wildly convoluted solution to the problem of entropy not being invertible. Or closer to computer terms, a solution that insists that P = NP. There is information lost.
If you wanna argue that there's no difference between the word cup and a cup itself because there is no word without the observer who has the language, then yeah.
Programming is an expression of logic, which is absolutely mathematics.
But then we also have to think about naming variables and classes, structuring our code so that it is more readable by other developers, and so on. That's less about formal reasoning and more about communication.
There is an engineering aspect to programming (prototyping, architecture, optimization, etc). It's a combination of mathematics and engineering. Software Engineering.
Structuring sentences and naming variables so that it is easier for other people to understand is less about formal mathematical reasoning, and more about communication.
You could name a variable x, y, or Banana, but it doesn't change the logic.
I mean the reason we get mad at this is because it is someone destroying "society" in some sense. Even if that society is your team or just the set of programmers. It would be a pretty dick move were I to just use a word that significantly diverged from conventional meaning and expected you to mull it over. Similarly if I drop a unknown out of context math equation. It would be meaningless.
And I'm on your side, really! I strongly advocate for documenting. And let's be real, the conclusion of your argument more strongly argues for documentation than good variable names. Because variable names are much more constrained and much more easily misinterpreted considering how any word has multiple definitions. Surrounding code is often insufficient to derive necessary contextualization.
Mathematicians do have to deal with difficulties in naming things.
> They just use i, x, etc. all over the place
I do agree with your point btw, but I did want to note that there are good conventions around symbols. The brevity is heavily influenced by the medium. Variable names sucked when you had punch cards. It's still burdensome to write long names when using paper, chalkboard, whiteboard, or any system that doesn't have autocomplete.In general, lower case letters are used as constants, excluding x,y,z,t,i,j,k (sometimes u,v,w). It isn't a hard rule, but strong preference to begin at the beginning of the alphabet for these. Capital letters usually are held for things like Variable Sets (like random variables). Greek letters need context for constants or variables. BB and Cal typefaces for sets (e.g. Real Numbers, Integers). And much more.
I think a lot of the difficulty in it is that these "rules" or patterns are generally learned through usage and often not explicitly stated. But learning them can really help read unfamiliar topics and is why "notation abuse" leads to confusion. But after all, math is all about abstraction so technically any symbol will do, but no doubt some are (significantly) better than others for communicating.
There are two hard things in Computer Science:
- Cache Invalidation
- Naming Things
- Off-by-One Errorsand also philosophy.
The murky world of software patents would like a word about that.
For me, coding also feels artistic at times. But we see artistic beauty in mathematics all the time, so no wonder. But often I look at ugly code, and maybe that is subjective, but fixing that code makes it also feel prettier.
It is clear all developers have their owm artistic style, and probably that is why there is so much disagreement in the industry. Maybe we are lacking the pure mathemetical language to describe our intent in a more beutiful and precise way that is more clearly the-right-way. As in how we find beauty in simple physics equations.
> Not "coding uses math", I mean it is math.
Arguably writing a novel is math, if you use the right definition of math. But sometimes its more helpful to use more informal definitions that capture what people mean then what is technically accurate.
No, not always. Quite a lot of high-level code doesn't require any math at all. It doesn't take math to perform CRUD operations, which account for a lot of programming work. Sure, the underlying machine code is all based on math, but the higher level programming doesn't need to involve a single math equation for it to be useful. Let's see where the goalposts move now...
But the CRUD logic is so basic and boring, so obvious, that it doesn't require any thought.
Which code? The machine code that underlies everything? Or the lines of simple high-level CRUD that don't even need a single number or logic statement to function? Not all programming has to be mathematical or even logical at a high enough level, and I say this as someone who's been coding assembly language for 40 years.
Those lines ARE mathematical logical statements.
Each line defines logical operations that are executed by the computer.
Same for high level or low level programming. It's all logic.
Assigning a variable is a mathematical operation. It is a logical state transition. This is formalized in Programming Language Theory.
We are not talking about quarks. We are talking about lines of code which are objectively mathematical statements, no matter how non-mathematical they seem to you subjectively.
You start with a practical problem to solve, and a computing machine that can perform logical operations on data. Your job is to figure out a correct sequence of logical operations that will solve the problem. The program that you have written is a mathematical structure. It is mathematics.
In the case of code, we can argue that the map is the territory.
Those business requirements are inputs to the process of writing the code.
Once the code is actually written, that exists as a formal logical system, defined by mathematics, not business requirements.
>Once the code is actually written, that exists as a formal logical system, defined by mathematics
I still think that's not code, but your favorite model of code. For spellchecker language is defined by mathematics too: it splits text into words by whitespace, then for each word not found in dictionary it selects best matches and sorts them by relevance. Oh and characters are stored as numbers.
Writing code IS a math skill. When writing code you are writing logic in a formal system. Logic is mathematics.
You may be thinking that mathematics is just like doing arithmetic or solving equations. It is way deeper and broader than that.
> I still think that's not code, but your favourite model of code
Code is not just modelled through mathematics, it is actually defined by mathematics. It is fundamentally a mathematical construct, grounded in formal semantics.
Code is not modelled mathematically, it is defined mathematically.
It exists as an abstraction which is fully defined by operational semantics and denotational semantics, not modelled or approximated.
In the counter example of a quark, that exists in nature and is modelled by mathematics, but not defined by mathematics.
If you're going to accuse someone of confusing the map with the territory, you really should make sure you aren't making the same error.
> It's like trying to argue about the distinction between U(1), the complex numbers with magnitude 1, and the unit circle, and getting upset when the mathematicians say "those are 3 names for the same thing". Or saying that writing C is programming but writing in a functional language like Scala or Haskell (or Lean) is not.
As ndriscoll suggests, it is tautological. I mean look at what I said. I really need you to hear it. I said that coding is math. So what I hear is "How programming languages helps with programming languages?" Why are you expecting me to hear anything different? > What math says about zero based indexes?
Start at 0? Start at 1? Who cares, it is the same thing. The natural numbers, non-negative integers, integers, even integers, who cares? They're the same thing. And who cares about indexing at 0 or 1 in programming? That's always been a silly argument that's inconsequential. > How do you prevent off by one errors?
By not being off by one? What's the question? Like being confused about if you start at 0 or start at 1 and how to get the right bound? It is a shift from one to the other, but they are isomorphic. We can perfectly map. But I really don't get the question. You can formalize these relationships with equations you know. I know it isn't "cool" but you can grab a pen and paper (or a whiteboard) and write down your program structure if you are often falling for these mistakes. This seems more about the difficulties of keeping track of a lot of things in your head all at once. > How do you prevent buffer overflows?
By not going over your bounds? I'm so confused. I mean you are asking something like "if f(x) = inf when x > 10, how does math help you prevent the output of the function from being infinite?"Maybe what will help is seeing what some of the Programming Languages people do and why they like Haskell[1].
Or maybe check out Bartosz Milewski[2,3]. His blog[2], is titled "Bartosz Milewski's Programming Cafe: Category Theory, Haskell, Concurrency, C++". It may look very mathy, and you'd be right(!), but it is all about programming! Go check out his Category Theory Course[3], it is _for programmers_.
Don't trust me, go look at papers published in programming language conferences [4]. You'll find plenty of papers that are VERY mathy as well as plenty that are not. It really depends on the topic and what is the best language for the problems they're solving. But you'll certainly find some of the answers you're looking for.
Seriously, don't trust me, verify these things yourself. Google them. Ask an LLM. I don't know what to tell you because these are verifiable things (i.e. my claims are falsifiable!). The only thing you need to do is look.
[0] https://news.ycombinator.com/item?id=43882197
[1] https://excessivelyadequate.com/posts/isomorphisms.html
[2] https://bartoszmilewski.com/
[3] https://www.youtube.com/watch?v=I8LbkfSSR58&list=PLbgaMIhjbm...
Mentioning Scala is ironic, it's very light on math spik and to begin with was created to unify object oriented with functional programming, which is mathematically meaningless, because both are Turing complete and thus equivalent, tautological.
>So what I hear is "How programming languages helps with programming languages?"
Oh, right, in mathematics axiom is argument, but in reality it isn't. In programming you should assert what you assume, otherwise your assumptions can be wrong due to divergence from reality, but there no reality in mathematics, only fantasy, so you can't understand this with mathematics alone.
No. Code is an abstraction. It exists as a logical structure, grounded in mathematical logic.
> It doesn't take math to perform CRUD operation
Yes it does. Just because the objects you are working with aren't numbers doesn't mean it isn't math. In fact, that's my entire point. It is why I quoted Poincare in the first place. He didn't say "numbers" he said "objects".In a typical implementation these are database operations. That involves relational algebra operations, state transitions, boolean logic.
The READ part can be a very complex SQL query (composed of many algebraic operations) but even the simplest query (SELECT * from t where ID = 1) is filtering a set based on a predicate. That is mathematics.
No one is moving goalposts. Set theory and logic are at the foundations of mathematics.
This is math:
{x | x.id = 1}
OTOH, a SQL query is a SQL query.
This thread is hilarious though. It's like
- Cashier: here is your change.
- Customer: you did math!
- Cashier, no, I gave you change.
- Customer: that IS math!
- Cashier: You mean, I used math to give you change?
- Customer: No, giving change doesn't use math, it IS math!!!!" [2]
= D
Moving along.. FWIW, indeed SQL was created to model set theory (relational algebra and tuple calculus), the close relationship is no accident of course [0][1])
> No one is moving goalposts
I feel too they are.
First goal post:
> Coding IS math. >> No, not always. Quite a lot of high-level code doesn't require any math at all. It doesn't take math to perform CRUD operations
Second goal post:
> CREATE, READ, UPDATE, DELETE are fundamentally mathematical in nature
CRUD is closely related to SQL, and SQL is closely related to various mathematics. Are they identical and therefore equivalent? No - because your database is not going to like it when you write "{x | x.id = 1}", and the Oracle DB might not like something that you can write for your Postgres DB.
[0] https://simpleprogrammer.com/mastering-sql/
[1] https://en.wikipedia.org/wiki/SQL
[2] To quote: """Not "coding uses math", I mean it is math""" @ https://news.ycombinator.com/item?id=43872771
Goes back to this ridiculous proposition:
- Cashier: You mean, I used math to give you change?
- Customer: No, giving change doesn't use math, it IS math!!!!" [2]
The proposition is that "code IS math", not defined by, not uses, not inspired by, not relies on, not modeled after, but IS.
Computer programs are proofs[1]. This is intuitively and also formally true. You would agree writing proofs is doing math, yeah? Then obviously writing a computer program is also doing math.
Like I have a degree in math and have been a software engineer for over a decade. I do not know what distinction people are trying to get at. It's like trying to argue about the distinction between U(1), the complex numbers with magnitude 1, and the unit circle, and getting upset when the mathematicians say "those are 3 names for the same thing". Or saying that writing C is programming but writing in a functional language like Scala or Haskell (or Lean) is not.
[0] Modulo details like NULLs and multi-set semantics, but surely that's not the distinction?
[1] Up to isomorphism
This is an interesting example: "Or saying that writing C is programming but writing in a functional language like Scala or Haskell (or Lean) is not."
The first part is everything we need to look at. Are we saying that writing C is equivalent and equal to the entirety of all programming? That if you're programming then you are writing C code. No, there is an implied "is a form of" in there. Given the other clarifications and that so many people are claiming to be mathematicians, I would have expected the precision to say exactly "C is a form of programming" rather than "C is programming."
Turns out, the analogy of saying "the set of reals is the set of naturals" is more fitting compared to sets that are actually equal.
In math are highly concerned with structures and abstraction. We have things called operators. They aren't just addition and multiplication. We also use those words to describe different operations. They have things like groups, rings, fields, and algebras. Yes, plural.
The purpose of these things is to create logical frameworks. It matters not what the operators are. Nor does it matter what objects we operate on. Poincaré is explicitly saying this.
The part you're not understanding is the abstraction. This is what math is about. It is also why the Programming Language people are deeper in the math side and love Category Theory (I have a few friends who's PL dissertations are more math heavy than some math dissertations I've seen). It's no surprise. What's a function? How do you abstract functions? How do you define structure? These are shared critical questions. PL people are more concerned with types but I wouldn't say that makes them any less of a mathematician than a set theorist.
We can perfectly describe the CRUD operations with set theory. Do most programmers need concern themselves with this? Absolutely not. But is it something people designing those operations and systems is thinking about? Yes.
I'd encourage you to learn some set theory, abstract algebra, and maybe a bit of cat theory. It'll make these things pretty clear. But I'd caution about having strong opinions on topics you aren't intimately familiar with. Especially when arguing with those that are. Frankly, CRUD is a terrible example. I'm confident a quick google search (or asking a GPT) would quickly point you to relational algebra. It's discussed in most database classes. It certainly was in the one I was an assistant for.
We are talking about textbook CS fundamentals.
As someone that is "on the other side of the fence", and getting flamed for it, maybe I can shed some light since I have the other perspective as well. IMO, The reason for not seeing eye to eye is (for example) akin to saying "word problems are math". (Thinking of a grade school word problems for common reference). Yes, they are readily mapped to mathematical models that can solve the word problem & perhaps almost indistinguishably so. Though no - word problems are not math. Word problems are a series of phrases and words. That's where the talking past each other comes in... Different interpretations of "word problems are math", or "code is math". It's seemingly not clear whether we are talking about logical 'implies', 'element of', or 'equals'.
Which goes to "We can perfectly describe the CRUD operations with set theory.", we all agree there. That is not readily conveyed though when writing things like "code is math".
> That's where the talking past each other comes in...
Then sorry, but that's your own damn fault. I was clear about my definition and quoted a famous mathematician to give some authority, to not be "trust me even though I'm some rando". The way to respond to that is not "you're wrong, trust me, I'm some rando".Yes, I agree we're misunderstanding each other because we're using different definitions but "you've" rejected "mine" without defining "yours" and expecting everyone to understand. Of course that'll lead to confusion. You can reject the mathematicians definition of math, but you sure gotta say more than "trust me" and it's a pretty wild thing to do, especially as non mathematicians.
The problem here is one side who's dabbled in cooking says "a chef makes desserts" and chefs are responding "we do a lot more than that". Maybe there's a few chefs that go "yeah all I do is dessert" and everyone points to that while ignoring the second part of their sentence is "but that's just my speciality." Wouldn't you think that conversation is insane? The only reason it's obviously so is because we all know what a chef is and agree on the definition. But who is better qualified to define the chef's job? The chef or consumer?
In another thread, you characterized my response as stating: " ¬(A ↦ B) ⟹ ¬(B ↦ A)" (and this is a great example of language not being math, but math being language!). That was not at all my claim.
My claim is "I believe you are saying 'A = B'. It appears that 'B != A', therefore 'A != B'." My only claims are
(1) I believe you are writing to convey that you mean Math IS Language in the sense they are equal, identical, interchangeable, and fully equivalent, and bi-directionally so
(2) that: B != A
The only results can either be:
- "yeah, because B != A, the statement A = B is not true"
- Your claim (1) is false, I'm not actually saying "A = B"
- Your claim (2) is false, "B = A" is in fact true. I would find that to be an interesting assertion and would have loved to explore more why you think that.
That is a good analogy, except programming languages are formal languages, not natural languages.
> they are readily mapped to mathematical models
With code we are not talking about something that is mapped to mathematical models. Code is not modelled by mathematics, it is defined by mathematics (denotational semantics and operational semantics).
"Code is math" is true in a theoretical sense. Practically, coding doesn't always feel like what is commonly thought of as "doing mathematics", but it is essentially mathematical.
Actually I'm starting to wonder whether the thing that made university math easy for me was I quickly developed a good internal "type checker"/"type inference engine" in my head, and that helped make the next steps of proofs seem straightforward.
[0] https://gist.github.com/ndriscoll/881c4f5f0398039a3a74543450...
Though middle-school or not, it's still math.
For anything CRUD, you put the data into a database. The underlying database is relational, or a key->store.
If it's relational, that's one branch of mathematics. If it's another kind of database, it's another branch of mathematics. Mathematics is extensive, and covers more things you can imagine at a glance.
The main difference between writing mathematics and programming, and this applies to any form of programming, is that in mathematics writing a formal proof is amazingly close to: you write the program, and you are also the compiler, and you are the CPU, performing all operations yourself. With programming you only have to write the program.
Source: On one hand I have studied pure mathematics (not the simplified applied mathematics that are taught in engineering, which is mostly equations), on the other hand I have been working as a software developer for over 15 years.
This is vague and doesn't mean anything. People can't even agree what 'objects' are and people did a lot of programming before the term 'object' was invented.
Programming is about is fundamentally about instructions and data. Yin and yang of two things that are completely different, even if people can occasionally mix them and conflate them.
I'm surprised I hit a nerve with so many people. I'm quoting someone who's considered one of the greatest mathematicians. Obviously I don't know the backgrounds of people but it seems like programmers have strong opinions on what math is that disagrees with what mathematicians say they do.
At what point does the abstract description just not offer any useful insight anymore?
I'm surprised I hit a nerve with so many people.
A lot of people had very good explanations for why you're pretty far off in trying to say two things are the same.
Programming is much more like building a machine than any sort of straight math. There is state, there is interactivity, there is performance, there is IO and there are real world implications to all of it.
Saying they are the same is like saying gardening is plumbing just because you sometimes use a hose.
> [No,] it's not math it's 'category theory'
That's a wild claim considering Category Theory is a branch of mathematics | Category theory is a general theory of mathematical structures and their relations.
- https://en.wikipedia.org/wiki/Category_theory
It is necessary that you provide an alternative definition as to what "category theory" is, though I suspect it will make many category theorists and mathematicians upset. > A lot of people had
A lot of non-mathematicians disagreed with mathematicians.
https://news.ycombinator.com/item?id=43882197It's not a wild claim since you misquoted me.
A lot of non-mathematicians disagreed with mathematicians.
Mathematicians can claim whatever they want, when it comes to programming, programmers understand it better and they're trying to explain to you why this is nonsense. Vanderbilt claims to be "the harvard of the south" but wouldn't you know it, harvard doesn't claim to be "the vanderbilt of the north".
Show me programming languages designed by mathematicians to be 'mathematically pure' and I'll show you a language that hasn't been used to ship software that people want to use.
In other words: It's math in a sense that for most of us with a computer science background is often not very relevant to how we work.
I find this distinction useful in the abstract, that one can engage different parts of the brain for different components of development. This probably explains why a well-written DSL can be so powerful in the right context.
Firstly, computer science is math.
Secondly, I remember covering graphs in a discrete math course back when I was in college.
> What if you do it in SQL?
SQL is more-or-less a poor implementation of relational algebra. Ie, math.
But it's hardly a useful grouping any more. You can study and do well in computer science with minimal knowledge of most of the core mathematical subjects.
While graph theory certainly crosses over into math, you can cover most of the parts of it relevant to most computer science as a discussion of algorithms that would not be the natural way of dealing with them for most mathematicians.
You will fail at Theoretical Computer Science without mathematical proficiency. Go read some textbooks and papers in theoretical CS. It is a subfield of mathematics. Theorems and proofs. Rigorous and difficult mathematics.
I wrote my MSc thesis on the use of statistical methods for reducing error rates for OCR, and most of the papers in my literature review hardly required more than basic arithmetic and algebra.
So I stand by my statement.
Sure, there are subsets of computer science where you need more maths, just like in any field there are sub fields where you will need to understand other subjects as well, but that does not alter what I claimed.
EDIT:
Some authors are quicker to pull out the maths than others, and frankly in a lot of CS papers maths is used to obscure lack of rigor rather than to provide it. E.g the problem I ran across when writing my thesis was that once you unpacked the limited math into code you'd often reveal unstated assumptions that were less than obvious if you just read their formulas.
I agree is not a useful grouping in practice. I'm just interested in what makes you think like you do.
What I claimed was that in computer science we often discuss things in terms that would not be the natural way of dealing with it in maths. We do that because our focus is different, and our abstractions are different.
It doesn't mean it's not math. It means it's not useful to insist that it isn't a different field, and its obtuse when people insist it's all the same.
So how much of programming is maths? Before we answer that, let's answer: How much of maths is actually maths? Because first we define maths, and then we define programming based on whatever that is, but until we have that first concrete definition this discussion cannot occur.
I will add that "it is taught by the maths department in college" is a flimsy argument, and frankly one the Physics department in particular would mock.
That means that definition shifts over time. For example, courses on numerical analysis, graph algorithms, programming, and on compilers used to be part of “what you’d learn in a math department”.
It likely also even today will show geographical variation.
Just like in math.
BTW relational DBs are math.
It's funny, reading the post you're replying to, I basically read it as
> I don't need math, I need <math, but by another name>
My teenage daughter used to complain about math, and I spent some time trying to explain to her that we use math every day... EVERY day. Now, when I see her do something that was math (even if it's not obvious it was math), I say "Math... every day". I say that a lot.
Also, yes, my daughter finds me annoying. But also funny; but likely not for the math thing.
> I don't need math, I need <math, but by another name>
This seems to be how it always goes. I think we've confused a lot of people by conflating math with arithmetic.