Lightnews — Scholar-powered news

Alexander Obenauer @alexanderobenauer.com · 1d

Glad it arrived! Hope you’re enjoying it

Alexander Obenauer @alexanderobenauer.com · 12d

Yeah this is straight where my head went too. There are a lot of little sub-questions in here that I wish I had the time to ask!

1 1

Alexander Obenauer @alexanderobenauer.com · 12d

I’m going to an event that Tim Berners-Lee will be at for his latest book.

We can submit questions for TBL in advance, so I’ve been considering what I’d ask.

What would you ask?

3 3

Alexander Obenauer @alexanderobenauer.com · 22d

Shipped a little refresh to the little lab site.

Also added some graphics made for the User Environments zine to the Canon Cat / Jasper essay 🙂

2

Alexander Obenauer @alexanderobenauer.com · 23d

One syntax sugar I’ve enjoyed using in the language:

It will match on unlabeled first params for dot calls on any expression of the right type.

$One other interesting feature of Wonderful is how it handles certain kinds of dot calls. If a function has an unlabeled first parameter, that function can be used in a dot call on matching types: ```Swift func square(_ num: Int) -> Int { return num * num; } let a = 10; var b: Int; b = square(a); // standard function call b = a.square(); // same result as standard call ``` This matches on any expression of the right type, so you can even use it with literals or more complex expressions: ```Swift func square(_ num: Int) -> Int { return num * num; } var a = 10.square(); var b = (5 * 2).square(); ``` This lets us add member functions to types in the current scope with little formality. And by flipping calls around this way, we can chain the use of functions together which read from left to right: ```Swift func square(_ num: Int) -> Int { return num * num } func double(_ num: Int) -> Int { return num * 2 } func abs(_ num: Int) -> Int { return num < 0 ? -num : num } print((-3).abs().double().square()) // abs(-3)=3, double(3)=6, square(6)=36 ```$

1 1 4

Alexander Obenauer @alexanderobenauer.com · 24d

The programming language is purpose-built for the itemized environment.

The lab report includes a demo, discussion of the features that help with handling items and item views, and explores how its own architecture can support a prospective itemized IDE.

lab.alexanderobenauer.com/updates/the-...

The Little Lab

Experiments, essays, and more.

lab.alexanderobenauer.com

1 2

Alexander Obenauer @alexanderobenauer.com · 24d

Last month, I started a series diving into the implementation of a user environment for personal computing that I've been working on this year.

The second lab report is out now, on the environment's programming language.

DESIGNING A LANGUAGE FOR THE ITEMIZED ENVIRONMENT
September 17

In this lab report, we look at Wonderful, the language purpose-built for handling items and interfaces in the itemized operator environment.

I’m in the midst of building a new user environment with the kinds of ideas that I’ve been exploring for personal computing’s future. Over the course of several lab reports, we’re looking at how this user environment works, inside and out. In the last lab report, we explored the Item Store, a database of chronological facts that serves as our persistent storage layer in the itemized environment.

Now, we’re going to take a look at the programming language purpose-built for handling items and interfaces in this environment. It has several features that help interfaces connect to the item store, and for users to iterate on their interfaces and programs from within their normal operating spaces, interacting with code items with the same benefits they gain from the rest of their things existing in an itemized environment.

First, we’ll look at the basics of the language, then dive into some ways it serves the particulars of an itemized environment. Finally, we will look at how it is internally architected to allow the itemization of its own code — so that it can be further developed in-environment, with the benefits of an itemized IDE interface.

1 1 12

Alexander Obenauer @alexanderobenauer.com · 28d

Yours will be out next week!

1 1

Alexander Obenauer @alexanderobenauer.com · Sep 10

It's a lot of fun shipping these out all over the world.

1 3

Alexander Obenauer @alexanderobenauer.com · Sep 10

This week:

Making books and watching turkeys.

1 6

Reposted by Alexander Obenauer

Alexander Obenauer @alexanderobenauer.com · Aug 28

This year, I’ve been building a user environment that reifies personal computing of the kind I’ve explored for the last several years — something I can fully live in.

I'm kicking off a series of lab reports that take a deep dive into this environment's implementation.

Building an Item Store for the itemized environment

*In this lab report, we look at the _Item Store_, a database of chronological facts that serves as the itemized environment's persistent storage.*

This year, I've been hard at work building a user environment that reifies personal computing of the kind I've explored for the last several years — something I can fully live in.

Over the next several lab reports, we're going to take a deep dive into this environment and its implementation, as well as a bit of the project's philosophy. This first report is on the environment's storage mechanism. The next one will cover the environment's programming language. After that, we'll move toward the environment's interface.

First, we will look at the kinds of ideas the Item Store was built to support. Then we will look at how the Item Store works, highlighting some key implementation details.

$"Deleting" in the item store is not the same as "erasing". Here's the implementation for a function that deletes a fact: ```Swift func deleteFact(_ fact: Fact) { insert(fact: Fact( factId: fact.factId, itemId: fact.itemId, attribute: fact.attribute, value: fact.value, numericalValue: fact.numericalValue, type: fact.type, flags: fact.flags ^ 1, timestamp: Date() )) } ``` When we delete a fact, we are actually inserting a new fact describing the earlier one as deleted. This means that the item store can be a complete chronology of the items it describes. We can also mark an entire item as deleted, and when we do so, we can name a successor item: ```Swift ItemStore.shared.deleteItem(itemId: "1", successorItemId: "2") ``` This creates a reference between the deleted item and the successor item, helping to describe your item graph's connections more completely. For example, when you send an email, a "draft" email item is deleted, but can be referenced by the "sent" message that succeeds it. When you view that sent message later, it can be easy to jump into its draft, to view earlier variations, this way.$

3 2 16

