This is undeniably true. UberJars and UberWars are yooooge. On Mon, Dec 7, 2015 at 3:29 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Image size? What a joke when one faces "Uber Jars"...
On Mon, Dec 7, 2015 at 11:08 PM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
And this "victory of dead code and date" that files usually promote can further benefit Pharo .
For example lets take one of the main problems of the Pharo image, its size. There is already an effort to modularilise the image to make it small and everything else installable and unistallable.
But why not go a step further and have dead zone files. So you end up with a tiny image containing just the basics (few kbs if possible) even no GUI and IDE tools and instead you have a collection of files that can be read by the image , each file contains a diffirent project, you can view their code and their data but not install them in the image to do so. And only when you decide that "sure I could use this project" then you instruct the image to import the file and make the code and the data live and part of the image. This way the pharo system can keep growing without growing the image at all and let the users decide how much they want to grow the image themselves.
Technically speaking this functionality is already available through monticello , where monticello allow you to view a local or remote repository of code without loading the code to the image (via the "open button"). So its not even a new concept. Though in my mind I imagine all this happening from inside the System Browser.
Thats just one scenario how dead data and code can greatly benefit the Pharo system. I can keep brainstorming forever for the usefulness of files for Pharo.
On Mon, Dec 7, 2015 at 9:20 PM horrido <horrido.hobbies@gmail.com> wrote:
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.