It's too late for an edit, but looking at the article again, especially
the conclusion, I wonder even more about the seeming dismissal of
Smalltalk:
> * storing code in a networked database with version control and realtime sync
This sounds a lot like Monticello and/or what Lively Kernel does over
Webdav?
> * a structured editor to enable rich ASTs with unique UUIDs
I'd say something similar is achieved by Smalltalk with it's view that
there is no "source code" -- there is only the compiled code that is
also viewable/editable as text (this is not so much about code, but a
feature of a truly object oriented system).
> * managing environments declaratively so that evaluating code is always safe
I don't see how "evaluating code" can "always" be safe? Or is this
similar to having the ability to deploy a separate dev-image in
Smalltalk terms?
> * a uniform (logical) data model where every piece of state is globally addressable
One example of this would be an object graph?
> * a model for change that tracks history and causality
I take it this is the "live programming" bit discussed alongside here.
If all input and output is via messages, it would seem feasible to
simply log messages (possibly collapse some messages (ie: +1, -1, +1,
-1, +1 becomes just "+1").
> * a powerful query language that can be used for querying code, runtime state, causal graphs, profiling data etc
I'm not entirely convinced we need a "powerful" query language. But
something to specify context (show me all counters in the date widget)
would be good -- but it would be fine to express it as
"in:someDateModule var:count". Maybe I just read "powerful query
language" differently than the author (intended).
> * composable gui tools with transparent guts
We seem to be reinventing these forever.
> * a smooth interface to the old world so we don't end up sharing a grave with smalltalk
I really didn't want to go all "Smalltalk did that" (I'm not even sure
it did I only know new-ish Smalltalks) -- but I think the eco-system
is in the process of proving the death-by-different wrong: We use Apps
on phones and through the web -- and the fact that eg: Google
spreadsheets has pretty a pretty crappy interface with "the old world"
doesn't seem to bother anyone. I mean, yeah, we know that we probably
need to interface with some form of external file system -- but now we
can pretty much just throw http/dav at the problem.
I guess I'm just grumpy -- arguably there's no difference between
running a javascript vm on bare metal vs running a Smalltalk system on
bare metal (except for the language part, but we can implement the
language(s) we need on top of js anyway…). I just can't help but feel we
might do better with a system better designed to be a system, rather
than the web browser that accidentally became a vm and virtualized
display driver. It doesn't strike me as likely that we'll see a proper
security model that actually works for javascript in the near future,
for example.
What you glossed over was the 'model for change' part and the implications that follow from there.
It's a shame that it's not being said more clearly and explicitly in the post; but that 'model for change' implies immutable/persistent data structures and all that comes along with that.
The foundational assumption that data is never deleted or updated but just garbage collected does really change a lot.
Essentially (I'm hoping!) they're just saying: let's build another Smalltalk but with persistent data structures and reactive programming instead of Smalltalk's MVC model.
But yeah; it does sound like they need to study the Smalltalk ecosystem a bit better to figure out that apart from those two things Smalltalk did already do pretty much everything they want to be doing here; or find a marketing angle that's less off putting to those that know Smalltalk well...
> * storing code in a networked database with version control and realtime sync
This sounds a lot like Monticello and/or what Lively Kernel does over Webdav?
> * a structured editor to enable rich ASTs with unique UUIDs
I'd say something similar is achieved by Smalltalk with it's view that there is no "source code" -- there is only the compiled code that is also viewable/editable as text (this is not so much about code, but a feature of a truly object oriented system).
> * managing environments declaratively so that evaluating code is always safe
I don't see how "evaluating code" can "always" be safe? Or is this similar to having the ability to deploy a separate dev-image in Smalltalk terms?
> * a uniform (logical) data model where every piece of state is globally addressable
One example of this would be an object graph?
> * a model for change that tracks history and causality
I take it this is the "live programming" bit discussed alongside here. If all input and output is via messages, it would seem feasible to simply log messages (possibly collapse some messages (ie: +1, -1, +1, -1, +1 becomes just "+1").
> * a powerful query language that can be used for querying code, runtime state, causal graphs, profiling data etc
I'm not entirely convinced we need a "powerful" query language. But something to specify context (show me all counters in the date widget) would be good -- but it would be fine to express it as "in:someDateModule var:count". Maybe I just read "powerful query language" differently than the author (intended).
> * composable gui tools with transparent guts
We seem to be reinventing these forever.
> * a smooth interface to the old world so we don't end up sharing a grave with smalltalk
I really didn't want to go all "Smalltalk did that" (I'm not even sure it did I only know new-ish Smalltalks) -- but I think the eco-system is in the process of proving the death-by-different wrong: We use Apps on phones and through the web -- and the fact that eg: Google spreadsheets has pretty a pretty crappy interface with "the old world" doesn't seem to bother anyone. I mean, yeah, we know that we probably need to interface with some form of external file system -- but now we can pretty much just throw http/dav at the problem.
I guess I'm just grumpy -- arguably there's no difference between running a javascript vm on bare metal vs running a Smalltalk system on bare metal (except for the language part, but we can implement the language(s) we need on top of js anyway…). I just can't help but feel we might do better with a system better designed to be a system, rather than the web browser that accidentally became a vm and virtualized display driver. It doesn't strike me as likely that we'll see a proper security model that actually works for javascript in the near future, for example.