https://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865890.html
> Look man you do more harm with these articles than you do good.
No. Just... no.
> This Smalltalk hype is the worst of its kind and completely misses the point of why Smalltalk is great.
Speaking of "hype(rbole)"...
> "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.
>> >
>>
>>
>