When we talk about reactive language we should think not about reactive programming or even reactive data accessors, but about reactive data structures. The main point of separate language for reactive datas is that it should work perfectly (effecianlty) with a data with all possible (by a language) ways. In other words, the language should expose API for data accesing and transformation and limit it to fit in a most efficient compile output. It means we should be able to analize AOT all accessors in classic for / map and optimize it or throw it away from a language and replace it by some variations of pick: listOfAC = listOfAB.pick({a: 'identity', b: b => toC(b) }).
I think there probably is some amount of API that is unavoidable but there is something attractive about not having much in the way of API for this. We might have no choice for things like lists. To specially handle compilations for things like array literals. Mostly I don't view this necessarily always been in a runtime primitive mechanism. The reason I focus on language is because as our analysis gets better the implementation could change dramatically. We see this with Svelte and I've seen this taken even further with Marko. Those don't even have reactive primitives anymore at runtime but just call some functions. My hope is that behavior (but not the implementation) can be well defined in mostly with regular language mechanisms. Lists might just have to be the exception.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When we talk about reactive language we should think not about reactive programming or even reactive data accessors, but about reactive data structures. The main point of separate language for reactive datas is that it should work perfectly (effecianlty) with a data with all possible (by a language) ways. In other words, the language should expose API for data accesing and transformation and limit it to fit in a most efficient compile output. It means we should be able to analize AOT all accessors in classic
for/mapand optimize it or throw it away from a language and replace it by some variations ofpick:listOfAC = listOfAB.pick({a: 'identity', b: b => toC(b) }).I think there probably is some amount of API that is unavoidable but there is something attractive about not having much in the way of API for this. We might have no choice for things like lists. To specially handle compilations for things like array literals. Mostly I don't view this necessarily always been in a runtime primitive mechanism. The reason I focus on language is because as our analysis gets better the implementation could change dramatically. We see this with Svelte and I've seen this taken even further with Marko. Those don't even have reactive primitives anymore at runtime but just call some functions. My hope is that behavior (but not the implementation) can be well defined in mostly with regular language mechanisms. Lists might just have to be the exception.