[armitron]

Given that this is pretty much an inferior version of the Pharo Glamorous Toolkit [1], which has been available for years, it is very disappointing to not see a reference/attribution. Especially taking into account that the - pioneering - research happened in the Smalltalk camp. If I wanted to be cynical I would say that presenting half-assed re-implementations of good ideas found in non-popular projects (Smalltalk, Common Lisp) in an easily-digestible manner with a veneer of freshness, is very prevalent in the Clojure domain.

I find REBL to be inferior because it largely misses the "moldable tool" point of GT. REBL focuses on the data (almost solely one could say) but presents a rigid UI - other than the data-specific part - whilst GT allows _everything_ to be molded at runtime which is of course the better approach. GT obsessively focuses on the interplay between data and the person interacting with said data. In systems theory terms, person and data mesh together into cybernetic entanglement.

[1] https://gtoolkit.com

[bmillare]

I interpreted the talk as the tool viewer was a proof-of-concept in order to advocate the benefits of using the nav and datafy protocols. I believe Stu is not claiming its particularly novel, but instead wants to inspire tool makers to use the protocols and make better tools, hence his mentioning of his curiosity of what the Clojurescript guys could make. I mean I had the idea of a data viewer with some partial implementation with no knowledge of GT, and another person in this thread has been working on a similar idea, the tool concept isn't that novel (based on the features you describe). On the other hand, Clojure being a dynamic language by default makes any open source dataviewer written in Clojure automatically "moldable". Further, because of the protocols, its easy to swap between different people's implementations of the viewers. Clojurescript in particular is at an advantage because of the vast web resources and Clojurescript can compile itself.