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

101–110 of 256 posts

Re: Think in Math, Write in Code

#101

Post by mannykannot »

rowanG077 wrote: post #96
mannykannot wrote: post #95

Earlier quoted context omitted.

Your designers are working with abstract models. They are thinking about problems at a conceptual model, they are not putting up structures and seeing if they work.

code is also an abstract model. The CAD designers absolutely test if things work. Why do you think almost every engineering bureau has 3D printers.

> Code is also an abstract model.

Sure, but it is not the only one. You are allowed to think at other levels, and it can be quite useful, especially on larger systems.

Re: Think in Math, Write in Code

#102

Post by deadgrey19 »

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 here. The complexity is all in the "fast" part, and to solve that, a deep understanding of the architecture of the system is necessary. Fancy algorithms (maths) will not help you here. e.g. Will compression help? Depends on the properties of the system. Will batching help? Depends on the system. Will threading help? Depends on the system.

Re: Think in Math, Write in Code

#103

Post by mruts »

sabas123 wrote: post #75
nicoburns wrote: post #52

Earlier quoted context omitted.

> Sure, mathematical thinking can be useful, but it's only one type of logical thinking among many types which can be applied to programming. Completely agree with this. I did a Maths and Philosophy degree, and I reckon the Philosophy was more useful to my career in programming than the Maths was. Although this probably depends on what kind of programming you do.

As somebody interested in both but having mainly been a programmer all my life. Could you describe in what ways philosophy can help somebody? My (heavily uninformed) guess would be the ever questioning if our assumptions are actually true or not.

I've always felt that formal logic has been more useful to programming than math has for me.

Re: Think in Math, Write in Code

#104

Post by traderjane »

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…

You don't need fancy math because someone else did it for you, but if the industry is to compete and advance, it's going to need all sorts of people. The fact that you don't have to juggle every mathematical complexity underlying your domain is a success of human cooperation and compartmentalization. It's certainly not free or inherent.

Re: Think in Math, Write in Code

#105

Post by mruts »

onion2k wrote: post #14
skohan wrote: post #10

Earlier quoted context omitted.

I think single letter variable names are fine within the scope of a single function. Especially if I'm doing something with a lot of math, like a lighting calculation, the computations are often more readable with short variable names. I'll also usually give a detailed description of what the variable is in comments for clarity.

I think single letter variable names are fine within the scope of a single function. I don't. One of the things I like most about eslint is the id-length rule - https://eslint.org/docs/rules/id-length

I find that I can reason about code more effectively the shorter the variable names are. Rob Pike writes the same thing in the Practice of Programming.

Re: Think in Math, Write in Code

#106

Post by deadgrey19 »

traderjane wrote: post #104
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…

You don't need fancy math because someone else did it for you, but if the industry is to compete and advance, it's going to need all sorts of people. The fact that you don't have to juggle every mathematical complexity underlying your domain is a success of human cooperation and compartmentalization. It's certainly not free or inherent.

How so? Can you give an example?

Re: Think in Math, Write in Code

#107

Post by onion2k »

skohan wrote: post #62
onion2k wrote: post #14

Earlier quoted context omitted.

I think single letter variable names are fine within the scope of a single function. I don't. One of the things I like most about eslint is the id-length rule - https://eslint.org/docs/rules/id-length

I think it depends. In the context of a complex mathematical formula, where you have many intermediate results with very abstract meanings, I think it's more clear to use a single character name than to try to be descriptive with something like: `productOfLuminanceAndDotProductOfSurfaceNormalAndLightDirectionDividedByScatteringConstant`. I think there are a lot of advantages to abiding by styling conventions and usin…

* productOfLuminanceAndDotProductOfSurfaceNormalAndLightDirectionDividedByScatteringConstant*

Note that the id-length rule also allows you to limit the maximum length of a variable name. This is why.

Re: Think in Math, Write in Code

#108

Post by ryandrake »

rowanG077 wrote: post #78
mannykannot wrote: post #55

Earlier quoted context omitted.

This is not a useful analogy; it is more of an excuse for not trying to think things through. Would this be a reasonable analogy for building a bridge? If you don't have a reasonably detailed idea of what you want and how to achieve it, you are unlikely to get it. https://dilbert.com/strip/1991-9-6

Building software is not even remotely the same thing as building a bridge. It would be more akin to the architect creating the drawings twice for the bridge. Once as an exploratory version and the second one the production version. Oh wait that is actually how architects work. In fact at my work we have multiple CAD designers(not architects though) and it's not uncommon for them to completely throw away a design and…

Maybe if we treated the practice of software development more like bridge building, we would have better reliability, fewer outages, fewer zero-day exploits, fewer patches and bugfixes--software that actually works the first time, and every time for years.

Re: Think in Math, Write in Code

#109

Post by skohan »

onion2k wrote: post #107
skohan wrote: post #62

Earlier quoted context omitted.

I think it depends. In the context of a complex mathematical formula, where you have many intermediate results with very abstract meanings, I think it's more clear to use a single character name than to try to be descriptive with something like: `productOfLuminanceAndDotProductOfSurfaceNormalAndLightDirectionDividedByScatteringConstant`. I think there are a lot of advantages to abiding by styling conventions and usin…

* productOfLuminanceAndDotProductOfSurfaceNormalAndLightDirectionDividedByScatteringConstant* Note that the id-length rule also allows you to limit the maximum length of a variable name. This is why.

I understand that, but what in your mind would be a good replacement to name such a complex, abstract value? A long acronym perhaps? I don't see how that's any more clear or less arbitrary than a single character name.

Re: Think in Math, Write in Code

#110

Post by philote »

deadgrey19 wrote: post #106
traderjane wrote: post #104

Earlier quoted context omitted.

You don't need fancy math because someone else did it for you, but if the industry is to compete and advance, it's going to need all sorts of people. The fact that you don't have to juggle every mathematical complexity underlying your domain is a success of human cooperation and compartmentalization. It's certainly not free or inherent.

How so? Can you give an example?

For example, if you do end up needing compression, are you going to write you own compression library or use an existing one somebody else already wrote?
Post reply on HN