https://futureofcoding.org/ logo
Join Slack
Powered by
Is this excerpt a draft or is it up somewhere? Can...
# thinking-together
d
Is this excerpt a draft or is it up somewhere? Can’t wait to hear more about what you’re working on!
💯 3
(Don’t know if sharing to #C5T9GPWFL notifies the recipient, so I’m adding an @ibdknox for good measure)
i
This was from an internal thing I was writing just to layout some of our thoughts. 🙂
In particular, I was contrasting the "summon and place" style of interaction that nodes/blocks have vs the "locate and act" that you have with text:
Text on the other hand works just like normal painting. You locate the area where you want to do something and then act directly in that area. This places more emphasis on the result rather than the change itself. Afterall, the 
+
node isn’t what I care about, it’s the actual behavior that we end up with that matters. This fits more of a noun/subject-first way of thinking where you first find what you want to work on and then act directly on that thing. 
Visual density aside, I believe the difference in interaction style is a big part of what holds these other types of editors back. In most situations, locate + act is a much more contextual and expressive way to work. It’d require significant advantages to offset all the awkwardness and busy work that comes with painting off to the side.
💡 1
We're trying to take a bit of a different approach this time and aren't saying too much publicly until the explorations have settled down a bit. We'd like to already be some level of "successful" first instead of showing lots of things that just end up being cool demos rather than a fully fledged system.
The good news is that after evaluating quite a lot of stuff I think we're ready to put a stake in the ground and move forward. We've learned and created a lot since Eve and I'm pretty excited about where things are headed. 🙂
🎉 2
👍 2
🙂 1
d
Exciting to hear— can’t wait to see where it goes. Thanks for the extra context! I was intrigued by your comment from a while back: “the language I designed based on everything we’d learned through Eve was dataflow with state machines embedded in it, but it turns out if you flip that the other way around you get something pretty neat.” Curious if that had legs, or if the stake landed somewhere else? (Of course if you’d rather not say yet I respect that.)
👍 1
i
still very positive on both variants, though where we're landing is a bit muddier on which one is the "embedded" one
in some sense they serve different purposes. I've come to think of hierarchical statecharts as more a form of structure rather than as actual behavior
one thing that I really took from Eve was the idea that what we really need is a system that somehow mixes declarative and imperative expression seamlessly
➕ 1
interestingly dataflow is kind of both, same with statemachines
but I think they address pretty different aspects of the design space
StateCharts with a couple of modifications are a pretty good way of directly describing structure and certain kinds of stateful processes. Dataflow is quite a bit better at describing computation, but at the cost of being a pretty poor structural representation.
So the question is which do you try to bring to the foreground?
Regardless of the choice, the idea of states (in the statemachine sense) being a core primitive of the system seems to be a really good one and makes the expression of many programs significantly better
where "better" = clearer to understand, easier to write, and easier to confidently modify from our experiences.
it'll be interesting to see to what degree our editing workflow will focus on states/dataflow vs having them melt away into the background. I don't really have a good sense for that yet. 🙂
d
Sweet. Sounds like you’re really onto something. State machines are a cool “tool for thought” in that they can actually help an inexperienced programmer walk through edge cases and design more robust programs. I’ve been kind of barking up a similar tree for an internal project (combining state machines and dataflow), and finding the dividing line sometimes confusing. In my thinking right now it’s something like control flow vs. data flow. The weird thing is that HSM has a concept of “state machines all the way down”, but data flow does too, and you can kind of mix and match as you go down (but it’s not clear to me yet how useful this is in practice)
i
yeah
simulink is an example that focused on dataflow with HSMs embedded to good effect I think
one interesting thing is that we found that in dataflow you still want to represent control flow meaningfully within the same space.
The latest work in VPLs for game engines have also found that and started doing vertical control flow, horizontal data flow, which I think is really effective
it lets you read the "spine" to get the main idea of what's going on and then look off to the left for the details if you need to
a bunch of our explorations centered around digging into that further and trying to find nice ways to address some of the remaining downsides of the node/wire paradigm
d
Nice, I’ve had the same vertical/horizontal thought but didn’t realize that about game engine VPLs. Most of my prior art is Labview plus a bunch of demos I’ve seen here. I’ve used matlab but never simulink, I’ll take a look. When you say HSM are good for structure, one way I’m thinking of them is as a sensible way to perform dynamic switching of the links between dataflow nodes. Is that what you mean or something different?
i
yeah, that's a way of thinking about their purpose from a behavioral structure standpoint. You also need the structure of the entities themselves, which we found can map pretty nicely to states as well if you squint
💯 1
in a turtles all the way down sense, you tend to have entities and states interleaved throughout the hierarchy
so we just made everything a state
and explored that
very cool model and lots of goodness to be had there
d
Love it. I resonate with everything you’re saying, but I think your picture on implementation is much clearer than mine. Hopefully we can just swap out my experiment with Eve++ once it’s ready for primetime 😀
i
🙂
c
Did you explore and abandon any areas that you think are dead ends?
i
it depends on how you define dead end. I think most of the things we looked at could/have found success in certain domains
so at some level it depends on what your goals are
I think the "summon and place" workflow is a bit of a dead end, but there are ways to address it
e.g. having composite "formula" nodes and such
the conclusion we arrive at in the document I was quoting before more or less boils down to the idea that making meaningful progress requires finding combinations of things that have largely been considered dichotomous
👍 1
declarative vs imperative, text vs graphical, implicit vs explicit..
there's a ton more to explore down any one of these, but I think choosing one and assuming it'll be enough likely is a dead end
❤️ 2
If we step out of the domain of computers, there's more than enough evidence to start to see what the pros and cons of each end of the spectrum are
unless you can find a way to offset those cons, you'll end up with something that is a difference in degree rather than a difference in kind
👍 1
c
I remember a while ago I think you said how something you realised with Eve was it was too hard to go straight for new people/expanding the market, and you need to get people who are coding already on board to be sustainable
(I might have misquoted that a bit)
Is that still how this new project is going?
i
we kind of always knew that going after end-users requires first getting more technical folks on board, the more recent belief is that I've become far less convinced that going after end-users (unless for pedagogical purposes) is the better path
💡 1
if we want to frame things in terms of global utility, it's likely the case that over a shortish timeframe (< 20 years) you'll gain more going after people who are already aware they need to program
the new project is motivated by the question "if we only care about making Josh and I superhuman, what would that take and how far could we get?"
👍 1
I think we've implicitly expanded that to "any sufficiently motivated person who already programs or wants to," but I think that's a reasonable place to start
There's a difference between building tools that will accelerate people to crazy heights and convincing a group of folks that flying is interesting to begin with.
d
Sounds like a fantastic goal. Curious if distributed systems and realtime applications are in scope. Same with graphics.
i
Yes, yes, and yes! 😄
d
Amazing 😄
i
Actually, depends on what you mean by realtime applications
in principle it would be fast enough to do hard realtime stuff, but I'm not particularly worried about synchronized clocks and hard budget cutoffs
d
Lol me neither. I’m thinking more IoT and games. Though robotics would be cool too
i
ah yeah, those would be fine. A flight controller? probably not?
it could ostensibly be extended in that direction if you want I guess
d
But a drone remote control 👍
i
yep
d
How far are you thinking on the graphics side?
i
all the way to shaders
one of our tests is if we can build a high fidelity game with it
d
I’m gonna cry
Lol
I’ve been wanting something like this for a long time
i
haha, well you don't know what it is yet so don't get too excited 😉
we're taking some interesting directions that I suspect will be a bit controversial
but we have a mounting list of evidence that's giving me more and more confidence
d
Between eve, the team, and the stated goals I feel like I have enough to get excited about 😉 but of course will suspend judgment. Any nuggets about the interesting directions?
i
a very high performance system that removes almost all the power you would have in a normal systems programming language is one example
you have no control of layout
because of that decision though, we can do utterly insane stuff
e.g. your whole program is laid out to optimize cache coherency based on an analysis of the access patterns actually present in the code
d
🤯
i
I was matching hand-written, cached optimized rust - but our code looks like a domain description rather than the horrid stuff you normally do.
d
Ok, I love both of those decisions
i
it was running in JS 😛
❗ 1
another side effect of that choice is that you can just grab a set of things and say "these live on the GPU"
to your distributed systems question, you can also say "these live in this postgres database" or "these live on a server"
We talked about the "world-scale computer" that we wanted to create with Eve. A big part of what I've been trying to figure out since is how we could actually have it.
I don't intend to run into performance issues again. 🙂
❤️ 1
d
This all sounds so right, for 99% of use cases. Any rough feeling on a beta at this point? 1-2 years? I’m sure a lot will change as you go
i
not sure when we expand it out, but I'm expecting to show at least this crowd stuff in the next couple of months
❤️ 2
d
Awesome. Well thanks for sharing some tidbits, and I’ll be keeping an eye out
💯 1
i
👍 😄
k
The idea of looking at control flow first really resonates. On my project I trace all events and I've often found myself doing a blunt 
grep label trace
as the first step of debugging a problem.
☝️ 1
Open in Slack
PreviousNext
Powered by