Hacker News Comments on
Light Table - Chris Granger
ClojureTV
·
Youtube
·
12
HN points
·
3
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this video.This is exactly my impression after taking a quick glance through these articles as well.If anyone is curious and would like to see a practical demonstration of this data-oriented approach of modelling problems, I highly recommend this talk from Mark Bastian in Clojure/conj 2015: https://www.youtube.com/watch?v=Tb823aqgX_0
In it, he contrasts the data-oriented modelling approach with a traditional OOP approach for implementing a board game, and was able to come up with a complete implementation of the game with the former approach that was shorter than even the structural boilerplate for the OOP version.
Another related talk that I loved was Chris Granger's 2013 talk on Light Table: https://www.youtube.com/watch?v=V1Eu9vZaDYw
Where he walks through his process of building a game in ClojureScript using an Entity-Component-System architecture, which is very well suited to this data oriented modeling approach.
Also on the topic of functional/data-oriented game programming, one of my favorites is Chris Granger's Light Table talk, where he talked through the design of a game built in ClojureScript using the Entity Component System architecture: https://www.youtube.com/watch?v=V1Eu9vZaDYw
> GUI libraries are an interesting special case: They involve huge class hierarchies, lots of implementation inheritance, circular references, and tricky ownership.I doubt they have to be. There are other ways to do GUI, see for instance how Light Table uses a database-like Entity Component System. https://www.youtube.com/watch?v=V1Eu9vZaDYw
⬐ jerfI am fairly confident "someone" could write a composition-based UI. I know of no fundamental reason why that would be impossible, or even any more difficult than doing one with inheritance.However, that does not solve the problem that all the mature existing UI widget toolkits are based on inheritance, and that causes a serious "impedance mismatch" with languages that don't have inheritance.
As I expect more languages to start privileging composition over inheritance, I also therefore expect this problem to continue to become more acute until "someone" finally solves it. However, GUI toolkits are huge and "someone" is likely to be a substantially-sized organization. The problem is going to have to become very painful before it is solved well.
⬐ carry_bitYou might be able to create something like React. The API would be composition-based, and the library would bottom out against an existing UI toolkit.⬐ loup-vaillantGranted, current GUI toolkits are huge. On the other hand, I have worked with Qt, and this convinced me most of the complexity there was a blend of avoidable bloat and a long tail of features few people ever use (a bit like offices suites).I'm pretty sure properly written GUI toolkits can be much smaller. As in, satisfying 90% of our needs in a couple thousand lines of code. (The remaining 10% might require heaps and heaps of code, but I'm sure it doesn't have to affect the core.)
It's only an intuition at this point (I have yet to implement my own GUI toolkit). But I have reasons to believe this intuition is right: http://www.vpri.org/pdf/tr2012001_steps.pdf
⬐ shadowmintGiven that as far as I know, there are no examples of tiny fully-featured GUI libraries (it's all either trivial like cgui or a massive bloated mammoth like qt/wpf/android), isn't that a bit of a rich statement?I'm pretty sure properly written GUI toolkits can be much smaller...
Like, I'm sure you can write a procedural generator in a handful of lines of code that spits out the full works of Shakespeare. It's probably possible, if you have the right seed and the right algorithm.
...but practically speaking, how do you actually build one?
The same goes for UI libraries; certainly it should be possible (in theory) to have a minimal beautiful GUI libraries with an excellent API; but every attempt to build one seems to have failed.
Perhaps the problem domain is actually more difficult than you're giving it credit for...
⬐ elcritch⬐ jerfIt's certainly a tricky endeavor, but not impossible:- http://www.fltk.org/index.php - https://github.com/froggey/Mezzano
Then again most gui libraries end up including networking, file handling, etc...
⬐ loup-vaillantvpri.org managed to squeeze a GUI toolkit and a document format and the whole compiler toolchain required for the language (including rasterization) in about 20K lines of code, and it's fast enough to run in a laptop.I'm pretty sure we haven't explored the sheer depth of simplifications that can still be done.
⬐ shadowmintSounds cool. Got a link?I can't find anything on their website that seems to be that sort of thing?
⬐ renoxI doubt that you'll find much.. They didn't release the code of their "crown jevel" (Frank, the 'word processor'), which makes me quite unimpressed about these year of research where the main result is a bunch of papers and demos but (nearly no) code (except for the OMeta part).⬐ loup-vaillantI believe they did release the source code, not far from here: http://vpri.org/fonc_wiki/index.php?title=Installation_Guide (may be outdated, you may want to ask the FONC mailing list, may not work on your machine… it's a proof of concept anyway, not a hardened engineering artefact).Their writing is here: http://vpri.org/html/writings.php
Their various reports are there (most recent first):
http://www.vpri.org/pdf/tr2012001_steps.pdf
http://www.vpri.org/pdf/tr2011004_steps11.pdf
http://www.vpri.org/pdf/tr2010004_steps10.pdf
http://www.vpri.org/pdf/tr2009016_steps09.pdf
⬐ renoxMaybe the word processor is there, maybe it isn't, there isn't much documentation, I've asked the FONC mailing list..Well, I guess I ought to put this in here, rather than rewrite it :) : https://news.ycombinator.com/item?id=12410471The "long tail" is like the long tail of Excel or Word; yeah, everybody only uses 5% of it but everybody uses a different 5%.