News for hackers. Stuff that matters.

sb

Re:Start Using Emacs – A Thorough Guide for Beginners on Tuesday September 03, 2013 @02:25PM (#6322702)
Seconded! Especially with magit (and I suppose with vc in general) key chords are really nice.
Re:Start Using Emacs – A Thorough Guide for Beginners on Tuesday September 03, 2013 @02:24PM (#6322691)
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.

Re:Memory Allocators 101 on Thursday May 16, 2013 @05:35PM (#5721325)
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...

Re:Show HN: Most mentioned movies on HN on Saturday April 27, 2013 @11:32PM (#5620068)
ABC, always be coding.
Re:Oberon – The Overlooked Jewel [pdf] on Thursday April 25, 2013 @11:05AM (#5607592)
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...

Re:The other side of "academic freedom" on Sunday April 21, 2013 @10:46PM (#5587478)
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])

Re:Why Python, Ruby, and Javascript are Slow on Saturday March 02, 2013 @12:56PM (#5310300)
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.

Re:Why Python, Ruby, and Javascript are Slow on Friday March 01, 2013 @04:55PM (#5307180)
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 :)

Re:Why Python, Ruby, and Javascript are Slow on Friday March 01, 2013 @04:21PM (#5307014)
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.

Older »