You make a convincing argument. Files are useful. In modern circumstances, Smalltalk has to coexist with a file-based world. As Joachim wrote earlier, we are well-equipped to deal with files, but we do not think in terms of files when we code our applications. We are not obliged to use a file-based toolchain. The point of my article was to persuade other developers that letting their obsession with file-based tools prevent them from adopting Smalltalk is short-sighted and counter-productive. Files have their uses, but they should look beyond files for other software creation possibilities. Smalltalk has much to offer.
And, yes, it would be very good to have 64-bit support in Smalltalk. kilon.alios wrote > 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!" > > On Mon, Dec 7, 2015 at 6:45 PM horrido < > horrido.hobbies@ > > wrote: > >> 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! >> >> >> >> kilon.alios wrote >> > That's the thing you can't take the argument further without >> diminishing >> > the value of you argument precisely for the fact that the vm is far >> closer >> > related to the image than it is to 0s and 1s. That tight relation is >> > fundamental to the behavior and existence of the image. It defines its >> > functionality, purpose and limitations. >> > >> > The image itself is a file and the fact that it can store live state in >> a >> > binary format does not make it unique or any less of a file. In my case >> I >> > use blender files, they store the entire live state of the blender >> window >> > including images and even Python scripts. Similar examples are >> countless >> > out there. >> > >> > So the answer to the question what makes the image file format unique >> is >> > simply.... Nothing >> > What's the advantage of using the image format compared to other files >> ? >> > None >> > >> > On Mon, 7 Dec 2015 at 15:14, Ben Coman < >> >> > btc@ >> >> > > wrote: >> > >> >> On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis < >> >> > kilon.alios@ >> >> > > >> >> wrote: >> >> > "A Smalltalk Image is your entire system. The Image includes all the >> >> tools >> >> > required to interact, customize and add functionality to your >> system, >> >> so >> >> > Smalltalk’s IDE is a very Integrated Development Environment." >> >> > >> >> > >> >> > Thats not the case even for someone like me that has been working >> with >> >> > smalltalk for only 2 years. The Image is not even the engine that >> >> drives >> >> > smalltalk . Thats the job of the VM that exists in a completely >> >> different >> >> > universe than smalltalk. It exists in the same universe than many >> other >> >> > languages do exists and thats the C universe, the universe of the >> OS. >> >> > Essentially what drives your system is not smalltalk is C. The >> >> diffirence is >> >> > that for a part of it that is high level enough, Slang is used, a >> >> Hybrid >> >> > language between C and Smalltalk that compiles to C. So while in the >> >> image >> >> > everything is , well almost everything, an object all the way down, >> in >> >> the >> >> > VM everything is C all the way down. >> >> >> >> To take that argument further, the VM is not even the thing driving >> >> the image ;). Essentially what drives it are the 1's and 0's of >> >> machine code. Further, what drives that are the electrons flowing >> >> through the chip. I think its fair to say that we *code* in Pharo >> >> without files. Files relate to Pharo only to the same extent that a >> >> database like Oracle or Postgres can be said to use files. That is, >> >> when you do SQL queries, are you *thinking* in terms of files, even >> >> though files are used by the server to store the data? Its just a >> >> matter of where you draw the line of abstraction. >> >> >> >> cheers -ben >> >> >> >> > Ironically an image misses the most important tool to even generate >> >> this >> >> C >> >> > code and thats the VMMaker that has to be installed separately. And >> of >> >> > course there are parts of the system that are coded in pure C, like >> >> some >> >> > core functionalities of the VM and of course plugins and external >> >> libraries >> >> > that the image has to rely on make things happen. >> >> > >> >> > Of course the image is still fairly powerful, you can change the >> >> syntax, >> >> > implement high level libraries, IDE tools and much more. But its not >> >> the >> >> > core of the system just another essential part of it. >> >> > >> >> > >> >> > On Mon, Dec 7, 2015 at 9:24 AM Dimitris Chloupis < >> >> > kilon.alios@ >> >> > > >> >> > wrote: >> >> >>> >> >> >>> >> >> >>> well, i wouldn't need or even want it in memory, so on disk is >> fine. >> >> the >> >> >>> problem is more likely management of the same. browsing the >> changes >> >> is >> >> >>> not >> >> >>> really convenient. ideally i'd like to see versions in the >> >> class-browser >> >> >>> and >> >> >>> in the debugger, where on error i could then take a look at older >> >> >>> versions for >> >> >>> comparison, and switch to them to see if maybe the last change was >> >> the >> >> >>> cause of >> >> >>> the error. >> >> >>> >> >> >>> greetings, martin. >> >> >>> >> >> >> >> >> >> There are versions already for methods. So the functionality is >> there. >> >> >> >> >> >> I disagree however with you, I think that changes file was created >> for >> >> the >> >> >> precise scenarios of an image crash/ lockdown. In that case you may >> >> want to >> >> >> go back through the code and dont remember which method was >> triggered >> >> or >> >> >> what else was defined and created. In the case going >> chronologically >> >> which >> >> >> is how the changes file is already organised is far more useful >> than >> >> going >> >> >> method and class based. >> >> >> >> >> >> But I do agree it would be useful to extend the tools working with >> >> changes >> >> >> , but then none stop anyone from doing so and is not that hard to >> do. >> >> >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865820.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> -- View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865872.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
