> You may not use REBL for commercial use.
[0]: https://danielcompton.net/2018/03/28/clojure-survey-2018
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
I genuinely believe that Clojure could have taken over the world if it had a more sensible open-source governance model.
It's like "how to not get people to use your tool" 101
That said I'm not Emacs expert so it may be harder than I imagine.
I'd assume it means you cannot sell REBL itself or a derivative, not that you cannot use it as a developer tool to build your project, which kind of makes sense.
I wouldn't want to read too much into this particular prototype of REBL. I think they don't want to have people re-package this iteration and sell it as-is.
Their idiomatic database can travel through time, they focus intently on composition, referential integrity, immutability to the database level
They have specs which can validate things typically better than types and they compose
They focus on shared protocols which gives them amazing leverage, like the internet works because we all cooperate via the http protocol
I've been looking quite closely at datomic recently and that database looks ducking magic
Now datafy and nav will give rise to generalised browsers of anything Clojure can touch, conceptually it's kind of like my file system, my SQL browser, my web browser, my profilers, my debuggers and any number of other things I haven't imagined, all merged into one
I’ve only been playing with Clojure for a few months, but it feels like a spaceship. This addition just adds to the mystique.
My first thought upon seeing the REBL browser in action was that it looks like those protocols enable something like Smalltalk’s amazing integrated full-system dev environment—the most intriguing aspect of that language to me by far—to the Clojure world, without having to buy into the “system as image” paradigm that Smalltalk seems to require. Can anyone with Smalltalk experience comment on how accurate this hunch is? It just screams “best of both worlds” to this noob.
EDIT: I should have read the other comments first: it looks like this is a common sentiment, which is very encouraging. I’d still like to hear the first impressions of a Smalltalk veteran.
That really bugs me with a great many popular languages. There's a REPL, but the libraries and tooling don't really embrace it.
But it's difficult with Python as soon as you try to do anything beyond a single module. CL and Clojure have proper packages and namespaces so it works fine. But in Python you're limited to working on the context of a single module. If you modify a module that was imported then you have to restart the REPL because you can't reload modules. It just doesn't work.
In CL I would just load the entire system then eval whatever part I want to. From that point I would never not have the current version of the system completely loaded into the running image. Much the same with emacs itself. It is a running image of your emacs lisp system and you can just modify it and eval as-you-go. Does any other language even come close to this?
I made a video to demonstrate it some time ago. Apologies for the dreadful sound quality. https://youtu.be/k-mAuNY9szI
I've been spending occasional free moments working on one since 2014[0], and this is the first time I've come across something with any significant overlap in conception[1].
It still blows my mind that I can describe the concept to programmers (and/or show a video demo) and have the most typical response be along the lines of, "but what would you use it for?" (To be fair though: this is certainly in part—though not totally—due to the particulars of the poor job I've done attempting to communicate the idea, e.g. by demoing visualizations of algorithms on random data.)
It would be easier to answer what you wouldn't use it for. When is it not useful to see the data your code is operating on? When in the video he talked about having one monitor for the data browser and one for emacs, that made complete sense to me. I see writing programs in the future turning out that way: you get a dedicated, mostly passive display of the data your code is operating while you program.
It's almost like we're so trained at having to deal with invisible program data it ceases to be obvious that in building something whose fundamental goal is to transform data (i.e. computer programs), one would benefit enormously through the ability to see the data being transformed.
Prior to this the best way I had of describing the purpose was to point to the Chrome dev tools object explorer and Firefox's console.table(...)[2]. But this is the first thing I've seen also taking on the 'unifying' aspect of the project, based on—as was pointed out in the video—the fact that data tends to come in a limited number of shapes.
[0] http://symbolflux.com/projects/avd
[1] There are still significant differences though—for one thing mine is focused much more on time-evolution of data. Where he showed the quick display of a graph of a set of numeric values for instance, I'm building a corresponding feature but it would instead work with a single numeric variable and display a graph of its values over time.
[2] https://developer.mozilla.org/en-US/docs/Web/API/Console/tab...
Status Quo? (the status quo being... print statements?)
Another easy example of a long available better model that is still niche/ignored: pipelines in PowerShell [1] are clearly superior in many fronts, but people prefer keep parsing plain text with regular expressions rather than learn a new shell language.
1: https://docs.microsoft.com/en-us/powershell/scripting/gettin...
PowerShell sounds great and I'm sure there are some people who are very productive with it but it's ultimately a silo. It's never going to be as low-friction to support as text.
Clojure separates data from the functions that operate on it. In contrast, Objects intertwine those two things. You can roughly think of the "data" part of an Object as its attributes, and the "function" part its methods.
1: an "atom" in clojure is not what it is in traditional lisp lingo; is there a name in clojure for type that is roughly the union of: symbol, number, character, boolean ? perhaps "primitive"?
For an example - while technically a set of all prime numbers is data - you can't just view it in the REPL as a whole. So I interpret the "not data" notion as a shortcut to saying - a subset of data and optionally some way to navigate throgh the rest of it.
> This is design work. Thanks Rich.
Well said! It feels to me that the power of a whole language with simplicity as a core philosophy is now starting to snowball up some really powerful tooling - since small changes can create big improvements.
We've got some new developers at work who are learning Clojure and so I've been rewatching some old Rich Hickey videos (Hammock Driven Development) and it's cool to see the payoff 7 years later of what he was talking about back then.
Still lots of fun, mind you. And anything to bring these environments to more folks. I just worry about things that only demo well if well rehearsed. Which seems to be more technology than makes sense.
Strongly recommend a watch particularly if you're modelling something in a typed language
clojure.spec was a nice step up to natively dealing with data 'shapes', I'm hoping the datify/nav protocols will be a step up to what I'm doing as well. It's basically a generalised browser over data with different print representations, collection handling, publishing, muxing, etc. The REBL will hopefully raise consciousness of just how abysmal the representation and navigation of the web is today.
While clojure is far from perfect, it actually has a story for shipping your code, in a form where you don't need to embarrass yourself when your customer gets it, into servers, web pages, desktops and cell phones.
They tried to fix the errors with Spec but honestly I don't think that solution worked that well. Spec is great for generative testing and other solutions but no one wants to write specs for every single small little potential error that could happen.
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.
[edit] more context
1: https://github.com/clojure/clojure/blob/master/changes.md#21...
2: https://mobile.twitter.com/puredanger/status/102810365424144...
"A [REST] (REBL) client enters a [REST application] (REBL browser) through a [simple fixed URL] (initial EDN [2] data). [All] future actions the client may take are discovered within [resource representations] (metadata) returned [from the server]. The media types used for these representations, and the link relations they may contain, are standardized. The client transitions through application states by selecting from [the links within a representation] (the annotated data) or by manipulating the representation in other ways afforded by its media type. In this way, [RESTful] (REBL) interaction is driven by [hypermedia] (metadata), rather than out-of-band information.
1: https://en.wikipedia.org/wiki/HATEOAS , the one thing that makes REST REST but nobody implements in their "RESTful APIs".
