121–130 of 229 posts
Earlier quoted context omitted.
True. The editor on the left side does look like emacs.
That's the FVWM window manager. His FVWM config (or at least some version of it) is available if you're curious: https://www-cs-faculty.stanford.edu/~knuth/programs/.fvwm2rc .
When I see the picture in the article, I was wondering what kind of editor he is using
> 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?
Whenever I start at a new company, before I get thrown into the heart of things and become "too busy" to write these kinds of programs, I like to write things that automate the boring stuff.
Some recent examples:
- a cli for inspecting, adding comments to, and updating the status of JIRA tickets. because our hosted JIRA instance was god-awful slow and their web interface is a mess. - a tool for monitoring things and pinging me with macos native notifications when things crash or complete.
Was my net productivity positive for writing these tools? hard to tell.
There are some companies full of engineers whose actual job is to write tools like this; I'm not sure what they would do for fun :P
Earlier quoted context omitted.
On the contrary, I think it's extremely useful to have the algorithms realized in a form that has a cost model free of handwaving. The books are to a great extent focused on computational costs, and high-level languages obscure those costs. The only exception is that the books only rarely dive into the variable computational costs due to operating on values of different sizes; heapsort, for example, is only O(N log N…
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.
I suspect that isn't the reason this kind of analysis isn't usually done, though. If you measure the running time of a standard comparison sorting algorithm on real data on almost any general-purpose computer from 1955 to 1985, you will find that, above very small sizes, it is quite precisely proportional to N log N, where N is the number of records. The extra factor of log N doesn't show up. Why is that?
It's because almost all of those computers, even bit-serial designs like the RCA 1802 and the LGP-30, aren't bit-addressable; the smallest amount of data an instruction can manipulate is a character, typically 6-9 bits, but often 32 bits. And almost none of them could manage more than 4 gigabytes of data, because that would have been too expensive. So in practice the average time to compare two separately stored keys does not vary by a factor of 100 or so over the data sets the machine could process, as you would expect from looking at key unique prefix length. It might vary by a factor of 2 to 4, but more often was actually constant. 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.
After 1985, caches and massive parallelism complicate the picture a bit, initially for largish machines (though Stretch too had cache, such monsters were exceptions) and finally for almost all types of computers, though perhaps not yet the numerical majority of computers, which are probably mostly 8051s and Cortex-Ms and things like that.
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.
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.
Earlier 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"…
Cool but fake.
Earlier quoted context omitted.
Here's two that prove it. [0] - https://blog.codinghorror.com/quantity-always-trumps-quality... [1] - https://www.amazon.com/dp/0961454733/?tag=codihorr-20
prove what? That someone printed the anecdote in a book?
Earlier quoted context omitted.
This is interesting and very true. It reminds me of people who are excellent at something but their life gets held back by alcohol/drugs or bad relationships or some other _low minimum_. That first sentence is really profound in my opinion.
You've never experienced good art by a tortured artist, then?
Earlier quoted context omitted.
Here's two that prove it. [0] - https://blog.codinghorror.com/quantity-always-trumps-quality... [1] - https://www.amazon.com/dp/0961454733/?tag=codihorr-20
prove what? That someone printed the anecdote in a book?
Your approach might be different than mine.
Earlier quoted context omitted.
I've heard it said (maybe by Frank Zappa? can't remember for sure) that the difference between a professional musician and an amateur is not how well they play at their best, but how well they play at their worst.
This is similar to skateboarding. If someone wants to go from zero to landing one kickflip in a couple of days, he can (albeit a terrible one), yet while the best skateboarders may very well miss their tricks more often than videos would make you think, but their overall consistency is incredible. When one lands a trick for the first time, the saying goes: "Two to make it true".
To expand upon what you said: it's amazing when you take that trick, a kickflip for example, and you're so confident in your consistency, that you apply it to something new. Kickflip to rock to fakie, kickflip down a set of stairs, kickflip to 50-50, and so on. The consistency you gain from that trick opens up the door to a whole new world of combinations.
There's so much about skateboarding, the culture (or counter culture in some cases) around it that translate so well to programming/hacking (and life in general). The trials of learning something new. The acceptance and overcoming of failure. The respect you shown and earned when you're at the park and you or someone else puts down a sick trick.
One of my favorite creative minds in skateboarding, Rodney Mullen, talks a bit about the relationship between hacking and skateboarding in his TED talk. [1]
> 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?
Earlier quoted context omitted.
I think what he has in mind are small programs that do some kind of nontrivial computation without much in the way of IO or UI. For example, [1] is a program from December 2019 that "finds n-bit binary squares that are palindromic". A great way to get into this kind of thing if you're stuck for ideas is to go through the Online Encyclopedia of Integer Sequences [2] and just write little programs to print out the firs…
Along these lines, Project Euler is great.