directory tree is not as easy to view and edit as JSON.
One big JSON file is harder.
I am not fancy, and the aim is to simply use file system as database.
Not fancy stuff like "database as file system as database".
76 karma · joined June 21, 2020
One big JSON file is harder.
I am not fancy, and the aim is to simply use file system as database.
Not fancy stuff like "database as file system as database".
Which is "database as file system".
Not even complicated to implement.
See couchDB for how to handle "what if two people are editing a file at once".
I think it is only good to use directory as data table to store JSON data files, but not for JSON data properties.
I am using Btrfs.
Btrfs inode limits is in a whole different league (whereas ext4's inodes are allocated at filesystem creation time and cannot be resized after creation, typically at 1-2 million, with a hard limit of 4 billion, btrfs's inodes are dynamically allocated as needed, and the hard limit is 2^64, around 18.4 quintillion.
> -- https://unix.stackexchange.com/questions/18388/what-are-the-...
This is also the reason I am researching this old "What if" problem.
Because I think comparing to some version of MySQL or PostgreSQL, files are stable, open and timeless.
I read it, and I think it describes bad ways of using file system, but there are also good ways.
Just like there are bad ways of using SQL databases, and there are also NoSQL, and bad ways of using NoSQL databases.
Maybe there are some benchmarks in the past.
I agree.
We (developers) should also design tools to address the need of small scale web apps.
Maybe, we do not even need some general tools to use file system as database, just speak this method more often.
My aim is to build a open-source mini vercel and netlify alternative.
`x-server` is just a starting point.
I have even more "evil" projects, like "using file system as database", I will leave that for another Show HN :) :) :)
So far, feedback here are helpful to me.
Sorry about the mis-deleting.
I thinks I accidently deleted this repo.
Now it is back: https://github.com/xieyuheng/x-server
I removed the syntax of rearrange, and added a new builtin `@spread`, I hope it is less confusing now :)
I will not miss an issue there :)
In the paper "Interaction Nets" ( https://github.com/cicada-lang/inet/blob/master/docs/referen... ), there is an example of 1-dimensional Cellular Automata. (Section 1.4. Example: Cellular Automata).
> About the stack-based layer of the language.
I have some concerns about it when deciding to use it, because it is so different from common programming languages. I am comfortable with postfix notation, because I am familiar with the Forth language ( https://en.wikipedia.org/wiki/Forth_(programming_language) ).
> About Rearrange.
I will improve the docs about it.
> About `closeAllFreePorts`
If `closeAllFreePorts` is the culprit, maybe it is because of my wrong implementation of the web frontend (not the language).
I should not call `closeAllFreePorts` in a loop.
see: https://github.com/cicada-lang/inet-website/blob/master/src/...
and: https://github.com/cicada-lang/inet-website/blob/master/src/...
It is a bug that I should fix.
I also implemented a command line program and a REPL: https://github.com/cicada-lang/inet#command-line-tool
Maybe a few thousand steps will not be slow there.
If you made an implementation, I will make a list of implementations in the homepage ( https://inet.run ), and add your implementation to the list :)
------
I do not know much about LLM yet, but I like hypergraphs too :)
(I learned about it from Wolfram Physics's docs.)
------
> They definitely both share the distinctions of principal ports v.s. auxiliary ports.
Version (1) and (2) both have principal ports v.s. auxiliary ports.
But only (1) has input ports v.s. output ports.
(I was actually quite shocked by this, when I read the 1997 paper.)
My current plan is to programming with interaction nets directly, and to view Lamping's "optimal lambda calculus reduction" as an example.
I have not read Lamping's paper yet. But if it uses "Interaction Combinators", maybe I can not even do it in my implementation.
Because there are two version of inet:
(1) Lafont's 1990 paper "Interaction Nets"
(2) Lafont's 1997 paper "Interaction Combinators"
I implemented (1) where a port has a sign (input port v.s. output port). Given two ports, I can only connect them when they have opposite signs.
In (2) there is no input port v.s. output port, ports are not signed (Lafont called the signed version "directed" in (2)).
"Interaction Combinators" uses self interaction (rule about a node interacting with itself), it is not possible in signed version of inet.
Because one node only has one principle port, thus can not connect to it's own principle port, because the same principle port has the same sign, not opposite signs.
------
I said "programming with interaction nets directly", because it seems already a more practical language than lambda calculus, for we do not need lambda encoding to express datatype and pattern matching, we can define rules case by case directly.
It makes me want to learn more about quantum computing.
The foundational paper about interaction nets is published in 1990. (https://github.com/cicada-lang/inet/blob/master/docs/referen...) There must be some interesting developments during these 30 more years, maybe some of the developments are related to quantum computing ~
I am also somewhat naive minded, although I implemented this language, I actually only read the first 1990 paper about interaction nets, there are many follow up papers by the original author Lafont, some papers are about combinators, some papers are about linear logic and proof theory background of inet.
I will keep learning.
I think I have just caught the first user of this little language :)
It is amazing that you can understand the language simply by my minimal amount of docs, and write this non-trivial example.
I will study your example and add it to the repository.
Your implementation of `Bin` reminds me of the implementation of binary number in minikanren ( http://minikanren.org ), in a book called "The Reasoned Schemer".
Self-hoist will be a very very interesting challenge!
(1) Maybe we can do it by firstly implement a low level graph processing VM, and compile it to the byte-code of the VM.
(2) How about self-interpreting? like lisp's meta-circular evaluator. Maybe this is even more challenging then compiling.
Either way, We will need some built-in primitive functions about IO, and also some primitive functions about string processing (to parse the syntax).
Maybe we can keep the core pure, and extend the lower layer stack-based language.
Should we do this in this JavaScript/TypeScript implementation? or to do this in a C/C++/Rust/Zig implementation? (the later seems have more potential to be practical)