The devil is in the details ;)
It matters to me, I just came across the need to share data between multiple images. So I was pointed by the good people here to the Fuel library that , surprise surprise , it generates binary files that contain objects in their live state that helps you move and share code and data between images. Works well and I really like its design :)
We are not talking here about something sophisticated, we are talking here super basic functionality. Images sharing data and code. What we use ? Files. The image by itself has no functionality to even cover this super basic scenario because as a format is made to be self contained.
How you cant even care for such basic functionality ? Of course you will at some point. Its unavoidable.
The nice thing about files is that they have one very big advantage over the image. That is, specialization. When an app find a specific file , just by looking at its extension it immediately knows the structure of the data and the code that it may contain.
On other hand when you have an object system like the image is, such specifications go outside the window meaning you have to deal with the fact and trust that those that made those images have adhered to specific guidelines so you can make sure that your code wont run in front of some very nasty surprises.
But since the image itself allow you hack so deeply as the syntax of the language , you can't be sure how the data and code will be presented. Sure they will objects, but the format does not really matter so much as the structure itself.
In those cases files win hands down because they tend to be far more restricted on how they are structured. Not because there is anything special to these files, apart from the fact that their authors made sure to follow the specific structure to ensure compatibility with third party apps.
So not only Files are not on the Stone Age but they have evolved the level of specification to a whole new level that have made the foundation of our every day lives.
Sure you could probably replace files with a new way that is more Smalltalk friendly and still retain all the advantages of files and file system but , Smalltalk has not presented such solution to my knowledge. Hence we the smalltalkers we will still keep relying heavily on files for our every day needs until such solution is presented to us. Also with the huge wealth of file formats it would be a pain in the ass to replace them with a smalltalk solution.
In the mean time there are even more pressing matter that the image file has to attend to, which is far more stone age , to use your remark , than files. That is the ability to use full memory of the system and the ability to deal with large data without any large hits on performance. In short good support for 64 bit and big data.
��
"But these are implementation details...implementation of the base system.
/From the perspective of a programmer writing an application/, none of this
matters.
As I said earlier, the only reason why Smalltalk has to deal with files at
all is because we live in a file-based culture. And the reason our culture
is so entrenched with files is because we are too heavily invested in them,
and we aren't going to budge. *Files are about as low a storage abstraction
as you can get*, and they pre-date even Unix. Yes, files belong in the Stone
Age!"