Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming as a Way of Thinking

blogs.scientificamerican.com

Post reply on HN
Print view View original

61–70 of 133 posts

Re: Programming as a Way of Thinking

#61

Post by ramblenode »

ccleve wrote: post #22

This article starts to get at an idea that I've had for a while now -- that mathematicians are doing it wrong. In the software business we learned a long time ago to name our variables properly, name our functions logically, and to control complexity by breaking ideas into modules and then hiding the details inside. If you can't name something, then you don't know what it is, and that tells you that you should rethin…

It is a different convention but I don't think it's inherently less understandable. The semantically opaque variable names in math texts are usually accompanied by some sort of explanation, e.g. "Let x be... and let f(x) be...". Whereas this type of comment is usually required for a proof, comments are often omitted from programming statements when the variable names are self-documenting.

Re: Programming as a Way of Thinking

#62

Post by Retric »

eldavido wrote: post #30
ccleve wrote: post #22

This article starts to get at an idea that I've had for a while now -- that mathematicians are doing it wrong. In the software business we learned a long time ago to name our variables properly, name our functions logically, and to control complexity by breaking ideas into modules and then hiding the details inside. If you can't name something, then you don't know what it is, and that tells you that you should rethin…

It's more standard than people realize. Offhand: x: "some real-valued variable" n: "a countable quantity, usually a total" i: "an index" k: "some kind of constant", often an integer, whose value doesn't change, "c" is also used for this e: almost never used as a variable, it's Euler's number p: some kind of probability, or a prime number, along with p and q t: some kind of parameter, often goes from [0,1] or (0,1) z:…

For any high school student... i is irrational number. z is also the third dimension as in x,y,z. e is base 10 exponent as in 4e12.

So, while you might be used to that notation and in context it's clear that's far from universal. Further someone can be an expert in more than one area and incompatible notation slows down collaboration for little gain.

Re: Programming as a Way of Thinking

#63

Post by throwawayjava »

gbrown wrote: post #51
runeks wrote: post #34

Earlier quoted context omitted.

The variables named 'anything' can represent anything, that's the point. Are you saying we should avoid writing code that's too general? I understand that not all languages are powerful enough to allow defining functions that can operate on any type. But this doesn't mean that languages with this expressive power should refrain from using it; it means that users of less powerful languages need to learn something new…

That would create incredibly verbose code, which would be very hard to parse (IMHO).

Exactly the opposite. Typed languages without parametric/generic code result in extraordinarily verbose and bug-prone code. You end up constantly casting to/from void* or Object.

That's why all popular typed languages after C provide a facility for writing parametric code.

And without exception, the standard libraries for those languages using single-variable names (S,T) for types. Because when you have 1-3 type variables, and you're writing generic code, "Type" doesn't really communicate anything that "T" doesn't.

Re: Programming as a Way of Thinking

#64

Post by vlasev »

tnecniv wrote: post #56
ccleve wrote: post #22

This article starts to get at an idea that I've had for a while now -- that mathematicians are doing it wrong. In the software business we learned a long time ago to name our variables properly, name our functions logically, and to control complexity by breaking ideas into modules and then hiding the details inside. If you can't name something, then you don't know what it is, and that tells you that you should rethin…

I used to think this way, but as I learned more math, I realized that the way mathematicians do things isn't an issue in practice. I do wish notation was more standardized, but that's a nitpick (i.e. whether/how scalars and vectors are distinguished). When it comes to proofs, you can only keep so much information in your head at once. In most cases, if you have a ton of variables floating around, you are probably try…

> whether/how scalars and vectors are distinguished

This becomes less of an issue once you go through some abstract algebra. But typically, constants would come from the start of the English alphabet, and vectors, from the end.

> I will note the worst code I've ever read was written by a control theorist that used only single letter variables. I later found out the variable names were the same as a paper, but the paper was not provided in the program comments.

Did the code remain "worst" after you found out the names came from a paper?

Re: Programming as a Way of Thinking

#65

Post by osoba »

danielpatrick wrote: post #49
osoba wrote: post #40

Earlier quoted context omitted.

U, V: vector spaces u, v: elements of vector spaces G, H: groups g, h: elements of groups or g, h: homomorphisms, isomorphisms etc e: group identity K, F: fields I: ideals f: functions (x): sequences x_i: i-th element of a sequence A, B: matrices It all depends on the context it's used of course

This notation has developed over tens to hundreds of years before we had the capabilities of autocomplete and formal typing where a computer can help us write longer names more quickly. This is why single letters became prominent, they were simply easier and faster to write. But anyone who is serious about writing maintainable code today should be using an IDE where the benefits of susinctness are entirely relegated…

It's actually the other way around. Mathematical notation used to be very much language-like and tedious to read. As time went by (and math became more complicated) notation was developed to make it more succinct and easier to understand. (And sometimes the more succinct notation helps to develop new insights. The change from Roman to the Indian/Arabic number systems made calculations easier for everybody) https://en.wikipedia.org/wiki/History_of_mathematical_notati...

Compare the two following statements:

One from Euklid's elements (written 2.5k years ago):

"Given two straight lines constructed from the ends of a straight line and meeting in a point, there cannot be constructed from the ends of the same straight line, and on the same side of it, two other straight lines meeting in another point and equal to the former two respectively, namely each equal to that from the same end."

And my attempt of translating the above, in what should effectively be Hilbert's notation (19th-20th century):

If there are two triangles ABC and ABD where AC=AD and BC=BD and C and D are on the same side of AB then C and D are the same point.

Which one was easier to parse in your mind?

