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.
Why programming is a good medium for expressing poorly understood ideas (1967)
41–50 of 70 posts
Re: Why programming is a good medium for expressing poorly understood ideas (1967)
#42Earlier 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.
Any programmer except a Haskell programmer.
Re: Why programming is a good medium for expressing poorly understood ideas (1967)
#43Earlier quoted context omitted.
He was very wise on this matter. The best code I've written was thanks to first designing it on paper.
One time, in university I did not have access to a computer for a couple of days and had to write code for a b-tree in C++. I designed and wrote the code fully on paper and when I got access to a computer, I typed it in and it worked! I think that was my peak.
Have you tried to recreate that peak? I'm wondering if it worked so well why you might not have continued working in that mode?
Re: Why programming is a good medium for expressing poorly understood ideas (1967)
#44Re: Why programming is a good medium for expressing poorly understood ideas (1967)
#45Earlier quoted context omitted.
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?
For me it's both. You're trying to visualize the problem, its parts and how they interact, and you may write down some code for specific sub problems because it just popped into your head and you don't want to context switch. There's a limited amount of things you can keep in your head at once, and the paper is somewhat of a navigational aid and rapid access memory. Paper also offers you a lot of flexibility in regar…
> There's a limited amount of things you can keep in your head at once, and the paper is somewhat of a navigational aid and rapid access memory.
Funny how you describe and justify operating a low-tech tool with computer-y terms, almost like you were a computer yourself.
Re: Why programming is a good medium for expressing poorly understood ideas (1967)
#46Earlier quoted context omitted.
For me it's both. You're trying to visualize the problem, its parts and how they interact, and you may write down some code for specific sub problems because it just popped into your head and you don't want to context switch. There's a limited amount of things you can keep in your head at once, and the paper is somewhat of a navigational aid and rapid access memory. Paper also offers you a lot of flexibility in regar…
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.
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 things in no time in no time. Unless I need an incredibly straight line, I usually forgo rulers at this point.
If your handwriting has slowed down, or you're cramping, you might want to give that a little bit of practice as well. No need for the cleanest Suetterlin, but getting posture right and yourself up to speed might be worth the time investment. I've been playing around with the palmer method recently, it seems quite nice for this purpose.
Then there's tools. You don't want to be writing with cheap ballpoint pens on rough paper. The lines don't come out properly, which will make you press harder, which leads to fatigue. My current favourite pens are the Uniball eye-fine which is my go to for writing, as its a very smooth disposable ink pen. I've got one of those in front of me with a Kum ergonomic grip. Fountain pens are also very nice, and an entry level Lamy, Pelikan or Pilot will serve you nicely, but they're more suited for linear writing as they may smudge.
Pencils are nice for sketching, but you have to sharpen them, which is annoying. For regular use I use a Faber-Castell Grip 1345 0.5mm mechanical pencil, which is still affordable but doesn't have many of the issues that cheaper mechanical pencils suffer from (broken leads, leads going back in because of insufficient internal grip, etc.). The Faber-Castel leads are also very nice and sturdy and make decent lines even at low pressures.
Paper isn't that variable, as long as you don't totally cheap out on it. I'm particular to .5cm grid paper, but there's circumstances when plain white is nicer to work on.
It's a bit much of a list, but I think a lot about stationery. You don't need all of these, and if you find other tools that do the job for you, then by all means go for them, these are just my personal favourites. One pen and a block of paper is more than sufficient.
But I do think coding and thinking through problems on paper is a valuable skill. One neat thing it allows you to do is to go to a different place than the one you type things at to go think deeply about problems, because it's a lot more portable than a laptop. If like me, you haven't quite figured out how pseudo-code works and still write straight up source code, it also gives you a reason to memorize reserved words which I find does make things quicker ("was it import or include?"). And finally, your IDE won't distract you by having the gumption to tell you that "hey, you aren't using this variable, you lugnut, lookie look, this import is BROKEN! Aint you got any IntelliSense in you?" when you really want to be thinking about more conceptual things and not tiny implementation details. Sometimes you do do your best work when you're away from where you do your regular work.
Re: Why programming is a good medium for expressing poorly understood ideas (1967)
#47My 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.
Re: Why programming is a good medium for expressing poorly understood ideas (1967)
#48My 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…
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!
Re: Why programming is a good medium for expressing poorly understood ideas (1967)
#49Earlier 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…
Re: Why programming is a good medium for expressing poorly understood ideas (1967)
#50Earlier quoted context omitted.
Yes I learned how to program on paper. It was when computer access was expensive. We learned how to write code on paper and then go over each line with a table for variable values as we run over the code. I learned BASIC on punch cards using an IBM Mainframe for the junior high school math computer club, and it got changed to the math contest club after they couldn't afford computer time anymore. In modern times ther…
Do you still do any programming on paper? I've noticed I've occasionally felt like I've relied too much on my tools like my IDE or Resharper. I've been thinking I should get in the habit of doing some programming using just a simply text editor or pencil/paper to prevent that.
I find it very beneficial in the early stage of planning a program (or a subsystem of program).