Lively.next: A personal programming kit | Hacker News Reader

Lively.next: A personal programming kit

lively-next.org

68 pointsMichaelAO25 comments

Author here. lively.next is a runtime and development environment. It comes with a graphical user interface and programming tools that allow you to program similarly to Smalltalk and Self, i.e. instead of a edit-compile-run cycle you have an ever running "program" and change various parts of it directly. With that you have access to runtime objects that you can inspect, use for code completion, or modify.

Apart from the UI (inspired by Self's Morphic [1]), lively.next implements a meta system on top of normal JavaScript that makes such things possible as to hold on and inspect system state (variables defined inside a module, mechanisms for redefining things etc).

Also, lively.next runs on any JS system and it's various packages can be embedded, e.g. to create a programming environment for node.js and other such things.

The Lively project evolved over time and lively.next is the newest version:

- https://www.lively-kernel.org is from the Sun Labs / HPI days (check out the ancient http://sunlabs-kernel.lively-web.org, fully SVG based rendering)

- Lively Web: https://lively-web.org A live, programmable wiki (2012-2015)

- lively.next since 2016 https://lively-next.org.

[1] http://ftp.squeak.org/docs/Self-4.0-UI-Framework.pdf

This sounds interesting for personal use, but I'm curious about how you share programs with people who aren't running the whole lively environment? What does that look like?

There are two parts to this:

a) How to user graphical constructions (we call them parts) outside of the main framework? We currently work on ways to "snapshot" them in a way that they include all their dependencies. So not just the object (graph) state but really all code dependencies. es6 modules are a big help here since they allow to trace dependencies statically. This is work in progress and we will post updates about this.

The state right now is that you can the HTML view of morphs into web pages, e.g. see [2]

b) Several parts of the system can be used standalone, e.g. you can enable support for Lively tooling in node.js processes or arbitrary webpages. See https://lively-next.org/worlds/lively-2-webpage for a bookmarklet that loads the lively.vm [1] and lively-system-interface on a arbitrary web page: https://imgur.com/a/2foGR. This allows you to then use the workspaces, system browser, inspectors, etc. on remote targets.

[1] https://livelykernel.github.io/lively.vm/

[2] https://lively-next.org/worlds/lively.next%20website

Thanks for the links. I've been looking for something where I can save executable snippets (shelling out to things or making RPCs to services) in a smalltalk-like browser, and it looks like this might work. I tried Amber a few months back, but couldn't figure out how to get node to shell out, so I went back to TCL+tk.

This appears to be a system in the Smalltalk lineage but based on Node and JavaScript and currently seems only to target MacOS. It uses Self/Smalltalk's UI system and is based on ideas by Alan Kay (of Xerox PARC fame and one of the creators of Smalltalk). The web interface looks and feels similar to a web-capable Smalltalk variant called Lively Kernel[1] but in a less-mature state of development and with more of a focus on text.

1) https://lively-kernel.org/

Another semi-graphical live programming environment I guess.

I'm still hoping for http://witheve.com/ to take off :)

Lively reminds me of TouchDesigner (node based programming with a focus on visuals) http://derivative.ca/events/2017/AlienCovenant/

Seeing this brings back the question that always pops up when seeing smalltalk-esque IDEs; why don't these ever take off? Maybe they aren't solving a specific problem someone has and are being too general? Not flexible enough? Maybe someone who has tried out these systems to solve a specific problem can comment?

I guess people are just married to their customized Vim, Emacs, Visual Studio etc. setups which they are using for many years. These Smalltalk-related IDEs are too different and break a lot of old habits.

I was myself a fairly dedicated emacs user and what I like so much about the Lively UI is that you a) get all the programmability and customizability that you have e.g. with elisp (all the stuff on the screen can be programmed, keybindings, windows, everything down to the characters in texts) while b) get a user interface that is way more powerful than simple text. It's easy to embed images and interactive objects into normal texts allowing things to be more interactive to use. It's easy to plot and visualize data (interactively, not just a static screen), e.g. see the plotly morph in the partsbin. There is a sketch morph in the PartsBin as well, allowing you to sketch and take handwritten notes, I use this in combination with Astropad. Etc.

