One of the comments I always have when I see environments like this is that it looks really neat to have all these adjustable sliders and partial debugging and whatnot, but when you attempt to apply this to any truly useful program (ie: Anything that performs side effects) it really starts to break down if that side-effect isn't idempotent, like writing a file to a disk, or making a network call you really only want to make once, etc.
Do you have any strategies for that, or is the idea that these features are really only for testing functions that don't cause those sorts of side effects?
I wonder if the debugger could be combined with a really good mocking framework. That seems like a good idea for a "live" testing framework. Maybe that's something that could be used to help prototype unit tests themselves.
(First congrats on a great looking project and really good copywriting/teaser.)
I think this sort of highly interactive environment is best suited for languages without side effects at all.
I.e. purely functional language as you see it in a spreadsheet.
Allowing any language (JS, Python and so on) gives problems with how to handle errors, show variable values that change over time, how to handle programs that take a long time to evaluate (or never evaluates), how to handle programs that modify the environment (i.e env.x = env.x + 1) and so on.
A lot of Carbide's widgets depend on having access to a program's parse tree, which (to the extent of my understanding) a lot of these protocols (Jupyter/MS's Language Server Protocol) don't provide.
In order to inspect an expression, we have to be able to take the document, parse it into an abstract syntax tree, determine branches which are expressions, and annotate them so that a code generator can wrap it in some log invocation.
It'd be great if it were possible to apply "one simple trick" and support a hundred different languages all at once, but in this case I don't think the existing abstractions really suffice.
You've done a wonderful job. It takes courage to think in completely new directions, actually do something about it and then give it away- like a Buddha.
Sorry about the naysayers. Please remember that most of us on this forum are wannabes trying to one-up each other to make up for our failures. Don't blame us, we're all humans... :(
It looks like y'all are really aiming for Bret Victor-style direct manipulation, which is a bit more ambitious, but Tonic has incorporated some similar ideas, including time-traveling debugging, and it seems like there's a lot of overlap around the more basic features, like the automagical approach to packaging and the data visualization stuff.
I think Tonic is great, and the stuff they've done with CRIU for pausing resuming computation is really clever. On the surface, Tonic is meant for building NodeJS services, whereas Carbide is focused on things which run in the browser.
One aspect of Tonic that I find really interesting is the attention they've paid to reproducibility.
Traditional notebook programming environments (Mathematica and Jupyter) are sensitive to the order of execution of the cells, which often makes it kinda hard to reproduce results. This stems from the fact that cells are used for two things— controlling what gets executed, and as a means for visualizing output.
As far as I'm aware, Tonic is designed so that there is only one way that a program can execute, so there's any notebook is automatically trivially reproducible. This has the side effect of making every notebook essentially equivalent to a single file which is evaluated in-order. Essentially, they've made it so cells only mediate what output is displayed, and not what gets executed.
Carbide takes the opposite approach— leaving cells to only control what gets executed, and introducing something else (probes) to visualize output within a cell.
I know it sounds crazy, but hear me out. I would love to hack on adding VR support to something like this. A real Minority Report development environment is something I've always dreamed of having.
No promises, but I can't get experimenting without source. Wink :).
This is something I dreamed about it too, another thing I dreamed about was speaking what I wanted and the computed programmed it for me. I think I might be closer to telling the computer what to develop and have it open up in Carbide then the first idea, because I'll probably need a Unity behind the Carbide and I don't want that, will be heavy as hell.
This looks great. I really love tonicdev [1], but I'm reluctant to use it on production data because it's SaaS [2]. If you open-sourced this and I can run it "behind the firewall", that would be awesome.
[1] https://tonicdev.com
[2] I don't want to share production keys with Yet Another SaaS
I'm normally pretty cynical about these sorts of efforts but this seems pretty compelling.
One pet peeve about the site, please consider adding a "Who" section or note. One of the first things I look for in an interesting site or project is the "human face" of it, so to speak.
> We're thinking of releasing Carbide as open source in the coming weeks if there's a community interested in building stuff on top of it.
I'm really interested in things like Carbide, and I'm finding it inspirational as a user interface experiment. But I'll be sticking with Jupyter for the time being on my current project — I think we would be kind of dumb to build stuff we cared about on top of it if it's not open source; without open source, you don't have a community, you just have consumers.
FWIW the jet-engine mode is still active on my laptop now.
Great job, I think the idea of adding different languages or widgets should have an "App" concept were people plugin technologies. That way there can be various githubs of projects separate from the main project were people contribute at free will, that would be really awesome and great for the project.
Best Regards,
I'm one of the creators of Carbide, and I'm really excited to share it with you all.
We're thinking of releasing Carbide as open source in the coming weeks if there's a community interested in building stuff on top of it.
One of the areas we'd appreciate help with is adding support for different languages— Python, Scala, Haskell, Rust, etc.
Other than that, general feedback / questions welcome.
We've scrabling to turn off jet-engine mode on the website :)