smarks

Yes, I was wondering about this too. I also tracked this down to the IEEE article but it unfortunately has no other detail. I find it hard to conceive that a 20-line program would take three days to toggle into a computer, even if each line expanded to several words of computer memory.

Here's some speculation, though. The SPEEDAC had 4096 18-bit words. [1] If one were able to toggle manually at a rate of one bit per second, it would take over 20 hours of toggling to fill memory. If you add time to recheck values, set addresses correctly, and so forth, it's quite plausible that loading a large program would take three full eight-hour workdays.

An automatic loader would thus save the three days it would have taken to toggle in a program that filled memory. Again, this is just my speculation. But regardless, it's a remarkable achievement.

[1] https://en.wikipedia.org/wiki/SPEEDAC

Coincidentally, I just bought this book the week before last. Definitely an interesting historical perspective. I've only skimmed it a bit, but one thing that struck me was at the time (1969) the metasyntax for specifying the syntax of a programming language wasn't a settled thing. BNF was relatively new, but there were several alternatives in active use. She did point out the possibility of ambiguities, but there was no mention of LR (Knuth 1965) or LALR (DeRemer 1969) parsing. I guess parsing techniques were considered research at the time, not settled practice.

Usage of "intern" in this sense is much older than Common Lisp. The earliest reference I could find in a few minutes of searching is from 1974, from the MACLISP Reference Manual:

http://www.softwarepreservation.org/projects/LISP/MIT/Moon-M...

See sections 6.3 and 6.4 and the glossary for definitions and uses of the word.

Unfortunately they don't shed any light on where the term "intern" comes from. Typical usage is that a string is «"interned" or registered in an obarray» but it doesn't explain much more than that. Interning occurs most often at read time, when a string read from the input is turned into an atom, so I'd guess that "intern" is short for "internalize" or similar.

Also agree. Plus, if you sign up for the ACM Digital Library, you get online access to a tremendous library of papers, publications, conference proceedings, etc.

I was once on a project with a tech lead who was really good at finding bugs by inspection. In the "How to Reproduce" section of bugs he'd file, he'd always simply write "Eyeball the code."

Lysator has been around since forever. The English information page [1] says it was founded in 1973. I remember it from the early days of the Internet and possibly even from Usenet days.

Among other things it has a large repository of historical documents and papers on C programming and standardization dating back to the 1980s. See [2].

For what it's worth, I bookmarked the latter link in 2001.

[1] http://www.lysator.liu.se/english/

[2] http://www.lysator.liu.se/c/

I'm curious as to how many people care about nroff/troff style man pages. I work in the group that delivers the Java JDK, and for many years we delivered nroff/troff man pages for the commands such as java, javac, javap, etc.

Some time ago because of "Corporate Documentation Standards" the sources were converted into some XML-based markup, from which nroff/troff markup was produced -- not entirely successfully. More recently because of "Revised Corporate Documentation Standards" the XML sources were converted into yet another format, and the team responsible has given up maintaining the tool that converted that format into nroff/troff. So the plan now is to deliver straight HTML, with the rationale being "nobody looks at man pages anymore."

As an old UNIX hack I opposed this, to no avail.

Are man pages really irrelevant?

Very sad story. The guy's initials are immortalized in the magic number of the zip file format, the bytes of which are

    0x50 0x4b 0x03 0x04

The values 0x50 0x4b are 'P' 'K' in ASCII.

Note also that every Java JAR file is also a ZIP file, so they all begin with the same magic number.

Thanks for the update. Of course if there are any performance problems, I'm sure the javac team would like to hear about it, as this is something they do pay attention to.

A digression on Java compiler performance:

> Java's compile times are sorta reasonable but are apparently getting worse.

I'm not entirely sure what this is about. Could it have anything to do with JEP 215? [1] There were some slowdowns in `javac` in Java 8, but these should be fixed in Java 9. Note this has more to do with type inference than with Java's type system per se, though this distinction is of little difference to most Java programmers.

In our experience with OpenJDK builds, the main performance issues have been around redundant loading/parsing of library class files and JVM/JIT warmup time. These have mostly been mitigated by JEP 199. [2] With the exception of the issues I mentioned above, it's hard for me to see that static typing has had an impact on the performance of Java compilation.

