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.