"

*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 <s...@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.hobb...@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_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.
> >
>
>
>

Reply via email to