
All ideas are old ideas - llambda
http://www.chris-granger.com/2012/10/05/all-ideas-are-old-ideas/
======
btilly
The problem with having your code all in a software image is that the second
you do this you lose a large existing toolset that people have invested a lot
in mastering.

Just think of everything that you know how to do which involves a filesystem.
I regularly use editors, grep -r, cd, edit in one directory and run unit tests
in another, revision control systems, etc. People have invested a lot of
energy into these tools, and have strong opinions about which ones they prefer
and why. (Perhaps you prefer an integrated IDE. Doesn't matter, my point
remains.)

As soon as you move to an image based system, your entire toolset no longer
works within the inside of that image. It is, of course, a programmatic
environment and replacements for every filesystem manipulation you are
familiar with are available. Sometimes those replacements are better (though
better is often just in the eye of the beholder). But they are guaranteed to
be _different_. And as you move from one image based language (say, a Lisp
dialect) to another (eg Smalltalk), they will be different again.

By contrast if you move from one filesystem based language to another, you
will still have a learning curve, but there is a large toolset that you do not
have to relearn.

~~~
groby_b
"The problem with driving a car is that you lose almost all the skills you
obtained by driving a horse carriage".

Yes, the image interop part is a bit more difficult to solve. I'm not saying
it's exactly like the switch from carriage to car, but I'm saying that _some_
changes are worth losing existing skills

~~~
btilly
Consider that image-based environments have been losing ground to file-system
based ones for years.

Consider also that core ideas that make image-based environments good can be
separated from the image-based system and moved into non-image based systems.
Two examples that I would give for Smalltalk are Ruby's borrowing of
Smalltalks OO model, and various IDEs borrowing the idea of a refactoring
browser.

Borrowing the other way is much harder. For instance consider the distributed
version control patterns that git enables. Image-based software development
communities are sufficiently small and fragmented that they are unlikely to
all duplicate the functionality of git. And because of the internal
differences, they each would have to reinvent it. By contrast once git became
available, it was immediately available for use with C++, Java, Python,
JavaScript, Haskell...

There are advantages to image-based environments, but do they outweigh the
disadvantages? Before concluding that they do, you might want to re-read Worse
Is Better.

~~~
hermanhermitage
Good points.

A possible approach is to consider the file system the image - consider a UI
for managing a VM image and processes within that image.

The difference is then essentially deciding what is the center of the system.

The older image based language systems assume they are the center and all must
pass through them - like a monolithic kernel.

Perhaps what could be explored is more transparent integration between
language runtimes and file system objects.

~~~
DeepDuh
I think you hit the nail on the head. Build systems like GNU Make pull
information about the file system to find out what has been updated. All we
basically have to do is to

1) move from an information pull to a push. (Sidenote: This is something that
'kind of' works in OSX GUI, although it seems to me that 10.7 has broken this
functionality for certain usecases. E.g. I'm connected to my host mac with my
linux vm through SSH and when I've updated a file from within that VM, the
host Finder windows get updated automatically and Preview.app windows get
updated when I click into them).

2) Extend the functionality to runtimes as well, i.e. enable hotloading like
in the new Unreal engine.

------
kemiller
Something I've always wondered is how image-oriented languages like smalltalk
handle deployment, version management, etc. How do you make a frozen,
repeatable bundle? I realize that may be the wrong question, that those things
are irrelevant, but if so, why are they irrelevant? What is it about those
environments that compensates?

~~~
pnathan
one way to do it is to load the entire system into the image and actually just
straight up deploy the image as an executable.

~~~
kemiller
I guess I don't understand where the line between code and data lies, then. Is
there a store for variable data that is separate from the image?

EDIT: To clarify, I know that Lisp and Smalltalk have a fuzzy-to-nonexistent
line between code and data. What I want to know is how you'd manage that in
practice. If I'm changing an existing piece of software, I don't want to
expose production users to its incomplete state, so I can't change the running
production site directly. (Right?) But if I'm developing locally, or even in a
staging version, I don't want to transfer my test/sample data.

Maybe a better question is, "What is a typical workflow like for modifying
production software?"

~~~
pnathan
> Maybe a better question is, "What is a typical workflow like for modifying
> production software?"

In a modern Common Lisp web server set up, you'll likely have a SWANK
connection available for debugging and patching. You will have to write live-
patching code to correctly lock, drop/unbind old definitions, rebind new
definitions, and unlock. It will likely remind you of a DB migration script.

For a non-live upgrade, you'll have a process that starts up the new server
image, gets it ready to receive connections, then switch the routing & drop
the old server. It's not too different from other systems, IMO.

------
hermanhermitage
It's great to see Chris write this up.

It's always refreshing to see someone explore the work of those who have had
similar concerns or solved similar problems. Whether they have independently
chosen a similar direction or are standing on the shoulders.

Provides a good reference for new comers wanting to understand what approaches
have been explored before.

We live in exciting times. The confusion of (programming) tongues is in full
swing; the CPU clock wall is with us; high level features such as closures and
GC now have fairly efficient implementations - it seems there are now enough
transistors to deliver much of the abstraction that was envisioned by the
founders but gave way to pragmatic concerns in the early microcomputer era.

