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

Think in Math, Write in Code

justinmeiners.github.io

Post reply on HN
Print view View original

141–150 of 256 posts

Re: Think in Math, Write in Code

#141

Post by hangonhn »

pgcj_poster wrote: post #67

I was surprised to learn that I really enjoy coding, whereas I rather dislike math. I feel like this article might resonate with some people, but not with me. > Programming languages are implementation tools, not thinking tools. They are strict formal languages invented to instruct machines in a human-friendly way. In contrast, thoughts are best expressed through a medium which is free and flexible. I don't find math…

I think I am reasonably good at math compared to the average person and really loved it growing up and I would also agree that coding is not that similar to it. Coding is a lot more "tactile". It feels much closer to the arts than to math. The idea that we can treat computing as something purely abstract has never come to fruition for me because there are a lot of details in CS and some details matter a lot.

When I was starting out in my career, I worked at a hedge fund. The fund had a bunch of physicists and mathematicians working on models and they actually wrote the code for those models. They wrote some of the worst code I've ever seen. For example, rather than structuring their code properly, they would use exceptions to pass messages around. If function A needed some information from many levels deep in the stack, they would just throw an exception with the message inside. Function A would catch the exception. These aren't actual exceptions but they didn't to refactor their code. As you can imagine their code had horrific performance.

If you abstract away all the details a lot of concepts and constructs in CS look very similar but some of those details that were abstracted away are going to matter a lot when the code is actually run.

Re: Think in Math, Write in Code

#142

Post by CaioAlonso »

"The natural language which has been effectively used for thinking about computation, for thousands of years, is mathematics."

I'm not sure if this is true. Harold Abelson creates the distinction[1] between Mathematics being the study of truth and Computing being the study of process. It seems to me that these really are different things and Mathematics isn't the "natural language" to discuss computations, but rather truth and patterns. But of course process (computing) can only happen within the boundaries of mathematical truths and patterns.

[1] https://www.youtube.com/watch?v=2Op3QLzMgSY the first few minutes

Re: Think in Math, Write in Code

#144

Post by kian »

warent wrote: post #8

There's an unpopular and somewhat seemingly contradictory opinion that I have regarding this, because this isn't the first time I've seen this topic brought up. Mathematics and programming are not really all that related to each other and I think there's an overemphasis on the importance of math in programming for 99% of applications. Sure, mathematical thinking can be useful, but it's only one type of logical thinki…

Mathematical thinking can be extremely useful for programmers who never touch 3d games, or physics engines, or anything else requiring calculus or matrices. Functions are mathematical objects, and can be combined using operators that obey mathematical laws into other functions - thinking of them in this way leads to the functional and concatenative programming paradigms. These combinations can also be rearranged in ways that also behave mathematically (i.e. according to simple rules that do not change, and have been explored for millenia), making it much easier to both refactor and optimize code. They can even be used as foundational abstractions for organizing your code, leading to horizontal rather than vertical abstraction - i.e., using the tower of abstract algebra or category theory types, we can organize our code in a way that anyone who understands that type will immediately grasp, whether or not they understand the internals. Math is everywhere, and you're using it, whether you know it or not. Might as well use it well.

Re: Think in Math, Write in Code

#145

Post by deadgrey19 »

philote wrote: post #110
deadgrey19 wrote: post #106

Earlier quoted context omitted.

How so? Can you give an example?

For example, if you do end up needing compression, are you going to write you own compression library or use an existing one somebody else already wrote?

I think you're missing the point. I'm talking about the concept of mathematically modelling the program first, before writing it (as per the article). This process only applies to certain types of applications, ones that are rooted in algorithmic transformations (like compression), rather than in system and I/O operations, like copying a packet from a network RX buffer into a disk block, in the most efficient way.

Re: Think in Math, Write in Code

#146

Post by auggierose »

warent wrote: post #8

There's an unpopular and somewhat seemingly contradictory opinion that I have regarding this, because this isn't the first time I've seen this topic brought up. Mathematics and programming are not really all that related to each other and I think there's an overemphasis on the importance of math in programming for 99% of applications. Sure, mathematical thinking can be useful, but it's only one type of logical thinki…

I'd say every type of logical thinking is math. Otherwise it wouldn't be logical.

Re: Think in Math, Write in Code

#147

Post by heinrichhartman »

I spent more than 10years in Academia doing math. One thing I loved about this time, is that I was able to sit down anywhere and pound at my current research problems, without having any additional notes or books with me. Just pen and paper.

Formal reasoning feels very empowering.

You write down assumptions, apply transformation, arrive at conclusion. Proof one Lemma at a time. Work through some examples. Eventually you arrive at a deeper understanding of the problem, and maybe even a solution.

When I started working in Software, I largely lost the ability to reason formally about the thing I am doing. Also I need manuals and computers around to make progress. This still frustrates me today. And I have tried hard to reason formally about code, to gain back this experience:

- Doing Lambda Calculus by hand is possible.

- LISP is already tedious (scoping rules/mutable state!).

- Register machines are a nightmare to do by hand (See Knuth's books)

- The semantics of C are nearly impossible to write down by hand, and work with.

I am excited about this blog post, because it shows a new way of approaching the situation. Model the problem domain with mathematical language, and leverage the Lemmas/Theorems in your implementation.

Some, food for thought. Thanks Justin!

Re: Think in Math, Write in Code

#148

Post by justinmeiners »

_zachs wrote: post #134

I disagree with the author’s points that you can’t represent a graph with a single interface. Write an interface with the methods you need, i.e., `findNeighbors()`, `getAllFriends()`, `retrieveDogPhotos()`, and implement it for the specific underlying data structure/implementation of Graph you choose later. A graph is a graph, the interface doesn’t care if you’re using an adjacency matrix or a node. I don’t see how w…

Can you represent Facebook's graph of friends as an interface?

Do you think they also do a lot of graph theory about it?

Re: Think in Math, Write in Code

#149

Post by nomel »

mannykannot wrote: post #38
mjburgess wrote: post #29

Earlier quoted context omitted.

That's a different sense of "imperfect", meaning, "inexact". Here: Malformed

There's some non-trivial math behind the methods for defining and selecting well-formed data.

And they tend to always accept data that is malformed to look like regular data.

Re: Think in Math, Write in Code

#150

Post by justinmeiners »

enriquto wrote: post #2

I do that. Then people hate me because all my variable names are single letters... At least, for functions use self-documenting names instead of "f", "g", as in math.

names work well in programs because the variable typically models something in the world we understand. company.name, NetworkConnection, etc.

In math and in programming this isn't always the case. Often you have a variable "epislon" that means "the tiny amount of space between this circle and the other circle that is shrinking".

In these cases there is no good name to give the variable. The meaning comes from the context.

In programming I follow the practice of using longer identifiers for more global scope, and shorter ones for smaller scope.

Which do you prefer?

(define (sqr x)(* x x))

(define (sqr number_to_square) (* number_to_square number_to_suqare))

Post reply on HN