521 karma · joined June 19, 2008
Do not read blogs and above all do not write them.
AFAIR, Matt Might had a somewhat different point of view, where he elaborates on strategies how to publish blog posts out of presentations, etc. To me the social web compares very well with the TV on the time-sink scale: you save a lot of time by not doing it.Come to think of it that this is probably the most important detractor for having an NLP based "recommender." Personally, something like this might be interesting, probably even a great help, but at the end of the day, people need to really read a lot of papers, follow the proceedings of their target conferences, journals, and asking colleagues for their bibliographies. This has the added benefit of teaching them how to present their own work in contrast to others, do meaningful evaluations (in the best of all worlds, of course!) and figure out who is doing interesting work and might be valuable to get into contact with. Of course, some parts could be automated, but there is currently no incentive for scientists to do so.
IMHO, it would be a much more important step for CS researches to publish their code, too, because I frequently come across papers that have no implementation or evaluation at all--and that's really bad, because then the least-publishable unit becomes an idea with nice pictures. Researchers can be very successful using this "publication strategy." Come to think of it, there should be another approach to rank scientists by the number of publications, or their impact; unfortunately, I have no idea what could work instead.
While I agree that there are systemic problems with peer review and how the science "enterprise" works, there is fitting analogy from politics by Winston Churchill: "The worst form of government except for all the others."
(unrelated, but still interesting: I guess the guy with the mustache looks kind of familiar, too...)
Then, I also think that your comment about people having written top-down recursive descent parsers for a long time without concrete historical reference is suprising, particularly when we all know of a prominent example (C) that you cannot parse with LL techniques (I rememeber a professor at university remarking on K&R probably not knowing about LL -- though I can't attest to this being true or not.)
I can also not figure out how you connect the Dragon book to Parser combinators. Having implemented parsers in both, monadic and combinatoric style (both of which btw. are a mess to debug) the best connection I can think of is translating formal grammar descriptions using parser combinators. Is this what you are referring to?
I like your characterization of compilers being just calling functions and loops plus switches and pointers to text. While we know about Church-Turing thesis, I am positive that the intricacies of database system implementation, operating system implementation and programming langauge implementation deserves distinction (which is supported by many of them having dedicated special interest groups.)
thanks so much for linking this. I have always been a fan of the history of computing (e.g., Moshe Vardi mentioned Charles Peirce in a talk once http://en.wikipedia.org/wiki/Charles_Sanders_Peirce, and I have seen a reconstruction of one of Leibniz' calculators [http://de.wikipedia.org/w/index.php?title=Datei:Leibnitzrech...), but I did not know that Konrad Zuse got a patent on the concept of pipelining in 1949. (AFAIR Hennesy and Pattern's "Computer Architecture: A Quantitative Approach" cites Tomasulo's algorithm from 1967)
I am positive that Python 3 could be a lot faster than Python 2. If people are interested in what's possible, they should follow the corresponding mailing list (python-dev).
It would also be very informative to know what the differences in automatic memory management techniques are (i.e., what did the previous implementation do?) Personally, I am also interested in interpreter optimization techniques, and it would therefore be interesting to me what--or if at all--the previous VM used for example threaded code or something along these lines.
Anyways, PLDI has the "Best of PLDI" papers from 1979 to 1999 (http://www.informatik.uni-trier.de/~ley/db/conf/pldi/pldi200...) and they establish the most important paper 10 after its publication. AFAIK/IIRC OOPSLA/SPLASH does this now as well. I think it's good, but it would also be very interesting to know, whether there is an intersection between the set of "Best Paper" awards and the set of "Most important/impact" awards.
Regarding the list: I think it's a nice effort, but lacks several excellent and remarkable books. Just quickly browsing, I found the following essential books missing:
* In algorithms:
- Aho, Hopcroft, Ullman: The Design and Analysis of Algorithms.
- Wirth: Algorithms and Data Structures.
* In Compilers:
- Wirth: Compiler Construction.
- Grune, Bal, Jacobs, Cerial: Modern Compiler Design.
- Muchnick: Advanced Compiler Design and Implementation.
* In Lambda calculus:
- Barendregt: Introduction to Lambda Calculus.
* In theoretical computer science:
- Kozen: Automata and Computability.
- Davis: Computability and Unsolvability.
* In concepts of PLs:
- Turbak, Gifford, Sheldon: Design Concepts in Programming Languages.
(In general, the list does not mention any of Wirth's books, which is a shame. The Project Oberon book should also be mentioned in OS stuff, I guess...)Regarding compiler construction: As has been previously mentioned several times on HN, Cooper's and Torczon's "Engineering a Compiler" is a more recent and (IMHO much more readable and accessible) choice.
Furthermore, I think this "problem" is attributable to jit-compilation in general, since you have to store the code somewhere. The situation was/is somehow similar to the JVM's memory requirements. An interesting alternative to code generation is to optimize interpreters instead.
(Since you've read Faust and the intial post mentions Gibbon's Rise and Fall, you might be interested in Theodor Mommsen's "History of Rome" as well.)
I have been using vim extensively for about 8 years and used a boring phase during my previous work-life to start learning Emacs. My motivation was not because I liked anything particularly well in Emacs or disliked vim, but more that I wanted to see first-hand what the difference is really all about. (So that I know what the flame wars are all about, without ever needing [and also never wanting] to participate in one...)
I am still using vim from time to time, but cannot imagine going back to vim full-time and leaving Emacs. The learning curve is steep and getting a nice setup takes considerable time (thankfully, there are very enlightening articles, for example the one from Steve Yegge, as well as the excellent emacswiki; plus, many people post their ".emacs" file on the web.) IIRC, it took me about 6 months until I felt proficient, and now, after almost 5 years or so, I couldn't actually be happier. There are many reasons to my happiness with Emacs (TRAMP, ido, yasnippet, auctex+reftex, vcs-interface, dired+, org-mode, macros, breadcrumbs, etc.) but I don't want to get into that, let's just finish this by saying: if you're generally interested and have some time at your hands (it's far less cumbersome as you might think, and mechanically codifying is usually [for me at least] not really the time consuming task in programming), just do it and stick with it for a couple of weeks!
http://web.mit.edu/newsoffice/nr/2000/neurogifts.html
I guess that its top 3 still hold. In addition, I found the following:
- $1b endowment to found Vedanta University from Anil Agarwal Foundation (2006)
- $454.5m to National Taiwan University from Terry Gou (2007)
- $400m to Columbia from John Kluge (4th largest in 2007)
- $360m to RPI from an anonymous donor (page mentions largest in US history in 2001)
I could not easily find the official list all of these pages refer to, anybody has an idea?
(Minor remark: for smaller tasks [and instead of launching a terminal window] I prefer to use the DirOpus clone "worker" on UNIX.)
A stack-based virtual machine architecture has compact code representation (only bytecodes) where operands are pushed onto and popped of the corresponding argument stack. Register based VM-architectures require you to encode source and destination registers into the operations. IIRC, for Java bytecode, going from a stack-based representation to a register-based virtual machine grew the code size by more than 40%. But on the other hand interpretation got more efficient, since you have less instructions overall and thus fewer instruction dispatches. If you want more details I'll gladly point you to the excellent and canonical reference for this: Shi, Casey, Ertl and Gregg: "Virtual machine showdown: Stack versus registers." TACO http://dl.acm.org/citation.cfm?id=1328195.1328197 (There is also the journal article's predecessor from VEE05, https://www.usenix.org/events/vee05/full_papers/p153-yunhe.p...)
Law: You can't check code you can't parse. Checking code deeply requires understanding the code's semantics. The most basic requirement is that you parse it. Parsing is considered a solved problem. Unfortunately, this view is naïve, rooted in the widely believed myth that programming languages exist.