“the classic dissection of the problem caused by IRBs”

An argument that the system of boards that license human-subject research is so fundamentally misconceived that it inevitably does more harm than good.

Linked Visualisations via Galois Dependencies - Tomas Petricek

We present new language-based dynamic analysis techniques for linking visualisations and other structured outputs to data in a fine-grained way, allowing a user to interactively explore how data attributes map to visual or other output elements by selecting (focusing on) substructures of interest. This can help both programmers and end-users understand how data sources and complex outputs are related, which can be a challenge even for someone with expert knowledge of the problem domain. Our approach builds on bidirectional program slicing techniques based on Galois connections, which provide desirable round-tripping properties. Unlike the prior work in program slicing, our approach allows selections to be negated. In a setting with negation, the bidirectional analysis has a De Morgan dual, which can be used to link different outputs generated from the same input. This offers a principled language-based foundation for a popular interactive visualisation feature called brushing and linking where selections in one chart automatically select corresponding elements in another related chart. Although such view coordination features are valuable comprehension aids, they tend be to hard-coded into specific applications or libraries, or require programmer effort.

Typed Image-based Programming with Structure Editing - Tomas Petricek

Many beloved programming systems are image-based: self-contained worlds that persist both code and data in a single file. Examples include Smalltalk, LISP, HyperCard, Flash, and spreadsheets. Image-based programming avoids much of the complexity of modern programming technology stacks and encourages more casual and exploratory programming. However conventional file-based programming has better support for collaboration and deployment. These problems have been blamed for the limited commercial success of Smalltalk. We propose to enable collaboration in image-based programming via types and structure editing. We focus on the problem of schema change on persistent data. We turn to static types, which paradoxically require more schema change but also provide a mechanism to express and execute those changes. To determine those changes we turn to structure editing, so that we can capture changes in type definitions with sufficient fidelity to automatically adapt the data to suit. We conjecture that typical schema changes can be handled through structure editing of static types. That positions us to tackle collaboration with what could be called version control for structure editing. We present a theory realizing this idea, which is our main technical contribution. While we focus here on editing types, if we can extend the approach to cover the entire programming experience then it would offer a new way to collaborate in image-based programming.

Composable data visualizations - Tomas Petricek

When visualizing data, you have to choose between high-level data visualization libraries such as Google Charts or low-level libraries like D3. In high-level libraries, you specify the type of chart you want, but you are limited to the features that the author of the library implemented. With low-level libraries, you have full control over the look of the chart, but you have to tediously transform your values to coordinates in pixels yourself. What would an elegant functional approach to data visualization look like? A functional programmer would want a domain-specific language that has a small number of primitives that allow us to define high level abstractions such as a bar chart, but does not limit what we can do. When creating charts, we should be able to use domain values such as a currency exchange rate, rather than pixels in its basic building blocks. As is often the case with domain-specific languages, finding the right primitives is more of an art than science. For this reason, we present our solution, a library named Compost, as a functional pearl. We hope to convince the reader that Compost is elegant and we illustrate this with a wide range of examples

Man as a Rationalist Animal – sam zdat

On /Seeing Like a State/. About legibility, /metis/, and institutions.

The Illustrated Retrieval Transformer – Jay Alammar – Visualizing machine learning one concept at a time.

This article breaks down DeepMind’s RETRO (Retrieval-Enhanced TRansfOrmer) and how it works. The model performs on par with GPT-3 despite being 4% its size (7.5 billion parameters vs. 185 billion for GPT-3 Da Vinci).

EconGraphs

Intuitive interactive visualizations of key concepts in economics

1Lab

A formalised, cross-linked reference resource for mathematics done in Homotopy Type Theory.

Future-proof ethics - EA Forum

This piece kicks off a series on how we might try to be reliably “ahead of the curve” on ethics: making ethical decisions that look better - with hindsight, after a great deal of future moral progress - than what conventional wisdom would recommend.

I examine the idea that a combination of utilitarianism (“the greatest good for the greatest number”) and sentientism (“if you can experience pleasure and/or suffering, you matter ethically”) gives us a good chance for “future-proof ethics,” a system that is reliably ahead of the curve.

About half of my motivation here is to explain some of the strange-seeming views on ethics that are common in the effective altruism community, so that people who aren’t intrinsically interested in moral philosophy can better see the motivation and appeal of such views. Outside of the effective altruist community, I think people tend to drastically under-appreciate some of the good reasons to embrace utilitarianism and sentientism.

But the other half of my motivation is to help effective altruists see the limits of this sort of ethical system, and see reasons to doubt that it is as “future-proof” as I suspect some casually imagine it is. In order to do that, I need to first lay out what the motivations and ambitions of this sort of ethical system are, before examining how confident we should be that this system will live up to its hopes.

The feelings on which people act are often superior to the arguments they employ

James Q. Wilson

Pizza Isn’t Italian - by H.D. Miller

As in America, prior to the 1950’s, pizza wasn’t something most Italians knew or cared about. In 1900, there were supposedly no pizzerias in Italy anywhere outside of the medieval walls of Napoli. You couldn’t even get pizza in the suburbs. Pizza was strictly street food for poor people in the crowded tangled alleys near the port.

pizza is more American than Italian, in that most of the current popular variations, from deep dish to pepperoni, were developed in the United States and shipped outward to the world.

So, pizza didn’t spread to the rest of Italy until the 1960’s, after it had taken off in the Americas.

Defending Human Civilization From Supervolcanic Eruptions

JPL Paper

The Flying Train (1902) (YouTube)

Incredible footage from a suspended electric train in Wuppertal Germany

GitHub - szabta89/IncA: Incremental Program Analysis Framework

IncA is a program analysis framework. It comes with a DSL for the definition of program analyses and the runtime system evaluates program analyses incrementally to achieve the performance that is needed for real-time feedback in IDEs. When code gets changed, the IncA runtime system incrementally updates analysis results instead of the repeated recomputation from scratch. IncA program analysis code is translated into graph patterns, and we reuse existing incremental graph pattern matching solutions to evaluate the analysis code on the AST of the analyzed program.

The first chapter of A. Ya. Khinchin’s book on continued fractions is a superlatively clear and concise introduction to the most important parts of continued fraction theory. After that it kinds gets into the weeds. They’re interesting weeds, but the results from the first chapter are widely applicable to all sorts of programming problems. Mark Dominus

Index of Yvain’s (Excellent) Articles - LessWrong

(Yvain = Scott Alexander)

The Go language’s first commit (1972)

the first commit appears to be from computing legend Brian Kernighan in July 1972

Twitter