You Are in a Box

i think this is on a good track! i like that it's designed to be extensible while still keeping some amount of structure, and that the DSL makes things very compact. how are those filters implemented? are you spawning a shell to run jq or are you interpreting in-process or something like that?

in general i'd love to see a bunch more DSLs, i think using general-purpose languages for everything is most of the time not actually helpful (cc https://jyn.dev/constrained-languages-are-easier-to-optimize...). i have some vague thoughts about how to make interop between DSLs and the host language easier but i need to think about them some more.

If you're also using jq you might as well ditch Jansson and use jq's `jv` API. I highly recommend it.

Sharing data is just totally undefined for the overwhelming majority of all data in the world, because there just isn't any standard for the format the data should be in.

Data models are even harder, because whereas data is produced by the world, and data formats are produced to intentionally be somewhat generalized, data models are generally produced in the context of a piece of software.

Your brain is a box.

Your body is a box.

/s

originally i had them both in one article but it was getting to be really quite long and i am still thinking through what i want to say in the follow-up

Answer: The text will be mostly all lowercase, along with some sentence case

  let host;
  if (document.referrer) { host = (new URL(document.referrer)).host; }
  if (host === "news.ycombinator.com" || host === "lobste.rs") {
    let style = document.createElement('style');
    // let transform = host === "lobste.rs" ? 
    style.textContent = `
      body { text-transform: uppercase; }
      pre, code { text-transform: none; }
    `;
    document.head.appendChild(style);
    console.log("HN readers clearly can't handle the typing habits of the average trans girl.");
    return;
  }

All the apps are carefully sandboxed, because left unattended they will steal your data. The new category of AI largely works by sending your data to a server in the US where it can be surveilled. It would be great to have interoperability but first the user has to have confidence that it's not going to be weaponized against them.

Yes, but the specific format (and the way that the data transmission between processes and other pieces of the system is working) for the "exterior" design is an effect of the operating system. A different operating system might have a different way.

Whether it is interior or exterior, there is going to be different data types and other differences between structures, used in different ways. (One example of a difference which does not merely involve the interpretation of byte sequences, is transmissions of capabilities in systems that use capability-based security.)

I think that it is helpful to have a combination of interior and exterior functions, although most things will be exterior. However, for some things it is more helpful to do them internally within a process, for various reasons (including efficiency, requirements according to the specific operating system in use, security, and others).

> IMO it's better to have 1 type of glue, than 2 or more types

It might depend on the specific use. For some uses, it might be necessary to do it differently.

I also think that it is a mistake to assume one character set or one operating system for everything, though. However, even then, you probably wouldn't need more than one type of glue for many things, even if this "type of glue" is not the same as you would use in a different system.

> The data sent over the wire can't be interpreted without the schema information compiled into the binary.

A program is unlikely to be able to do much with data that the program is not designed to handle, regardless of how the schema is tramsmitted, so in-band communication of the schema probably wouldn't help much.

However, there can be multiple levels; e.g. with DER format, a program that does not understand the specific schema would still be able to read most of the values (with some exceptions if implicit types are used), sequences, etc, but does not know what any of that stuff means.

(I use DER format in some programs and formats that I do, because I think it is better than JSON in many ways.)

These issues are also things that my own ideas of operating system design would hopefully improve some of this. The command shell has a combination and data format would hopefully be more helpful.

Data and data collections should have app-tributes, apps shouldn't have data.

The problem with most operating systems is that they need to model space time and minds as first class but they don't.

I've been using my own personal OS for years now that I call imtropy, once your abstraction maps to reality everything becomes easier to reason about.

The simple fact is most people and programmers are stuck in logic and rationality when they should think a layer deeper, coherence is all that matters.

https://news.ycombinator.com/newsguidelines.html

(Of course annoyances are annoying, but they're also distracting, and they tend to get stuck at the top of threads, choking out more interesting conversation.)

[1] https://www.youtube.com/watch?v=F4ifVvgZU58&t=623s

Not sure what it has to do with Sam Altman though.

trust me.

Seems to be a trend though now to do it everywhere in public. I've seen the htmx author do that and the guy who wrote the second forked version of opencode.

  *##body:style(text-transform: lowercase !important;)

also, it's worth noting that proper capitalization does not automatically yield text worth reading. from that perspective, i like lower case text as a form of rebellion against the artifice of rules; any rebellion against particular aesthetics is fair game in my book. more generally, i'm skeptical of process advocacy in cases where the process seems to be done for its own sake.

on the flip side, good grammar helps me parse sentences, so i do sympathize with arguments in its favor.