sb's comments

Seconded! Especially with magit (and I suppose with vc in general) key chords are really nice.

I started using emacs about seven years ago after about eight years of exclusively using vim, primarily because I wanted to see what the editor war's were all about (and because I got the blues from work and needed something uplifting...) I agree with the learning curve, and constantly am fine tuning my setup and configuration, but once you've mastered the basics, it truly becomes one of the most powerful editors. Plus it is constantly evolving (e.g., multiple cursors).

Another good emacs guide that I came across recently is:

http://m00natic.github.io/emacs/emacs-wiki.html

Additional resources I found helpful:

http://www.emacswiki.org/emacs/EmacsNiftyTricks

http://web.psung.name/emacstips/essential.html

Plus, check out the videos from Magnar Sveen's emacs rocks:

http://emacsrocks.com

In general many commenters have a misconception that the mentioned French "baccalaureate" is related to the US/UK undergraduate bachelor's degree. As the article points out, and the corresponding wikipedia page hints at, this somewhat roughly translates to a high school diploma in the US, the British A-levels, the German Abitur, etc.

There is an interesting comment that illustrates the distinction between US/Europe education systems by observing that in Europe high schools are general followed by focused specific subject studies, whereas in the US there is a lot of focusing already happening in the high schools. Interestingly, though, there seems to be a general education requirement for an undergraduate degree; since I am from Europe this seems to have the purpose of ensuring that all admitted students get to the same level before specializing.

Managing free memory is indeed an interesting problem. Besides the simple free-list approach sketched by the author (sidestepping the first-fit vs. best-fit search strategy, which affects fragmentation, too), I always found the buddy-list to be particularly interesting:

https://en.wikipedia.org/wiki/Buddy_memory_allocation

Unfortunately, the article is not a very good explanation, I remember having seen a drawing of the data structure, but cannot recall from where...

edit:

It turns out that the mentioned jemalloc internally uses buddy lists as well.

A couple of years ago, I read his paper "Definitional Interpreters for Higher Order Languages" [1], because it was suggested to me by a friend. It was a joyful read, and to the best of my knowledge it is the first treatment of how to implement higher-order language constructs in a first-order language. Just recently, I thought of the paper, so it's sad news that the author has died...

[1] http://repository.readscheme.org/ftp/papers/plsemantics/reyn...

ABC, always be coding.

I tried Oberon once and have to say that it was way ahead of its time. Not only did the author (of the linked paper) invent one of the first JIT compiled systems, but also the ability to execute code with a mouse click (similar to Rob Pike's ACME editor) is---for a systems programming language---still not available today.

There were several novel research ideas tried for the Oberon system. I remember there was some paper called "Active Text" that allowed putting videos into code comments. (Probably that could have been done in Smalltalk, too.)

Finally, all of the books explaining details are heartily recommended. Wirth's compiler book (referred to at HN several times) is a classic easy-going introduction (the Oberon-0 grammar fits on only two pages IIRC! [1]), his algorithm book (also available for download, also referred to multiple times at HN) has some of the nicest descriptions that I did not find anywhere else (showing a divide-and-conquer approach to computing the median [near the Quicksort treatment]; plus polyphase sort, which might be useful again in data centers), and finally the Project Oberon book contains some unique treatment on system software that is not easily found anywhere else. For example, it contains the details on what's called PieceLinkText, which is the (at least AFAIK) best data structure to implement a text editor and it's operations. (Predating rope-strings by a fair amount of time, too.)

edit:

[1]: just checked my own copy; Oberon-0's grammar actually fits on one page, the full Oberon grammar fits on two pages!

[2]: URLs:

- Compiler book: http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf

- Algorithm book: http://www.inf.ethz.ch/personal/wirth/books/AlgorithmE1/AD20...

- Project Oberon: http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd...

ad 1: Please also do keep in mind that there are career steps after obtaining tenure. If you say "Fuck it" right after getting tenure, you are almost certain to never make it thus far.

I also do agree with the other comment regarding funding agencies. Another problematic way that NSF does business (inviting professors for peer review that is) is that this virtually guarantees that some of your peers know exactly what you're doing, which reduces effectiveness of double-blind submissions substantially (to the point where it is hard to believe it works at all; didn't it ever occur strange to anyone that the same people from the same top schools are consistently successful? [with grants and publications in the top venues])

I know these from the site, and have looked at the Django benchmark that's listed there. I think it's a rather small benchmark that does exercise lots of Django internals (but that benchmark comes from Unladden Swallow). I don't know for the twisted ones, though.

What I actually wanted to know, what the biggest application is, i.e., a not benchmark.

ad 1) Hm, this seems to be a good point, but what's with the following line of thinking: some thread A interprets a program P, while another thread B compiles P to native machine code (P'). Now, if another thread C would start executing P' (taking the data/snapshot from A), then C's caches should build up and remain accurate. Of course, if this happens too often, then the caching behavior will be shitty. I always wondered (based on my interest in interpretation), how much I-cache misses the instruction cache flushes after inline-caching in native machine code cause. (If you have some data on that, please let me know.)

