An image IS a file !!!
An image *can be stored to* a file. The image is not the file. Ceci n'est pas une pipe. The reason it is image-based is that the image is the primary representation. The copy of the image stored in a file is simply a persisting back-up of the image. Unlike file based systems like, say an SQL d/b. There, the file is the primary representation, and what is in memory is (generally) both transient and partial. (i.e. we load in things from disk, and write things out to disk, and the disk is the canonical representation of the state. With the image based system, the file-copy of the image is transient and often partial. The 'image' of the system (i.e. the current state of system and contents that is held in memory (including anything paged out to store in virtual memory) is the primary representation, and the canonical representation of state. (Although it could be that the changes file is kept in lock-step automagically - I've never looked into what the changes file is actually doing at a moment-to--moment level, at which point the changes file would be partial and capable of generating or providing a canonical representation of state ). On 6 December 2015 at 19:58, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
"Files belong in the Stone Age"
No they do not !
"Smalltalk is an image-based programming language."
An image IS a file !!!
"An image is essentially a self-contained operating system that manages all the code for you, thanks to an easy-to-use IDE"
no its not!!! the vm is the virtual OS , the image is the OS libraries. The VM also is a binary file separate from image and comes with a lot more files , plugins and external libraries.
Look man you do more harm with these articles than you do good. This Smalltalk hype is the worst of its kind and completely misses the point of why Smalltalk is great.
It would even make zero diffirence if we were to break the image file down to much smaller files, it would still be a live coding enviroment. Actually you dont even need those files to be even binary , text source code files can still store live state and be all about objects.
And on top of that there are people there asking you the easiest questions and you cannot even answer them while at the same time you proclaim the end of File's "Stone age".
And on top of that you post this in amber-lang which is not even relevant in any way with your article (since its not image based) just to get more attention.
On Sun, Dec 6, 2015 at 8:40 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
There are a lot of questions in there, too much to answer.
The basic answer is that everything is modelled as objects, even the objects themselves. There is a complete meta model of what could be considered code and even the execution of code. Furthermore, even versioning is modelled nicely too. Of course, Pharo interfaces with the outside world, it can read and write files, it can do networking. The object world and its code can, in various ways, be mapped to concepts of this world. For example, https://github.com/pharo-project/pharo-core contains (a copy, one representation) of all code in Pharo. There is also the option to save the whole object world to a single snapshot file, called an image. Running on servers, containers, embedded devices is all possible, in multiple ways, with or without a (G)UI. At that point Pharo consists of a couple of files, most notably the image file.
HTH,
Sven
On 06 Dec 2015, at 17:58, horrido <horrido.hobbies@gmail.com> wrote:
I submitted an article at Reddit called "Stop Thinking in Terms of Files." Some guy with the handle "audioen" wrote the following comment:
We have heard that smalltalk appears to use model similar to a LISP machine of yore in that the programming environment = the OS = the runtime environment. Once you define a function, it simply exists without being written to a file or compiled into some process that runs it. You can just call it, or undefine it and it ceases to be. From this point of view, it is probably perfectly valid to say that it has no files, because it doesn't need them.
On the other hand, let's assume that your smalltalk image got a little bit corrupted so that some packages/functions/whatever are now missing or not functioning. Or, let's say that you accidentally undefined a function and that was a mistake and now you really want to get it back. How would you do that? The file-based answer is that you hopefully had backups of the files that held definition of that function. What passes for a backup in smalltalk land?
And how do you deal with version control? How do you recover from mistakes? If you wanted to share your crap to someone else collaboratively through e.g. github, how would you do that? You'd have to export your functions into individual files, probably, and packages as directories into git. Someone would check them out, eval them, make changes, and commit updated functions. How does this kind of process look like, in a non-file paradigm, if it is done at all? (Does smalltalk VM even support networking?)
In general how do you even dump the state of the VM in some way that you can show someone what exactly your project is made of, in textual form? It's not very nice to dump an entire image and tell them to just run that. I bet the image is much larger and contains historical stuff that you no longer care about. What if you really just wanted to publish a recipe that can construct something equivalent of that particular image? What does "docker" for smalltalk look like?
If you tell us files suck, tell us also how you solve the same problems that we solve through files. Especially that collaborative programming through github use case interests me a little. -----
I must confess, I'm not fully qualified to answer this comment, /at least, not optimally/. Perhaps some of you can go to the Reddit link
<https://www.reddit.com/r/programming/comments/3vjlta/stop_thinking_in_terms_...> and respond? Thanks.
-- View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.