ibdknox

You mention:

    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. :)

> 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.

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.

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. :)

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.

Huh, does MIRI mean that rust is actually doing some form of partial evaluation during compilation? What's the best way to learn more about that?

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.

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.

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.

For what it's worth, I have used Vim since ~2004. When I built Light Table, one of the first things I did was put a Vim mode into it. I understand pretty well why at least I use Vim. I also believe that these days there's relatively little payoff given the cost of investment. Rarely is the speed of text-editing the bottleneck in building something real. Moreover, there are far more powerful ways to interact with code than at the text buffer level.