Readit NewsProject: http://lighttable.com/
HN search: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
The top submission there is the place to start.
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.
If anything what bothers me is not the lack of innovation in programming languages per se but the relative lack of innovation in program representation. We have high res monitors with incredible graphical capabilities but we still mostly just represent code as flat text files. There've been a few experiments to change the status quo, I remember the Lighttable editor making a bit of a buzz a few years ago, but nothing really changed overall. 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 co-dfns source I've seen[1] is much longer. Do you know if there's a write-up somewhere of the differences between that and Appendix B from the dissertation?
I piled standout quotes below.
I think a big takeaway from the intersection of Bret Victor, Alan Kay, Jim Hollan and the ink&switch folks and your work is that the right dynamic interface can be the "place we live in" on the computer.
Victor shows a history of interactive direct manipulation interfaces, live environments where explorations of models or the creation of art go hand in hand with everything else related to that task: data input, explicit (programmatic) requirements and the visual output.
Hollan and ink&switch show the environment (ZUIs, canvas) can contain everything for doing work, the code alongside any manipulation of the viewport that can be conceived. Tools infinitely more advanced than Microsoft OneNote and designed 40 years ago.
From what I know about your work, I see another take on the environment I want to live in on the computer. I dont understand why I would want to lose power by stepping away from my language/interpreter/compiler/repl into a GUI or some portal when I can bring whatever it is which is nice about GUIs or portals into my dynamic computing environment. I very much want a personal DSL or set of DSLs for what I do on the computer, and I want to be able to hook into anything ala middle mouse button in plan9.
The superior alternative to walled gardens and this absurd world of bloat and 'feature loss' (for lack of a better term for software engineering's enthusiastic rejection of history) seems to be known, and facets of it advocated by you and these others. It seems clear that "using the computer" needs to return to "programming the computer" and that to achieve that we need to fundamentally change "programming the computer" to be a more communicative activity, to foster a better relationship between the computer and the user.
Where is this work being done now? VPRI shut down 2 years ago, Dynamicland seems to be on hiatus? I am inspired most these days by indie developers who write their own tools and build wild looking knowledge engines or what they sometimes call "trackers."[1] And of course the histories and papers put forward by the above and their predecessors. And I play with my own, building an environment where I can write, draw, code, execute and interact with it all. I see no existing product which approaches what I want.
> Everyone is busy building stuff for right now, today, rarely for tomorrow.
> Even when efficient solutions have been known for ages, we still struggle with the same problems: package management, build systems, compilers, language design, IDEs.
> You need to occasionally throw stuff away and replace it with better stuff.
> Business won’t care Neither will users. They are only learned to expect what we can provide.
> There’s no competition either. Everybody is building the same slow, bloated, unreliable products.
> The only thing required is not building on top of a huge pile of crap that modern toolchain is.
> I want something to believe in, a worthy end goal, a future better than what we have today, and I want a community of engineers who share that vision.
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.
1/ What didn't seem to get mentioned was the speed to market. It's far worse to build the right thing no one wants, than to build the crappy thing that some people want a lot. As a result, it makes sense for people to leverage electron--but it has consequences for users down the line.
2/ Because we deal with orders of magnitude with software, it's not actually a good ROI to deal with things that are under 1x improvement on a human scale. So what made sense to optimize when computers were 300MHz doesn't make sense at all when computers are 1GHz, given a limited time and budget.
3/ Anecdotally (and others can nix or verify), what I hear from ex-Googlers is that no one gets credit for maintaining the existing software or trying to make it faster. The only way you get promoted is if you created a new project. So that's what people end up doing, and you get 4 or 5 versions of the same project that do the same thing, all not very well.
I agree that the suckage is a problem. But I think it's the structure of incentives in the environment that software is written that also needs to be addressed, not just the technical deficiencies of how we practice writing software, like how to maintain state.
It's interesting Chris Granger submitted this. I can see that the gears have been turning for him on this topic again.
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. :)
The guy is most definitely at least a genius.
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.
Which includes:
> 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.
Judging by GitHub contribution data (https://github.com/LightTable/LightTable/graphs/contributors...), it seems there has only been 25 commits (from one author) since Sep 20, 2019.
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/