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

41–50 of 256 posts

Re: Think in Math, Write in Code

#41

Post by m3at »

1. Identify a problem 2. Design algorithms and data structures to solve it 3. Implement and test them ... In practice, work is not so well organized as there is interplay between steps. You may write code to inform the design.

As the author acknowledged, real life rarely allow such clean division.

One tool that I find very useful to interleave the three - or at least to allow shorter loops - is jupyter notebooks. The name is quite accurate, it can be used as a notebook to come up with solutions, and can easily be discarded once used. Unlike prototype code which has a tendency to evolve into the final codebase.

It's a common tool in data science but I'm not sure about other fields. Has someone used it for other purposes?

[1] https://jupyter.org/

Edit: formatting

Re: Think in Math, Write in Code

#42

Post by rowanG077 »

mannykannot wrote: post #16
rowanG077 wrote: post #11

Earlier quoted context omitted.

Really? I think the best way to solve a problem is to code it. I can never see all the corner cases and logical inconsistencies before I start typing. I have tried to formally model software before I start writing it and in the end it was largely a waste of time because real understanding of the problem comes with coding the solution. Of course when doing it like this you write a lot of code which later is unused or…

Really? yes, it is very common. The problem of this approach is that it does not scale to large systems. If you don't spend much time on thinking in the abstract about how it will work and what might go wrong, then, by the time you have written enough code to find that out, you may have gone a long way down the wrong path, and not all architectural-level mistakes and oversights can be patched over. No-one does this p…

If you want to have low quality solutions that kinda work on the first try then sure go for it. Your approach will inevitably lead to insurmountable technical debt that can't be paid off.

Big projects should be cut into smaller pieces where each piece can be relatively easily rewritten.

Re: Think in Math, Write in Code

#43

Post by segmondy »

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…

Mathematics and programming are strongly related more than most people think.

http://www.norvig.com/spell-correct.html How did he solve it? Using probability theory and sets.

It's not just games, cryptography, finance, signal processing, compression, optimization, and AI that require mathematics, tons of programming does most people just don't realize it and brute force their way to a solution.

Lot's of real world problem can be solved with algebra, calculus, Boolean algebra, linear algebra, geometry, sets, graph theory, combinatorics, probability and stats. What typically happens is most programmers are giving a problem, and what do they do? They start thinking in code. How did we solve problems before computer?

Apply that kind of thinking, then solve the problem with mathematics. Your code will often be much smaller and dense. Sure, dealing with output and input doesn't require you to write mathematical code, but the core of your problem can often be solved with some mathematics.

Re: Think in Math, Write in Code

#44

Post by xhgdvjky »

codr7 wrote: post #7

It's not math, though. It's abstract reasoning, as is math. And that's about as deep as the similarities go. Math can't deal with imperfect input and/or side effects without turning into something else. And code without real world side effects is useless, as is real world perfection.

side effects are an implementation detail

Re: Think in Math, Write in Code

#45

Post by drbojingle »

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…

What do you mean by math though? Are you focusing on numbers? Usually when I thing about math I'm thinking about boundaries and how inputs effect outputs. Those things do matter to programmers.

Re: Think in Math, Write in Code

#46

Post by cartlidge »

onion2k wrote: post #5
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.

I do that. Then people hate me because all my variable names are single letters... Then you're thinking in math and also writing in math, so you're getting the second bit wrong. You need to write in code, and code should be optimized for readability.

I thought the point of code is to make it more difficult for the non-initiate to read it...

Actually, I think a good, justly polymorphic function should probably have a word of a reasonable length and parameters that are called `a`, `x`, `f`, since the parameters convey almost no information. If they have any greater length, it's just a restatement of the known information about the type.

The more unique information a name conveys, the less information the types convey and the bigger a chance you have of bugs or coding yourself into a hole.

But also, if you've called it `x` hopefully there's only one thing it can be and its scope is just one or two lines so you've written a single unit. If there's anything else `x` could be, then you've got a problem - your unit is too much.

Not every piece of code should be written this way, but your vocabulary should be built up of pieces like this.

Re: Think in Math, Write in Code

#47

Post by grovehaw »

gitrebase wrote: post #4

I like that Python is quite close to my raw thoughts for simple problems. So writing an algorithm in Python almost feels like writing pseudocode. Heck, these days given an option between writing pseudocode and writing Python code, I choose Python for simple problems. Is there a similar programming language that makes mathematicians feel at home? Something that makes them feel that they would rather write their implem…

Some people feel at home with APL (A Programming Language) or its descendants. It was first developed by Ken Iverson as a notation to be used on paper for communicating procedures and algorithms. It was the subject of a book published in 1962, then became a programming language running on IBM mainframes in 1966.

The following line of code produces all the prime numbers below the value R.

  (~T∊T∘.×T)/T←1↓⍳R
More history and a full explanation of this code can be found at https://www.computerhistory.org/atchm/the-apl-programming-la...

Re: Think in Math, Write in Code

#49

Post by indigochill »

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.

For that matter, use self-documenting names in math, too. And please don't recycle notation for completely unrelated concepts, even if they are in different fields.

Coming to math from computing, the only explanation I can come up with for the disaster that is mathematical notation is that mathematicians are universally sadomasochists.

Re: Think in Math, Write in Code

#50

Post by mannykannot »

rowanG077 wrote: post #42
mannykannot wrote: post #16

Earlier quoted context omitted.

Really? yes, it is very common. The problem of this approach is that it does not scale to large systems. If you don't spend much time on thinking in the abstract about how it will work and what might go wrong, then, by the time you have written enough code to find that out, you may have gone a long way down the wrong path, and not all architectural-level mistakes and oversights can be patched over. No-one does this p…

If you want to have low quality solutions that kinda work on the first try then sure go for it. Your approach will inevitably lead to insurmountable technical debt that can't be paid off. Big projects should be cut into smaller pieces where each piece can be relatively easily rewritten.

> Big projects should be cut into smaller pieces where each piece can be relatively easy rewritten.

To come up with the right smaller pieces, you have to think about how they will work together to achieve the big picture. That means interfaces and their contracts, and if you get them wrong, you end up with pieces that don't fit together, and do not, collectively, get the job done.

Big problems cannot be effectively solved in a bottom-up manner, and perhaps the most pervasive fallacy in software development today is the notion that the principle of modularity means you only have to think about code in small pieces.

Post reply on HN