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

21–30 of 68 posts

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

#21

Post by agumonkey »

bbcbasic wrote: post #9

In response to the dead comment "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.

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.

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

#22

Post by varjag »

agumonkey wrote: post #19
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.

In other words, slang.

No, the vocabulary. Slang is an alternative language for common concepts, not the case with math.

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

#23

Post by noelwelsh »

js8 wrote: post #16

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.

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

#24

Post by dllthomas »

agumonkey wrote: post #19
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.

In other words, slang.

Jargon.

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

#25

Post by gilgoomesh »

agumonkey wrote: post #19
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.

In other words, slang.

Slang is colloquial, local and rapidly changing. Technical language is formal, usually widespread and entrenched.

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

#26

Post by arghbleargh »

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.

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

#27

Post by imron »

douche wrote: post #7
imron wrote: post #5

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…

Is the problem there the actual math, or the obscure, arcane notation that's used to describe it? Combine that with the frequently terrible and all-too-often incomplete source code that's provided as a reference implementation...

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.

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

#28

Post by imron »

semi-extrinsic wrote: post #14
douche wrote: post #7

Earlier quoted context omitted.

Is the problem there the actual math, or the obscure, arcane notation that's used to describe it? Combine that with the frequently terrible and all-too-often incomplete source code that's provided as a reference implementation...

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.

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

#29

Post by js8 »

varjag wrote: post #18
js8 wrote: post #15

Earlier quoted context omitted.

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

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.

Post reply on HN