I am looking forward to IDEs that manage and simplify complexity, and hardware
ISAs that throw a few more transistors at things like STM, tagged data and
memory management.

I can see a future where I can edit code in a language foreign to me, but see
an instant side-by-side (editable) version in a dialect I'm more comfortable
with. Switch in another view and drag and drop states in my state machine via
direct manipulation, and so forth.

------
charlieflowers
This really got me thinking about the ideas that we can mine from old,
neglected systems that lost the marketing battles and are simply considered
obsolete now.

~~~
ChuckMcM
So one of the things I've been working on in my 'spare' time is a simple
training computer. One of the things I have been very careful to do is
document what sources of information and inspiration I'm using in that
design/implementation (all pre-1992) in order to insure that should someone
try to throw a patent troll lawsuit at it I would be well equipped to defend.
Sad really.

------
pnathan
I am very glad to see the Light Table team taking a hard look at the 70s & 80s
work. It's very... heartening.

Personally, I am wondering when light-table mode for emacs/common lisp will
come out. :-)

~~~
bitdiddle
talk about blast from the past, I spent a few years looking at a Symbolics
machine, though I rarely saw that Genera login, the machine stayed up for days
on end.

light-table mode for emacs/common lisp would be neat. As a schemer I think
what would be really awesome is to see light-table merged with the
emacs/guile/geiser work. Geiser is also trying to resurrect the lisp machine.

------
mark_l_watson
I had a Xerox 1108 Lisp Machine from 1982 to about 1987 (and for one month, I
ran Smalltalk on it rather than Lisp).

Yes, it was awesome compared to using a timeshared VAX (or whatever), but as
fantastic as my 1108 was for its time and no matter how much I loved it at the
time, I like my development environments today a lot more. Examples:
development and debugging of both server side and client side code (GWT on
client, something REST full on the server side) with IntelliJ Java debuggers
open on both client and server code - hopefully you may only need this once a
month but useful when you need it. Repl based development with a smart IDE
(like Clojure in IntelliJ or Ruby in RubyMine). Interactive Scala worksheets
in the Eclipse/ScalaIDE (sort of like Chris's Light Table).

In addition to a lot of NLP work on my 1108, I was also just getting into
neural networks back then and my NN simulations ran like mollasses on the
1108. Any of my laptops are many orders of magnitude faster for just about
anything I do than my 1108.

------
zaptheimpaler
chris - In the 8/17 post you said there would be a big announcement coming up
soon. Any updates on that? I think there was some speculation that it would be
Python support - that would be awesome!

------
6ren
[please refute, not just downvote] Just because something can be done doesn't
mean it _should_ be done (maybe it should be done, but for some other reason).

I'm suggesting that barriers to modifying systems have had an accidental
benefit of favouring standardization.

The basic problem is that it's hard to create systems (APIs, generalization,
documentation, test-cases, integration with everything else). Brooks claims
it's 9 times as much effort as making something that "works for me". If you
can't amortise that over many users, it's usually not worth doing the job
properly.

But if it's just for you, you don't need all that polish, right? Well, no. If
you are standing on the shoulders of giants, it's really helpful if those
giants are stable, function as you expect, interact correctly with other
tools, and have clear documentation for when you've forgotten the details
(writing it yourself doesn't make your memory perfect). SOTSOG is really
important for building complex systems, because it enables you to push down
details to a lower level of abstraction, so you have less clutter to deal
with. It's getting the abstractions right that is so difficult (we've all seen
it done wrong).

There are huge advantages to using standardized systems, that have been
improved, tested, documented etc by others. If you want to do something
different, it's very helpful if you can start with standardized components
around the new part, so you can just concentrate on the interesting stuff, and
not need to build the whole world from scratch. Of course, the existing stuff
is not perfect - the question is whether it's worth it for you to spend the
time needed to make something better.

Some issues in assessing this argument: These are ideas have been around for a
long time, but haven't taken off. Highly modifiable systems like lisp, despite
having clever and devoted users, lack the standardized libraries of less
flexible languages like Java.

But there is one kind of area where such systems are absolutely brilliant -
exploration at the systems level. Many (most?) programming language ideas have
been developed in lisp, even though did not become popular in that form,
because lisp is great for language exploration, but not for standardization.
Similarly, an OS that can be modified on the fly, is great for exploring OS
ideas. You can iterate quickly, see the results and so on.

Of course, it seems possible that one could have it both ways - a highly
flexible system that also had standardized components. But that doesn't seem
to happen. Flexibility and standardization are natural enemies, both in
differences in the tools that support them... and the kinds of people who use
those tools.

BTW: There's a middle way. Create tools that can be standardized on. i.e.
libraries, frameworks, engines, DSLs. Light table could be perfect for that...
but people who use it may want to make tools that are just as flexible as
light table, and so don't support standardization.

------
pyrotechnick
What has been will be again, what has been done will be done again; there is
nothing new under the sun.

~~~
GlennS
Except, you know, computers...