All that stuff makes the environment much more convenient to use for general content creation, not just programming.

Something that is not to underestimate is the amount of work it takes to support various kinds of content and programming languages nicely in this form. To get the most from it you want some kind of runtime integration to get feedback (errors completion) or at least good type system support integrated. It's interesting to watch a project like Atom grow – the plugin system they have is nice but ultimately the kinds of interaction they support with it are only text based. I think, in order to have a Smalltalk-like IDE take off, one needs to have similar support for extensions while allowing those to be easily integrated with richer tools like inspectors and debuggers.

Worse is better/creative limitation/blub paradox: Smalltalk, like Lisp, is too powerful; you can do essentially anything you desire in a bunch of different ways. Too much flexibility makes it harder for a clear use case to emerge and having too many choice points only makes pathfinding through the solution space more difficult unless you've made a bunch of firm decisions beforehand. Other languages like Go or Python make many of these decisions for you. It seems like the ideal pattern in these ultra-expressive languages is to construct a much more restricted DSL which can ultimately lead to a proliferation of completing solutions a la the JS ecosystem.

Inner platform/walled garden: Almost all Smalltalk systems basically implement their own operating system complete with their own integrated graphics system/window manager, process scheduler, and so on. It's an amazing environment for creating applications but it doesn't play well with the outside world and there isn't a straightforward way to 'shake' an image down to just your application. Deployment usually comes with the overhead of the entire Smalltalk system and interop with native can be somewhat limited. Imagine if Java applications only ran within Eclipse.

Zipf's law: The popular languages are so popular that their communities generate their own gravity (i.e. lots of effort tends to attract more effort). Despite Smalltalk's many appealing qualities (ergonomics, simplicity, maturity, robustness..) it stands in the shadow of giants; many people don't even know it's there or can't invest the effort to give it a shot so it never achieves critical mass.

Slightly tangential question: why call it "lively.next" ? What is the .next? I understand including a ".tld" in a name when the TLD is part of the domain name, but "lively dot next" doesn't exactly roll off the tongue and .next isn't even an available TLD?

Hoping it will be one at some point :)

We first wanted lively.web but then came the .web tld disaster .

.next was chosen b/c there were / are several versions of Lively over the years with version numbers LivelyKernel 2 [1], Lively4 [2], etc. lively.next should simply signal that this is the ongoing and evolving project in the Lively family.

[1] https://lively-web.org [2] https://github.com/LivelyKernel/lively4-core

How hard is it to get this to work with something other than Javascript?

Not very hard. Two years ago we did something similar for Clojure: http://cloxp.github.io/cloxp-intro.html https://www.youtube.com/watch?v=qQvvgzvPgQI

We are currently evaluating options for getting this stuff funded and Python would be a another target language / platform.

Thanks, I was particularly wondering about Python and R. Will try this out anyway.

I can see python being very useful for this, but perhaps ruby would be a better fit? I can't help but wonder if lively.next+ruby on the truffle vm might not be able to steal a lot of attention, and kick off a bit of an "old-style" / message-passing object oriented revival... One can hope...

On The other hand, zope/zodb did manage to get pretty far wrt "magically persistent" object graphs for python.

FYI: Theres a large margin of empty space on the left on safari OSX, requiring horizontal scroll to see the site.

And on Firefox 45.6 ESR on Debian.

Thanks, will be fixed!

I really want to try this, but it doesn't progress from "loading" on my iPad.

Will look into it. For now, most of the UI is geared towards mouse and keyboard, however. I can recommend Astropad [1] or some similar app, I regularly use it and Lively for sketching and notes.

[1] https://astropad.com/

Can this be run on a non-connected chromebook?

We have not added support for this yet but there is no reason why it shouldn't be possible. Generally, the serialized objects can be synchronized into the browser's indexdb (we use pouchdb in the background so this is pretty straightforward) and together with a service worker and some caching this is doable.

That frontpage uses alot of words to say absolutely nothing...

Someone care to tl;dr what this is?

Reply on news.ycombinator.com