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

181–190 of 256 posts

Re: Think in Math, Write in Code

#181

Post by oeoeo00 »

dkarl wrote: post #171
misterdoubt wrote: post #136

Earlier quoted context omitted.

Ah, well, you just described the relative value of math in much the way I'd describe the relative value of... well, just about any intellectual pursuit. Same in philosophy. Or in law. Or in physics. A lot of people with particular interest in one area -- say, mathematics -- don't realize that much of what is important is much more generally applicable. It's not that these things are distinctly important for math. It'…

That's true to a certain extent, but math and programming share the property of being built up from logical building blocks that are combined in strict logical ways. Law and philosophy are built on language and culture; physics is closer but is empirical. Math and programs are built from logic, and this gives them more of a common aesthetic sense. For example, in law or philosophy, repeating the same argument multipl…

It’s possible I am misunderstanding you, but think I agree with this.

There’s kind of two ideas going on here (in this thread in general), I think.

One seems to be of a mindset I’d describe as thinking in math means glomming onto knowing linear algebra.

The other seems to be thinking in interconnections, minimalist definitions, and those abstract concepts that exist in math (and all kinds of things) for connecting discrete ideas into composite ideas.

One thing that bugs me is code with overly specific semantics, where it reads like that’s the only problem the code could solve.

When if it’s broken into concepts and abstraction in the PLANNING stage the code ends up being less verbose and descriptive of the human problem and more useful for a variety of problems.

So instead of code to balance a checkbook, I’d write code to add/subtract numbers and input numbers from my checking account.

I see a whole lot of code with too much specific semantic meaning. And it ends in practice that we think code in one system is highly specific to that system and minimizes effort to reuse.

At least that’s been my experience at work. Ymmv

Re: Think in Math, Write in Code

#182

Post by tonyarkles »

munificent wrote: post #155
chongli wrote: post #115

Earlier quoted context omitted.

What you're describing is a very limited view of math, resembling the general public view of math as being algebra, trigonometry, geometry, and calculus; that is, all the math people are exposed to in secondary school. Look further and you'll see disciplines such as mathematical logic, combinatorics, and graph theory, without which you wouldn't have networking or binary or computers at all, really. I don't know what…

> that's a special case of the field of optimization, another mathematical discipline. I'm not sure how you can claim that the entire field of optimization is a "mathematical discipline". Algorithm analysis is, I suppose, but most other practical optimization work has little if anything to do with math. When I've spent time doing optimization work, it has often involved things like: * Discovering some API I'm using i…

I'm not sure why you're being downvoted, but I agree with all of your points. Those aren't things that really lend themselves well to mathematical modelling. But... there is a huge field of math that does apply to this: statistics.

The first two cases are somewhat special:

- It may be immediately obvious that an API is terrible, and that the replacement is not. If API 1 takes 1 sec to call, and API 2 takes 100ms to call, easy choice without stats.

- Caching can be dangerous. While not really a stats problem, you do need to have a really solid model of what is getting cached, and how to know when to invalidate those cache entries.

For the rest of the examples you provided, you're making changes that may make the problem better, may have no effect, or may make the problem worse. You absolutely need to use statistics to determine whether or not changes like those are actually having an effect. Performance analysis is part math and part art, and without the math background, you're likely going to be spinning your wheels a bunch. Beyond stats, fields like queuing theory are going to make a huge impact when you're doing performance optimization in distributed systems.

Re: Think in Math, Write in Code

#183

Post by [deleted] »

geomark wrote: post #112
Junk_Collector wrote: post #82

Earlier quoted context omitted.

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.

Sure, I can see that. But isn't it similar with language and other subjects? You just learn the basics, nothing deep, no turns of phrases, little expressiveness. Perhaps there is little correlation between those who excel at coding at a young age and those who go on to be good programmers when they get older. I just find it interesting that at this young age I see a correlation between coding skills and language skil…

[deleted]

Re: Think in Math, Write in Code

#184

Post by kd0amg »

agentultra wrote: post #164
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 not really all that related to each other I may be wrong but I believe the Curry-Howard correspondence disproves your claim. One can translate between the two and find that they are equivalent. The difficulty is that some programming languages are hard to model mathematically due to the way they were designed and implemented. Some, like Idris or Agda, make it easy to see the correspo…

Curry-Howard maps typical practical tasks on the programming side to completely useless make-work on the math side. Turning a customer's name and address into text to make a mailing label has to happen at some point, but you really don't need to go through all those steps to show that if customers exist, then strings exist.

Re: Think in Math, Write in Code

#185

Post by ben509 »

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 often take the compromise technique: write a prototype and build off that.

The prototype is generally a mess, but I throw that out anyway.

Re: Think in Math, Write in Code

#186

Post by davesmith1983 »

This sort of of article seems to come up every so often. The vast majority of programs are boring programs that are replications of business processes that were on paper in the past. The vast majority of code I have written is "if the user is from this country and they have an address show this screen". That is business rules and I would wager outside of specialist fields that is the vast majority of the work that programmers do.

Before I was a programmer I studied mechanical engineering. There is a lot of maths in that and the closest thing you get to programming is Control Engineering.

Re: Think in Math, Write in Code

#187

Post by raegis »

hwayne wrote: post #169
pron wrote: post #126

Earlier quoted context omitted.

I prefer TLA+ (it's both simpler and more powerful than PlusCal), except when specifying something at the code level (e.g. something like weak-memory-model concurrency algorithm).

For 95% of people, PlusCal will suit them just fine. I'm starting to see people say "I shouldn't learn PlusCal because it's not really TLA+", get disheartened about how difficult TLA+ is to learn, and believe they aren't able to use formal methods. I'd rather 10 people use a slightly-more-limited tool than 1 person use "the real thing".

I have the same opinion about the beauty of TLA+ vs PlusCal, so I find PlusCal frustrating to read. But I don't think the original poster was giving a dismissive opinion of PlusCal. Lamport's genius here is that he made TLA+ accessible via PlusCal. I appreciate this, as well as the video lectures which he made because he "realized that people don't read anymore...".

Re: Think in Math, Write in Code

#188

Post by thaumasiotes »

braythwayt wrote: post #13
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…

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.

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

How do you make a statue of an elephant?

Re: Think in Math, Write in Code

#190

Post by sound1 »

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…

This. If you are solving a mathematical problem then think in math, if you are solving an accounting problem then think like an accountant. Programming is a general purpose tool to solve problems in various domains. Just because computer science has roots in math doesn't mean computer programs must also behave same way. General purpose computing and absractions weren't invented for nothing. [Disclaimer: didn't read the article]
Post reply on HN