The OS should provide a statically typed environment.

[sonata_green]

Crossposted from Mastodon, since this turned out longer than I expected.

---

Unix, and consequently every modern OS, is stringly typed, i.e., data is passed between programs as strings and nothing else. JSON is an attempt to improve the situation, but it's not enough. A real cure to this would be a deep-rooted overhaul of how we think about computer systems.

Rule of thumb: if you're doing it right, a programming language shouldn't have a "syntax". It should have IDEs that write typed ASTs. There's no reason for source code to be text¹ files.

If you want to create an SVG image, you use Inkscape, not $EDITOR². Even though SVG is ultimately XML. Inkscape doesn't even show you the XML, nor should it.

Apply that thinking to everything. On the back end, that means static typing. On the front end, that means a real usecase-native editor rather than a generic text (string) editor.

Maybe you can make a semigeneric "object editor" with plugins, like Emacs with major modes, but for editing typed data where Emacs only handles text (strings).

And no, JSON is not typed data. Not even slightly. At best it's a string representation of typed data. But it's still a string.

If you have to "serialize" data to pass data to another program, or "parse" it to receive it, something has gone horribly wrong.

---

1. Whenever you hear "text", you should always mentally substitute "string(s)". A text file is a single huge string.

2. Note how we always say $EDITOR, never $TEXTEDITOR, because obviously the only thing you would ever want to edit is strings, right?

Comments

[everythingisoptional]

Endorsed

[anthropicprincipal]

You may be interested in PowerShell.

[frobisherw]

Hmmmm... not sure I agree. All digital data is a sequence of bits -- that's always going to be true. I agree that not all (or even lots) of digital data should be treated as a sequence of Unicode codepoints; but claiming that data is really typed ASTs... isn't accurate. Lots of data can be treated as typed ASTs -- but it's still really a sequence of bits.

And the idea that a single sequence of bits can (or should) only be interpreted as one particular "type" -- that's misleading, and unnecessarily limiting. I want to retain access to the underlying bit sequence, so if my usual IDE's interpretation of it is insufficient, I can use a different program to interpret it differently. If the IDE (or the whole OS) refuses me access to the actual bit sequence -- then I'm a prisoner of the assumptions of whoever wrote the "blessed" IDE. Fuck that noise.

Your thoughts?

(also posted to my journal: https://frobisherw.dreamwidth.org/6181.html )

[sonata_green]

I suppose you could always choose to read in the file as raw binary data, in the same way that a contemporary OS lets you read a text file in binary mode. But you shouldn't have to, any more than you should have to use a hex editor to write strings.

[pseudonym_loving_magpie]

I would go as far as a dynamically typed data structure, like what JSON represents instead of the string that represents it. Maybe with optional static type checking, but an easy way to bypass it when you don't want it.

I would want a generic object structure editor that works without plugins when necessary, because even with this deep-rooted overhaul, the OS needs to allow for new software (i.e. the plugins) sometimes being buggy.

The representation of file systems and directory structures seems analogous - programs that use directories rarely need to look at the raw binary representation of a directory, so the OS or sysadmin or file system can change them without the programs caring.

So I don't think you'd need to make the raw binary format any more accessible than that - it's there if you make a copy of the file system image, but otherwise it's usually just the filesystem and OS that access it, and if you want a serialised copy you make it from the structure (the equivalent in a unix file system would be the "tar" command).