So close, if they just extend it a little outputs from programs become tables in a database
and inputs become select statements from those database tables.
Indeed, it’s a shame to have a VisiCalc-style spreadsheet and not an Improv one. Improv had a clean separation of data (which could be multidimensional, viewed as pivot tables) and formulae (which could create new rows / columns or individual values). Dataframe models like pandas are closer to Improv and it is my sincere hope that VisiCalc derivative will eventually become extinct.
My Von Neumann vs Harvard senses are tingling. It might just be the case that the internal representation and parser was made for both (as well that other holiest of wars, R1C1 or baby-mode). Neither makes sense for Pipeworld though where factory expressions can spawn applications that spawn cells that spawn applications that …
Since the point here is the inclusion and use of the spreadsheet as an intermediate interactive representation to scribble and break up the cat | grep | awk | … bond (among others) the presence of a structured explicit data model in the input should steer the mode of operation.
I’m loving the capabilities arcan brings to the world. One thing the Marvel movies got right is the user interfaces: I want Tony Stark OS to be the way we move applications around from screen to screen to device to device, and move data within those.
This is very cool and highly relevant to my interests! Although I am going to give similar feedback as people gave to me – it is hard to find all the components of the project, and what it is
I made this table of 13 components recently, and it took quite awhile, but it was a good exercise -
At some point I would like to figure out if there is any bridge possible between the old world of terminals and a new display server protocol like Arcan
Right now I am not sure if there is anything we can build against, e.g. if there is a stable protocol, Lua APIs, etc.
It could be a separate bridge with the headless shell perhaps
Basically I think it is the same problem as in Oils – once you have ~10 years of work, then people are going to “jump into the middle”
And they won’t have read all the history
So then there needs to be a way of jumping from arbitray points in the middle back out to the “big picture”, in a way that doesn’t require reading the entire website!
There’s over 20 years here and a wider scope than I’ve talked about in public. I disseminate in a third or second- order form first and slowly inch towards single practical cases rather than the other way around. It is more of a ‘bare minimum due diligence’ rather than a means of approaching the general public. I am not building community and don’t seek attention, just a way out of the walled slop garden slope. I am paying my respects to the people that helped me once upon a time. Many of them unfortunately passed; many of them with an epitaph encoded somewhere in the project.
There are stable protocols, stable APIs and stable libraries and the TUI / Terminal / Networking are explicitly shaped to be decoupled from anything else I have in the stack, so all nine circles aren’t at all necessary. The first funded stage of the network protocol is being written up in increasingly formal ways right now.
The napkin model I sketched down in the Ontology still holds enough to unpack Arcan as OS Design which, in parallel to the Terminal/Tui track and the 12 design principles covers ‘most of it’. There is one piece left on the schedule that was recently funded, tentatively titled ‘Arcan Explained: a browser for different Webs’, then I’m done with the high level explanations and can consider first order ‘As *** Implementation’.
So close, if they just extend it a little outputs from programs become tables in a database and inputs become select statements from those database tables.
Indeed, it’s a shame to have a VisiCalc-style spreadsheet and not an Improv one. Improv had a clean separation of data (which could be multidimensional, viewed as pivot tables) and formulae (which could create new rows / columns or individual values). Dataframe models like pandas are closer to Improv and it is my sincere hope that VisiCalc derivative will eventually become extinct.
My Von Neumann vs Harvard senses are tingling. It might just be the case that the internal representation and parser was made for both (as well that other holiest of wars, R1C1 or baby-mode). Neither makes sense for Pipeworld though where factory expressions can spawn applications that spawn cells that spawn applications that …
Since the point here is the inclusion and use of the spreadsheet as an intermediate interactive representation to scribble and break up the cat | grep | awk | … bond (among others) the presence of a structured explicit data model in the input should steer the mode of operation.
Awesome, this (for me) really helps to grok the capabilities of
pipewirepipeworld!Not pipewire ;) Pipeworld
Yep :P
I’m loving the capabilities arcan brings to the world. One thing the Marvel movies got right is the user interfaces: I want Tony Stark OS to be the way we move applications around from screen to screen to device to device, and move data within those.
Arcan gets us closest, I think.
We only really lack the ‘move data’ part and NLnet sponsor that in a new grant.
This is very cool and highly relevant to my interests! Although I am going to give similar feedback as people gave to me – it is hard to find all the components of the project, and what it is
I made this table of 13 components recently, and it took quite awhile, but it was a good exercise -
https://www.oilshell.org/blog/2024/09/project-overview.html#thirteen-parts-of-the-oils-project
When I click on docs, I get these:
https://github.com/letoram/arcan/wiki
I’d like to see what all the components and protocols are on one page, e.g.
Basically I think there does need to be a glossary, since although the screenshots are very informative, the text doesn’t always make sense to me
My best attempt is the Oils cross reference with short definitions of every term I use - https://www.oilshell.org/cross-ref.html
Also it looks like you have organized the shell into “spreadsheet” and “debug” builtins, in Oils I have these tables of contents - https://www.oilshell.org/release/0.23.0/doc/ref/toc-ysh.html
At some point I would like to figure out if there is any bridge possible between the old world of terminals and a new display server protocol like Arcan
Right now I am not sure if there is anything we can build against, e.g. if there is a stable protocol, Lua APIs, etc.
It could be a separate bridge with the headless shell perhaps
https://www.oilshell.org/blog/2023/12/screencasts.html#headless-protocol-oils-web_shell
But all in all it’s great to see continued progress!
Basically I think it is the same problem as in Oils – once you have ~10 years of work, then people are going to “jump into the middle”
And they won’t have read all the history
So then there needs to be a way of jumping from arbitray points in the middle back out to the “big picture”, in a way that doesn’t require reading the entire website!
There’s over 20 years here and a wider scope than I’ve talked about in public. I disseminate in a third or second- order form first and slowly inch towards single practical cases rather than the other way around. It is more of a ‘bare minimum due diligence’ rather than a means of approaching the general public. I am not building community and don’t seek attention, just a way out of the walled slop garden slope. I am paying my respects to the people that helped me once upon a time. Many of them unfortunately passed; many of them with an epitaph encoded somewhere in the project.
There are stable protocols, stable APIs and stable libraries and the TUI / Terminal / Networking are explicitly shaped to be decoupled from anything else I have in the stack, so all nine circles aren’t at all necessary. The first funded stage of the network protocol is being written up in increasingly formal ways right now.
The napkin model I sketched down in the Ontology still holds enough to unpack Arcan as OS Design which, in parallel to the Terminal/Tui track and the 12 design principles covers ‘most of it’. There is one piece left on the schedule that was recently funded, tentatively titled ‘Arcan Explained: a browser for different Webs’, then I’m done with the high level explanations and can consider first order ‘As *** Implementation’.