ad 3) I am well aware of that. However, I remember that at PLDI'11 there was a talk from Univ. of Edinburgh chaps doing parallel trace-based dynamic binary translation. Obviously, DBT is less work than a high level, full-blown JIT, but at least it's not nil :)

Interesting point of view, the problem in compiler construction is well known ("Proebsting's law", though it says it's more like 18 years instead of 10.)

The issue with benchmarks is surely well known, also by the PyPy authors; I wonder what the biggest application is that they have benchmarked or that runs on PyPy.

Your point on the JIT compiler interrupting program execution is certainly valid, too, but not necessarily so. One could easily do the code generation in a separate background thread and let execution switch over only if necessary. But, as you have already said, a latency issue certainly exists. This is one of the cases where interpreters usually have a leg up, and there are promising ways of optimizing interpreters.

Hm, there are already some comments about possible optimizations kicking in and asking for assembly code (which is always a good idea to look for changes). However, before doing all of these things, I would want to know how these results were measured? How many repetitions, which machine configuration, standard deviation, etc. It could very well be that this behavior is due to some pre-caching in Windows or some other external factor.

I agree that it is all about cost, however this is far more "local" to many US citizens than they might imagine. For example, most of the coke bottles outside of the US come in half litres, while in the US they come in 20 fluid ounces (this is certainly true for many other products, too.) Hence, companies that make coke filling machines must accommodate the imperial system on top of the metric system, as well. Given that the metric system company can easily grab most of the market share, it should eventually be able to get larger economies of scale. In the end, it could very well be that machinery to supply imperial unit sized products becomes more expensive, a cost that will most certainly be relegated to the consumer.

This year I either read, or started to read the following interesting books:

Mathematics: Form and Function by Saunders Mac Lane. This is one of my favorite books concerning the "build-up" of mathematics (it also contains nice diagrams of "relatedness" of subjects). On HN somebody once recommended Mathematics: Its contents, methods, and meaning (from Russian mathematicians in the 50s) which is similar but without the cross references.

Proofs and Refutations by Imre Lakatos. I have started reading this only recently and have to say that I find the approach and idea excellent. It would be great if we had something comparable for CS theory as well.

Notes on Introductory Combinatorics by Polya, Tarjan, and Woods. Have not read this exhaustively, but the introduction with Pascal's triangle and some of Polya' legendary problem solving insights (paraphrased from my memory: "you are on to something once you find a pattern") are definitely highlights in this book.

Mathematical Discovery: On Understanding, Learning and Teaching Problem Solving by George Polya. Based on the previous book and my fond memories of reading "How to Solve it", I got this one from the library. Again I can't attest for all of the contents, but AFAICT now it's another gem from Polya.

From HN advice in previous years I read The Tibetan Book on Living and Dying, which I can heartily recommend, too. It is an anti-thesis to Christian theology and I find it to contain many insightful comments and different views on leading a good, meaningful life. I disagree with some of the church-y comments on that it really is important to have a master and that only the master can do certain things, but that's probably just me being an atheist all along.

I actually read some other books, but the list is already kind of long and might hold interesting pointers for other mathematically inclined readers, too. I for one am always fascinated on how much advice on problem solving in mathematics translates to CS.

Nice article (the Stanford Encyclopedia of Philosophy has many more, btw.), but I like the "Introduction to Lambda Calculus" by Henk Barendregt (one of the people working in Lambda calculus, see for instance the citation to his book "The Lambda Calculus: Its syntax and semantics." in the references), which has the added benefit of being free:

http://www.cse.chalmers.se/research/group/logic/TypesSS05/Ex... (also covers typed lambda calculus AFAIR)

I love that one, and it always surprises me when I meet people who can't express themselves properly. There are some of the earlier EWDs, where he meets a lot with German computer scientists (in particular one of the founding fathers of the field there, Friedrich L. Bauer, whom he calls "Uncle Fritz"), and it seems that he had good understanding of German, too.

There is also an interesting video of Dijkstra from a Netherland's television station (http://www.cs.utexas.edu/~EWD/video-audio/NoorderlichtVideo....)

In college I was reading a lot of the EWDs (particularly his trip reports, some hilarious stuff there) and IIRC he didn't like C/C++ a lot and thought that functional programming has some promising ideas. This was in the later EWDs, I'd say 1150+.

There are some fun quotations of him about APL and Basic.

I usually recommend E.T. Jaynes' "Probability Theory: The Logic of Science", which is one of the most beautiful and comprehensive books on the subject.

To get the "logic of science" part, you also need to have (IMHO) some fairly decent grasp of combinatorics, for which I quite recently stumbled upon one of the best books in this field: "Notes on Introductory to Combinatorics." (I like the links to many of Polya's gems of "How to solve it.")

For many other references, a quick HN search for publicly available references will result in other endorsements, too (a preliminary version of the Jaynes' book used to be available, too)

Hm, I have never really thought about NLP, but I guess maintaining an NLP program somebody else has written must be even more of a nightmare than what we have now...