> Light Table will continue to go on strong. We haven’t talked too much about it lately, but it’s used by tens of thousands of people and still growing. We use it every day to help us build Eve and thanks to the awesome people in the community that has sprung up around it, it gets better every week.
The solution is to build a "graph" of archetypes to cache these results... If ComponentIds are densely packed, you can use sparse sets to cheaply jump between archetypes.
I couldn't quite figure out from the description how the edges are actually stored and I was curious why having the ComponentIds densely packed helps. I'd love to hear more about how the graph is represented. :)
We ended up cutting some of the technical ECS details from the blog post to make it more easily-digestible. The description in this pull request is effectively a stand-alone blog post describing things like the Archetype Graph: https://github.com/bevyengine/bevy/pull/1525
> I wish that a big company like Google, Apple or Microsoft attempted something bold in that space.
Me too. I tried stirring things up a bit when we were nearing the end of Eve, but nobody bit. This is work that _can_ be done, someone just has to fund it and let it grow without too much interference. The big players certainly have the ability to take care of the first part, not so sure about the second though.
> I remember the Lighttable editor making a bit of a buzz a few years ago
It's hard to believe.. but that was 8(!) years ago now. Time sure does fly.
The 17 lines don't include the parser or the code generator, which most people would count as "part of a compiler" in a practical sense. They are usually the most mechanical parts of a compiler though, so there's relatively little to be excited about in them.
I'm working on tools/interfaces at Relational AI, which is doing really cool work in the declarative languages space. It was started by several of the folks whose papers were foundational to Eve. :)
I agree with the post, though as others have pointed out, it doesn't really dive into the fact that this problem is systemic and would require a shift in incentive structure.
I think the last quote you have is one of the most important missing pieces for making a meaningful change in this space. A lot of people want something better, but right now, as a community, I don't think we really know what that is. What is the complete story for an ideal version of software development? And by that I don't mean idealized examples, I mean the ideal version of the real process we have to go through. What does perfect look like in the world of changing requirements, shifting teams, legacy systems, crappy APIs, and insufficient budgets? If we could show that - not the simple examples we had for Eve, but something that addresses the raw reality of engineering - I think it would just be a matter of beating the drum.
I might strengthen your argument even more and say it's largely a non-technical problem. We have had the tools necessary to build good software for a long time. As others have pointed out, I think a lot of this comes down to incentives and the fact that no one has demonstrated the tradeoff in a compelling way so far.
I find it really interesting that no one in the future of programming/coding community has been able to really articulate or demonstrate what an "ideal" version of software engineering would be like. What would the perfect project look like both socially and technically? What would I gain and what would I give up to have that? Can you demonstrate it beyond the handpicked examples you'll start with? We definitely didn't get there.
It's much harder to create a clear narrative around the social aspects of engineering, but it's not impossible - we weren't talking about agile 20 years ago. The question is can we come up with a complete system that resonates enough with people to actually push behavior change through? Solving that is very different than building the next great language or framework. It requires starting a movement and capturing a belief that the community has in some actionable form.
I've been thinking a lot about all of this since we closed down Eve. I've also been working on a few things. :)
I'll take this opportunity to appreciate C# in VS as a counterexample to the article. Fast as hell (sub-second compile times for a moderately large project on my 2011 vintage 2500k), extremely stable, productive, and aesthetically pleasing. So, thanks.
It's very hard for me to get away from C# because it's just so crazy productive. The tooling is fanstastic and the runtime performance is more than good enough.
One thing I found was that surprisingly the C# code I write outperforms the C++ code I used to write at equal development times.
I was good at C++, but the language has so many footguns and in general is so slow to develop in that I would stick to "simple" and straightforward solutions. I avoided multi-threading like the plague because it was just so hard to get right.
Meanwhile in C# it's just so easy to sprinkle a little bit of multithreading into almost any application (even command-line tools) that I do it "just because". Even if the single-threaded performance is not-so-great, the end result is often much better.
Similarly, it's easy to apply complex algorithms or switch between a few variants until something works well. In C++ or even Rust, the strict ownership semantics makes some algorithm changes require wholesale changes to the rest of the program, making this kind of experimentation a no-go.
The thing that blows my mind is the "modern" approach to programming that seems to be mostly young people pretending that Java or C# just don't exist.
Have you seen what JavaScript and Python people call "easy?"
I saw a page describing a REST API based on JSON where they basically had thousands of functions with no documentation, no schema, and no typed return values. It was all "Just look at what the website JS does and reverse engineer it! It's so easy!"
I was flabbergasted. In Visual Studio I can literally just paste a WSDL URL into a form and it'll auto-generate a 100K-line client with async methods and strongly-typed parameters and return values in like... a second. Ditto for Linq-2-SQL or similar frameworks.
I've also been lurking on the FoC community, and hadn't seen much on an articulation on the social and incentive structures that produce software. Do you think they'd be receptive to it?
And by "social and inventive structures", I'm assuming you're talking about change on the order of how open source software or agile development changed how we develop software?
While agile did address how to do software in an environment for changing requirements and limited time, we don't currently have anything that addresses an attention to speed of software, building solid foundations, and incentives to maintain software.
What would a complete system encompass that's currently missing in your mind?
I think you will see great change if you were to look at the personalities around one opportunity.
Because it's never problems really, it's perceived that way though.
A certain challange needs a specific set of personalities to solve it. That's the real puzzle.
Great engineers will never be able to solve things properly unlessed given the chance by those who control the surroundings.
We seek how we should develop, what method should be used, is it agile or is it lean? But maybe the problem starts earlier and focusing on exactly what methods and tools to use we miss out on the most simplest solution even beginners can see.
For example I am an architect, I tend to not touch the economics in a project. It's better fitted for other persons.
While not having read much about team based development I do want to be directed to well read literature about it. Maybe it's better called social programming, just another label of what we really do.
The one I miss the most at work is my wife. She clearly is the best reverse of me and makes me perform 1000x better. I find that very funny since she does not care about IT at all.
Depends on your definition of genius, but I definitely agree that these folks don't quite hold up the sentiment that "anyone can do it." I would put Martin Thompson, Raph Levien, and Jonathan Blow at least in the top 0.1% of programmers.
They are great examples for his overall point though. It probably would've been better just to leave out the genius bit and talk about them as folks proving it can be done.
Yeah, there are many others I'd add to a more general list - Carmack, Bellard, Wirth, the folks from Our Machinery, etc. I was just referencing the people specifically mentioned in the original post.
MIRI is short for "MIR Interpreter"; it can run basically any Rust code. But, in the compiler itself, its interface is restricted a bit; we haven't fully defined what "const fn" will be.
I completely agree that the semantics are probably the most overall useful thing we presented in this version of Eve. Having the world just be views over a datastore that you don't have to manage in any meaningful way is hugely liberating coming from the way we program now. You don't have to worry so much about how things are "placed" - you can always access them wherever and however you want. Bloom gave us a nice way of thinking about how to deal with change in that context so that it's not just some giant pile of scary mutable state.
Removing the fetching and placing of data is probably the biggest source of Eve's efficiency too. It turns out a lot of the code we write is nothing more than plumbing things into the correct location.
> I completely agree that the semantics [of views over a datastore] are probably the most overall useful thing presented in this version of Eve.
Were you guys planning a next version of Eve with a different useful semantic? Or was this idea of having the world as views over a datastore the last overall useful idea that you guys ended up with?
There were a few directions we went hereafter. One was thinking of the world in terms of simulations, another was statemachine oriented. There are a few things that were never quite right with the set of semantics here: things that really were an ordered set of steps (far fewer things than you think, but still some) were pretty hard to express and the distinction between commit and bind caused some weird things to happen at the edges. The former could be fixed by directly integrating statemachines into the language. The latter remains a bit of an open problem. Some things you want to manually manage the lifetime of, others you want to be tied to their supports. The problem is that you often want to mix and match those freely, which is just a tough thing to reason about.
Taking a stronger stance that Eve was still a bit too much like programming, and not as directly modeling as we meant for it to be, can take you to some interesting places too.
yeah, that was a very early version that we never released publicly, but was effectively a cleaned up version "Aurora," which I presented at Strange Loop once upon a time ago.
