Several things I disagree with [1] 1) "Living in the image" , I think this is a usual smalltalker misconception in that just because you do not see something it means it does not exist.
Obviously thats not the case with the Pharo image. The Pharo image is indeed a binary file and self contained enviroment but not user friendly by itself because the Pharo image only stores bytecode, which is hard to read. The actual source code you see inside the image which what we do 99% of the time is coming not from the image but a file called "sources" and yes its a text file and a typical smalltalk source code file. Of course this does not stop there and we have also the changes files, which is also a text file, for recovering lost changes. Even the more modern Epicea , heavily relies on text files and of course then you have other tools like GTPlayground who store the code snippets also as source code files and of course Monticello which uses mcz files which are nothing more than zip files containing standard smalltalk source filex, again text files. And the story does not end there that we live outside the image far more we are willing to admit , there is of course the VM which the image cannot access , hence why we want to move GUI support completely to the image. But also the foundation of the power of Pharo which is the C libraries it has to rely on to do all of the basic stuff, open, close and create files, read , play sounds, display graphic formats , access databases and a ton more are all outside the image and the image is able to communicate with them either via plugins or the UFFI. 2) I would not call a zip file containing text files a binary based VCS.Thats what a mcz is. Because if we do then so is Git since git as well is Zipping the files because like Monticello , it recognises that is a waste of space to upload uncompressed files. We know how valuable online space is cause pretty much anything online nowdays implements its own type of compression. By the way binary files storing byte code is not anything special , its actually the standard , Java has them in the form of .class file and python has them in .pyc where the first time you run code its compiled and stored to this files and then its those files that are executed , source code itself is never executed. It may have been special in the 70s and 80s but definitely not since 90s. What makes the image special however is the storing of the live state and live execution of code.... but even that is not special because modern applications always utilise a form of storing live data and live execution for means of convenience, but we as Pharo offer this outside the box. So yes the pharo image is special but not as special. Actually the real irony here is that the MCZ is image unfriendly because not only it contains text files but unlike Git cannot version control binary files, you can version control a Pharo image with Git but you cannot do it with Pharo VCS. So Git is more Pharo friendly than Pharo itself at least for that purpose. I always found it strange that monticello does not support version control for binary files , especially if you take into consideration how much value we put in the live state and live context of execution. Also Git has LFS which deals with large binary files and solve the problem of accumulation of wasted space via the git commits. Other than that, as always excellent talk, very easy to understand.... and you do not look like grandpa to me :D On Sun, Jan 15, 2017 at 10:47 PM Dale Henrichs < dale.henri...@gemtalksystems.com> wrote: > I gave a talk at Smalltalks 2016 entitled: "Dangerous Liaisons: > Smalltalk, files, and git"[1] and this thread is a perfect example the > dangers I was thinking about:). > > For "history buffs", here's a link for my talk at STIC 2012 entitled > "Practical Git for Smalltalk"[2]. > > Dale > > [1] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git > > [2] https://www.youtube.com/watch?v=ZIkoBQphtyM > > >
