Think in Math, Write in Code • Hacker News Board

Re: Think in Math, Write in Code

#241

Post by codr7 » Fri, Jul 19, 2019, 3:29 PM UTC

wa1987 wrote: post #132

codr7 wrote: post #128

Earlier quoted context omitted.

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.

Haskell and others have pretty much proved it's possible in practice as well. But from my experience the cure is worse than the disease. Wishing that software was as formal as math is one thing. Pretending it is leads nowhere worth going.

I have most of my feet in the C++/Common Lisp camps these days. Where you accept that the world is a messy place with complex problems that don't fit neatly into labeled boxes, and use the most powerful tools you can think of to deal with it.

Re: Think in Math, Write in Code

#242

Post by codr7 » Fri, Jul 19, 2019, 3:36 PM UTC

Syzygies wrote: post #162

FridgeSeal wrote: post #100

Earlier quoted context omitted.

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)

My first language (not counting Basic or Fortran on punched cards) was APL, and my current language is Haskell. I'm a PhD mathematician. Luckily, I was trained far enough down the street from MIT to escape their Lisp world view, so we coded our computer algebra system in C, and it was fast enough to succeed and bring us tenure. Today, we'd choose Haskell. Thinking in Haskell is the same feeling as thinking about math…

Haskell is definitely one of the languages that looks most like math. Being used to math, and solving math problems, I can certainly see how that's helpful.

Making the jump to stating that everyone would be better off coding math style, which is what some are desperately trying to pull off; doesn't make any sort of sense.

It's remarkable how far you can get within such a rigid and formal framework. But for most messy real world problems, there are better solutions. Lisp being the most powerful invented so far.

Re: Think in Math, Write in Code

#243

Post by hinkley » Fri, Jul 19, 2019, 5:24 PM UTC

higherkinded wrote: post #231

hinkley wrote: post #216

Earlier quoted context omitted.

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…

How come math's to blame? That's clearly just some nuts level of incompetence that spawned all of spaghetti described. Lack of any conscious effort. After all, the mathematical thinking mentioned in the article inevitably includes covering the corner cases of the problem at hand as well as of the solution proposed, not to mention simplification and generalization. That's not trying to be smart, that's outright being…

Math isn't to blame. But neither is it the solution.

Re: Think in Math, Write in Code

#244

Post by 1PlayerOne » Fri, Jul 19, 2019, 6:08 PM UTC

TrackerFF wrote: post #113

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…

Well, from a practical standpoint, it's more desirable to put out a partially-working system fast, which can be improved upon as it is live - than spend too much time planning and implementing a fully working system. Note: By partially and fully, I simply mean systems with more and less bugs. Rarely do companies and startups have the luxury to just lean back and take their time. It's a race against competitors, and e…

So true. Slick presentation, indifferent or bad design and implementation. And then patching and billing client all the long day. Sad!

Re: Think in Math, Write in Code

#245

Post by lunias » Fri, Jul 19, 2019, 8:45 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…

I agree a lot. Mathematics intersects with programming when you use programming to solve mathematical problems. I find that that happens rarely for me (although it has happened). I feel like the biggest boons for programmers are having a good grasp on logic, pattern recognition, category theory, and the process of abstraction.

Re: Think in Math, Write in Code

#246

Post by eximius » Fri, Jul 19, 2019, 10:43 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 don't find math to be "free and flexible," at least, not compared with prose.

Then you haven't done math to a sufficient level. Which most people don't if they aren't math majors.

I'm not talking about calculus or differential equations, etc. Even engineers and CS focuses too entirely on calculation (though CS has its own kind of proofs which are more what I'd call math). Besides mathematicians, only physicists occaisionally look at math this way.

At a certain point, math is about proofs which are a kind of rigorous prose. My math tests in upper level courses were done in essay blue books up to 10 pages of single space text, on one particularly long test.

There are multiple ways to prove a theorem. There are multiple ways to write a program. Some are shorter, some are longer. Some are more cryptic and hard to follow. Some rely on the work of others to outsource your own efforts. They are really quite similar except for math doesn't have a compiler (Coq and it's I'll excluded).

Re: Think in Math, Write in Code

#247

Post by kragen » Sat, Jul 20, 2019, 3:37 AM UTC

grovehaw wrote: post #47

gitrebase wrote: post #4

