Live data from Hacker News

Programming as a Way of Thinking

blogs.scientificamerican.com

31–40 of 133 posts

Re: Programming as a Way of Thinking

#31
post #28
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…

If a variable can be literally anything, what would you name it instead of 'a'? 'anything'? Sometimes a variable does not refer to anything specific at all. For example, type variables in Haskell are often denoted using single letters, simply because they can be literally anything, and no sane human wants to type out 'anything' all the time, just so her code can be used as a beginner's intro to the language in questi…

There may be occasions when a single letter makes sense, but this should be the exception, not the rule. If you've got a ton of "anything" variables in your code, then that means there's probably a better, more understandable design for your system which expresses what the variables represent with more precision.

Re: Programming as a Way of Thinking

#32
Not sure what I was expecting from the title, but for sure not what I read. Maybe I'm quite old now, but working with latches and switches was always a way of thinking. Writing awful BASIC with GOTO and subroutines was not that different. Writing OO code is quite different at first impact but then you discover that it is basically the same way of thinking. The real way of thinking of programmers doesn't have anything to do with the languages, it's more about finding solutions for some problem. If you can't find solutions by yourself, banging your head, it doesn't mean that you have to find a better language for your software, doing nothing in the meantime, it means that you have to start from scratch understanding how to fix things and how to solve problems. If you just wait for the next big thing or the next shiny solution that fixes everything for you then imho programming is not for you.

Re: Programming as a Way of Thinking

#33
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…

> ... a paper that uses entirely unnecessary equations, and doesn't bother to define symbols. This practice wastes everyone's time.

I agree with you there, notation should be defined, otherwise it doesn't help explain anything.

However, consider that for people who are already used to the notation those "unnecessary" equations are actually more compact and precise than reading the accompanying text. What seems difficult to you may be easy for someone else, and vice versa.

> ... the key to it is to force mathematicians to name their variables.

I believe you overestimate how much of an improvement that would be. How much code have you seen that had variables like int num or String str? If num can be any arbitrary number, and str is just a generic string, there isn't necessarily a more descriptive name you can use.

Mathematics is full of these cases. Say, some general equation involves three real numbers and a real valued function of two real parameters. They are completely generic, so a mathematician might name them x, y, z and f and write the equation as f(x,y) = z.

How would you call them? All I can think of would be the first parameter, the second parameter, the result and the function, which is not much more descriptive for the added verbosity.

The problem with using descriptive names in mathematics is that most entities you are dealing with are so generic that naming them doesn't help. Of course I'm not opposed to e.g. writing NormalDistribution instead of just N, since this is actually a very specific concept. But there is just no way to completely eliminate single letter variables from mathematics without using an equally nondescriptive replacement.

Re: Programming as a Way of Thinking

#34
post #31
post #28

Earlier quoted context omitted.

If a variable can be literally anything, what would you name it instead of 'a'? 'anything'? Sometimes a variable does not refer to anything specific at all. For example, type variables in Haskell are often denoted using single letters, simply because they can be literally anything, and no sane human wants to type out 'anything' all the time, just so her code can be used as a beginner's intro to the language in questi…

There may be occasions when a single letter makes sense, but this should be the exception, not the rule. If you've got a ton of "anything" variables in your code, then that means there's probably a better, more understandable design for your system which expresses what the variables represent with more precision.

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 (as I had to).

Re: Programming as a Way of Thinking

#35
Some discussion of the efficiency cost of our current favorite higher level languages would be nice. There are things about Python that people love, and I think we should strive to provide that with something more like a 2% performance penalty instead of ~200%+

Languages like Nim are very promising on that front.

Re: Programming as a Way of Thinking

#36
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:…

k, along with j, is also often an index.

Of course, this mathematical convention carried over into programming as well, with i,j, and k serving as index variables.

Re: Programming as a Way of Thinking

#37
post #33
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…

> ... a paper that uses entirely unnecessary equations, and doesn't bother to define symbols. This practice wastes everyone's time. I agree with you there, notation should be defined, otherwise it doesn't help explain anything. However, consider that for people who are already used to the notation those "unnecessary" equations are actually more compact and precise than reading the accompanying text. What seems diffic…

Naming is hard, no question. Context helps, though. In realm where I live, computer science, x, y, and z likely correspond to something in the problem domain, like "rate" or "time". And even if we're dealing in pure, as opposed to applied, math, you should still be able to come up with names like "surfaceArea" or "interval".

Re: Programming as a Way of Thinking

#38
> The languages I am calling modern are not particularly new; in fact, Python is more than 25 years old. But they are not yet widely taught in high schools and colleges.

Seems like a strange claim, because

> eight of the top 10 CS departments, and 27 of the top 39, teach Python in introductory CS0 or CS1 courses. [1]

[1] https://cacm.acm.org/blogs/blog-cacm/176450-python-is-now-th...

Re: Programming as a Way of Thinking

#39
I saw Allen Downey speak about this concept a year ago in a small forum at the University of Richmond. Several professors in the audience challenged his thinking. I approached one after that and asked what he thought and the answer was basically that Dr. Downey's approach is spot on. This coming from a CS professor.

I have just started reading his Think Stats book http://www.allendowney.com/wp/books/ which is starting to help me better understand statistics. Not far enough into the book yet to make a complete judgement however.

Got to say I like seeing different perspectives on traditional subjects. My youngest is going to Olin next year in Mechanical Engineering and seeing these sorts of articles keeps me excited about her unconventional engineering education at Olin.

Re: Programming as a Way of Thinking

#40
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:…

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

Post reply on HN