The LT blog also had a few updates as the community drove the project forward for a few more releases.

http://lighttable.com/2015/12/10/light-table-0-8-0/

http://lighttable.com/2017/01/27/light-table-roadmap-2017/

http://lighttable.com/2019/03/31/New-year-old-plans/

    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.

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.

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

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.

Comments URL: https://news.ycombinator.com/item?id=21929709

Points: 934

# Comments: 488

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.

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 was the PM on Visual Studio. I can assure the things I showed in Light Table weren't there. Nor were they in Eclipse, as I studied that as well. You can pick and choose any number of things from our work over the years and say "Hey, but this looks like that" - I'm sure it does, but the question is does it work like that? Does it enable you the way the things we showed did?

> Light Table was also ultimately abandoned before completion.

Unfortunately even after paying ourselves only just enough to live in the area (around 40% of what my peers were paid), we needed to find a way to eat. No software is ever done, but we had more than 40,000 people using it and Light Table was a stated influence on tools at Apple, Google, and Microsoft. We did our best. Was there more to do? Of course, there always is, but at some point we had to make the hard decision to leave LT in the hands of the community. I'm curious what direction you think we should've gone instead?

> Perhaps Granger should rein in his ambitions somewhat

Maybe, but at the same time, we had people willing to let us try. You paid literally nothing for access to our work, nor to the effects our research had on others, so I'm not sure why there's this much negativity here. We need people testing the fringes because where we are is so far from where we could be. Lots of things did work in Eve and there were cases where we were so much more efficient it hardly felt like we were "programming" at all anymore. We've shared everything we've done and we'll continue telling more people about it in the hope that others can benefit from what we've learned.

And yet you're the one acting hurt, while I'm the one having to shutdown the project. That's very different from the HN that rallied us to do our kickstarter in the first place - the one that encouraged innovation and trying to do crazy things in the off chance that they work. There's so much more to do and I sincerely hope HN doesn't become so cynical and demeaning that it's not worth sharing people's efforts here.

Providing a one-size-fits-all solution here is probably impossible, but it seems like it would be nice to provide some mechanism to be notified that you're making edits based on stale information. If such a mechanism existed, it would be easy to add a bunch of canned merge strategies. In doing so you can probably teach people a little bit about the pitfalls they're likely to run into (these sorts of bugs are insanely difficult to track down), while not really making them do much work.

The approach we've taken in Eve is that we can't solve all these problems for you, but we can at least let you know that things can go sideways and prompt you to make a deliberate decision about what should happen. It's amazing how helpful that ends up being.