Login  Register

Re: Stop Thinking in Terms of Files

Posted by EuanM on Dec 07, 2015; 9:18pm
URL: https://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865889.html

>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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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_of_files/>
>> > 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.
>> >
>>
>>
>