Programming is not math • Hacker News Board

Re: Programming is not math

#101

Post by cowbell » Fri, Jul 18, 2014, 5:57 PM UTC

altcognito wrote: post #56

cowbell wrote: post #43

Learning a programming language is a lot like learning a human language, but understanding math is how you learn efficient programming. If you don't use mathematical reasoning, then you'll produce O(n^3) when you could have produced O(n). Any hack can throw together a script that will hobble along with 4 rows of data. Throw a million rows at the same script and it might terminate properly in a few years. Or maybe it…

You don't need mathematical reasoning to realize that loops within loops generate slowness. And as far as under-specifying versus over-specifying, I find that understanding the domain problem is better inoculation against horribly written code than understanding "inefficient" boolean branching. > lesser programmers are afraid to fix it Red flag.

It isn't just loops. It's everything.

http://highscalability.com/numbers-everyone-should-know

If you just had to say "avoid nested loops" there would be no problem. Programming a solution that works at scale requires math and understanding where you will have bottlenecks before you write a single line of code.

>understanding the domain problem is better inoculation

How does one understand a problem without understanding boolean algebra?

Example. You have good/bad credit, car/motorcycle, new/used, drivers license yes/no. Which combinations allow testDrive()? Now add condition 'ok' to credit, moped and 18 wheeler to vehicles, and commercial to driver's license, because the boss forgot about those. Now how many combinations? Who is allowed to do what? How do you arrange the code so you don't spend time evaluating methods when driver's license of 'no' can short circuit the entire operation? (oh, except for moped, in certain states)

That's entirely boolean logic. If a person is not good at that, they suck at programming AND understanding domain problems.

Re: Programming is not math

#102

Post by mamcx » Fri, Jul 18, 2014, 6:20 PM UTC

bediger4000 wrote: post #96

mamcx wrote: post #92

Earlier quoted context omitted.

The central idea of the linked post is that programming have long ago spread to more circles apart of math, and if in the past solve math problemas was the #1 activity that is not longer the case, and then, programming is dominated by other activities apart of math. But, some people insist to teach programming ignoring that and still thinking that programming is a tool for math. Now, I think is more right to say math…

It's really good that some form of craft programming has spread as "not math". But let's not kid ourselves that math isn't programming, and programming isn't math. It's like finding your way from St Louis to Chicago (in the US) or Rheims to Paris, say. You don't need to know that you're navigating on the surface of a spherical body. You just need to know a little map reading, or listen to Google Navigation giving you…

Yeah, but the problem (as you point) is that you can say that navigating is astronomy, or physics or relativity. But you don't call "traveling is relativity!", you call it traveling. Math, (classic) physics and relativity are ways to understand it, sure, even describe it, but what is more true than the other: classic physics, relativity, math?.

Here the problem is not about understanding the foundation of things, is about not apply to all the levels in the abstraction the same label. When you walk in the part you are NOT doing math. Your are walking.

This is the point expressed in the blog. It have not argued that programming is totally devoid of math, that math can't be used to formally think about it or something like that. Is that is better to think that programing is programing, and like you don't say "programing is relativity" then teach programming using relativity(!) and dismiss programing as a real, whole thing that only can be explained by relativity(!) and tell everyone that to be a good programmer you MUST understand very well relativity.

That is what the article is saying.

Re: Programming is not math

#103

Post by agumonkey » Fri, Jul 18, 2014, 6:41 PM UTC

Push side-effects away and you have maths. Imperative code conflates all the logical relationships onto big state. When you use functions or `algebraic types` you see the overwhelming presence of simple logic and recursion. Be it Lambda Calc, FP, Relational...

Re: Programming is not math

#104

Post by jordigh » Fri, Jul 18, 2014, 6:41 PM UTC

tel wrote: post #74

jordigh wrote: post #64

Earlier quoted context omitted.

> And half of mathematics is more or less the study of formal languages and their consequences? No, just a small fraction is: http://www.ams.org/mathscinet/msc/msc2010.html?t=&s=68Q45++F... This is but a branch of a branch (computer science): https://en.wikipedia.org/wiki/Mathematics_Subject_Classifica...

That's a really restrictive and explicit demarcation of "formal language". I'd happily describe logic as formal language and then go hunting for places which seem to have non-trivial interactions with logic.

Well, if you define it to be broad enough, then you are correct by definition.

My point here is that there is a big, broad cultural gap between mathematics and programming that you are not going to breach merely by saying that a lot of mathematics is about formal languages (in the nontechnical sense of "formal language").