As a bonus try rewriting this formula using longer variable names and tell me how legible it would look http://i.imgur.com/wCWkyNL.png (it's from a proof of one of Syllow's theorems https://en.wikipedia.org/wiki/Sylow_theorems )

Re: Programming as a Way of Thinking

#66

Post by vlasev »

sqeaky wrote: post #47
btilly wrote: post #44

Earlier quoted context omitted.

This article starts to get at an idea that I've had for a while now -- that mathematicians are doing it wrong. And you're making a typical programmer mistake in thinking that. Programming is geared towards having people who are experts in programming, but not in a specific subject area, be able to develop and maintain code. Therefore practices like descriptive variable names help provide context to people who cannot…

> Programming is geared towards having people who are experts in programming Programming is getting simpler all the time. Compare modern Python or Ruby to the earliest punch cards. We programmers are going out of way to make it as easy to understand as possible for as many as we can. There are programming languages suitable for children to use while making robots out of Legos. It is hard to see how variable names vs…

A mathematician doing math is more akin to a processor executing instruction than a developer doing programming. When you have to reference a variable X in your head 1000 times (an underestimate) in the process of working on a problem, it makes immense sense to name it X rather than DescriptiveVariableName.

In fact, in my own research for my Master's degree, I only made breakthroughs once I simplified the notation. And we're talking about a change like Q(x,y,z) -> Q, Q(x,0,y) -> Q_2^0, dQ(0,y,0)/dx -> Q_{1,3}^{1,0}. The power of concise notation can be quite a bit greater than that increase in opaqueness it creates.

The way math is communicated suffers from this, for sure. However, you gotta think about what will happen once you read a paper that has more descriptive variable names. You sit down to prove a few results. You start manipulating concepts and symbols. You end up shortening the names until you basically come up with your own concise notation. The thing is that how math is read is very much linked to how math is done.

Re: Programming as a Way of Thinking

#67

Post by HiroshiSan »

ccleve wrote: post #22

This article starts to get at an idea that I've had for a while now -- that mathematicians are doing it wrong. In the software business we learned a long time ago to name our variables properly, name our functions logically, and to control complexity by breaking ideas into modules and then hiding the details inside. If you can't name something, then you don't know what it is, and that tells you that you should rethin…

Instead of dismissing mathematical syntax as laziness plain and simple Jeremy Kun (a mathematician) explains some reasons towards mathematical syntax.

https://jeremykun.com/2013/02/08/why-there-is-no-hitchhikers...

Re: Programming as a Way of Thinking

#68

Post by vlasev »

ccleve wrote: post #26
School-Cotton wrote: post #23

Earlier quoted context omitted.

Are you a mathematician? How much math have you studied?

I'm a software developer. I need to understand computer science papers to get my work done. I've studied enough. High school and several courses in college. Enough that I should be able to take it from here and learn on my own.

So let me get this straight...You are mainly a software developer who has an issue with math notation that is meant for mathematicians? Could it perhaps be that you haven't taken enough math to become in tune with how it's done/studied/read?

I come from the other direction. I studied math first. And yes, at first I had an issue with the long variable/function names. But soon enough I realized that programming is done quite differently than math. With IDEs and autocompletion, long variable names are not really a problem.

One could argue that variable names should be descriptive in programming, because there is a lot more reading involved. Whereas in math, there is a lot more writing/doing involved. I might manipulate a math variable name 1000 times in my head in the process of working on a problem. I might even WRITE it down that many times! In programming, I might READ a variable name 1000 times in debugging.

Re: Programming as a Way of Thinking

#69

Post by pfooti »

ccleve wrote: post #22

This article starts to get at an idea that I've had for a while now -- that mathematicians are doing it wrong. In the software business we learned a long time ago to name our variables properly, name our functions logically, and to control complexity by breaking ideas into modules and then hiding the details inside. If you can't name something, then you don't know what it is, and that tells you that you should rethin…

This feels like an instance of the XKCD:927 principle. Math notation tends to be big and ugly and hard to wrap your head around at times. It's context-specific (if you're summing over an array, you'll maybe use i as an index value and reference x_i. If you're working with complex numbers, i is a constant.

Importantly, this language and its practices have evolved over centuries, in response to a lot of different competing needs. It's probably highly-optimized for something, just not what you need it for.

That said, if you're dealing with indices of an array in a sum / product series and that array is of complex numbers, it's actually not terribly ambiguous to do x_i * (2i - 1) or something.

On the other (third? gripping?) hand, you do have a point - there's usually unwritten practices about what different variables reference (theta is usually an angle, k is a constant, n an integer, usually). That can be gatekeeping, and it's super-frustrating to work in a language that doesn't expose type information.

927: https://xkcd.com/927/

Re: Programming as a Way of Thinking

#70

Post by kccqzy »

ccleve wrote: post #22

This article starts to get at an idea that I've had for a while now -- that mathematicians are doing it wrong. In the software business we learned a long time ago to name our variables properly, name our functions logically, and to control complexity by breaking ideas into modules and then hiding the details inside. If you can't name something, then you don't know what it is, and that tells you that you should rethin…

Not everything can be so easily named. A lot of times mathematicians deal with a much higher level of abstraction than you are, and at that level, there are no intuitive names available. It is not a failing of mathematicians, but rather a failing of human natural language to be unable to name these concepts.

You might want to read some very old math books that predated the introduction of symbols to stand for things. Go read how ancient mathematicians express Pythagoras's theorem. We have verbose monstrosities that is much more simplified now.

Natural language is verbose. Once you can deal with the level of abstraction, conciseness reduces your cognitive load significant.

Post reply on HN