jasone

The FreeBSD manual pages. They are thorough, accurate, and well maintained. I still refer to them on occasion even though I've not actively developed on FreeBSD for the better part of a decade now.

I read it at age 11, again at age 28. The difference in personal experience was remarkable. The best parts of the story were very different between those ages.

Books have to be rather exceptional to earn even two readings. So far only the following have gone 3+.

Dune - Frank Herbert

The Hobbit and LOTR - JRR Tolkien

Magician - Raymond E Feist

The Great Gatsby - F Scott Fitzgerald

This article gets a lot right about the shortcomings of the standard malloc API. But I find it unfortunate that it starts off citing modern allocators including jemalloc, yet makes no mention that jemalloc has for nearly a decade provided the non-standard *allocx API to address essentially all of the discussed shortcomings. I encourage people to read the jemalloc manual page for comprehension.

I found the prequel, "A Deepness in the Sky", even more compelling. The book's theme is the inevitable collapse of legacy software under the weight of its own complexity. And the book views codified government as a form of legacy software.

I've read eight of the Culture novels now, and "The Player of Games" was in the bottom two for me. I'm mystified that most others seem to rank this book so high. "Use of Weapons" and "Surface Detail" are my favorites so far, but they're rarely mentioned here.

Hah, you could have done worse. The double-dose introduction to stack-based programming via HP calculators and Adobe PostScript in the 90s led me to spend on the order of 3000 hours developing Onyx (https://github.com/canonware/onyx), which started off as a PostScript clone minus graphics, and ended up a thing of its own.

On the bright side, I learned a tremendous amount about lexing, interpreters, exceptions, tail-call optimization, data structures, garbage collection, etc., which opened up lots of possibilities in later projects. With the benefit of hard experience I would never recommend using a stack-based language for a large project, but as a learning tool it has some nice qualities.

It held up for me. I played a lot of Stratego with family and friends as a kid, but there was one friend in particular who routinely wiped the battlefield with my pieces. I couldn't understand how he so consistently beat me, and as an adult I was able to 1) reason more deeply about the game, and 2) quickly learn deeper strategy from the Internet. As a result, the game is even richer now to me than it was in the 1980s.

I could have been happier with the soundtrack, but I think most of that is on the director rather than Hans Zimmer. The Dune Sketchbook Soundtrack [1] was in my opinion quite good; I think the director just chose to avoid some of the really cool, but rather esoteric, music he had available.

1: https://www.youtube.com/watch?v=huC_e9EkN8U

Turbo Pascal 2.0. It was a fantastic IDE for learning to program.

I (an American teen) also ate there in April 1990, with partially overlapping observations. The food was higher quality than anything else I ate during a week in Moscow, but it struck me as pretty standard McDonald's fare. As for the line, it was very long, but moved in fast spurts. Customers were admitted in waves and it was the most efficient retail orchestration I'd ever seen. There was some magical blend of Soviet queuing efficiency and fast food efficiency going on that left a deep impression.

I have found Jekyll on GitHub to be a pretty good solution overall. I put this Makefile in the git repo to make my workflow simple:

https://gist.github.com/jasone/b0208286b44208b705156fdf046ca...

The one issue I'm frustrated with is that syntax highlighting for code blocks depends on GitHub's blessing:

https://github.com/github/linguist/issues/2598

For example, this page from my blog highlights OCaml code, but not the language I'm developing (Hemlock):

https://branchtaken.com/blog/2021/11/15/string-formatting-in...

Given the low likelihood of Hemlock sweeping the software world before this becomes a critical presentation issue, I'm probably going to switch my publication workflow to pre-generate html.

Similarly, I have used dc as my desktop calculator of choice since the mid-90s. It has been useful in many one-liner scripts too. A simple, powerful tool.

The single best book I've encountered for this sort of learning is Programming Language Pragmatics, by Michael L Scott. I read an earlier edition (3rd?) cover to cover well after entering industry, and it was invaluable for both broadening my perspective and fully grasping many foundational concepts.

When I was finishing up a bioinformatics doctoral program in 2009 I looked far and wide for postdoc positions in the field. My recollection is that the typical salary range was $27k-$30k. What surprised me was that I dug far back in a systematics-specific newsgroup and found the same salary range being advertised for the previous 10+ years. I can't speak to what has happened over the past 12 years, since the low postdoc salaries pushed me to industry, but I can say that you're off with the "more than two decades" claim, at least as a universal claim.

Ah, East of Eden. I'm halfway through it right now, and it is fantastic so far. I've found many good recommendations over the years from HN threads. For example, I've read 7/10 of the Culture novels by Iain M Banks now, and a couple of them were exceptionally good (Use of Weapons, Surface Detail). Most discussion here ranks the books roughly the opposite of how I would, but chances are good you will thoroughly enjoy at least some of them.

Last year I finally got around to reading the Book of the New Sun series by Gene Wolfe (another series recommended more than once on HN). Oh wow. So, so good. Yet I hesitate when recommending these books, because they are challenging to read, both in terms of vocabulary and deeply entangled story. Many times I had, "Wait, what?" moments where I reread entire chapters to make sure I really understood what had just happened. And there are many pieces I won't be able to fit together without at least another reading or two. The prime audience for these books is narrower than most of what I've read, but if the books speak to you, you're in for a huge treat. There are five books, but the first four are commonly published as pairs:

- Shadow & Claw

- Sword & Citadel

- Urth of the New Sun

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

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

A great thing about working in California is that state law makes employment contract clauses that say the company "owns your brain" unenforceable. Among other things that puts a real damper on lock-in with non-compete clauses. Employment contracts typically have a "list of inventions" attachment, on which you can list everything you lay claim to having invented (whether you actually worked on an artifact or just designed something). I was at times extremely liberal in what I listed as inventions, and no employer ever balked. FWIW, that includes two FAANGs.

All that said, if you intend to moonlight on a project that significantly overlaps with your employer's business, you're on shaky ground ethically and legally. For such projects it becomes difficult to claim you did all the work on your own time, with your own resources.

I'm surprised the speedup for Lark is so small (<2X). Back in the Python 2.x days I wrote an LR(1) parser generator, and ended up porting it to Cython because it was taking several minutes to generate the parser I was working on. IIRC generation times dropped from over 3 minutes to less than 20 seconds, so ~10X speedup.

I read this article a few years ago, and it put me off reading Cloud Atlas for quite a while; I didn't know which version to read, and didn't want to read both. But last year I decided to just go for it and read the American version. It was a thoroughly rewarding read.

Cloud Atlas has an interesting interleaved timeline structure, which I'm particularly fond of when well done. The Licanius trilogy by James Islington has some similar devices. And Use of Weapons by Iain M Banks, which is one of my favorite books ever, does something even more involved: forward and backward story lines meet in the middle.

First off, recognize that peer review is a deeply flawed process, but it's generally less bad than no peer review. Peer review is primarily capable of catching methodological flaws, and of improving how the results are contextualized relative to prior art. Peer review does not imply replication of claimed results. In this case the original author falsified data, intentionally misleading the reviewers. The methods described in the papers were untruthful, which is much more challenging to catch than merely poor methods. In the end he was caught because of the non-random structure of falsified experimental noise in his data across multiple experiments. That, in combination with others' inability to replicate the results, caused the results to be retracted, and the author called out for the fraud. It may not have been feasible to recognize the fraud in any individual paper.

This appears to have been an extreme case of scientific misconduct. Many less egregious cases are never caught. And many unintentionally flawed papers are never caught as erroneous. But the overarching trend is an increase in the body of knowledge. Peer review is just one component of society's scientific research infrastructure, critical yet inadequate by itself.

Previously discussed:

- https://news.ycombinator.com/item?id=13230904

- https://news.ycombinator.com/item?id=13271746

Perhaps you are imagining less imperfect, less egotistical, less insecure scientists in a past Golden Age of Science. I for one have stopped believing such an era ever existed, or will ever exist. But I continue to believe that the scientific process will continue to serve humanity well despite the terrible flaws of us humans attempting to apply it. Yes, I believe in the scientific process , that it will self-correct, that the attacks by bad actors and self-deluded participants will come out in the wash.

As a doctoral student I had a paper rejected because I didn't toe the dogmatic line of one prestigious reviewer (seriously, the review feedback lacked only the word "dogma"). Terrible, right? But this is a common theme over centuries as near as I can tell, and here we are, living in a magnificent future!

We will continue to benefit from the scientific process, despite all our individual flaws, and despite how easily we each fool ourselves (and sometimes others).

Ugh, drivel. Even people in high-reputation positions can, and do, spout nonsense. There are many risks when bicycling, including motorists treating bicyclists even worse on average when they wear helmets. But when when the head hits the road, a helmet substantially reduces the likelihood of traumatic brain injury (TBI). Just like crumple zones in cars substantially reduce auto-accident-related injuries.

Been there, done that, got a crushed helmet and concussion rather than a life-altering TBI or death.

This is a cool paper, though it doesn't solve the problem that a general purpose tracing accelerator would have to. In order to handle diverse object/value layouts there needs to be some way of determining from the run-time type which words are references. The type information block (TIB) is a flexible, common solution, yet this paper changes the run-time memory layout to do away with TIBs entirely and instead segregate reference/non-reference words using a bidirectional layout (non-references precede the header, references follow the header). The bidirectional layout is a reasonable approach in many cases, but it is not universally applicable. Therefore I see the accelerator as described to be merely an example of co-designed acceleration. And therein lies the rub with GC acceleration -- there are so many approaches to memory layout that it's difficult to come up with a clean abstraction that can be meaningfully accelerated via special-purpose hardware.

Paper URL: https://people.eecs.berkeley.edu/~krste/papers/maas-isca18-h...

This. I self-hosted from the mid-90s until giving up in 2017. My outgoing email was increasingly black-holed by major email providers. I eventually accepted that I would either have to give up on email or pay for hosting. At some level this feels like paying protection money, but there are a lot of things about the internet that don't match up very well with 90s idealism.

I have used kakoune almost exclusively for two years. Prior to that I used vim for 16 years, emacs for 10 years before that. For me kakoune started as vim visual mode done right, but I have come to love the editor because it has a small orthogonal command interface that provides all the power I had with vim, but with lower cognitive burden.

Kakoune is a fantastic tool of rare quality. I find it a joy to use.

There are lots of possible causes and solutions. Some are hard health-related problems you can at best mitigate. But if you're otherwise healthy and just spend a lot of time at the computer, there are potentially some "easy" solutions. In particular:

- Use proper sitting posture, change position often, stand/walk when possible.

- Use an ergonomic keyboard which avoids troublesome positions/movements.

- Exercise. In particular, do some resistance (weight) training.

Anecdotes:

- In my mid 20s emacs pinky could have done me in, but Kinesis ergonomic keyboards worked around emacs afflictions.

- In my late 30s arthritis started troubling me, but a decade later I have less pain (inconsequential) due to taking better care of my health/fitness. But on the downside 16-hour programming days are now a distant memory.

I've read many, many anecdotes over the years, and they make clear that people have diverse afflictions. Be careful about following advice that doesn't apply to your circumstances.

Unless you're dealing with mail, in which case you're more likely to succeed with "Coeur D Alene". Our city name apparently isn't sufficiently American in some contexts.

I recall reading about spice being used to mask the flavor of food starting to go bad. It's not a preservative function, rather it allows people to eat poor-tasting-but-not-yet-poisonous food.