TreeHouse
wasmtalk
| TreeHouse | wasmtalk | |
|---|---|---|
| 2 | 2 | |
| 1 | 10 | |
| - | - | |
| 0.0 | 0.0 | |
| over 1 year ago | over 1 year ago | |
| Pascal | CSS | |
| GNU General Public License v3.0 only | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
TreeHouse
-
Projectional Editing (2008)
I've done some limited experimentation with this[2], and it seems like a quite powerful technique for programming. I was inspired by this demo[1] of Dion from 2020. (The first video is amazing)
[1] https://media.handmade-seattle.com/dion-systems/
[2] https://github.com/mikewarot/TreeHouse
- Programming Breakthroughs We Need
wasmtalk
-
Programming Breakthroughs We Need
I've had very similar thoughts and have wrote about them here. I would be interested in discussing more.
https://github.com/brennancheung/wasmtalk
Some key takeaways from the above link:
- The programmer's tool should be a tool for manipulating an annotated AST (not text)
- There should be many different types of UX's for different scenarios, each maps to and from an AST in a UX that is optimal for the developer for that scenario
- We must be conscious of human brain limitations and cognitive psychology and work within those constraints
- "Reading" and "Writing" code should have different UX's because they are radically different use cases
- Use RPN. It models the real world. Humans are designed to manipulate their environment in an incremental manner seeing the result each step of the way. When we have to plan out and write code for an extended period of time, trying to play compiler in our head, we overload our brain unnecessarily and highly likely to make simple mistakes.
- Testing should be a first class citizen in the developer experience and indeed baked into how we develop at a fundamental level that it seems strange that they are even decoupled to begin with.
- An Experiment with Smalltalk and WebAssembly
What are some alternatives?
MonkeyType - A Python library that generates static type annotations by collecting runtime types
dylint - Run Rust lints from dynamic libraries
Prisma - Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
gui-thunks - how to create GUIs that queue
remote-apis - An API for caching and execution of actions on a remote system.
pbrt-v3 - Source code for pbrt, the renderer described in the third edition of "Physically Based Rendering: From Theory To Implementation", by Matt Pharr, Wenzel Jakob, and Greg Humphreys.
infer - A static analyzer for Java, C, C++, and Objective-C
MyDef - Programming in the next paradigm -- your way
crystal - 🔮 Graphile's Crystal Monorepo; home to Grafast, PostGraphile, pg-introspection, pg-sql2 and much more!
Bazel - a fast, scalable, multi-language and extensible build system
AdonisJs Framework - AdonisJS is a TypeScript-first web framework for building web apps and API servers. It comes with support for testing, modern tooling, an ecosystem of official packages, and more.
Sourcetrail - Sourcetrail - free and open-source interactive source explorer