I am building Block because some of my local tools were becoming a pile of glue scripts: one file for Python, another for JavaScript, a shell command to connect them, and temporary files to move data between stages.
Block is an open-source, local-first programming language and execution engine. A single .blk document keeps the workflow visible while each stage still runs in its native runtime.
A tiny example
<py>
values = [4, 8, 15, 16, 23, 42]
result = dict(count=len(values), total=sum(values))
</py>
<js>
result.average = result.total / result.count
console.log(JSON.stringify(result))
</js>
~~~
The Python and JavaScript processes do not share memory directly. Block serializes compatible data at the boundary, then starts the next stage in document order. That makes the hand-off explicit and keeps the source readable, but sockets, file handles, callbacks, and live database connections stay inside the stage that owns them.
## What I am trying to solve
- Keep a multi-language workflow in one reviewable entry point
- Reuse the libraries and runtimes developers already know
- Make execution order and state movement visible
- Reduce fragile working-directory and temporary-file glue
- Provide a small native core for simple logic, checks, and diagnostics
The current release line includes Lite, Standard, and Plus editions, a Windows CLI, project and workspace discovery, read-only checks and plans, examples, checksums, and a documented security boundary.
## What Block is not
It is not a replacement for Python, Node.js, PHP, Lua, or shell scripting. It does not make native code safe just because it is inside a Block file, and it is not a complete operating-system sandbox. Untrusted code still needs a separately isolated environment.
Source and examples: https://github.com/O-O1112/Block_lang/
Website: https://o-o1112.github.io/Block_lang/
I would especially value feedback on the language boundary: Is this kind of explicit state hand-off useful in practice? Which combination of runtimes would make a good first example? Installation reports, documentation corrections, and small contributions are welcome.
Top comments (0)