I very much disagree. I suppose it depends on how exactly you define "far"... but I've been a professional programmer for 15 years now, and have very little math skills (maybe some algebra? mostly forgotten by now, and calculus always escaped me).
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.
"But is downplaying the importance of math a sustainable message for future generations of engineers?"
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.
> 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.
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.
Potentially all of the programming can be, and most likely will be replaced by machines, so it's a moot point. Until then, there are tons of programming jobs that are poor fit for automation but are definitely thin on engineering challenges.
It really depends on what you consider to be engineering. Traditionally, engineering was creation of a "blueprint". Once you had that, someone had to actually build the thing in the real world (the craftsmen). But in software? The blueprint is the final product!
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.
I would argue with waterfall model (naïve translation of engineering to software) being out of favor for decades now, almost nobody actually makes "blueprints" for software. Agile, XP and TDD is basically "put something together and make sure it doesn't fall apart when we ship it".
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.
> most software development jobs are closer to "renovate the kitchen"
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.
There are ISO standards for what is known as waterfall model, from block diagrams (the actual blueprint) to project flow. It was the only model in widespread use before time-sharing systems and then personal computing came to dominate the market. The Mythical Man-Month was written as an argument against established practice in the field then.
> 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.
Engineering is the process of modelling reality mathematically to save time and money while building useful things.
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 disagree. There are plenty of people who I would consider excellent engineers, both in software field (Linus Torvalds) and outside it, but they are not doing any mathematical modelling (except in the sense I outline in the other comment). They are just using lots of heuristics, experience and common sense. But in more mature fields, like mechanical or electrical engineering, such approach is more historical, since the theory and modelling is very well developed. Still, to restrict engineering only to that sounds very wrong from the historical perspective.
> Unless you are saying that you use assembler even though you don't need to.
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.
I did pretty well in math, both in high-school and in university, (Comp Sci degree, with Math a compulsory first-year subject), and when I try looking at a paper describing an algorithm in some Comp Sci related field it's literally all greek to me.
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.
It's not arcane notation, it's content-aware compression at work. When a mathematician sees a small greek delta with subscripts ij, they immediately know it's the Kronecker delta. If every paper would explain every convention and notation in the field, all papers would be huge and much less readable for those working in the field.
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).
Indeed. Making it easier for beginners to read is like writing:
// 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)
{
...
}
}
Yes, it's very much this. There is so much established convention and if you don't know that convention, then it involves a non-trivial amount of time to work through it and figure it out.
I remember the first time I saw \mathbb{R}^n. I thought "What the heck does that mean?!"
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?)
The problem is rarely the math, and when it is, I can always find the explanation behind it.
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.
An anecdote from the other side: I trained in Mathematics before I ever did any serious programming, and have taken only a handful of proper CS courses from a theory-heavy institution in math-heavy areas (i.e. they were math classes first, and programming was mostly an afterthought). The result is that I actually find pseudo-code descriptions of algorithms far harder to work with than equations. Without a good overview, I just see a collection of vaguely related code-statements, and not a design until I've put a lot of effort in. On the other hand, I can usually grasp the point of something expressed as an equation much more rapidly, if only because my previous experience gives me more heuristics to rely on.
Agree. The term ‘computer’ itself comes from the word ‘compute’ as computer is built primarily to help human compute numbers. Many interesting real life problems can be modeled as mathematics problem - Halim & Halim, 2011
I have all the wrong math. I got discrete math in CS - number theory, formal logic, and combinatorics. Now you need more real-number math - probability, statistics, and matrix algebra.
My best advice is to take the fun math, whatever that may be. If a class is fun, you learn it properly, so you will be much more able to adapt the concepts and strategies to other problem domains.
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.
When you use information to deduce information about information, you're doing both I guess. Abstract math was elusive to me in college because it was folding over itself, there was no concrete object layer as before. Anything could be reflected about. Sets of applications from sets of applications to sets of sets. After looking at lots of CS ideas I kinda recognize this too. You encode relationships between anything and deduce new relationships.
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).
There is other big connection between math and programming, which article completely ignores - functional programming (from the mathematical side it corresponds to various lambda calculi).
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.
No idea why this is downvoted. If you are a functional programmer you can lean on maths all day, and get wonderful correctness guarantees for your programs. The maths is typically very simple algebra, but it's there.
> functional programming (from the mathematical side it corresponds to various lambda calculi)
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.)
As someone who has done a fair bit of both math and programming, I will agree that having some math knowledge has definitely helped at various times when programming, but I don't think these specific instances (e.g. the 10 examples given in the article) constitute the primary reason it's a good idea to learn math. For the purposes of handling those specific situations, I think you would do fine to just learn the math as you encounter the need for it (and 95+% of the time you don't need anything beyond high school).
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.
This comment sums up my own thinking better than I could have. Though if the pure functional approach gains more ground, the link between maths will become more direct -- writing a Haskell program feels a lot like writing a formal proof of an algorithm. And all proofs are maths.
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.
Agree 100%. The strong connections between FP and maths make the programming in an FP language very much like doing maths. Usually very simple maths, but that's a good thing.
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.
Exactly! Keith Devlin also made this point in an article (from 2003) in Communications of the ACM called "Why universities require computer science students to take math" (pdf) ftp://ftp.gunadarma.ac.id/.upload/Communication-ACM/September-2003/p36-devlin.pdf
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."
Exactly. Programming is mathematics, all of it. It is not just overlaping with mathematics in few peculiar areas but it is nothing but mathematics and must be treated as such.
I agree with what you say, but it seems obvious to me.
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 disagree, I would say most programmers know too little math and even too little computer science. As a field we are way behind most other fields in how well we know our own field. Yet most programmers are somewhat familiar with many other fields because they spend a lot of time reading about stuff on the internet.
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.
I don't think that reading about stuff online leads to knowledge, just like repeating writing the same boring CRUD app over and over again won't make you a much better programmer.
> 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.
I am not using a scientist role model. I am using a role model like Linus Torvalds, John Carmack or Eric Lippert. Would you disagree that these are good programmer role models? They have DEEP knowledge, not just "hey man have you seen the latest javascript framework".
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.
These are role models that I personally very much agree with. At the same time, the industry has need for relatively few people like them. Of course, if every programmer would magically turn into them, that'd be great. But no one turns into them over night. And I think it's obvious that it makes no sense honing yourself into a perfect logical machine of deadly precision, if tomorrow you're still writing the same boring crap. Most programmers have boring jobs. Not because they're bad, but because most software being written is solving boring problems.
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.
I think the average programmer makes many more mistakes due to not knowing computer science and math / lacking a deep understanding of programming than due to any other deficiency like not knowing laws. It is at least true for the programmers I've worked with and have not been satisfied with.
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.
The language of computation is now a common tongue and of course there will be people who master it poorly or who you perhaps would call inferior.
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.
Mathematics is a tool that you as a programmer are supposed to be able to use (among other tools) to solve problems.
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.
For me I found that having an education in math made me a better scientist, and being a better scientist made me a better developer. Having a background in mathematics makes you very sensitive to when and where assumptions get made, as well as very exacting about the line of reasoning between evidence and conclusions. It's surprising how common unchallenged assumptions can be in science, but in development work it's practically a disease. Troubleshooting and root cause analysis are extremely important parts of dev work, and it's amazing how bad the average dev is at it. Prone to jumping to conclusions and ready to blame the usual suspects even when the evidence doesn't match.
Math is good and can be useful. I went back to school after 15 years to study math (currently studying for a Complex Analysis final.) If people are interested, I would encourage them to study math, whether or not they think they are "good at math." However, I disagree with most of this article.
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).
> In the next 10 years, software engineers aren’t still going to be limited to programming web and mobile apps. They’ll be working on writing mainstream computer vision and virtual reality apps, working with interesting cryptographic algorithms for security and building amazing self-learning products using machine learning. You can’t go very far in any of these fields without a solid mathematical foundation.
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.
> Number theory. If you’re ever asked how one algorithm or data structure performs over another, you’ll need a solid grasp of number theory to make that analysis.
Um, what? I mean, apart from some fancy/hypothetical cache aligning nonsense, I have no idea how this makes sense. Maybe someone can explain?
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.
This is more than slightly tangential, but that article led me by two steps to the Wikipedia article on OCaml based prop trading shop Jane Street Capital, which contained this very odd paragraph:
"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]"
I took a number of math classes, but I've forgotten the overwhelming majority of it. It's hard to remember anything if you never use it for a full decade (my French is gone too). That's not to say I haven't used math, but I just look it up or learn it as needed.
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.
Yes I agree, math is extremely important for people who would like to become a Computer Scientist or Computer Engineer. The vast majority of people learning programming in school are not going to do that. Making these people learn these topics and possibly turning off potential students is counter productive. Many people could gain a lot by just having basic programming skills, and those people are scared off by any mention of the word math.
67 comments
[ 2.7 ms ] story [ 122 ms ] threadAs 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.
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.
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
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).
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.
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.
"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).
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.)
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.
When I was interviewing we were always asking basic probability and combinatorics questions. They should probably only talk for themself.
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]
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.
Um, what? I mean, apart from some fancy/hypothetical cache aligning nonsense, I have no idea how this makes sense. Maybe someone can explain?
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.
"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 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.