wasmtalk
gui-thunks
wasmtalk | gui-thunks | |
---|---|---|
2 | 2 | |
10 | 3 | |
- | - | |
0.0 | 10.0 | |
over 1 year ago | about 4 years ago | |
CSS | ||
- | - |
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.
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
gui-thunks
-
Humble Chronicles: Managing State with Signals
It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation.
But the implementations are rarely extracted out for general purpose usage and rarely have a rich API.
I've been thinking a lot about a general purpose "epoll" which be registered on objects that change. I want to be able to register a reaction to a sequence of actions on arbitrary objects with an epoll style API.
One of my ideas is GUI thunking. The idea that every interaction with the GUI raises a new type that can be interacted with, to queue up behaviours on the GUI. This is essentially Future<> that are typed and the system reacts to the new type based on what you did.
It's a bit like terraform plan and apply, but applied to general purpose GUIs.
For example, you can click download file, then queue up installation and then using the application, ALL BEFORE it is installed. Because the actual computation is separate from the type information that was queued up.
Imagine using AWS Console to set up an entire infrastructure and wire everything together but not actually execute anything until the very end when you click "Run".
https://github.com/samsquire/gui-thunks
-
Programming Breakthroughs We Need
I spend everyday thinking of what my computer could be doing.
Most of the time the CPU is waiting for IO - memory, network, SSD, disk and not doing any work.
You might like my idea called GUI Thunking.
https://github.com/samsquire/gui-thunks
What are some alternatives?
dylint - Run Rust lints from dynamic libraries
incremental-rs
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.
signal - Functional Reactive Programming implementation for Rust
MyDef - Programming in the next paradigm -- your way
Bazel - a fast, scalable, multi-language and extensible build system
c4-notation - Technical resources for using the C4 model for visualizing software architecture.
Sourcetrail - Sourcetrail - free and open-source interactive source explorer
language-server-protocol - Defines a common protocol for language servers.