Far from it. Most of mathematics does not talk about formal languages and most of mathematics itself uses very informal language. It looks forbidding to outsiders, but there are many linguistic styles, fashions, abbreviations, shorthands, jokes, puns, and conventions in mathematical writing, very little of which is easy to algorithmically feed into a computer.

Re: Programming is not math

#105

Post by kluge » Fri, Jul 18, 2014, 6:53 PM UTC

jabelk wrote: post #98

tel wrote: post #4

> Programming is Language. And half of mathematics is more or less the study of formal languages and their consequences? You can say that they're different in order to keep people who are scared of math from projecting those feelings to programming. Or you can say they're the same to draw deep insight between programming and one of the oldest fields of study of human kind. I find that people tend to reject the relati…

That was my thought too, math is obviously tied very closely to language. And programming did come from CS which came from math. Web/App dev is just so far downstream from all of the math, that people in those roles can get away with ignoring it. In fact, if you accept the premise of math as a language, most of the piece can be boiled down to: "language skills help programming skills, whether that language is mathema…

I think she was implying that college-dropouts that build software projects can afford to buy Teslas without understanding math.

Re: Programming is not math

#106

Post by tel » Fri, Jul 18, 2014, 6:56 PM UTC

jordigh wrote: post #104

tel wrote: post #74

Earlier quoted context omitted.

That's a really restrictive and explicit demarcation of "formal language". I'd happily describe logic as formal language and then go hunting for places which seem to have non-trivial interactions with logic.

Well, if you define it to be broad enough, then you are correct by definition. My point here is that there is a big, broad cultural gap between mathematics and programming that you are not going to breach merely by saying that a lot of mathematics is about formal languages (in the nontechnical sense of "formal language"). Far from it. Most of mathematics does not talk about formal languages and most of mathematics it…

Sure, and I'm not claiming that you must unify them. Or that you can't. I'm also not saying that the language of mathematics is a formal language, but instead that it shares structure with them. The very notion of the interplay between a theory and its model is not dissimilar.

I'm not trying to absolve a cultural gap. Nor am I trying to claim that if you dropped a mathematician into a programming role they would thrive, or visa versa.

I'm simply trying to claim that there is a whole lot of similarity between the two and refutations of that are silly. Seeking a clear-cut demarcation between fields is a little silly as an exercise.

Finally, exploiting the similarity is powerful. Both fields benefit from this fact already and the more widespread the idea is the better.

Re: Programming is not math

#107

Post by jerf » Fri, Jul 18, 2014, 7:21 PM UTC

ivanmaeder wrote: post #61

jerf wrote: post #31

Earlier quoted context omitted.

Programming is deeply and inextricably mathematical. However, most programmers don't actually know mathematics, so it's difficult to see that. This is further exacerbated by the fact that people creating APIs and libraries also don't know math, so they don't see it, and consequently design APIs and libraries that don't show mathematical characteristics. (This is not because they are "better"... it just means that mat…

I might be one of those people that don't realise that programming is math because I don't know enough math. I know about the classic algorithms, but I've never had to code any for real. And I haven't had to write a compiler. I know enough about graphs and trees to know when to use them, but don't ask me about all the different ways to traverse them, or the differences between red and black trees, and balancing trees…

"So do you think it's really a case of regular everyday programmers not being better because they don't know math?"

Causation is a strong claim, and I lack the evidence to back it up.

For an application programmer moving things in and out of databases, here's an example of the sort of thing you are dealing with all the time and may not realize how deeply mathematical it all is:

   1. There exists a set of Operations on the database.
   2. Each Operation has some characteristics:
      a. Atomic
      b. Consistent
      c. Isolated
      d. Durable
      and each of those statements itself carries mathematical content (for
      instance, almost all databases ship with ways of choosing what
      Isolation means).
   3. Operations may be composed into Transactions, which depending on how
      they are manipulated may or may not violate the properties of the 
      isolation itself.
   4. For each such Transaction, it may either Succeed, Fail, or do something
      probably-horrifying in between.

As you go to use the database, you need to understand these properties, how they work together, how to harness them best in your code and how to deal with when they break down (for instance, migrations often break transactions). As you write code that ties together database operations, you're doing mathematical work composing together various atomic operations to obtain the result you want. This is particularly obvious if you've ever written code that manages transactions yourself, but has to involve other various client-code function calls within the transaction; you rapidly get into the world of "recursive transactions" in one form or another.

How do we recognize a "mathematical" API? A more "mathematical" database will work to minimize the "do something probably-horrifying in between" cases. More of the compositions will be legal without breaking the Transaction promise, i.e., perhaps you will be able to roll back a schema change. The properties will be clearly spelled out for each operation, and the transaction will do a better job of maintaining them. Care will be taken to ensure that any data conversions are as "isomorphic" (for now, read "reversible") as possible, and will generally refuse to "guess" what something means.

