Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Immutability of Math and How Almost Everything Else Will Pass

blog.hackerrank.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: The Immutability of Math and How Almost Everything Else Will Pass

#41

Post by henrik_w »

arghbleargh wrote: post #26

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…

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

Re: The Immutability of Math and How Almost Everything Else Will Pass

#42

Post by arvinsim »

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

Re: The Immutability of Math and How Almost Everything Else Will Pass

#43

Post by sklogic »

arghbleargh wrote: post #26

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…

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.

Re: The Immutability of Math and How Almost Everything Else Will Pass

#44

Post by kaeluka »

arghbleargh wrote: post #26

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…

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.

Re: The Immutability of Math and How Almost Everything Else Will Pass

#45

Post by InclinedPlane »

arghbleargh wrote: post #26

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…

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.

Re: The Immutability of Math and How Almost Everything Else Will Pass

#46

Post by varjag »

js8 wrote: post #29
varjag wrote: post #18

Earlier quoted context omitted.

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…

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.

Re: The Immutability of Math and How Almost Everything Else Will Pass

#47

Post by TheOtherHobbes »

js8 wrote: post #29
varjag wrote: post #18

Earlier quoted context omitted.

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…

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.

Re: The Immutability of Math and How Almost Everything Else Will Pass

#48

Post by js8 »

varjag wrote: post #46
js8 wrote: post #29

Earlier quoted context omitted.

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…

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 t…

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

Re: The Immutability of Math and How Almost Everything Else Will Pass

#49

Post by Xcelerate »

imron wrote: post #28
semi-extrinsic wrote: post #14

Earlier quoted context omitted.

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.

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?)

Re: The Immutability of Math and How Almost Everything Else Will Pass

#50

Post by js8 »

TheOtherHobbes wrote: post #47
js8 wrote: post #29

Earlier quoted context omitted.

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…

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.
Post reply on HN