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.
Think in Math, Write in Code
21–30 of 256 posts
Re: Think in Math, Write in Code
#22I think that the total programming man hours spent on writing pure math computation would be dwarfed by the much larger number (I think) spent on doing menial computation: fetching data, transforming it and sending it forward/rendering some output. I suppose this article is targeted at that privileged former group.
Re: Think in Math, Write in Code
#23Earlier 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…
Really? yes, it is very common. The problem of this approach is that it does not scale to large systems. If you don't spend much time on thinking in the abstract about how it will work and what might go wrong, then, by the time you have written enough code to find that out, you may have gone a long way down the wrong path, and not all architectural-level mistakes and oversights can be patched over. No-one does this p…
Re: Think in Math, Write in Code
#24It's not math, though. It's abstract reasoning, as is math. And that's about as deep as the similarities go. Math can't deal with imperfect input and/or side effects without turning into something else. And code without real world side effects is useless, as is real world perfection.
See stats, probability, information theory, and signal analysis
Re: Think in Math, Write in Code
#25There'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…
Re: Think in Math, Write in Code
#26I 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…
Re: Think in Math, Write in Code
#27I think that the total programming man hours spent on writing pure math computation would be dwarfed by the much larger number (I think) spent on doing menial computation: fetching data, transforming it and sending it forward/rendering some output. I suppose this article is targeted at that privileged former group.
Just because some tasks are 'menial', doesn't mean they don't involve math at some level. You still want to get your data transforms right, and make sure that what you're fetching/sending over is what these other services expect.
Re: Think in Math, Write in Code
#28Earlier 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.
Re: Think in Math, Write in Code
#29It's not math, though. It's abstract reasoning, as is math. And that's about as deep as the similarities go. Math can't deal with imperfect input and/or side effects without turning into something else. And code without real world side effects is useless, as is real world perfection.
> Math can't deal with imperfect input See stats, probability, information theory, and signal analysis
Here: Malformed
Re: Think in Math, Write in Code
#30I 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…
It’s exactly like Paul Graham says, you might think that Python is just allowing you to write executable pseudo-code, but the interaction isn’t so simple.
I’ve programmed a lot of Python and when I first started out, I felt like it was very frictionless, like you said. An easy way to put down thoughts. But as I learned more about functional programming and type theory, I realized that Python is inadequate and operates a top low level. i.e it feels like there’s so much friction there.
I have used a variety of languages professionally (Scala, Haskell, OCaml, Racket, C, and Python mostly) and they all fall short (some more than others) on what I feel like I should be able to express. But if I had to chose, I would probably say OCaml or Racket come the closest to my thoughts, depending on the problem.
Anyway, my point is that it’s not obvious how your tools affect the level and abstraction of your thoughts. It’s almost always a bi-directional relationship, and therefore, choosing (or making) the right tool and method of abstraction is very important. See Beating the Averages[1]. PG talks about the a hypothetical language called Blub. Blub isn’t the best, but it’s not the worst either. If there was a platonic form of Blub, it would most definitely be Python.