Alexander Obenauer @alexanderobenauer.com · Aug 29

For things that can't be itemized further like an image, I've stored that blob outside the item store's db, and referenced it from inside (but opaquely return the blob as the value in response to queries). For now, without optimization; lots more to experiment with here when scale comes into play.

1

Alexander Obenauer @alexanderobenauer.com · Aug 28

They are defined using facts (e.g. item id, attribute, value), similar to Datomic's data model: docs.datomic.com/whatis/data-...

Datomic Data Model | Datomic

docs.datomic.com

1 2

Alexander Obenauer @alexanderobenauer.com · Aug 28

The way I've implemented this is w/ "items" which have both attributes and references (so, they are all "dicts" and "sets" in a sense). Each has a "type" which matches your use of "meaning" here. bsky.app/profile/alex...

Alexander Obenauer @alexanderobenauer.com · Aug 28

This year, I’ve been building a user environment that reifies personal computing of the kind I’ve explored for the last several years — something I can fully live in.

I'm kicking off a series of lab reports that take a deep dive into this environment's implementation.

$"Deleting" in the item store is not the same as "erasing". Here's the implementation for a function that deletes a fact: ```Swift func deleteFact(_ fact: Fact) { insert(fact: Fact( factId: fact.factId, itemId: fact.itemId, attribute: fact.attribute, value: fact.value, numericalValue: fact.numericalValue, type: fact.type, flags: fact.flags ^ 1, timestamp: Date() )) } ``` When we delete a fact, we are actually inserting a new fact describing the earlier one as deleted. This means that the item store can be a complete chronology of the items it describes. We can also mark an entire item as deleted, and when we do so, we can name a successor item: ```Swift ItemStore.shared.deleteItem(itemId: "1", successorItemId: "2") ``` This creates a reference between the deleted item and the successor item, helping to describe your item graph's connections more completely. For example, when you send an email, a "draft" email item is deleted, but can be referenced by the "sent" message that succeeds it. When you view that sent message later, it can be easy to jump into its draft, to view earlier variations, this way.$

1 3

Alexander Obenauer @alexanderobenauer.com · Aug 28

Next up: we'll cover the environment's programming language, which has some interesting little features.

After that, we'll move toward the environment's interface. Stay tuned.

2

Alexander Obenauer @alexanderobenauer.com · Aug 28

First up: the Item Store, which serves as the environment's storage mechanism, and defines the environment's data model.

Lots of little implementation details, such as: deleting is not erasing (see screenshot in prior post).

More in the report: lab.alexanderobenauer.com/updates/the-...

The Little Lab

Experiments, essays, and more.

lab.alexanderobenauer.com

1 2

Alexander Obenauer @alexanderobenauer.com · Aug 28

This year, I’ve been building a user environment that reifies personal computing of the kind I’ve explored for the last several years — something I can fully live in.

I'm kicking off a series of lab reports that take a deep dive into this environment's implementation.

$"Deleting" in the item store is not the same as "erasing". Here's the implementation for a function that deletes a fact: ```Swift func deleteFact(_ fact: Fact) { insert(fact: Fact( factId: fact.factId, itemId: fact.itemId, attribute: fact.attribute, value: fact.value, numericalValue: fact.numericalValue, type: fact.type, flags: fact.flags ^ 1, timestamp: Date() )) } ``` When we delete a fact, we are actually inserting a new fact describing the earlier one as deleted. This means that the item store can be a complete chronology of the items it describes. We can also mark an entire item as deleted, and when we do so, we can name a successor item: ```Swift ItemStore.shared.deleteItem(itemId: "1", successorItemId: "2") ``` This creates a reference between the deleted item and the successor item, helping to describe your item graph's connections more completely. For example, when you send an email, a "draft" email item is deleted, but can be referenced by the "sent" message that succeeds it. When you view that sent message later, it can be easy to jump into its draft, to view earlier variations, this way.$

3 2 16

Alexander Obenauer @alexanderobenauer.com · Aug 26

Roughly a quarter of the first ten years of Sarah and my marriage was spent on (very) long road trips.

This had the delightful effect of slowing down time, and the associations of places with times improved my (typically poor) recall: the years on the road are filled with inseparable memories.

It’s funny to have such a strong association of times with places. Lots of specific times in our lives were spent in distinct places, so my recall of memories often starts at this association. It’s also interesting to note that time slowed down when we were on the road. Particularly for the longer-than-a-year trips, when the year was packed with so many different places, each week or month holds distinct memories that don’t blur together. The gradual acceleration of life’s time was put on hold.

2

Reposted by Alexander Obenauer

Alexander Obenauer @alexanderobenauer.com · Aug 22

Prototyping zines

1 2 17

Alexander Obenauer @alexanderobenauer.com · Aug 22

Prototyping zines

1 2 17

Reposted by Alexander Obenauer

Alexander Obenauer @alexanderobenauer.com · Aug 18

carpe noctem

1 1 8

Alexander Obenauer @alexanderobenauer.com · Aug 18

carpe noctem

1 1 8

Alexander Obenauer @alexanderobenauer.com · Aug 15

I have enjoyed my work at the computer significantly more since starting to bind books daily.

Not that I didn’t enjoy it before, but there’s some kind of forced balance that I think I needed.

Alexander Obenauer @alexanderobenauer.com · Jul 30

This week:

Making books and watching deer.

4

Alexander Obenauer @alexanderobenauer.com · Jul 30

This week:

Making books and watching deer.

1 14

Alexander Obenauer @alexanderobenauer.com · Jul 28

You can see that it pulled quotes out of my notes (Kay's in this screenshot) and intersected ideas that I hadn't myself (Fermi Paradox and interfaces as the main bottleneck, two things I'd taken separate notes on).

1 3