Think in Math, Write in Code • Hacker News Board

Re: Think in Math, Write in Code

#211

Post by dr0wsy » Thu, Jul 18, 2019, 10:07 PM UTC

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…

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

I didn't convey my question clearly. What I'm wondering is how I should express programs, or part of them, using mathematical notation when I don't see them being mathematical in nature to begin with?

An example:

  def hello(name):
      if (name == "Bob"):
          print("Hello, " + name)
      else:
          print("Hello, World!")

How could I express this easily using mathematical notation?

It just feels weird that to convey this simple program on paper both I and the person I try to communicate with needs to have a grounding in category theory.

Hope you're able to understand my question. :)

Re: Think in Math, Write in Code

#212

Post by anaphor » Thu, Jul 18, 2019, 10:08 PM UTC

raegis wrote: post #187

hwayne wrote: post #169

Earlier quoted context omitted.

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

The video lecture series is amazing and should be mandatory viewing for any CS or SE program IMO.

Re: Think in Math, Write in Code

#213

Post by [deleted] » Thu, Jul 18, 2019, 10:08 PM UTC

TeMPOraL wrote: post #37

mruts wrote: post #32

Earlier quoted context omitted.

I’ve always thought that you don’t really understand a problem until you have a solution to it. What I like to do is first write a naive solution to a problem so I can understand it better. Then I throw away the code and start again. I invariably learn a lot more about a problem and the most elegant solution than I would have if I had just tried to write a perfect solution right off the bat. Code, after all, is cheap…

The problems we're solving when building software happen simultaneously at different levels. Some are best solved by prototyping. Others are best solved on a whiteboard. The trick is correctly identifying the problems, and then knowing which layer they belong to. If you try to code up a prototype for a design problem, you'll most likely waste a lot of time and not reach any useful conclusions in the end (or end up sh…

[deleted]

Re: Think in Math, Write in Code

#214

Post by jhayward » Thu, Jul 18, 2019, 10:22 PM UTC

1PlayerOne wrote: post #203

segmondy wrote: post #43

Earlier quoted context omitted.

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

I used to believe as you do until AlphaZero learn to play Go and Chess by itself and discovering new strategies in the process.

By using tensor calculus.

Re: Think in Math, Write in Code

#215

Post by naturlich » Thu, Jul 18, 2019, 10:25 PM UTC

dr0wsy wrote: post #211

naturlich wrote: post #130

Earlier quoted context omitted.

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…

> 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`. I didn't convey my question clearly. What I'm wondering is how I should express programs, or part of them, using mathematical no…

That was the second part of my answer: a graph on paper. Draw nodes of execution and represent the branch as two arrows coming from the node and heading to new nodes. Label the arrows with the predicates of the branch.

This is both definitely useful and definitely math.

Re: Think in Math, Write in Code

#216

Post by hinkley » Thu, Jul 18, 2019, 10:28 PM UTC

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…

My second job, the project had been run by a couple of vocational developers. They did okay. No version control, lots of corner cases not covered, lots of code that made inferences from incomplete data. But the team needed to grow significantly and none of this stuff was going to survive other people touching the code.

One of the bad patterns in the code was very complex nested boolean logic in places. Often with the same condition in several branches.

So I started using K-maps to untangle these. A few of them were much easier to read, but some of them... some of them it was unclear that all the cases were addressed. So I started putting big block comments above those, but we all know what happens to block comments over time.

Much later, big conditionals like that I would just move to a separate function, and then split em up to look like normal imperative code, instead of like math.

The first rule of teamwork is stop trying to be so goddamned clever all the time. It's like being a ball hog in basketball, football, soccer. Use that big brain to be wise instead. Find ways to make the code say what it means and mean what it says. Watch for human errors and think up ways to avoid them.

Math has very, very little to do with any of that. Psychology is probably a better place to spend your time.

Re: Think in Math, Write in Code

#217

Post by vikiomega9 » Thu, Jul 18, 2019, 10:41 PM UTC

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…

What you're describing is not optimization the math field, and second _some_ of the example do have basis in mathematics.

> Discovering some API I'm using is particularly slow and finding an alternate one that's faster. On it's own it has nothing to do with Math, but writing code as components/services/abstract layers with well-defined boundaries/interfaces/types mean it's easier to reason about the code and avoid bugs. Implicitly here I'm saying we should use a language that has strong type support.

> Adding caching. This is memoization and without the basis that general code functions should behave like their math counterparts this is hard to reason about.

> Reorganizing code to take advantage of vector instructions These are mapping operations that are well defined in functional languages. The vectorized interface numpy provides is an abstraction of maps.

> Making objects smaller to put less pressure on the GC This is orthogonal to the actual math basis for the code. For example using enums over strings is a localized change.

Re: Think in Math, Write in Code

#218

Post by filoleg » Thu, Jul 18, 2019, 10:41 PM UTC

optimuspaul wrote: post #90

lioeters wrote: post #59

Earlier quoted context omitted.

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.

A pretty good essay I've recently read that explores this topic.[0]

0. http://www.paulgraham.com/hp.html

Re: Think in Math, Write in Code

#219

Post by bcrosby95 » Thu, Jul 18, 2019, 10:44 PM UTC

justinmeiners wrote: post #150

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.

names work well in programs because the variable typically models something in the world we understand. company.name, NetworkConnection, etc. In math and in programming this isn't always the case. Often you have a variable "epislon" that means "the tiny amount of space between this circle and the other circle that is shrinking". In these cases there is no good name to give the variable. The meaning comes from the con…

Either over this:

(define (s x) (* x x))

Which is effectively what the OP does when they write their example. Their simple example quickly becomes unreadable after a few definitions.

Re: Think in Math, Write in Code

#220

Post by vikiomega9 » Thu, Jul 18, 2019, 10:46 PM UTC

If we start with the notion that everything is a model and that some are less wrong, then being as close as possible to math simply means the models are in some sense provably correct. Some models need more rigour in being proved as such.