samps

Thanks, Ben. I admit I mostly think tracing is just a mind-expanding concept to learn about, even if history has proven it’s not very practical as an organizing principle. But as you say, I’d love to offer more context on “what actually seems to work” industrially.

I had an identical experience with the REALbasic Cafe as a kid, down to eventually selling a couple of shareware projects. I wonder if we were there at the same time.

I think it would be more like RPN if it used a stack, and operands were specified as relative offsets (i.e., stack offsets). In the version I wrote, operands are still represented as absolute offsets in the expression table.

FWIW I did acknowledge this in the article:

> A sufficiently smart memory allocator might achieve the same thing, especially if you allocate the whole AST up front and never add to it

> Again, a really fast malloc might be hard to compete with—but you basically can’t beat bump allocation on sheer simplicity.

Indeed; I previously had these papers on the list but had to take them out for time this semester:

- Finding and understanding bugs in C compilers. Xuejun Yang, Yang Chen, Eric Eide, and John Regehr. PLDI 2011. https://dl.acm.org/citation.cfm?id=1993532 - Compiler validation via equivalence modulo inputs. Vu Le, Mehrdad Afshari, and Zhendong Su. PLDI 2014. https://dl.acm.org/citation.cfm?id=2594334

Hi! This course is about the "middle end," FWIW. We do not do parsing or codegen in 6120, and there is no goal (as there is in many undergrad-level compilers courses) of making a complete, end-to-end compiler for a C-like language.

To slightly refine this, Intel didn't have many "foundry customers" before Altera. Via Wikipedia (https://en.wikipedia.org/wiki/Intel#Opening_up_the_foundries...), the need to fill up the manufacturing lines was engendered by poor x86 CPU sales around ~2013, not poor third-party fab runs. In 2013, Intel was still ahead of TSMC with 22 nm.

From the first sentence of the article:

> for free for all developers.

> The diagram shows each core has icache and dcache; what they've ditched is cache coherency.

This is not quite true: the local data memories are not caches, i.e., they do not implicitly move memory in from a more distant tier in the memory hierarchy. They are just plain explicitly managed local memories (sometimes called "scratchpads" to distinguish them from caches).

Security bugs in HotSpot happen can and do happen. Check out the CVE list for the JRE: https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

> However, where it starts to get more interesting is the work done by W. Bastiaan Kleijn from Cornell University Library.

The authors are not from Cornell. I think the author made this mistake because the paper is posted on arXiv, and that’s what’s it says at the top of every page?

Mine's called Hooknook. It takes care of updating the GitHub repository for you on push and then invokes a command inside the repository. https://github.com/sampsyo/hooknook

import pdb ; pdb.set_trace()

As it stands, I'd agree with that---but the characterization definitely depends on who you talk to. I might be in the minority among "PP people," since the hype is still going strong and some smart people seem to see more potential than I (and you) do.

(I'm the author of the lecture notes.) I totally agree, and this is an underappreciated view in the PP community. The hype says "you just write your model; you'll get inference for free," but that obscures that current languages do nothing to help with cooking up an efficient inference algorithm for a particular situation. That's still a hard problem. When the only inference algorithm anyone actually uses is some MCMC variant, I think that's a broken promise.

There's some chance we'll be able to find clever new ways to derive better inference algorithms in specific situations using program analysis, but I wouldn't hold my breath. And it's impossible, of course, for anything like that to work for every possible program in a Turing-complete language.

Needless to say, I disagree. It can be straight-up misleading to report means without including a more nuanced view of the distribution. You don't need to use a bunch of fancy statistics, but you do need to consider whether your results could have arisen by random chance. That's not a distraction; it's accurately reporting what you found.

Here's one frightening example of spurious performance results in CS: https://www.cis.upenn.edu/~cis501/papers/producing-wrong-dat...

Yep! This suggestion comes up shockingly often, and I got tired of re-explaining my reasoning every time.

Thanks; I've added a phrase to the intro section to mention that beets is a desktop app.

TypeScript 1.8 already has unions and custom type guards! You can use them today. Woohoo! (Looking forward to those non-nullable types, though.)

Yes, that's worth celebrating!

But we also have to remember that, to someone not in those well-represented groups, it's not a huge consolation. Diversity isn't a floating-point number between 0.0 and 1.0.

I'm honestly shocked at the lack of empathy on display in this comment thread. The technology world has a diversity problem—why not assume that this is a good-faith effort to address it, just expressed in words you don't like? Why instead flip directly into Internet Outrage Status?

This kind of outpouring of rage, to be frank, is why Hacker News has such a bad reputation. Look around at the comments here: there are people complaining about the very notion that there might be something wrong with how hiring and promotion happens in technology. There are people, like @yoodenvranx, equating their own anecdotal problems with the victimization of white men. There are countless comments asserting that we are capable of "pure meritocracy," a notion that is invalidated by research on implicit bias.

The overwhelming consensus here is that (a) there is no problem, and (b) GitHub's attempts to address it are unjust. This is why Hacker News looks to the outside world like a self-affirming bubble with no grounding in reality.

Cool! I did a similar thing recently in a literate-programming style. https://github.com/sampsyo/tinygl http://sampsyo.github.io/tinygl/

In all seriousity, I would love a similar SSH server that automatically uses keys from GitHub for authentication. Great for setting up a little private git server without fiddling with keys.

Great point, John. Can I have a comments section on my site where only you are allowed to comment?

FYI, I've been on the Prompt 2.0 beta and it's seeming nearly baked: you may not have much longer to wait.

Here's what I did to promote beets (http://beets.radbox.org) over a long period of time (3ish years) before it became "popular":

- Post to domain-specific forums where I thought people would be interested. That includes stuff like /r/python on and /r/music in my case, as well as the user forums for music-streaming systems.

- Build community. IRC, mailing lists, close collaborations on GitHub. Encourage people to become GitHub collaborators early to solidify their commitment to the project.

- Keep trying to delight the users I have. Other people's endorsements on Twitter, HN, etc. consistently work better than my own.

- Screencast. On YouTube so it's easily shareable.

- Patience. Relentlessly make the project better. This is far away the best thing you can do; over the months and years, people will notice.

Yep. :)

I've heard from lots of folks running beets on their Pi.

Someone has done this for beets some time ago already: https://code.google.com/p/beetfs/

But it has bitrotted pretty badly.

Enable the web plugin first. :)