Kaya: Declarative Reactive(vimeo.com)
vimeo.com
Kaya: Declarative Reactive
http://vimeo.com/107069470
36 comments
> 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?
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.
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 the author: What do you think is the biggest flaw of spreadsheet programming? It seems like the biggest advances you are trying to make are "cells within cells", prototype oop, and immutability.
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.
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.
That's a really good question. You're not the first to suggest that it wouldn't scale in terms of complexity. But it was actually built to solve the problem of that type of scaling -- that was one its prime directives in being built -- but until it can really be tested, no one can know how it will truly hold up.
> 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).
> 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).
Is there anything else than the video? Some homepage or so? Is this an Open Source language or a commercial one?
I guess this is not related to this? http://kayalang.org/ http://en.wikipedia.org/wiki/Kaya_(programming_language)
I guess this is not related to this? http://kayalang.org/ http://en.wikipedia.org/wiki/Kaya_(programming_language)
Sorry, no, there's no site for the project. It's not related to the other Kaya language and so I'll have to change the name at some point. Contact me if you want to follow the project, my email is in my profile.
After watching the video, I appreciate the potential of Kaya. I clearly see the benefits of the native many-to-many construct, and its unified data/instructions model.
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?
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?
Yes! And so you can say: Employee.ReportsTo.ReportsTo.ReportsTo for example.
I have a hunch that Lloyd's Algorithm[0] would make for a nice demo in this environment, automagically updating the voronoi cells every iteration until an equilibrium is reached. Although I don't know if there's an efficient way to implement voronoi cells in this paradigm.
[0] http://en.wikipedia.org/wiki/Lloyd%27s_algorithm
[0] http://en.wikipedia.org/wiki/Lloyd%27s_algorithm
I'd like to see how this differs from what Chris Granger's Eve[0] will be one day.
His description of Eve is still very vague.
[0] http://www.chris-granger.com/2014/10/01/beyond-light-table/
His description of Eve is still very vague.
[0] http://www.chris-granger.com/2014/10/01/beyond-light-table/
Chris wrote me about six months ago asking about Kaya, so I sent him a similar presentation. It seems to me also that there might be overlap (from the little I know about Eve).
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.
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.
There's a lot more info about Eve here: http://podcasts.thoughtbot.com/giantrobots/111
Cool! This would be really interesting if immutability were the default to support time travel in queries and whatnot.
Thanks! It is, and that's a really nice use of it. It also functions as a built-in version control, unlimited/infinite undo, etc.
I would like to point out that http://kayalang.org/ is already a programming language, and that the language author might want to consider a name change.
Skip to 25:00 for the demo
The HN title is total flame bait and does not match the actual post title on either LtU or Vimeo; a mod should really change it. It may also make sense to change the link to the Vimeo presentation as linking to the LtU discussion forces people to click through to see anything and is a little strange – are we supposed to watch the video or read the LtU thread?
For easy access: The link to the video is: http://vimeo.com/107069470 (Some HNers just look at the comments first, so this might be useful for someone.)
And since the post now links to Vimeo, here is the LtU link: http://lambda-the-ultimate.org/node/5054
This is a presentation of Kaya at the Future of Programming Workshop. The title is accurate. Shortened in a clickbait fashion, perhaps, but not "total flame bait".
True. I read the "future of programming" part as someone being really excited rather than accurate though.
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.
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 title isn't flame bait. This really is the future of programming, in my opinion.
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.
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.
> This really is the future of programming, in my opinion.
That is exactly why it is flame bait :)
That is exactly why it is flame bait :)
You're welcome to think the future of programming consists of typing into text documents; I think it looks more like using a spreadsheet.
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.
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.
Crap like this makes me actively not want to listen to you and reflects badly on Kaya. If you want to effectively promote something, give an honest account of its advantages and drawbacks and let people judge for themselves whether it's going to be the future of programming or not. The presenter of this talk understands that and doesn't try to oversell it, simply describing Kaya as "declarative reactive"; you should respect this and not make their work look crankish because of the way you, not they, choose to present it.
I suspect he is the presenter. But agree totally - the tone of the talk works 100% better.
You're going to want to work on your communication if you want to evangelize your new tool and not alienate people. For the rest of the world, the value of Kaya is not a given and you're going to get a lot of practice explaining it.
I'm 'people' as well and am not alienated. Nothing to stop you offering a mini-lecture on PR but for myself, rather you didn't. I can make up my own mind on Kaya as presented.
[deleted]
[deleted]
[deleted]
Being the author, of course you'd say that.
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.
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.
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)?