rectang

The Coltrane changes are great, but on the scale of other harmonic innovations over the years inside Jazz and other traditions. They aren't analogous to Einstein.

What makes Giant Steps so amazing is the sheer speed at which those changes go past — if you slow it down, it's not that different from other Jazz tunes. It took took years of practice for Coltrane to acquire the specialized skillset for improvising over Giant Steps.

> one or more teams of researchers in the field going dark

If the intelligence community is going to nab the first team that has a quantum computing breakthrough, does it actually help the public to speed up research?

It seems like an arms race the public is destined to lose because the winning team will be subsumed no matter what.

> https://visidata.org/ai

Thanks for that list of levels, it's helpful to understand how these things are playing out and where I'm at in relation to other engineers utilizing LLM agents.

I can say that I feel comfortable at approximately AI level 5, with occasional forays to AI level 6 when I completely understand the interface and can test it but don't fully understand the implementation. It's not really that different from working on a team, with the agent as a team member.

Oh, IOT shock collars. Hope this company takes security more seriously than most IOT players, or some sick people are going to take hacking into these devices as an opportunity for animal cruelty. :(

> never underestimate people's power to ignore.

One of the hardest things to do is to put yourself in the place of those you see as villains and recognize that they generally see themselves as heroes. The human capacity for self-justification is extremely powerful.

I've just bought my copy.

Best-sellers don't sell that many copies in the absolute sense. From what I can tell Careless People has sold around 200,000. Moving the needle just a bit is worth it.

Indeed, that's why "salting the earth" is an age-old military tactic. "If I can't have it, then neither can you."

But I can also see why someone might wish for there to be a reason behind suffering.

Mainstream journalism can't compete its way out of its malaise by insisting on an "impartiality" that demands journalists lie by omission. Such journalism is utterly incapable of meeting the moment and opposing the innovative incrementalist autocracy of Orban, Ergogan, Putin, and others.

Such feckless news organizations are destined to become tools of the state; perhaps that is in fact the smartest play for the profits of their ownership. Certainly Bezos seems to be taking WaPo down the path of collaborator, as are the Ellisons with CBS.

The illusion-of-impartiality model has its loyalists, but this article is about the young news audiences who have have been lost. At least some of them have been lost, not to YouTube and influencers, but to other news outlets (left and right) who have embraced their own biases and adversarial perspectives. You call that a "performance of authenticity", but in the marketplace it has beaten a performance of impartiality which is at least as inauthentic.

It's not that the random YT channel is actually more trustworthy, but that it exposes the audience to adversarial perspectives which mainstream access journalists hide — thereby eroding the trust of young audiences for mainstream journalist outlets compared to previous generations for whom such adversarial perspectives were less available.

I would argue that reading discussion of "CEO says" "journalism" on HN will often better inform you than reading a mainstream journalist puff-piece interview of a CEO. Many journalists will not provide adversarial viewpoints, because to do so would stanch the flow of interview subjects.

Humans are by far the most vicious animal species, because the sophistication with which they apply torture is off-the-charts. Felines and orcas may consume their prey alive or play with them, but it's not in their capacity to keep their victims alive indefinitely with the express goal of inflicting maximum suffering.

A big problem is that the product of "access journalism" is untrustworthy.

In order to produce articles which generate large clickthrough rates for comparatively low cost, news organizations rely on interviews with people in power. But as a price of access, the people in power require a certain level of deference that compromises the news channel in the eyes of young audiences, when there are lots of other competing sources that don't observe the same deference.

Reuters is less guilty of this than the NY Times, but it's a problem that afflicts all traditional news organizations.

The phrase "spiritual successor to WordPress" is not likely to be judged a trademark violation, though. It doesn't create confusion in the marketplace as to whether Emdash is WordPress.

Hosting curated dependencies is a commercially valuable service. Eventually an economy arises where people pay vendors to vet packages.

Brandolini's Bullshit Asymmetry Principle is the adage for our age:

> The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.

https://en.wikipedia.org/wiki/Brandolini%27s_law

I just checked my Github settings, and found that sharing my data was "enabled".

This setting does not represent my wishes and I definitely would not have set it that way on purpose. It was either defaulted that way, or when the option was presented to me I configured it the opposite of how I intended.

Fortunately, none of the work I do these days with Copilot enabled is sensitive (if it was I would have been much more paranoid).

I'm in the USA and pay for Copilot as an individual.

Shit like this is why I pay for duck.ai where the main selling point is that the product is private by default.

It would be interesting to know whether that rule was onerous enough in practice that they had little choice but to break it in order to do their jobs effectively. They were responding to an emergency, seconds count, and they believed they had clearance from the controller.

Look, if you were to review my comment history you would have no doubt about where I stand on the current administration.

But scapegoating any single politician for the systemic problems of aviation is as unhelpful as scapegoating the controller for the crash at Laguardia.

By using the role name rather than proper name, I'd hoped to spare HN from a tangent like this. My point doesn't rest on the nature of single individual, but instead applies to a human tendency. Politicians and press both play to the base impulses of a mass audience, unlike the NTSB. This is not the first time that a politician has scapegoated individuals when systemic failure occurs.

> Deciding to change policies to effect the recommendation isn't their role.

And if it was the role of investigators to change policy, then there would be enormous pressure from industry to reach convenient conclusions, poisoning the investigation process.

In both cases, the controller's fate was grim. Peter Nielsen (Überlingen) was murdered by a relative of a crash victim. Robin Lee Wascher (LA), whose own parents had died in an earlier air crash, was crucified in the media and never worked as a controller again.

Both precedents are applicable, because the Laguardia controller is also going to be savaged.

Yes! But every news organization is leading with "I messed up." And the US President commented "They messed up", though it's unclear who that was in reference to.

Humans have a powerful need to affix blame and punish individuals. On the internet, you are forever the worst moment of your life.

We set air traffic controllers up to fail, and then when something goes wrong we torture them until they die, and then torture their memory after they die.

"Why not neither?"

Yes! And I wouldn't have picked it, but I went along with it when someone else wanted to read it.

The "software IC" metaphor may not have caught on, but these artifacts of early experimentation, competitors against what evolved into mainstream OOP, are many times more interesting to read than the Nth "OOP sux" article.

EDIT: I just went back over some of my notes... Cox predicted that companies would compete to provide different implementations of common interfaces ("software ICs"). In restrospect, that didn't happen but Cox's prediction was wrong in such an interesting way: software orgs rather than customers assumed control over interfaces.

The groups I ran were scheduled during lunch. Technical management would look the other way if we ran over time or if people spent a certain amount of their work day reading the material.

Even if you have enlightened technical management, it's helpful if you don't force them to spend political capital justifying groups like this. Getting our enlightened CTO to spend a few hundred dollars on books was easy when we were a startup. Once we got acquired, making that argument to unreceptive higher-ups wasn't worth it for anybody.

I gave a long post at the top level about running a book-focused reading group at a company, but your group sounds more like a Papers We Love[1] chapter.

I used to co-host the San Diego chapter of Papers We Love[2], and here's my secret sauce: I offered to meet with every presenter in advance for a dry run of their presentation. Probably two thirds of the presenters took me up on the offer.

For the group and the presenter, going through a dry run had the positive impact you would expect on presentation quality.

The benefit for me was that I got one-on-one discussion/learning with a wide variety of people passionate about a broad range of papers, and I also got to go through the material twice. So I learned much more and retained it better.

[1] https://paperswelove.org/

[2] https://www.youtube.com/channel/UCYPNnoVAQqb2Mue9v9f2euA

I ran reading groups over several years a medium-sized startup I worked for and for an open source community I was a part of. The groups were targeted not only at engineering staff but also semi-technical positions such as product management and low-skilled data pipeline specialists, with the aim of building bridges between departments and internal recruitment.

Running those reading groups was basically how I acquired a lot of knowledge I didn't get because I didn't major in Comp Sci as an undergrad.

Books/MOOCs we went through:

* Pro Git (Chacon) [three times]

* Programming Language Pragmatics (Scott)

* Calculus first semester (Coursera/OSU/Fowler)

* Eloquent JavaScript (Haverbeke)

* Learning Perl (Schwartz/Foy) [two or three times]

* Coding the Matrix (Coursera/Brown/Klein) [didn't finish]

* Object-Oriented Programming: An Evolutionary Approach (Cox)

* Learning Core Audio (Adamson/Avila)

The level of commitment from the participants was mixed. Nobody came for the free lunch (although arranging free lunch was essential in getting people to show up). Many people had ambitions that outstripped their commitment. But there were plenty of people who took advantage and learned tons.

One fellow, who I feel immensely fortunate to have known, went from zero experience to arguably our most productive IC within 2 years, and eventually landed at a FAANG. He also took a turn leading the discussion group.

Another participant was a Product Manager who became much better able to communicate with Engineering after improving her understanding of programming fundamentals.

The sessions were generally organized around questions that people would bring about the material — my motto was "we'll struggle through together". I preferred questions posed by others but always had enough of my own to fill space.

The tips I would have for people running such groups:

First you need a discussion leader. You need someone who can get the group unstuck and who knows the material. It's the same dynamic as having a good TA for a college discussion section.

Second, remove all friction. Corporate won't buy books? Screw it, I bought 'em myself. Corporate won't arrange for lunch? Screw it, I bought it for everybody. (Our CTO was highly supportive but once the company got acquired we couldn't get budget approved anymore). The total outlay I made leading the group was a few thousand dollars — far less than I would have paid for formal courses where I would have learned less.

Has there ever been a consideration for the git file format to allow storage of binary blobs uncompressed?

When I was screwing around with the Git file format, tricks I would use to save space like hard-linking or memory-mapping couldn't work, because data is always stored compressed after a header.

A general copy-on-write approach to save checkout space is presumably impossible, but I wonder what other people have traveled down similar paths have concluded.

I agree. Nevertheless I wonder if this approach can help with certain other places where Git sometimes struggles, such as whether or not two commits which have identical diffs but different parents should be considered equivalent.

In the general case, such commits cannot be considered the same — consider a commit which flips a boolean that one branch had flipped in another file. But there are common cases where the commits should be considered equivalent, such as many rebased branches. Can the CRDT approach help with e.g. deciding that `git branch -d BRANCH` should succeed when a rebased version of BRANCH has been merged?

> Papercuts like this are why I moved away from macOS.

It's been this way for decades. Microsoft was known for preserving backwards compatibility, while Apple was known for being willing to break stuff.

The differences aren't that extreme in reality: Microsoft breaks stuff more than it used to, while Apple has become comparatively more conservative than once upon a time.