> 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)"... On 6 December 2015 at 19:58, Dimitris Chloupis <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. >> > >> >> >
