Live data from Hacker News

Why programming is a good medium for expressing poorly understood ideas (1967)

web.media.mit.edu

51–60 of 70 posts

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#51
post #36

Earlier quoted context omitted.

I think I've never seen Hebrew. Or maybe I've seen it and didn't recognize it as Hebrew. Do you have an example?

Quick one: https://en.wikipedia.org/wiki/Aleph_number

There are also Beth numbers (https://en.wikipedia.org/wiki/Beth_number), closely related to Aleph numbers, but as far as I know that is the only place hebrew letters show up in mathematics.

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#52
post #46
post #39

Earlier quoted context omitted.

This is good encouragement for me to try using pen and paper again. The problem is that every time I do, I get frustrated by how slow it is for me, my hands get cramped, and I miss the backspace key. But perhaps I just need to keep at it for a bit, because I do see (and have experienced, back in college) the advantages.

The backspace key equivalent of pen and paper is crossing things out/erasing them. If there's a line of writing I don't like, I'll cross it out and start that piece over. If you want to get faster and better at sketching diagrams I'd recommend you practice some of the basic techniques that say concept artists use. Straight lines from the elbow with little wrist movement and a little practice, and you'll be drawing th…

Great advice here. Regarding beat drawing of diagrams with lines drawn from the elbow, there is a great set of online lessons that teach this through exercises. I totally recommend it:

http://drawabox.com/lesson/1

I have improved my drawing ability significantly by following these lessons.

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#53

My programming lecturer used to say "programming is the process of breaking a problem down so a high speed idiot can understand it, if you don't understand the problem then you can't explain it". He also said that a programmers most useful tool was a pencil and a 5mm square A4 pad. After years of solving thorny problems by getting away from the screen and scribbling in a pad I can't say he was wrong.

I keep my notebooks for many years and occasionally have fun looking back at old ones and trying to understand what it was that I was struggling with at the time. Usually I can't so somehow these doodles were extremely helpful while trying to pin down some problem long enough to be able to solve it but they definitely don't serve their intended goal as long term documentation for me. I probably should simply discard…

That's interesting. I do the reverse. I have a trail of hundreds of mind maps and lists on paper, some of them probably recycled by now. I've always wondered if it would have been better to save them and review. I think I've lost a lot of work on some problems/ideas I wanted to explore that way. Probably forgotten a good number of problems I was interested in to start with. Mostly personal though - professionally, my desk piles up until I'm forced to review the usefulness of each piece of paper (still, the 'where's that sheet gone' dance is common).

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#54

Earlier quoted context omitted.

I keep my notebooks for many years and occasionally have fun looking back at old ones and trying to understand what it was that I was struggling with at the time. Usually I can't so somehow these doodles were extremely helpful while trying to pin down some problem long enough to be able to solve it but they definitely don't serve their intended goal as long term documentation for me. I probably should simply discard…

I'm a pens-and-notebooks power user, and I know exactly what you're talking about. The trick is, whenever you're writing anything, add notes for your future self to make sense of whatever you're doing. It's like adding comments to explain your code. It's a little extra effort and bookkeeping but it makes old content so much more valuable!

That's a good insight. Thank you!

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#55

Earlier quoted context omitted.

He was an insanely smart guy, Type 2 Unixbeard (the skinny one with the pony tail rather than Type 1, the portly one with the T-shirt of a bankrupt tech company). Back in the 80's he worked on the software that ran/runs digital switching for (iirc) BT, high scale, high reliability stuff in C.

I had only one Unixbeard professor, and he was the best one I had in my program. He was also a Type 2.

I wish I had had a Unixbeard prof.

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#56

I'd love if all the formulas on Wikipedia were written as pseudo code with meaningful variable names. I'd understand them so much faster.

Seriously! Any programmer would get pilloried for working solely in single letter variable names. It's so tedious that this is the norm in math.

Your comment just made me realise why I hate any hackerrank "challenges" I have looked at. (Skyscanner uses them for interview tests, I have been close to applying twice, but got offered other jobs before I got around to completing them).

I have decided to try a warm up exercises a couple of times before applying but the way they word the questions is so unmeaningful: 'n' lines with y variables, plus spending 20 minutes trying to work out how to read their input. No debugger and not easy way to cut and paste, as its all in a web form.

Fuck that, I am a software engineer, I usually read data from databases and name my variables properly and use tools to help me understand the problem, not hinder myself.

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#57
post #28

My programming lecturer used to say "programming is the process of breaking a problem down so a high speed idiot can understand it, if you don't understand the problem then you can't explain it". He also said that a programmers most useful tool was a pencil and a 5mm square A4 pad. After years of solving thorny problems by getting away from the screen and scribbling in a pad I can't say he was wrong.

This might be a strange question, but what does 'scribbling on a pad' actually entail? Do you write the actual code, or is it usually more about drawing out the flow of program?

Drawing representations of data structures and algorithms for me. Imagine drawing a linked list. Probably a box with a pointer to another box. Code looks nothing like that, but when you have the idea on paper its a lot easier (for me) to work out what the code should be.

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#58
post #27

Earlier quoted context omitted.

The lack of an efficient IME for verbose math input on a computer certainly accounts for why math is still terse when done in real-time such as when extemporaneous lectures or when working something out. But I don't think it fully explains why the convention persists even in published works that took months or years to prepare; there's got to be a significant effect for the readers and not just the writers. If a long…

It's probably just the weight of tradition from the longhand days that leads people to use the short variable names, not that it's somehow better, even on a computer. All it would probably take would be for someone to start a math journal that required a minimum of three letter variable names and everyone would switch over.

Who would want to submit to such a journal?

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#59

Earlier quoted context omitted.

I don't think that's possible for most of them. Quite a few formulas aren't equivalent to any one program, and most variables don't have a fixed meaning. Can't really think of one that could be improved by writing it as pseudo code.

> I don't think that's possible for most of them. Quite a few formulas aren't equivalent to any one program, Even every proof can be expressed as a program, see Curry–Howard correspondence [1]. > and most variables don't have a fixed meaning. I think this is kind of the point of the original comment. For a physicist PV=nRT is concise and clear but for everyone else? The letters P, V, n, R, T can have many meanings bu…

>Even every proof can be expressed as a program, see Curry–Howard correspondence

Well, that is true, but that's still pretty far removed from any common programming language. And readability doesn't usually improve.

>For a physicist PV=nRT is concise and clear but for everyone else?

You've somewhat got a point there, physics would be a lot easier if all formulas and variables were actually defined when needed. But symbolic notation is still a necessity, simply because symbolic manipulation is really powerful, and it's a pain to have to write 'BOLTZMAN_CONSTANT' every single time, instead of just k_B.

Also, your notation might work for simple equations like the ideal gas equation, but an equation that's only slightly more complicated, the van der Waals equation, would become quite hideous:

    (pressure + number_of_particles^2 * attraction / volume^2) * (volume / number_of_particles + excluded_volume) == BOLTZMANN_CONSTANT * number_of_particles * temperature
I really wouldn't want to have to write that out several times just to do some calculations with it.

Re: Why programming is a good medium for expressing poorly understood ideas (1967)

#60
post #56

Earlier quoted context omitted.

Seriously! Any programmer would get pilloried for working solely in single letter variable names. It's so tedious that this is the norm in math.

Your comment just made me realise why I hate any hackerrank "challenges" I have looked at. (Skyscanner uses them for interview tests, I have been close to applying twice, but got offered other jobs before I got around to completing them). I have decided to try a warm up exercises a couple of times before applying but the way they word the questions is so unmeaningful: 'n' lines with y variables, plus spending 20 minu…

All right, so nowadays software engineers cannot read specifications, cannot program and correct their mistake without a debugger, cannot do anything without an IDE, cannot do anything without copy-pasting (from SO) and read their data from a database.

Jesus, please send me back to XXth century.

Post reply on HN