Stop Thinking in Terms of Files
Locked
12
12
 
|
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 and respond? Thanks. |
Re: Stop Thinking in Terms of Files
|
|
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 <[hidden email]> 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. > |
Re: Stop Thinking in Terms of Files
|
"Files belong in the Stone Age" No they do not !"Smalltalk is an image-based programming language." "An image is essentially a self-contained operating system that manages all the code for you, thanks to an easy-to-use IDE" 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 <[hidden email]> wrote: There are a lot of questions in there, too much to answer. |
|
|
"An image is essentially a self-contained operating system that manages all the code for you, thanks to an easy-to-use IDE."
I'm not trying to be pedantic. I'm using general parlance to convey an idea, and the idea is essentially correct. And I'm hardly alone. GemTalk's own "Pharo, the collaborActive Book" defines image in much the same way: "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." Let's not conflate implementation with the Smalltalk UI experience. Of course, under the hood, Smalltalk is implemented using files. Duh! Today, Smalltalk is hosted on Windows or Mac OS or Linux or whatever other OS. But the original idea behind Smalltalk was that it would be a self-contained operating system; no host required. Think back to the Xerox PARC days: how did they host Smalltalk? Remember the Xerox Alto? The reality is that the entire world is deeply entrenched on using files, much the same way the entire world is entrenched on using QWERTY keyboards and automobile steering wheels. Smalltalk has to live in this world, so it makes accommodations for filein/fileout, Git, etc. Amber for the web has to live with HTML, CSS, and JS files. However, this does not alter the basic premise of my article. Smalltalk programming is a file-free abstraction. In order to enjoy this environment, you should mentally unfetter yourself from the traditional methodology of using file-based tools like Emacs, IntelliJ, and so on. This is one of the main things holding back developers.
|
|
|
In reply to this post by kilon.alios
I didn't say I cannot answer the questions; I said I may not answer them optimally. After all, I haven't used Smalltalk in a long while, and I was never an expert to begin with. I'm certainly not up with the latest developments in Pharo. (For example, I didn't know that Pharo no longer has filein/fileout.)
I'd rather not give a weak response. Hence, I appealed to you guys. You live and breathe Smalltalk; I don't. I posted in amber-lang because I know many Pharoers are there, too, and I use Amber. The Pharo forum is less inviting for me, I find. This thread is a fine example. 
|
|
|
In reply to this post by kilon.alios
And for the record, a number of long-time Smalltalkers have expressed their appreciation for the work I've done. One of them (a 25-year Smalltalk veteran!!!) said to me: "You may think the job was thankless, but I think you did a great job." I really, truly appreciate his accolade.
Hey, I get it. Not everybody agrees with my marketing approach. And not every Smalltalker wants Smalltalk to become popular. I expect these folks to be in the minority. It is sad and unfortunate that the Smalltalk community is divided in this manner.
|
Re: Stop Thinking in Terms of Files
|
|
In reply to this post by Sven Van Caekenberghe-2
Excerpts from Sven Van Caekenberghe's message of 2015-12-06 19:39:51 +0100:
> There are a lot of questions in there, too much to answer. i am interested in the versioning of code and objects. the poster makes a good point there. what if i am on a non-networked machine, running pharoNOS or even squeakNOS, how would i keep old versions of my code/objects? is there any in-image solution for that? greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
Re: Stop Thinking in Terms of Files
|
|
Le 07/12/2015 02:50, Martin Bähr a écrit :
> Excerpts from Sven Van Caekenberghe's message of 2015-12-06 19:39:51 +0100: >> There are a lot of questions in there, too much to answer. > > i am interested in the versioning of code and objects. > the poster makes a good point there. The traditional, full approach, would have been to use an object oriented database like GemStone. Anything that can version objects can version Smalltalk code. > what if i am on a non-networked machine, running pharoNOS or even squeakNOS, > how would i keep old versions of my code/objects? is there any in-image > solution for that? The .changes provides that in a limited form. It would be easy to do better in memory, if needed. > greetings, martin. Regards, Thierry |
Re: Stop Thinking in Terms of Files
|
|
Excerpts from Thierry Goubier's message of 2015-12-07 06:42:51 +0100:
> > i am interested in the versioning of code and objects. > > the poster makes a good point there. > The traditional, full approach, would have been to use an object > oriented database like GemStone. Anything that can version objects can > version Smalltalk code. gemstone is proprietary, so that doesn't really work for me. are there alternatives? > > what if i am on a non-networked machine, running pharoNOS or even squeakNOS, > > how would i keep old versions of my code/objects? is there any in-image > > solution for that? > The .changes provides that in a limited form. It would be easy to do > better in memory, if needed. 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. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
|
|
Sounds a lot like good-old envy, which basically is an always-connected
object db for versioned code artefacts - from Methods, to Classes, Applications to Configuration Maps. I always miss it immediately when I work in other languages or Smalltalk dialects. The only thing that comes close to it seems to be STS which never made it into Pharo or Squeak, afaik. Of course Smalltalk is not done with files, and if we want external versioning, we rely on them. Smalltalk lives in the same universe as the rest of the computing world. Smalltalk does handle files well and has to if it wants to play with today's technologies. XML, JS, CSS, JSON, heck, the whole web is based on files. The whole discussion about files should be centered around the questuon whether organizing code by means of files is a good concept. In Smalltalk we think that code is basically objects, and files may or may not be a way of persisting them. So this is not about files per se. Kent Beck once wrote or said: "Source code in files, how quaint!" (why is that citation missing from the OP's article?, does any one have a link to the article?), completely ignoring that of course in the end the code is stored in files. So yes, we use files and we are well equipped with objects to handle files. But we do not THINK in files when we write code or organize artefacts. We see them as a way of storing stuff. Basically, what we do is not so far from other languages or environments, we just don't let files play a role in our code organization from the conceptual viewpoint. But no, we don't view ourselves as being done with files or haiving something better. Just my 2 cents Joachim Am 07.12.15 um 07:13 schrieb Martin Bähr: > Excerpts from Thierry Goubier's message of 2015-12-07 06:42:51 +0100: >>> i am interested in the versioning of code and objects. >>> the poster makes a good point there. >> The traditional, full approach, would have been to use an object >> oriented database like GemStone. Anything that can version objects can >> version Smalltalk code. > gemstone is proprietary, so that doesn't really work for me. are there alternatives? > >>> what if i am on a non-networked machine, running pharoNOS or even squeakNOS, >>> how would i keep old versions of my code/objects? is there any in-image >>> solution for that? >> The .changes provides that in a limited form. It would be easy to do >> better in memory, if needed. > 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. > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:[hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 |
Re: Stop Thinking in Terms of Files
|
|
In reply to this post by Martin Bähr
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. |
Re: Stop Thinking in Terms of Files
|
|
In reply to this post by Martin Bähr
Le 07/12/2015 07:13, Martin Bähr a écrit :
> Excerpts from Thierry Goubier's message of 2015-12-07 06:42:51 +0100: >>> i am interested in the versioning of code and objects. >>> the poster makes a good point there. >> The traditional, full approach, would have been to use an object >> oriented database like GemStone. Anything that can version objects can >> version Smalltalk code. > > gemstone is proprietary, so that doesn't really work for me. are there alternatives? I have not looked into the alternatives. I know what is needed for a transparent OO layer for Smalltalk, and I wrote some of the necessary support code for my PhD in 1997/1998, but I never went very deep into the versionning aspect (especially the transactions, commits and conflict resolution). In short, things are available, a lot of litterature, and maybe some stuff you can rely upon (the voyage/MongoDB/Sqlite layers we have now?). >>> what if i am on a non-networked machine, running pharoNOS or even squeakNOS, >>> how would i keep old versions of my code/objects? is there any in-image >>> solution for that? >> The .changes provides that in a limited form. It would be easy to do >> better in memory, if needed. > > well, i wouldn't need or even want it in memory, so on disk is fine. For a moment, I was thinking of systems without disk at all... > 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. What you describe is a GUI limitation, not the changes itself :(. A better integration of the browser/debugger with the code versionning. And just a local git, fossil or monticello repository would be enough. All the pieces are there. As an example, it would be very easy to make AltBrowser browse all the MC stuff, or RB changes, in addition to the normal (RPackage/Ring) live code structure (and hence give you access to class versions, method versions, etc...). Regards, Thierry |
Re: Stop Thinking in Terms of Files
|
|
In reply to this post by kilon.alios
"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. 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. On Mon, Dec 7, 2015 at 9:24 AM Dimitris Chloupis <[hidden email]> wrote:
|
Re: Stop Thinking in Terms of Files
|
|
In reply to this post by kilon.alios
Excerpts from Dimitris Chloupis's message of 2015-12-07 08:24:13 +0100:
> > 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. > There are versions already for methods. So the functionality is there. only if i save them in monticello though, and i can't just switch the version of a single method, only the whole changeset at once. in git i can limit browsing to a specific file, and then copy an old version of a file into the current workspace. it is a bit crude, but it can be done. i don't see that kind of functionality in pharo. the data is there, but the tools to use the data in this specific manner are not. > I think that changes file was created for the > precise scenarios of an image crash/ lockdown. indeed, i agree, changes are to recover from an image crash, and less useful to browse old versions of code. > 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. true, but that's not enough to use as an argument to "sell smalltalk" so i am afraid, all we can say about in-image versioning is: it's possible, but current tools don't support it. (note that i have no issue with the current state. dreaming about what we could do is nice, but it is important to be aware of what is currently well supported, and what isn't so that we avoid to oversell features that aren't practically usable.) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
|
|
In reply to this post by kilon.alios
When we switched from VisualWorks/ENVY to C# around 2003 we were surprised to see how bad source code management was in the Microsoft area those days - and asking around in the usual community groups those days made one think very clear: the world is thinking in files and noone will not be able to force these large numbers of developers to change their behaviour. That's the base problem.
But we will also not be able to change these large numbers to Smalltalkers anyway (mostly because it uses "." and NOT ";" or "[","]" instead of "{", "}" - strange, that so many younger programmers have then problems with this syntax - seems to come a monoculture of programmers ). These days we have git and svn and the quality of tools has improved very, very much - but limitations of the file based process are still there, BUT instead of changing the users: the tools available today (e.g. VisualStudio) do a huge work in the background to give an intelligent view on these files (where .NET is much better here than Java). So the users have their loved files and still have some intelligent repository-like view on the source code - they do not see the difference any more. The drawback of this approach is the huge-memory-demand of these tools - where Smalltalk's memory usage is more or less still there where is was 18 years ago. That's also message. And one comment about data corruption: I'm working now for 18 years with ENVY (with VASmalltalk) and I never had any serious problems with it. After such a long time I'm not thinking about the problems of having data corruption (to have a good backup system is still a need) any more - and the backup procedure is simply: copy one file. But yes there is a limitation of this superior repository: the external resources. It's pretty sad, that Pharo/Squeak had not the (open sourced) tools to go the repository based approach in the past - but at least the files there are only seen as a textual representation of the code and are used only for import/export and the core system is still image based development. To summarize: files seen only as an import/export representation (some kind of backup) of the source code is ok, but more was and still is simply "old aged". |
Re: Stop Thinking in Terms of Files
|
|
In reply to this post by Thierry Goubier
Excerpts from Thierry Goubier's message of 2015-12-07 08:33:03 +0100:
> > 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. > What you describe is a GUI limitation, not the changes itself :(. A > better integration of the browser/debugger with the code versionning. > And just a local git, fossil or monticello repository would be enough. > All the pieces are there. indeed. for me that's a good enough answer for now. at least for the source versioning. i can very well imagine how to make that work. unfortunately i don't think it is enough to support the question richard received. i am still not clear how object versioning would work. i mean, i can imagine this: x := Foo new. i can now save x in a database. and i can retrieve it, and the result is the same as the original call of Foo new. but we are talking about code versioning, so presumably, i want to version the class. i guess that would need to happen in the browser too. every time a code-change is saved, a new class object is created. that needs then to be stored in the database, along with the source code. and when browsing a class, i should get a list of historical objects, just like i can get a list of historical source versions. why would i want to version the class object? to avoid recompiling it, either to save time, or because recompiling does not guarantee that we do actually get the same result because it may be affected by the environment. (i don't know if that is an issue however) do i get that right? or are there other reasons for class object versioning, if there are any at all. > As an example, it would be very easy to make AltBrowser browse all the > MC stuff, or RB changes, in addition to the normal (RPackage/Ring) live > code structure (and hence give you access to class versions, method > versions, etc...). that is the second time someone suggests altbrowser. i am going to have to look at that...) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
Re: Stop Thinking in Terms of Files
|
|
In reply to this post by Martin Bähr
2015-12-07 8:53 GMT+01:00 Martin Bähr <[hidden email]>: Excerpts from Dimitris Chloupis's message of 2015-12-07 08:24:13 +0100: They are there: I implemented and demoed what you describe as a need over git a few years ago when I started GitFileTree [1]. Then, probably over more than a year ago, Dale Henrich implemented a lot more in his environment (tode). Now, what we may conclude is that the need may not be that great. Regards, Thierry |
|
|
In reply to this post by kilon.alios
On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> > 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. |
|
|
In reply to this post by marten
I don't understand people today. They seem so brittle and inflexible, unwilling to open their minds and learn.
When I was fresh out of university, my only programming experience was with FORTRAN on mainframes. My first job was on the newest technology of the day: DEC PDP-11. Subsequently, I had jobs working on Tandem NonStop computers (GUARDIAN OS and TAL programming language), Modcomp systems and their assembler, Unix and C, VAX and DCL, AS/400, Windows, Smalltalk and Seaside, Python and web2py, Java and Android, Objective-C and iOS, etc. Each and every job was an exciting, stimulating learning opportunity. It was **fun** diving into unexplored territory. These various environments were quite different from one another. But I had no trouble adapting. The various programming languages had *substantially* different syntaxes. But I wasn't bothered. It took little time for me to get comfortable with each new language. So why is Smalltalk giving people conniptions? Are they really so spoiled? Re: today's IDEs (Eclipse, IntelliJ, Visual Studio, etc.). The problem isn't that they are so resource-hungry. It's that they're so damn complex. The file-based underpinnings, the "plumbing" if you will, is what have caused the design of these tools to evolve into complex behemoths. When you start with a clean slate, you can design a clean, elegant IDE without compromise. And that's what we have in Pharo.
|
Re: Stop Thinking in Terms of Files
|
|
In reply to this post by Ben Coman
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 <[hidden email]> wrote: On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis <[hidden email]> wrote: |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |