🚧 This project is in a pre-nascent stage.

A set of basic programming tools with friendlier human interfaces.

I will seek to achieve this by doing the following:

• Build the human-to-tool and tool-to-tool interfaces closer to code as structured data rather than as text files, but try to keep a somewhat familiar visual aesthetic to current-day IDEs. See the dedicated readme.

• Remove friction from the collaborative programming experience by tightening integration of various developer tools, and supporting collaborative, real-time editing. See the dedicated readme.

• Treat terminology (words!) as a fundamental building-block of a programming language. See the dedicated readme.

• Misc (and less dramatic) features / design goals. See the dedicated readme.

It will combine a collaborative, real-time structure editor, strongly-typed, general-purpose OOP (maybe DSL-embeddable) language, and grammar-aware version-control system with some more builtin collaboration features. This (perhaps-obscene) amalgamation of commonly separated concerns is the inspiration for the name of the project.

Preface: None of these are "ideological" non-goals. They simply exist to help me set realistic boundaries and restrain myself from getting derailed or burnt-out trying to tackle difficult (but important) problems that aren't core to the project's goals.

The hope is that gemel can faithfully demonstrate benefits of structural tooling for programming with a high enough degree of quality to spark other peoples' interest in moving toward such a direction when designing future programming ecosystems.

I would love for gemel to gain interest as a proof-of-concept and exploring-ground for building a human-friendlier programming ecosystem. I would love for people to eventually join the continual effort to improve it. The intention is not for gemel itself to become widely depended upon for real-world work.

I hope people developing future gemel-like projects will also try to find grounds for compatibility, but I don't have much faith that that's realistically achievable; different programming languages exist because one size does not fit all. But who knows? We have things like LSP and tree-sitter, so maybe it is possible.

For information about the project architecture and technical design goals, see the dedicated documents.

For more information about structure editors and existing projects, see existing.md.

I will work on this until at least the end of 2024. I currently feel like I'm interested enough in the problem to keep working on it until 2032, but I can't promise that.

GitHub discussions are open for questions, concerns, ideas, and links to possibly helpful resources. The necessary groundwork before looking for help / contributions may not be ready until late 2022 or later.