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

91–100 of 256 posts

Re: Think in Math, Write in Code

#91

Post by j7ake »

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…

You could be provocative and say even computer science and programming are not very related. Traditional computer science education involves much more chalk and blackboard and less keyboard typing.

Re: Think in Math, Write in Code

#92

Post by newen »

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…

I have a math undergrad, didn't program much until my senior year. Then went to grad school in computer science. Learning data structure and algorithms was very easy for me compared to other students who came from non-math non-CS backgrounds because writing math proofs and designing algorithms are very very similar and use similar though processes and methods. Udi Manber's Introduction to Algorithms show how you use mathematical thought processes to design algorithms.

Re: Think in Math, Write in Code

#93

Post by mannykannot »

zbentley wrote: post #83
mannykannot wrote: post #55

Earlier quoted context omitted.

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

Well, yes, it is a useless analogy... Oh, you meant to say that comparing bridge-building to software development would be a useless analogy? It's not an analogy I made - the point is that just because you can make a cute analogy, it doesn't mean it offers any insight.

> I'm really tired of people being dogmatic about either approach

Exactly - and the implication that I am being dogmatic is a straw man. I am simply opposed to arguments that depend on poor analogies.

Furthermore, all of the bad things that you say can happen if you try to think ahead are as least as likely to happen if you don't, and especially if you have gone in the wrong direction for some time (I know the latter is a manifestation of the sunk-cost fallacy, but it happens a lot on real projects.)

Re: Think in Math, Write in Code

#94

Post by 0x445442 »

rowanG077 wrote: post #78
mannykannot wrote: post #55

Earlier quoted context omitted.

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

Building software is not even remotely the same thing as building a bridge. It would be more akin to the architect creating the drawings twice for the bridge. Once as an exploratory version and the second one the production version. Oh wait that is actually how architects work. In fact at my work we have multiple CAD designers(not architects though) and it's not uncommon for them to completely throw away a design and…

I'll bet the engineering process of the software written for the Apollo 11 lunar lander was much closer to the bridge building process than you might think. I'll also bet there's a whole host of software projects which use similar processes today. It's just that most of us writing DB skins for "The Enterprise" are rarely, if ever exposed to real engineering for the simple fact that quality software is expensive and typically, our organically grown solutions are good enough.

Re: Think in Math, Write in Code

#95

Post by mannykannot »

rowanG077 wrote: post #78
mannykannot wrote: post #55

Earlier quoted context omitted.

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

Building software is not even remotely the same thing as building a bridge. It would be more akin to the architect creating the drawings twice for the bridge. Once as an exploratory version and the second one the production version. Oh wait that is actually how architects work. In fact at my work we have multiple CAD designers(not architects though) and it's not uncommon for them to completely throw away a design and…

Your designers are working with abstract models. They are thinking about problems at a conceptual model, they are not putting up structures and seeing if they work.

Re: Think in Math, Write in Code

#96

Post by rowanG077 »

mannykannot wrote: post #95
rowanG077 wrote: post #78

Earlier quoted context omitted.

Building software is not even remotely the same thing as building a bridge. It would be more akin to the architect creating the drawings twice for the bridge. Once as an exploratory version and the second one the production version. Oh wait that is actually how architects work. In fact at my work we have multiple CAD designers(not architects though) and it's not uncommon for them to completely throw away a design and…

Your designers are working with abstract models. They are thinking about problems at a conceptual model, they are not putting up structures and seeing if they work.

code is also an abstract model.

The CAD designers absolutely test if things work. Why do you think almost every engineering bureau has 3D printers.

Re: Think in Math, Write in Code

#97

Post by hutzlibu »

sidlls wrote: post #60
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.

On the other hand the sculptor has considered the type of clay, the quantity, the tools she'd need to use to carve away those bits, and understands enough about what she wants to create to know what bits to carve away first. Programming may not be (all) math, but it's not art, either.

"Programming may not be (all) math, but it's not art, either."

Huh? Maybe the kind of common 8-5 office programming around buisness logic is not, but to design any bigger project is definitely art.

Re: Think in Math, Write in Code

#98

Post by mannykannot »

rowanG077 wrote: post #84
mannykannot wrote: post #50

Earlier quoted context omitted.

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

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

That's beside the point. The point is that coding is not the only way to verification, especially at the architectural level.

> I really don't understand why people want software to be different.

It seems to be you who wants to be different. Making prototypes is expensive and time-consuming, so engineers try to look ahead to anticipate problems. Prototyping in software is cheaper, but not so cheap (especially at the architectural level) that thinking ahead isn't beneficial.

Re: Think in Math, Write in Code

#99

Post by gaze »

rowanG077 wrote: post #11
LandR wrote: post #9

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

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…

I have found that the gap in understanding between thinking you understand something and implementing something as a program is often much smaller than the gap between having programmed something and having proven it.

Re: Think in Math, Write in Code

#100

Post by FridgeSeal »

codr7 wrote: post #31
_v7gu wrote: post #12

Earlier quoted context omitted.

Well, you have Maybe for imperfect inputs and monads for side effects.

But Haskell isn't math, it's code dressed up in a math costume.

Haskell is code (attempting to) implement category theory. It’s about as close to a programming language representing maths as we have (probably along with APL type languages)
Post reply on HN