An example of command-line bullshittery in computer science research | Hacker News Reader

An example of command-line bullshittery in computer science research

pgbovine.net

4 pointsyarapavan5 comments

I had Professors David H. Hubel and Torsten N. Wiesel for a really great undergraduate class. Later, to satisfy some undergraduate EE research requirement I did some work for Dr. Hubel. Hubel and Wiesel went on to win the Nobel prize for their research on the origin of visual perception in 1981.

It all sounds like a great story to tell my kids except for one thing: I didn't end up helping them in their research even one tiny bit. All I ended up doing was extreme command-line bullshittery for a semester trying to get a PDP-9 (an 18bit machine!) to talk to a system with some home-brew crt-to-film based output device. Everything had to be coded in low level assembly language and even booting up the PDP-9 in a dark lab was intimidating for someone starting out in CS, not to mention the strange hardware it was hooked up to ("flip this switch but not until the power supply to the film writer stabilizes", etc.)

In the end, Dr. Hubel couldn't have been more understanding, and it ended up as a good experience for me. Not because I did anything productive but because I had a sympathetic professor. Today, I've been programming computers for almost half a century and it's been great. I'm so grateful for the teachers, professors, co-workers and colleagues that have helped me over the rough spots, command-line bullshittery, and my own ignorance over the decades. It's nice to hear the concern Dr. Guo has for his students in the originally cited article (despite the frustration it ends up causing for him).

Another name for phenomenon is: "reality". And the typical way non-"computer science researchers" overcome it is through a system known as "working" or "doing work". As a software developer, I sometimes do so much work in a day that I can barely write a line of code.

Gotta concur. Setting up an SSL certificate or firewall do not constitute bullshit. The complexity of these systems lies in their solid engineering, not any inherit flaw.

SSL is designed to be secure, not easy to learn. I remember how painful it was to set up root certificates the first time I did it; combining certificate files, setting permissions correctly, configuring nginx. It's a pain in the ass. But as a result nobody can snoop on messages between me and my users. Worth it.

Firewalls are firewalls; having one in place means when you send a request to your server sometimes nothing will come back. Yes, if you've forgotten you have a firewall this makes it hard to debug. But if the firewall returned any kind of response it would be less secure.

I am bemused that the author finds this to be demeaning, merely annoyances blocking him from doing his pure "research." I suggest he take the time to study these systems and learn why the annoyances are there. Who knows, out of that might come a new research project that improves the way the world uses SSL!

Man, tell me about it! I needed to do some original research the other day and had to get to an out-of-the-way library.

Do you know how hard it is to learn to drive? Took me 3 months! And don't get me started on buying cars and insurance... All I wanted to do was read some papers!

Professor discovers that actual system creation is painstaking and easily becomes very painful unless great care is taken to manage the complexity... and all he's trying to do is hack two servers together. Imagine if his service had to be reliable!

Reply on news.ycombinator.com