views:

874

answers:

10

I'm really interested if someone knows a programming language that uses an image like Smalltalk...

I think that is one of the greatest ides in the history of computer science.. I can not find other language besides Smalltalk that is base on an image.

+1  A: 

From what I remember sitting at my dad's side back in the 80s, MUMPS is image-based. I could certainly be wrong, and a quick scan of the Wikipedia article didn't show anything, but it's possible...

Jon Skeet
+2  A: 

I'm curious as to if the Smalltalk Image system scales.

If you had 20 programmers working on the same codebase, how does that work? Do they each have their own image, or do they share one?

If you make a code modification that requires a modification of your environment, and someone makes a different modification with similar requirements, can the images be merged (as with Version Control)?

Bill K
why not post that as a question?
Rainer Joswig
Either developers exchange *change sets*, i.e. the equivalent of patches, or they use version control tools, which tend to work in a more DVCS-like fashion, and on code entities (classes and methods) rather than files and lines of code:- Envy- Store (Cincom Smalltalk)- Monticello (Squeak, Pharo).
Damien Pollet
For example with Envy/Developer, one programmer could create a new edition of a method, make and accept a series of changes to that method (each accepted change would be recoverable), explicitly name and version a particular edition (other programmers can see the changes) and then publish.
igouy
For example with Envy/Developer, although you could see that another programmer had created editions of code you were also working with, in practice you'd probably ignore that and merge with the published version and then publish your merged version.
igouy
I does NOT scale.
Adrian
+2  A: 

Most implementations of Common Lisp.

stesch
I do not know why but the LISP syntax is so hard to read... anyway I will check How common lisp is implemented using images.
ClaudioA
I haven't recommended Common Lisp. I've just answered the question.
stesch
The reason some people find the syntax so hard to read is that there pretty much isn't one. You just write the parse tree as S-expressions. Some people find this lack of structure...disturbing.
David Thornley
I found Smalltalk code hard to read till I started learning the language and understanding that everything reduces to "Object - Message". The same is for Lisp, everything reduces to "(function args)". I used to think the Lisp model is the simplest evere. But now I think Smalltalk's is more natural.
Andrei Vajna II
Yes, I see what you mean, and I Agree, Smalltalk is really close to natural language (at lest from my point of view :))
ClaudioA
+12  A: 

Many Lisp systems are using 'images'. That's where Smalltalk got it from, possibly - since Lisp had images already before Smalltalk existed. The OS on the Lisp Machines were basically Lisp images (even hierarchical images with incremental delta images).

If you ask which language uses a similar way to organize source code (i.e. not in files), then again Xerox InterLisp did that. Apple's Dylan did that. Some DB development tools might do that.

Rainer Joswig
+3  A: 

Factor is a Forth with many high-level features and an image.

Damien Pollet
+2  A: 

Yea, most Forths are image based.

Will Hartung
+1  A: 

To answer Bill K's question: apparently it works just fine (though I've not tried version control in a team personally).

All Smalltalk systems do it a bit differently, though. There's a very interesting podcast all about it on The Stack Trace. Much of it applies to all image-based development environments.

wbg
+2  A: 

I happened across this comment which I think gives a flavor of image based development.

'So while I can and do use the JVM for server-side computation, it’s a bit heavy weight for small and simple tasks. Common Lisp’s answer to this problem was an ingenious one. Instead of building programs that you run over and over, it offers an “environment” in which code is iteratively evaluated, so that you actually grow and nurture a burgeoning set of functionality within a long-running VM. I like this model when appropriate, and enjoy it, for example, in Emacs, which I can leave running for days on end while at the same time extending its functionality by writing new functions and customizing variables."

igouy
+1  A: 

You could actually consider SQL databases as being image based - the data and the code (stored procedures) are all stored together in one big opaque blob.

anon
A: 

By the definitions I can find, every Microsoft application (Excel, Access, Word, etc.) with VBA embedded would qualify, wouldn't they?

In fact, spreadsheets in general.

le dorfier
I can't see how those are 'image' based. Word is a program and it opens and saves documents. What would be an image here. In 'image' in the smalltalk sense means a full dump of the application, its code and data. Word documents don't contain 'Word'. Word does not contain 'Word documents'.
Rainer Joswig
If the executable image includes all the dynamically linked libraries, then I think there's a sense in which it merges.It seems like it's at least as legitimate as a SQL database, which is even more clearly bifurcated.
le dorfier
The image does not only contain libraries. An image is a snapshot of a running, say, Lisp with data, application state, ...Creating an application with libraries included is not about 'images'.
Rainer Joswig