(Overall I agree with the main thrust of the article, particularly with regard to the "set of complicated trade-offs." Personally I find static typing very helpful, but it won't solve software quality problems.)

[1] http://openjdk.java.net/jeps/215

[2] http://openjdk.java.net/jeps/199

Essentially, someone who asks continual questions and who seems unwilling to do any work, research, or to put any effort into learning on their own. Overview is here:

http://meta.stackexchange.com/questions/19665/the-help-vampi...

A common variation is someone who asks a reasonable question, gets an answer, then repeatedly modifies/extends the original question, or who asks a long series of follow up questions n comments. This variation is described here:

http://meta.stackoverflow.com/a/258279/1441122

No generator. I just took Trump's quote about Saddam Hussein and terrorists and changed a few key words.

How long until Trump says something like, "He's a bad guy -- really bad guy. But you know what he did well? He killed drug dealers. He did that so good. They didn't read them the rights. They didn't talk. They were pushers. Over."

I'd appreciate a link to /hidden as well, as I just spent some time hunting around for one.

Has it come to the point where your refrigerator has to wear a tinfoil hat?

And preferably only single malt whiskey that is over 12 years old.

This was brilliant. Thanks for (re)posting it.

I had never heard of Rota before. I'll have to read more about him. It's a bit sad that he lived for only a couple years after this lecture, dying at the relatively young age of 66. (Wikipedia)

Exactly. That's the No True No True Scotsman Fallacy Fallacy.

+1 for the phrase "information-rich sideband".

I agree that the title is misleading, but I'd clarify it to "Software development as typically practiced in industry is an anti-pattern." (Maybe it also applies to government; I don't know.) It seems fairly typical in my experience for the old thing to be continually patched over instead of fixed, awaiting replacement by the new thing that is never quite ready.

Too bad. The ads were more interesting than the article. (For example, British Airways' 787 service from SJC to LHR.)

(WARNING: crusty Sun old-timer memories follow)

For those who aren't familiar with this, up until the mid-1990s or so, Sun let individual engineers name their own workstations. In fact many regarded this as a privilege. Each workstation ran its own copy of sendmail, so one's email address was login@hostname. People came up with all kinds of clever login/hostname combinations, such as what Don mentioned, eat@joes.

My all time favorite was Rich Burridge's, whose workstation was named "stard". Since his login was richb, his email address was...

richb@stard

I thought "doober" was Wayne Rosing's machine.

(Not that this is of any consequence....) :-)

Very interesting! My question is, does it work in email? At least, it might be worth trying.

Story #3 reminds me of a rule: if your company's name causes spontaneous laughter from multiple people, it's a bad name. This really happened:

(at a party, in a group of 6-8 acquaintances)

Me: Oh hi Fred, how're you doing? I heard you got a new job. Where are you now?

Fred: I'm at Clustra Systems.

(entire group laughs spontaneously)

[explanation: everybody in the group other than Fred simultaneously thought, "That sounds like a Clustraf*ck of a company." OTOH maybe Fred did too.]

Not coincidentally, the NVIDIA Auditorium is in the Huang Engineering Center.

Ok, 37 comments so far and NOT ONE is about the talk itself? Come on, people!

I went to the talk and frankly I didn't follow most of it. I also didn't get any connection to trees. But it was interesting to learn that people have studied sequences (codes) and have proven theorems about properties of such codes. I had no idea that this was an area of study.

Tidbits:

Knuth's Commafree Eastman prover is written in C (actually CWEB, a literate programming toolset).

Knuth has memorized a bunch of digits of pi in binary using a mnemonic for remembering pi in octal.

The auditorium was about 75% full. Well attended but not packed. About the same as last year IIRC.

Yes, I also found this quite confusing. The way this paper was attributed seems quite sloppy. It mentions previous publication at the "NCSU COE People site" and gives a link, but omits mention that this paper was originally presented at the International Conference on Software Engineering (ICSE 2013):

http://2013.icse-conferences.org/index.html

These notes shouldn't have been tacked onto the abstract. Instead they should have been clearly separated from the paper itself.

In addition, the PVS Studio team "added a short section" which appears as if it were a modification to the paper, and and it also appears in the augmented table of contents. If one is not reading carefully, or if the section heading has scrolled of the top of the screen, one might be misled into thinking the "added section" was also authored by Johnson et. al. instead of by the PVS Studio team. The "added short section" should also have been published entirely separately.

Nice article, thanks for posting it.

It's ironic that this article mentions the Toyota Production System as an example of a safe and defect-free system. Another article about Toyota was posted on HN today:

«Toyotas Unintended Acceleration and the Big Bowl of "Spaghetti" Code (2013)»

http://www.safetyresearch.net/blog/articles/toyota-unintende...

Apparently Toyota's software development doesn't follow the Toyota Production System.

OK, that was a flip comment; it's pretty clear that TPS isn't suited to software development. However, it does seem clear that Toyota's software development practices are deficient.