By contrast, a less mathematical database will contain more operations that break the guarantees. The documentation of what properties are maintained by which operation will be lacking. Transactions will frequently be broken because it's "no big deal in practice". Data that doesn't fit the hole it is being put into will just be hit with a hammer until it fits, and you will not necessarily be able to figure out what it started as. ("This date is 0000-00-00... where did that come from?" three days later "Oh, crap, I inserted someone's name as their birthdate...")

Basically, PostgreSQL vs. MySQL, to put names on these two styles, especially older-school MySQL... because, you see, over the years MySQL has been forced to get more mathematical, because otherwise it loses data and is generally a pain to work with. PostgreSQL's heritage is far more "mathematical" than MySQL, and it manifests in a better product.

If this just sounds like "good API design", well, yeah, good API design encompasses having a strong mathematical focus, but being "mathematically-aware" code goes beyond that.

Few programmers really know math, but even fewer really get how to translate that into practical code. It's a hard discipline to learn.

Re: Programming is not math

#108

Post by stan_rogers » Fri, Jul 18, 2014, 7:51 PM UTC

mamcx wrote: post #92

bediger4000 wrote: post #82

Earlier quoted context omitted.

I'm not getting at "with math you can solve task X with efficiency". I'm getting at "even if you have a stunted view of math, you're still doing math by programming". I gave examples to the effect that if you don't understand math, and you believe "programming is not math", you'll be puzzled by your inability to perform tasks that when viewed as math, are known to be impossible, and you'll end up with false-to-fact v…

The central idea of the linked post is that programming have long ago spread to more circles apart of math, and if in the past solve math problemas was the #1 activity that is not longer the case, and then, programming is dominated by other activities apart of math. But, some people insist to teach programming ignoring that and still thinking that programming is a tool for math. Now, I think is more right to say math…

The point is that the formality of process description is mathematics. It may not be mathematics as you understand it, and that may largely be because you can intuit a large part of what you are doing as you are doing it, and that's an unfamiliar feeling with math. But let's get this straight: cancelling out out the unnecessary steps or factoring out the common steps in a procedure is exactly the same thing as it would be in an algebraic expression. In the simplest application, it may not seem like there's anything "formal" or "mathematical" going on there, but that's only because it's simple and easy to spot. You can also look at four things and see four things without counting them, and divide them into two twos without doing anything that feels like division. Just because it doesn't feel like mathematics to you doesn't mean it isn't.

Re: Programming is not math

#109

Post by jabelk » Fri, Jul 18, 2014, 8:33 PM UTC

kluge wrote: post #105

jabelk wrote: post #98

Earlier quoted context omitted.

That was my thought too, math is obviously tied very closely to language. And programming did come from CS which came from math. Web/App dev is just so far downstream from all of the math, that people in those roles can get away with ignoring it. In fact, if you accept the premise of math as a language, most of the piece can be boiled down to: "language skills help programming skills, whether that language is mathema…

I think she was implying that college-dropouts that build software projects can afford to buy Teslas without understanding math.

Now that you point it out I can see how it could be interpreted that way. I had trouble recognizing that because I don't think being wealthy (owning a Tesla) is an indicator that one "built something substantial".

Re: Programming is not math

#110

Post by altcognito » Fri, Jul 18, 2014, 8:42 PM UTC

cowbell wrote: post #101

altcognito wrote: post #56

Earlier quoted context omitted.

You don't need mathematical reasoning to realize that loops within loops generate slowness. And as far as under-specifying versus over-specifying, I find that understanding the domain problem is better inoculation against horribly written code than understanding "inefficient" boolean branching. > lesser programmers are afraid to fix it Red flag.

It isn't just loops. It's everything. http://highscalability.com/numbers-everyone-should-know If you just had to say "avoid nested loops" there would be no problem. Programming a solution that works at scale requires math and understanding where you will have bottlenecks before you write a single line of code. >understanding the domain problem is better inoculation How does one understand a problem without understand…

I'd be more worried about making the code readable and easy to modify than high performance. You realize this is at best 5-10 OPS right?

Because in 12 months, nobody is going to know that you saved 2 operations by cleverly "arranging" your code.

I'm not saying you shouldn't arrange your code as best you can, but performance in this situation would absolutely be secondary to readability.

The link you give has nothing to do with the topic of math. It's mostly about knowing how your application is interacting with the system and a basic pragmatic approach to lock contention (also not math).