The Immutability of Math and How Almost Everything Else Will Pass
blog.hackerrank.com
blog.hackerrank.com
To me, the primary value of math for programming is that it is a pure form of exercising many of the skills that help you write good code. For example:
- fluency in logical reasoning
- turning vague intuitions into precise statements (translating business requirements into code)
- formalizing proofs (covering all cases, establishing invariants)
- developing abstractions to succinctly describe relationships
- solving a problem systematically
You can also learn these skills by programming, of course, but probably not as quickly, because you will be distracted with other tasks such as debugging, setting up your dev environment, waiting for your program to run, etc. So in my opinion, what's important is not so much the immutability of the math itself, but rather the process of doing the math. I would be interested to know if others have had similar experiences.
That said: this might be a reason to teach less maths in schools. If someone can invent a good informatics curriculum for children, then it's OK if it eats into class time for maths, because the (hypothetical good) IT subject will teach them some of the most skills underpinning maths.
You might like the Bootstrap curriculum: http://www.bootstrapworld.org/ It's developed by the PLT research group behind Racket and How to Design Programs. Very good stuff.
Sample quote: "Once you realize that computing is all about constructing, manipulating, and reasoning about abstractions, it becomes clear that an important prerequisite for writing (good) computer programs is the ability to handle abstractions in a precise manner."
On the other hand, what gets overlooked, IMO, is the "other stuff". Humanities, law, business, biology, take your pick!
When faced with a problem, a programmer is always looking at at least two issues:
1. to implement, 2. to understand the problem domain.
I see math being exceptionally helpful in 1), but at most somewhat helpful in 2) -- because at the end of the day, programs that we write tend not to be about math, or logic. Category theory does not help you understand the contract your company signed with some other company 12 years ago, and the amendments they made 7 years ago. It does help you implement these things concisely and correctly. What'd would help you understand would be for a programmer to know something about contracts.
Most programmers that I know have a certain talent for and knowledge about math. Most programmers that I know, also don't know a lot about the world outside of computers. That includes me, fwiw.
I think that their careers would profit from considering learning some non-mathematical domains more than from learning more math.
I'm not arguing against math, but I'm arguing for a good balance. To know at least the basics of some other domains, before you set out to learn a lot about one.
I think the reality is the opposite of what you suggest, programmers are in no way an example of a profession where most practitioners have a deep and extensive knowledge. For most programmers, the learning method is finding out how to DO things (as in, find an example on the internet, try it, it works, I'm done) without actually understanding anything.
You must be very lucky in where you work if you think programmers know a lot of math and even know what "category theory" is.
> As a field we are way behind most other fields in how well we know our own field.
I'd be surprised if that was so. I think we have a tendency to idealise other fields' achievements :) Additionally, I think you're using a scientist as a role model for a programmer. I don't think that's a good role model. Most programmers are technicians, not scientists. They produce products, not knowledge.
> You must be very lucky in where you work
Hm. It is the case that I'm lucky! I work at a University, in a PL group. So the people around me daily have better math foundations than most. I'll admit that there is bias in what I say.
And I don't see why you think the average programmer knows less about the law than someone in another non-legal profession. In my experience this is simply not the case, and yes, reading about it on the internet is better than not reading about it at all. It's not like dentists spend their time reading actual law books. Honestly, I have no idea where you get this from, it sounds absolutely wrong, but I guess we'll have to agree to disagree on this.
I don't think that the average programmer knows less about the law (or any other field) than someone in another non-legal profession, I think that they know about the same amount. But they should know MORE about the other professions, because most programming jobs have to do with commerce, law, design, what have you. Software products almost always have to do with a domain that is not software. A dentist has little use for law in his working life, but a programmer is more likely to profit from a basic understanding.
One thing that is special about the programming profession is that it is very diverse in levels of skill. And that's not only ok, I think that's a good thing.
I think this diversity is connected to a few things, one of them:
Our work product is very cheap to copy, and in the resulting economy, a small difference in utility will lead to huge differences in market share. Given a large market, this makes it reasonable to hone your skills further, where in other professions you'd be facing diminishing returns much earlier. This applies more to software that is widely used -- it has a larger market. Given a small market, this applies much less. In other, oversimplified, words: if you're writing software that is used (directly, or indirectly) by thousands, it pays off to train yourself for an extra year, even if it increases the utility of your product by only a small percentage. On the other hand, if you're a freelancer building web pages for a local business (a market size of 1), you're not going to profit much from the increase in utility.
Becoming Carmack makes sense in a large market. In a small market, it doesn't make sense to try to dominate it, but to acquire new markets.
So in the real world, this is what causes me problems - actual problems with a large application that cause friction with clients - people being bad at programming and not knowing even the most basic computer science and math, mostly manifesting itself in the application becoming littered with inefficient code over time (the second most common problem being lack of or superficial technical knowledge, such as using a framework or even language without understanding how it works under the hood, this usually manifests itself in the same way).
Note that the "I don't need to know math/cs" people will often not realize they needed something because they will just solve the problem incorrectly, inefficiently, or decide it is not possible to solve efficiently and compromise on requirements. What's worse, even if they are shown the error of their ways multiple times, they almost never truly change their mind, regardless of evidence. It is a mindset people seem to commit to early in their career, or even to a more general version of the same mindset in childhood, and never change it. That's why there's so many of them.
Sure, there might be situations where it is not useful to be a better programmer than you are. But I would say that is not the norm. I don't work on some algorithmically-super-complex application, it is just a typical large application used by professionals for their work; it doesn't involve any truly difficult problems but has a huge number of relatively small and easy problems all over the place. I'd say it's somewhere in the middle of the software development spectrum.
I think this speaks more for the "inferiors" (programmers) not against it. You can make syntax in math represent anything but practically mean nothing, having programmers in fields where they could make big mistakes, points to its power.
Quite recently, mathematical knowledge was reserved for the "elite" in part because of the dense amount of esoteric grammar that exist in math, and i would say still is. Alot of things can be expressed in multiple ways like geometry, algebra. The "real" math you speak of is instilled convention.
Sometimes the most efficient way is not always the best way and correctness only exists in the framework itself.
If you are going to compare math and programming then you first have to acknowledge that math is also just a language, to express certain concepts in which itself is quite littered with dead and inefficient code.
The fact that the grammatical and syntax constraints of higher math are mostly applied ad-hoc in proofs,rings,fields means you can keep refining some fraction of it ad infinitum thereby giving the illusion of correctness but in its essence is a rich mans PHP.
There is nothing wrong with mathematics and it is certainly not reserved for "the elite" whatever that is supposed to mean.
Convention is irrelevant except to ensure other people familiar with the convention can easily know what you're talking about. For programmers it is especially irrelevant as we usually only care about finding solutions to problems.
Correctness does not "only exist in the framework itself". If I ask you "if there are 6 people in the room, is it possible that among them there is no group of 3 which know each other and no group of 3 which don't know each other" the only correct answer is "no". The fact that this concept has a name in mathematics does not make the answer "no" any less correct.
Dismissing the importance of mathematics because you somehow find it "elitist" is anti-intellectualism at its worst.
No, but most programming is definitely not engineering. Math savvy people will definitely be needed - more in some areas than in others, but it is silly to have something most people don't have use for in their daily work as a requirement.
The point being is that there is a need for people with engineering skills, but there is also a need for people with craftman skills. Perhaps what we are seeing is the early stages of different education paths to the different roles?
As for the different points:
"Number theory. If you’re ever asked how one algorithm or data structure performs over another"
Err, no. That would be courses in analysis, calculus or numerical calculation courses, or courses in discrete analysis if you can find one. Number theory is what you use to understand stuff like encryption.
(Also, the popups was very annoying on the page)
I disagree. We don't need people with craftman skills, or better to say, we shouldn't need. Because once you can define what is craft, then computer can be programmed to do it.
At work, I still code in (mainframe) assembler sometimes. It's a craft, but it has been largely replaced by compilers. Where it cannot be replaced by compiler (which is definitely not the case of my job), it becomes engineering.
Of course there is messiness that was mostly introduced by people, which makes lot of engineering rather trivial, and you can call it a craft if you stretch it. But that's mostly an artifact of doing things wrong.
Now what actually requires engineering is a whole another perspective. I'd argue most software development jobs are closer to "renovate the kitchen" than "calculate building wind load" type of work. Also remarkably in construction, the latter task turned out to be much easier to automate.
And why people need different kitchens? Cannot the differences required be resolved by configuration, do they have to be resolved by programming?
I argue that everybody having different kitchen is inefficient and wrong approach to software development.
Waterfall was never in favor - IMHO programmers (or software engineers) always recognized that there software has no good analogue to reality, and there is nothing like a blueprint for software.
> And why people need different kitchens? Cannot the differences required be resolved by configuration, do they have to be resolved by programming?
Sure, if all your want is say IKEA kitchen with IKEA appliances. Some people have genuinely different needs.
If you skip the modelling part and just build things you hope are going to work - and you can't be precise about when, if, or why they might not work, or how long it's going to take to build them - you're not doing engineering.
> I still code in (mainframe) assembler sometimes. It's a craft
You seem to be contradicting yourself. Unless you are saying that you use assembler even though you don't need to.
"It's a craft, but it has been largely replaced by compilers".
Yes, that's what I am saying. The use of assembler is historical legacy, so that's similar to how my mother does embroidery for restoration work (and also for fun!) even though she could just use CNC loom or something fancy like that.
This is what scared and convinced me to relearn Mathematics. I hated it when I took it up before but I realized that the coolest jobs requires it.
However, after a few months of self-learning, I discovered that the hard part is not learning the concepts. It is structuring your learning in such a way that you can retain what you learned after a few weeks.
It has been a challenged for me to do. Learning new higher level concepts exposed my gaps in learning the fundamentals.
So apart from the mandatory calculus, statistics and linear algebra, as an engineer I took functional analysis, operator algebras, group theory, and intro to hilbert spaces.
Interestingly, lambda calculus is a different language (syntactically) for mathematics than classical logic, so the connection is not obvious.
I think programming will eventually become more mathematical, due to this connection.
And category theory, in the case of Haskell. (and yes, to work with Haskell at a basic level, category theory isn't required. But as someone who is learning the basics of category theory, it sure helps understand the "why" behind a lot of things if you move to a more advanced level.)
I end up spending large amounts of time figuring out the meaning of all the various symbols in the paper and how I can map that to an actual computer program.
Thankfully I have enough Math in the back of my mind to work through it, but good luck getting in to the really interesting things (e.g. machine learning, 3d graphics, whatever) without having a good mathematical background. Without it, you'll lose first hand access to almost any paper written on the topic.
Combine that with the frequently terrible and all-too-often incomplete source code that's provided as a reference implementation...
Slang is created and perpetuated mostly for fun or historically for hiding from others (e.g. gay slang, black slang, thief slang), changes quickly, and doesn't compress much information, mostly encodes a word with a different word.
The only common thing with slang is that its a dialect constrained to a specific group of the population (mathematicians).
// This is where your code starts executing
int main( int argc, char *argv[])
{
// repeat 10 times, with i counting up from zero up to nine
for( int i = 0; i < 10; i += 1)
{
...
}
}I wish more time had been utilized in high school to explain all of the notation that I would need to know later on. It's difficult to Google symbols. (More recently, I spent a few hours trying to figure what a box with a times symbol in it means — in the context of the paper I was reading, it turned out to be the outer tensor product of linear group representations. Who would have guessed that?)
And, how do you introduce that in high school? Would you be able to wrap your head around the generic concept of exterior products back then?
It's more the notation (edit: and yes, the content aware compression) - I'm sure it's completely obvious to people who see/deal with it regularly, and I can appreciate its compactness, but unless it's a really simple one, the raw equations are just gobbledygook and often it's only after I've mapped it to some sort of pseudo-code that it starts to make sense for me and I can figure out what's going on.
It's a point of pain for me whenever I read a technical paper - almost to the point that I've toyed with the idea of building a 'math equations for programmers' site that helps deconstruct mathematical equations to programming form.
The truth is that I found my math education was a strange liability. I removed my math minor from my resume, as it prompted math based interviews. Having a Google interviewer go: "I see you have a math minor, so I'm going to ask you some math questions!", followed by the guy getting frustrated for 30 minutes, isn't a great experience.
Um, what? I mean, apart from some fancy/hypothetical cache aligning nonsense, I have no idea how this makes sense. Maybe someone can explain?
"Is CS a subfield of math or is math a subfield of CS?"
This is quite an interesting question because I watched a Robert Harper lecture where he argues the latter.
In a nutshell proofs can be mathematical objects and in particular they can be seen as programs.
You can both represent all math expressions in the form of computer programs (what makes programming a superset of doing Math), and can represent all programs as mathematical expressions (what makes doing Math a superset of programming).
"A number of people involved with the effective altruism movement have recommended Jane Street Capital as a place to work at for people considering earning to give, and some of the full-time employees as well as interns have been from the effective altruist community.[7][8][9][10][11] In September 2012, Tim Reynolds, one of Jane Street's co-founders, stepped down from the job to redirect his energies towards the philanthropic pursuit of teaching poor students to master photorealistic painting.[12]"
The author isn't going to make friends of mathematicians by declaring MATH as a subfield of CS in a diagram that looks like an org chart (because it's from a Forbes article? :-))
I was once righteously scolded after saying that logic was "merely" the physics of information. I learned a lesson.
We all can do better with more cross-pollination of different fields of study and less categorization.
When I was interviewing we were always asking basic probability and combinatorics questions. They should probably only talk for themself.
The graph in this article seems to indicate the latter, but i'm pretty sure that's not right. and how is AI a subfield
Take this breathless assertion for example:
> "[S]oftware development is quickly shapeshifting. If you discount mathematics, and in turn focus on learning transitory programming tools, you’ll be left without the skills necessary to adapt to emerging computer science concepts that have already started infiltrating engineering teams today. Without expanding mathematical knowledge, these software engineers are going to risk being left out of the most exciting, creative engineering jobs of the rapidly approaching future."
i.e. If you don't know math, in the future you'll miss out!
Not really. Adaption is a key skill of developers. Developers will adapt to whatever the future of software development brings. (And if not, there's plenty of maintenance to do!) Mathematical ideas only "infiltrate" software engineering to the degree that software engineering can accept them. It's a continuous process. Sooner or later, software engineering either absorbs a mathematical idea (e.g. relational algebra) or the idea passes out of fashion.
On the other hand, it has always been true that mathematics is part of many of "the most exciting, creative engineering jobs," for example: programming the Apollo guidance computer, implementing systems to predict the weather, designing the Page Rank algorithm, programming self-driving cars, simulating music synthesizers, or designing physics simulations for games.
So yeah, math is one of the places where the fun stuff is at, but you're not going to lose your job without it.
On the other hand, knowing CS fundamentals will probably help you adapt better than knowing CSS and some JavaScript.
> "We’re far beyond the point of needing engineers to code simple solutions."
I don't think so. The bulk of software development work is in integrating 3rd party components, refining user interfaces and marshaling data between communication and storage formats/APIs. From a coding point of view, this is relatively simple stuff -- but doing it at scale, at speed, with quality and finesse still takes great skill, care, and time. We're not "far beyond" this.
> "[A]re we all really still going to be coding web and mobile apps 10 years from now?"
Maybe not web and mobile, but there will be an equivalent.
One thing is certain, we're not all going to be coding machine-learning predictive data analytics engines from scratch. That is specialized work. If it's important enough to become mainstream, it will become componentised and commodified. Yes, there will always be companies developing the industry-leading "AAA games engine" or equivalent, but this is by no means the only way to participate in the market.
A final point: Software that is built on specialised knowledge (e.g. mathematical models, but it could also be physical, biological, psychological or other domain-specific models) often needs to be wrapped in a lot of non-specialised infrastructure in order to make it function as a product. There will always be roles for domain-specialists with software development chops, and these will be well-paid, fun jobs worthy of aspiration, but there will also be plenty of work for people who specialise in software (e.g. infrastructure, UI, networking, operating systems).
[edited to fix typo]
As a web developer, most of my skill have to do with designing user interfaces and API's, learning various libraries/languages/frameworks, defining problems, estimating, communicating with other humans, etc.
But I've had a 30 year career in software development (covering everything from low level comms software in the 80s through to workflow automation software today) and I never got further than A level maths - which for non-Brits, is the exams you typically do at around 18. I don't feel the lack of a university maths background has ever particularly held me back.