Think in Math, Write in Code • Hacker News Board

Re: Think in Math, Write in Code

#81

Post by UK-AL » Thu, Jul 18, 2019, 1:28 PM UTC

I honestly believe the majority of the problems in the industry comes from the refusal to treat programming as mathematics.

Everything has to be "easy", so anyone can understand from a basic level.

It's one of the reasons we don't like verifying software using TLA, coq(proofs for programs), refinement types or using functional programming techniques. "It's too difficult for the average programmer".

The first excuse is that we don't have enough time to do things "right". When I get the metrics in how much time we waste fixing bugs after the fact, then it moves on the too difficult argument.

The result is we have an entire ecosystem full of buggy unreliable software.

Re: Think in Math, Write in Code

#82

Post by Junk_Collector » Thu, Jul 18, 2019, 1:29 PM UTC

geomark wrote: post #71

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've been thinking about this quite a bit, but coming from a different angle. I've been helping at my kid's school with coding clubs for primary students. When teachers are recruiting for the coding club they always mention the students who are good at math as good candidates. But what I have noticed is that the students who do the best in coding are more often musically inclined or linguistically talented. It seems…

It's also worth thinking about that you don't really learn math in primary school so much as you learn numbers and computation, so when a teacher says a child is good at math they usually mean good at numbers. Very few teachers understand math well enough to identify who would be good at it and a lot of unfortunate students find this out when they get to college.

Re: Think in Math, Write in Code

#83

Post by zbentley » Thu, Jul 18, 2019, 1:30 PM UTC

mannykannot wrote: post #55

braythwayt wrote: post #13

Earlier quoted context omitted.

Writing a lot of code you later discard because it isn’t part of the final solution is like throwing clay on the table and then carving away the bits that don’t fit. Nobody criticizes the sculptor for the clay that ends up on the floor, and clay is heavy. We carve away bits, they have no mass and don’t need to be swept up, all we have to do is cut them away, revealing the final program.

This is not a useful analogy; it is more of an excuse for not trying to think things through. Would this be a reasonable analogy for building a bridge? If you don't have a reasonably detailed idea of what you want and how to achieve it, you are unlikely to get it. https://dilbert.com/strip/1991-9-6

> Would this be a reasonable analogy for building a bridge?

That is also a useless analogy. Do bridge builders get to test and re-test their bridges in the real, non-simulated world? Can they instantly make a copy of their bridge with a few critical differences and see how the two behave? Can they re-build their bridge in minutes?

Metaphors aside, I think history is ample evidence that "coding your way around a problem" rather than conceptualizing a solution first is a perfectly valid way to approach professional programming. It's not the only way, and it has drawbacks which others have pointed out here. So does the conceptualize-first approach: you might solve the wrong problem, make something inelastic in the face of changing requirements, or fall into the psychological trap of being attached to your mental model even when it turns out that you really didn't think of everything and have to make changes on the fly.

I'm really tired of people being dogmatic about either approach ("move fast and break things/pivot; anyone else isn't really interested in getting stuff done!", "you're just a messy code monkey unless you can hold the solution in your head before you start!"). It's almost always veiled arrogance rather than honest improvement-seeking, in my experience.

Re: Think in Math, Write in Code

#84

Post by rowanG077 » Thu, Jul 18, 2019, 1:34 PM UTC

mannykannot wrote: post #50

rowanG077 wrote: post #42

Earlier quoted context omitted.

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

That's my point you CANNOT possibly come up with the right smaller pieces until you have a solution that you have verified works.

What do you think other engineering principles do? They create a proof of concept. Verify it works and then create the real thing. That is why "real" engineering companies have hundreds of tools to test stuff.

I really don't understand why people want software to be different. You write some shitty throwaway web app then sure go ahead and don't prototype anything just hire a "software architect" that designs something and use that.

But do you want something that actually works then that is completely useless. Prototype, verify, start over if necessary. That is the way to write quality software.

Re: Think in Math, Write in Code

#85

Post by henrik_w » Thu, Jul 18, 2019, 1:37 PM UTC

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 too like find implementing the structures helps me find the solution. It's quite iterative for me. Also, I think of programming as a mix of math and writing:

https://henrikwarne.com/2019/03/30/programming-math-or-writi...

Re: Think in Math, Write in Code

#86

Post by arendtio » Thu, Jul 18, 2019, 1:41 PM UTC

IMHO, the biggest problem with math is the complex syntax. I mean, you can't just read it like a normal language, but instead, you have to know exactly what each symbol means and in which order they have to be evaluated.

It feels a bit like having a programming language that uses unique emojis as function names.

Personally, I find it much easier to read code (from a high-level programming language), than to read math formulas.

Re: Think in Math, Write in Code

#87

Post by cutler » Thu, Jul 18, 2019, 1:41 PM UTC

Mathematical thinking is only relevant to a subset of programming tasks. Your typical CRUD web app has nothing to do with maths but functional-style data processing may well fit the model. See DHH's distinction between engineers and developers where he characterises Ruby/Rails programmers as writers, many of whom come from an arts or humanities background.

Re: Think in Math, Write in Code

#88

Post by sixbrx » Thu, Jul 18, 2019, 1:43 PM UTC

pron wrote: post #33

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.

> Math can't deal with imperfect input and/or side effects without turning into something else. This is just not true. Differential equations certainly deal with change over time (except it's not called "side effects" there) and imperfections. The analog for discrete systems in temporal logic.

It's not called side effects there because there are none, in the modern mathematical formulation at least. The goal is to identify solution functions, and those are just sets of ordered pairs or something similarly inert.

Re: Think in Math, Write in Code

#89

Post by 0x445442 » Thu, Jul 18, 2019, 1:47 PM UTC

LandR wrote: post #9

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…

> Is this really a common thing? How can you try to implement something without first having had thought of the solution? Unfortunately, it's incredibly common. The result is always almost a mess. Functions that are never called, parameters that are never used, as they discovered their mistake as they were coding but then never went and cleaned up the stuff they don't use anymore. Broken logic, poor performance. Func…

Welcome to "Agile".

Re: Think in Math, Write in Code

#90

Post by optimuspaul » Thu, Jul 18, 2019, 1:49 PM UTC

lioeters wrote: post #59

kd5bjo wrote: post #19

Earlier quoted context omitted.

> Is this really a common thing? How can you try to implement something without first having had thought of the solution? There appears to be two distinct kinds of programmers that are about equally effective: ones that think through the problem first and then write down the solution on the one hand, and ones that start with something close and then iteratively refine it into the desired result on the other hand. Whe…

Fascinating, thank you for the link to the paper. They group these styles as: opportunistic versus systematic approach to programming. Paraphrasing below.. Opportunistic programmers develop solutions in an exploratory fashion, work in a more intuitive manner and seem to deliberately risk errors. They often try solutions without double-checking in the documentation whether the solutions were correct. They work in a hi…

I've always thought of those two groups using different labels. The Code Artists and the Engineers. The Artists have a strong need to be creating to understand something, whereas the engineer has a strong need to understand before they can create. And those that believe the programming is not an art fall into the latter group.