John_Maxwell_IV comments on PSA: Learn to code - Less Wrong

34 Post author: John_Maxwell_IV 25 May 2012 06:50PM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Comments (77)

You are viewing a single comment's thread. Show more comments above.

Comment author: wmorgan 25 May 2012 09:00:57PM *  6 points [-]

Agreed about debugging. Dijkstra said something like, "Debugging is the process of taking bugs out; therefore programming is the process of putting them in." Or consider the revelation of Maurice Wilkes:

As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.

One of the biggest misconceptions I notice in non-programmers is that they think it's mostly typing: "telling the computer what to do." Depending on the task, it's a lot of reading, or researching with Google, or staring intently at text on the screen for long minutes until you figure out what you're doing wrong.

Knowing how to program can often be secret sauce for semi-skilled labor. This resourceful individual claims to have tripled their salary by writing a program to mostly-automate their work, thereby collecting the lion's share of bonuses. At my company, I've saved whole person-weeks of others' time with really simple stuff.

My first software job was working for a guy who saw a need, wrote one program, and he's been supporting his family & lifestyle business for 7+ years by selling licenses for $1K-$10K per seat-year to corporate clients who are absolutely thrilled to buy them. Opportunities like this are everywhere, once you start to notice them.

the second most common letter for an English word to end in

Cribbing a bit from Doug McIlroy:

cat /usr/share/dict/words | \
sed -e 's/.*\(.\)/\1/' | \
tr A-Z a-z | \
sort | \
uniq -c | \
sort -rn

Edit: whoops, John_Maxwell_IV is right about the above program. It's 50% humor, 50% code golf.

Comment author: John_Maxwell_IV 25 May 2012 09:46:22PM 3 points [-]

Just for the benefit of bystanders, most computer programs to do what I described are far easier to understand than the one wmorgan wrote.

Comment author: fubarobfusco 26 May 2012 04:46:43AM *  2 points [-]

It's actually quite straightforward. It's just written in a language that most coders don't use, and moreover it uses data types that most "coderly" languages don't have. It would be pretty obvious to many experienced Unix sysadmins, though; there's nothing here that a sysadmin wouldn't use in doing log analysis or the like.

The most accessible data types in Unix shellscript are strings, semi-lazy streams of strings, and processes. A shell pipeline, such as the above, is a sequence of processes connected by streams; each process's output is the next one's input.

  1. cat /usr/share/dict/words | \ Create a stream of strings from a single file, namely a standard list of English words.
  2. sed -e 's/.*\(.\)/\1/' | \ For each word, extract the last letter.
  3. tr A-Z a-z | \ Change any uppercase letters to lowercase.
  4. sort | \ Sort the stream, so that all identical letters are adjacent to one another.
  5. uniq -c | \ Count identical adjacent letters.
  6. sort -rn Sort numerically so that the letters with the highest counts come first.

It is not really clear to me that this is particularly less expressive than the straightforward way to do an equivalent operation in modern Python, as follows:

import collections
c = collections.Counter()
for line in file("/usr/share/dict/words"):
line = line.strip().lower()
if not line:
continue
c[line[-1]] += 1
for (ltr, count) in c.most_common():
print ltr, count
Comment author: shokwave 28 May 2012 01:10:57PM 1 point [-]

Ways in which it might be less expressive: using the small, efficient pieces of Unix takes a while to be conceptually similar to using the different functions of a programming language. Using a regex.

(Inferential distance is hard to estimate; I know I like to hear where I'm incorrectly assuming short distances; I hope you do too).