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

131–140 of 256 posts

Re: Think in Math, Write in Code

#131

Post by jcora »

naturlich wrote: post #130
dr0wsy wrote: post #77

Earlier quoted context omitted.

> So if you want your programming to reap the benefits of (others', mostly) mathematical reasoning--use a functional language that is all about expressing the ways in which things compose! I do prefer using functional language over imperative ones, but I don't understand that is connected to model software on paper? > IO is modelled pretty well through monads. As are many other things, like nondeterministic processes…

You don't need to know category theory. You just need to understand a few things that came from it, like `Maybe`, which is the most obviously useful and trivially easy monad. Just forget about the fact that it's a monad and any general rules about monads and just learn how to use `Maybe`. From there, input handling is just a state machine. Easy to draw on paper as a graph. > Part of the benefits with modelling a prog…

> because you can also say

I don't think you can actually:D

I mean for each category of programmer there is a pretty clear line separating common knowledge from things you can't expect people to know. And for pretty much every category of programmer, if statements and category theory are the opposite ends of that line.

I mean I feel like you agree with this based on your first paragraph, his complaint isn't odd because it's saying you can't expect people to know category theory, it's because he thinks that category theory is necessary here.

Re: Think in Math, Write in Code

#132

Post by wa1987 »

codr7 wrote: post #128
wa1987 wrote: post #65

Earlier quoted context omitted.

> However, how should I express I/O? First thing that comes to mind is category theory, especially monads. Haskell's I/O monad for example: https://en.wikipedia.org/wiki/Monad_(functional_programming)...

But why? Having to sweet talk the compiler into simply reading/writing data by building towers of super abstract mathematical concepts doesn't look like a win from here. If that's the cure, I'll take the disease.

The question was about expressing I/O as a mathematical concept (on paper), not about talking to compilers.

Re: Think in Math, Write in Code

#133

Post by dkarl »

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…

Math has more aspects than just logical deduction via mechanical rules. Math also has an aesthetic aspect that guides people to find elegant, powerful solutions within the space defined by the mechanical rules. There may be many paths of deduction from point A to point B, which are all mechanically equally valid. But from the human point of view, they have different value. Some will be simple and easy to understand; others will rely on ideas from one or another realm of math, making them friendly to people who understand those ideas. Some will suggest, to the human brain, analogies to other problems. The mathematical validity of the argument is judged according to whether it correctly follows the mechanical rules, but all other aspects are judged by aesthetics and intuition and ultimately by how the solution is received and utilized by other mathematicians.

If the only aspect of mathematics that you bring into programming is logical deduction by mechanical rules, then I doubt it will help, except for rare cases where you prove or disprove the correctness of code. If, on the other hand, you bring over the aesthetic concern, the drive to make painfully difficult ideas more beautiful (ergonomic) for human brains, then it will help you make your code simpler, clearer, and easier for others to work with.

Is this really a common thing? How can you try to implement something without first having had thought of the solution?

It's common, and as you can imagine, it doesn't lead to good outcomes. When people start by coding first, it's so much work they tend to stop at their first solution, no matter how ugly it is. When people start by solving the abstract problem first (at a whiteboard, say) they look at their first solution and think, "I bet I can make this simpler so it's easier to code." The difficulty of coding motivates a bad solution if you start with code and a good solution if you write the code last.

Re: Think in Math, Write in Code

#134

Post by _zachs »

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 writing a mathematical function would be more robust and helpful in designing and implementing those features.

Re: Think in Math, Write in Code

#135

Post by seanmcdirmid »

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?

Some of us actually think by programming. In that sense, a REPL or notebook is probably a better medium, but the thinking is going on concurrently with prototyping.

It isn’t so much like “we are solving the problem at the same time we are writing the code for the solution” but more like “we are writing (disposable) code to help us solve the problem.”

Re: Think in Math, Write in Code

#136

Post by misterdoubt »

dkarl wrote: post #133
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…

Math has more aspects than just logical deduction via mechanical rules. Math also has an aesthetic aspect that guides people to find elegant, powerful solutions within the space defined by the mechanical rules. There may be many paths of deduction from point A to point B, which are all mechanically equally valid. But from the human point of view, they have different value. Some will be simple and easy to understand;…

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's that they are important for thinking.

Re: Think in Math, Write in Code

#137

Post by heinrichhartman »

arendtio wrote: post #86

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…

Oftentimes people make the mistake, of jumping directly to the formulas when reading mathematical texts. You will not have enough context to parse them!

Instead, think of a formula like a very dense sentence in a novel.

The protagonists are usually introduced in the paragraph before. You are assumed to know their names to make sense of the formula.

Re: Think in Math, Write in Code

#138

Post by seanmcdirmid »

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.

Math can be considered an art, though not a fine art. Programming by either extension is an art (though again, not a fine art).

https://en.m.wikipedia.org/wiki/Mathematics_and_art

Re: Think in Math, Write in Code

#139

Post by deadgrey19 »

chongli wrote: post #115
deadgrey19 wrote: post #102

Thinking in math first has been the catch cry of functional programmers (and their formal logic/verification friends) for decades. And there's nothing wrong with it, unless the problem you are trying to solve actually requires performance. Then, you have to think in "system" first. For example: Write a program that captures network packets and stores them to disk as fast as possible . There's no maths to think of her…

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…

What I'm discussing here is the general concept of modelling your program formally before writing it (as per the article). What I'm arguing is that this type of approach is only possible for a certain set of applications which take the form of y = f(x), where f(x) is some type of data transformation /computation operation (e.g. calculate the GCD of these ints, find the shortest path through a given graph, sort this set etc). There's another set of applications which I/O bound, are very important, and yet, the "computation" that they preform is limited to none. These applications are rooted in, and bounded by system parameters, like understanding how disks work, how network cards work, how CPUs work etc. This is an optimisation problem, but not one that can be modelled mathematically (in any reasonable way) because of the vast complexities of the system. Building a TLA+ "proof" of this system will reduce trivially to x = x, and yet, the system is still important, and difficult to write well.

Re: Think in Math, Write in Code

#140

Post by UncleMeat »

UK-AL wrote: post #81

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

Its difficult for all programmers. The tooling still isn't there.

Try verifying the correctness of a JavaScript program with model checking. It won't work. Or try verifying correctness with abstract interpretation. For any sound system the output will just be "Top".

We have very deliberately developed technologies that enable rapid development. For "make it so a little message appears on the screen saying what day it is" features this works very well but it means even our formal analysis methods fall over on dynamic languages with heavy framework use.

This isn't just laziness. I'm a hardcore PL person and even I think that soundness is largely a mistake when making real analysis engines.

Post reply on HN