I like that Python is quite close to my raw thoughts for simple problems. So writing an algorithm in Python almost feels like writing pseudocode. Heck, these days given an option between writing pseudocode and writing Python code, I choose Python for simple problems. Is there a similar programming language that makes mathematicians feel at home? Something that makes them feel that they would rather write their implem…

Some people feel at home with APL (A Programming Language) or its descendants. It was first developed by Ken Iverson as a notation to be used on paper for communicating procedures and algorithms. It was the subject of a book published in 1962, then became a programming language running on IBM mainframes in 1966. The following line of code produces all the prime numbers below the value R. (~T∊T∘.×T)/T←1↓⍳R More histor…

A fairly precise raw Python translation for the interested:

    T = range(1, R)[1:]                       # T←1↓ιR
    u = [[t*u for u in T] for t in T]         # T∘.×T
    v = [t for ei, t in
          zip([any(t in ui for ui in u) for t in T], T)
         if not ei]                           # (~T∈u)/T

As the standard poem on the subject by Dave Touretzky and Don Libes says:

    I wrote some hacks in APL,
    each on a single line.
    They're mutually recursive,
    and run in n-squared time!

In this case, of course, it runs in R-cubed time, not n-squared time. There's a perhaps more common, but slightly longer, APL one-liner for finding primes that does run in O(R²) time instead; from https://aplwiki.com/SieveOfEratosthenes †:

   (2=+⌿0=(⍳X)∘.|⍳X)/⍳X

Or, eliminating the inessential variations from the above version:

   (2=+⌿0=T∘.|T)/T←⍳R

If you want APL and are stuck with Python, you can probably get most of the APL you want in Numpy. A slightly looser translation of the first algorithm into Numpy:

    import numpy

    T = numpy.arange(2, R)
    print T[~numpy.equal.outer(T, numpy.multiply.outer(T, T)
                               ).any(axis=1).any(axis=1)]

Recent versions of Numpy have numpy.isin, which works like APL ∈, which would save you the .outer.any.any nonsense.

A much more compelling demonstration of APL is, in my mind, the interactive development process leading up the the one-liner Game of Life in this livecoding video: https://www.youtube.com/watch?v=a9xAKttWgP4

† This is not the Sieve of Eratosthenes, despite the article title; the Sieve is an immensely more efficient algorithm than trial division, producing the same results in near-linear time.

Re: Think in Math, Write in Code

#248

Post by dr0wsy » Sat, Jul 20, 2019, 9:50 AM UTC

naturlich wrote: post #215

dr0wsy wrote: post #211

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

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

Thanks! You don't happen to have some learning resources for modelling programs as state machines? I can't find anything when I search.

Re: Think in Math, Write in Code

#249

Post by dr0wsy » Sat, Jul 20, 2019, 10:06 AM UTC

justinmeiners wrote: post #230

dr0wsy wrote: post #208

Earlier quoted context omitted.

Thanks for the article and discussion that sprang up around it! The question I'm trying to ask is how I should express (part of) programs on paper using math when I don't see how they are related to math. Example: How could I easily express a function that takes a string as input and outputs the string capitalized using math notation? I understand that the problem you solve in the post should probably be put on paper…

This is a great question. What I really tried to emphasize in the article is that math is not a formal language. Since its just you and coworkers, write out the parts you need as you need them, and ignore details. After all, its an exercise to help you think. If I needed uppercase I would just say: `up(s)` is a function that maps a string s to its uppercase string Writing that down, you and I already have a pretty go…

Thanks for the explanation! An example to check if I understood you correctly.

  `func1(r, s)` is a function that sends a request `r` to a given server `s`. It returns a status code from the server.

How does that sound? It feels more like a spec than "doing math".

> I highly recommend that book I linked in the article: "Introduction to Graph Theory" By: Trudeau

I'll check it out! Does the book cover all the relevant parts you mentioned before?

Btw, it seems you don't link the book in the article. At least I couldn't find it when looked now.

Re: Think in Math, Write in Code

#250

Post by UK-AL » Sat, Jul 20, 2019, 2:41 PM UTC

codr7 wrote: post #125

JustFinishedBSG wrote: post #56

Earlier quoted context omitted.

> Math can't deal with imperfect input and/or side effects without turning into something else. It very much can though.

Not in any sense that matters here, no. There's no math equation for reading from a socket. Code is not math and math is not code. It's possible to sort of hide the fact by stacking enough abstractions on top, but in the end it's going to be the same old code that makes it happen.

Linear types and session types can enforce protocols for reading from a socket.