Kaya: Declarative Reactive
vimeo.com
vimeo.com
I have two major concerns after watching the video through.
First is the spreadsheet ui. Much of the drama and nonsense with bad spreadsheet programming is related to not having the _table_ as the primary data organizational tool. Data should be in labeled and typed columns not laid out in cells on the main sheet and then postfacto treated as coherent data.
I was more genuinely more confused by what you were trying to explain in the early part of the video because of the awkwardness of your spreadsheet ui metaphor. Ie as you were explaining the columns and rows, reordering etc around 4:30+ .
The spreadsheet should be just a layout medium for expression of A view of data tables.
Apple tried to fix this with https://en.wikipedia.org/wiki/Numbers_%28spreadsheet%29 but ymmv on how successfully.
Suggestion - experiment with using a graph (or just cards) with tables as nodes. Figure out how to use the edges to express the program coherently.
Your asteroids demo was nicely done but I would be very unhappy reading a medium size program with your current ui.
Suggestion - have tables only built as they are defined. Don't try to be too much like existing spreadsheets (though obviously some of your audience would like to see a very traditional spreadsheet ui).
My second major concern is that I think spreadsheets and spreadsheet programming would benefit from stronger typing. You seem to not be addressing that? As as an example from your video are people's children not people too?
How can we keep a money column from being used as someone's age etc (without a function in between)?
I'd be really interested in knowing the story there as well. If there's any documentation on the whys or why nots, or any videos/presentations, I'd be interested in seeing them.
For me, it always seemed like the biggest problem was that once a spreadsheet grows past a certain size, it becomes unmaintainable due to the makeshift unspecified schema, layers upon layers of hacks, and the repetition due to the lack of good abstraction tools. While your demo was impressive, it seemed like it was going in the wrong direction when it comes to addressing these issues. Databases and data processing often seem to form a ugly mess when mixed too closely. I concede that might be a hasty judgment, since I haven't really had the chance to play around with it yet.
> Databases and data processing often seem to form a ugly mess when mixed too closely.
Yes, that's true, and I think that it's due to granularity you normally get when using declarative languages like SQL. It's quite difficult to do anything but make a basic selection. Declarative is a lonely paradigm for that reason. I think this is different because of how you structure and select, and would then avoid those traps, but again, time will tell.
Email me and I'll update you on how it progresses (including what its biggest flaws are turning out to be).
I guess this is not related to this? http://kayalang.org/ http://en.wikipedia.org/wiki/Kaya_(programming_language)
I wonder if Kaya could store graphs efficiently, in addition to hierarchies. For example, can you have one table called Employees with a property Reports To, which references another Employee? In other words, can Kaya allow this: Employee.ReportsTo = @Employee?
His description of Eve is still very vague.
[0] http://www.chris-granger.com/2014/10/01/beyond-light-table/
I think we have a safe lead, though, based on that we've already spent many years getting through a lot of the implementation issues, which are the real crux. I wish his team a lot of good luck, because the devil is really in the details.
Although the future of programming is probably declarative once we stop doing it ourselves and leave the implementation details to the AI writing the program for us.
The link is to LtU because I submitted it once before as a direct link and it wasn't upvoted. I couldn't submit that link again directly.
That is exactly why it is flame bait :)
You're welcome to think the compiler and syntax are important; I think it's visualizations.
You're welcome to think the future is a grandchild of C; I think we haven't even begun the journey yet.
The fact that you actually believe that is a big red flag to me, especially when you refuse to put your argument in a written form.