I tend to be a good writer and able to express specific feelings easily. Should I learn to code?
For Donald Knuth, good coding is synonymous with beautiful expression
141–150 of 229 posts
Re: For Donald Knuth, good coding is synonymous with beautiful expression
#142Re: For Donald Knuth, good coding is synonymous with beautiful expression
#143Here’s the funny thing... If Knuth (or a modern avatar) were applying for a faculty position today, or coming up for tenure, would s/he succeed?
Re: For Donald Knuth, good coding is synonymous with beautiful expression
#144Earlier quoted context omitted.
>The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A"…
Ha! I had the same experience in my art evening classes. One evening our teacher told us that we had to produce three paintings in the 2.5 hour lesson. It is challenging enough producing one in that time period. It was a fantastic learning experience in letting go. The first picture I did was OK, the second was better and the third was great - all because I'd given up thinking at that point and was just doing. Someti…
On the other hand, I took a few semesters of elective photography courses in high school, and there’s a certain essential amount of time it takes to make a good photo print and run it through all the chemicals. It can’t really be compressed down shorter than about 35–40 minutes for the whole process with only limited ability to parallelize the work while maintaining quality, which makes it tough to make more than 1 or possibly 2 good prints in 1 class period.
All of the students I knew who focused on making 1 good print every day ended up learning more and making better images than the students who constantly tried to rush.
Re: For Donald Knuth, good coding is synonymous with beautiful expression
#145> I write an average of five new programs every week. Poets have to write poems. I have to write computer programs. It seems more obvious now that I read it. A lot of programmers out there, including myself, are looking for ways to improve their skills and I never thought to myself to write more programs. And not just programs for the sake of programs, but programs that force you to explain to the computer that you u…
What does it mean though? What programs? I can't write new programs at work where I maintain existing applications for the most part. What kind of programs, not for the sake of programs, can you actually write almost daily?
There’s a few utility functions that come to mind. Git hooks, for example.
Re: For Donald Knuth, good coding is synonymous with beautiful expression
#146Earlier quoted context omitted.
Totally agree. It doesn't help at all. Pseudocode would have benn sufficient. Fake machine code? Nope.
MMIX programs can actually be run, and MMIX has multiple simulators. Actual MMIX chips can be made. MMIX also allows students to reason about the properties of modern chips without experiencing quite the complexity they'd have to deal with normally. This is valuable for many reasons.
Things like branch prediction, caches, instruction pipelining? Not really. People want the algorithm, not a difficult to translate implementation.
Re: For Donald Knuth, good coding is synonymous with beautiful expression
#147Earlier quoted context omitted.
Ha! I had the same experience in my art evening classes. One evening our teacher told us that we had to produce three paintings in the 2.5 hour lesson. It is challenging enough producing one in that time period. It was a fantastic learning experience in letting go. The first picture I did was OK, the second was better and the third was great - all because I'd given up thinking at that point and was just doing. Someti…
On the other hand, I took a few semesters of elective photography courses in high school, and there’s a certain essential amount of time it takes to make a good photo print and run it through all the chemicals. It can’t really be compressed down shorter than about 35–40 minutes for the whole process with only limited ability to parallelize the work while maintaining quality, which makes it tough to make more than 1 o…
Apples to oranges. Painting is a purely creative process with style being valued over correctness. While there is artistic decision during manual film development, there is definitely a wrong way to develop a print. If you rush the chemical process, it will end up bad. Film is more like baking in that regard while painting is stove top cooking.
Re: For Donald Knuth, good coding is synonymous with beautiful expression
#148Earlier quoted context omitted.
>The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A"…
If I were graded solely on quantity, I would produce stuff that only just barely passes the bar of being a pot. (If you take a clump of clay and stick your finger in it, you basically have a pot.) Therefore, I think the story is false. Nice story though.
Any metric taken to the extreme is worthless.
Re: For Donald Knuth, good coding is synonymous with beautiful expression
#149Earlier quoted context omitted.
There's no reason you can't take into account things like varying key size, memory allocation, etc. in your computational model when it matters. For comparison sorting, the reason it isn't done is that if you're comparing keys of the same length, in the worst case, you have to look at the entirety of both keys. O(n log n) might be misleading, but it's a white lie at best.
There are a lot of very interesting issues there. For example, surely you have to look at the entirety of both keys at least once, yes; but you don't have to do it on every comparison, for example in mergesort where you can store a longest common prefix between pairs of adjacent keys and avoid comparing them byte by byte most of the time, or even storing them. The algorithm is tricky both to implement and to analyze,…
>I conjecture that it actually gets mergesort down to a real O(N log N) instead of the O(N log N log N) of the usual mergesorts.
I don't think it does in the worst case. I'd bet money you could construct an adversarial input that would force you to look at more of each key than you'd have to in order to get down to "real" O(n log n).
>MIX in particular had 5-character memory words, but only 4000 words of memory, so its comparison time for internal sorting is quite precisely constant for any realistic data.
If we're being precise here, then it is certainly bounded above by a constant. But, this is also the same sense in which there is literally no such thing as a Turing machine (all physical machines, even one the size of the universe, are linear bounded automata, at best).
> Anyway, back to the issue at hand: assembly language exposes all the computational costs by default, which is what you want if you're going to prove theorems about them, while high-level languages obscure them by default, so more of your theorems will be incorrect. And that's Knuth's primary concern.
Except, no, you don't. Both you and I just got through explaining why.
> That level of single-minded pursuit of excellence is the reason we can learn things from books Knuth wrote in the 1960s that are still useful for programming computers that are literally a billion times bigger than the machines Knuth used as his model. It's also the reason he's not done yet, 55 years later, with what he thought would be a single book, done in a year or two.
No, it most certainly is not. I'm assuming you've read at least some of TAOCP. Knuth certainly introduced some mathematics and techniques for the analysis of algorithms in TAOCP, but literally none of the algorithms themselves were first published there. This is not a research monograph. It's a reference. The algorithms themselves were published and proven, including runtimes, before they ever made it into those pages.
And, yes, there is plenty that almost anyone can learn from these books and the subsequent fascicles, but it's nothing to do with the computational model. Not one result in TAOCP contradicts the previously published work. We can learn from it because there is simply so much there to learn from. There's a reason that when Steve Jobs told Don Knuth "I've read all your books," Knuth responded that jobs was "full of shit." [0]
---
[0]:https://www.folklore.org/StoryView.py?project=Macintosh&stor...
Re: For Donald Knuth, good coding is synonymous with beautiful expression
#150Earlier quoted context omitted.
On the other hand, I took a few semesters of elective photography courses in high school, and there’s a certain essential amount of time it takes to make a good photo print and run it through all the chemicals. It can’t really be compressed down shorter than about 35–40 minutes for the whole process with only limited ability to parallelize the work while maintaining quality, which makes it tough to make more than 1 o…
Apples to oranges. Painting is a purely creative process with style being valued over correctness. While there is artistic decision during manual film development, there is definitely a wrong way to develop a print. If you rush the chemical process, it will end up bad. Film is more like baking in that regard while painting is stove top cooking.
I guess my point is: the important thing to learn here (in my opinion) is that regular deliberate practice with focused attention is helpful, not that people should try to rush out as much sloppy work in as short a time as possible.
Even the highest quantity of practice is not necessarily essential. My impression is that its spacing out over time is even more crucial.
I have a 3.5 year old, and I’ve been watching him learn all sorts of skills (learning to understand and use language, walk, run, jump, ride a balance bike, solve logic puzzles, build with construction toys, draw, ...), and it’s amazing the kinds of leaps he will make in balance, coordination, speed, understanding, etc. at some specific skill over the course of 3 or 4 months, even if we only practice the skill for 20 minutes once every few weeks.
Somehow the brain is churning on it in the background, and there are sudden leaps in ability which can’t be obviously explained based on direct practice time.