Show HN: IDE for a general-purpose visual programming language "Pipe" (pipelang.com)
Pipe IDE requires no account - all data is stored locally in your browser's database, keeping friction to a minimum.
======
Frequently Asked Questions
1. Why now?
The need for visual programming has become especially clear now that we're building with AI, which has introduced several serious problems that appear unrelated - yet visual programming addresses all of them at the root:
- AI predictability and customization. Instead of relying on one unpredictable, hard-to-customize model - which can only be changed through costly, time-consuming retraining - you can split it into small, specialized, and therefore more predictable agents, then build an explicitly programmed orchestration layer on top to coordinate them. Customization then happens through that orchestration layer, and visual programming is a far more user-friendly way to do it. This shift is already underway - specialized models like TypeSafe's Jev are built for exactly this kind of orchestration.
- Cybersecurity. AI makes it far easier for anyone to find and exploit vulnerabilities, so threats are growing. Because Pipe is semantically powerful enough to keep the entire program as a live visual graph in production rather than compiling it into a single opaque artifact, every block in an application stays directly accessible. That access solves two long-standing problems at once: slow patching, by swapping, disabling, or rerouting a faulty block in place instead of waiting on a full CI/CD deployment; and partially-blind monitoring, by tapping the inputs and outputs of any or all blocks directly, so telemetry no longer depends on log statements that may be missing where you need them.The EU Cyber Resilience Act's core demands map directly onto these capabilities - independent confirmation this approach is where regulation is heading.
- Code review. AI writes code faster than developers can review it, and leaning on AI to review AI doesn't fix the root problem - that AI can hallucinate too, so human eyes are still required. Visual programming gives those eyes a far clearer representation of the logic to review. AI-introduced errors are already piling up in production code - one study found nearly a quarter survive for months as silent technical debt.
2. Why start with a book instead of building the software first?
Most new languages start with an implementation. For visual languages, that software-first path is exactly what traps them in a single domain and keeps them from ever becoming general-purpose. I did the opposite and specified the full language first; the software is what I'm actively building now.
It avoids both failure modes. Software-first visual languages get stuck in their first implementation's domain, while purely theoretical ones get buried in complexity - too intricate and incomplete to be practical. Pipe takes the middle ground: well-chosen, practical primitives within a complete, coherent architecture.
The book's subtitle says it best - "A Pragmatic Approach to Visual Programming." It rests on seven years of R&D but stays in the practical lane, and the result is a consistent, usable, end-to-end visual language.
3. Do we need to rewrite our existing system in Pipe?
To some extent, yes - but the transition is far less disruptive than it sounds:
- The migration is gradual - you don't have to discard all existing code at once. You start by wrapping your entire project in a single top-level block. That's the initial step. Then, whenever you're ready, you add a workflow inside that top-level block and distribute the code across the visual blocks of the newly created workflow - and you can keep going, level by level.
- You choose how far to go. You can stop subdividing blocks at any point, so it's entirely your decision which parts of the system become visual and which remain as text.
- Pipe makes integrati...
2 comments
[ 0.30 ms ] story [ 13.5 ms ] thread