5 ms·

What you mean is, why can't you take everything that makes Smalltalk great away, and make it work like every other file based language. The answer is, because

What you mean is, why can't you take everything that makes Smalltalk great away, and make it work like every other file based language. The answer is, because then it would suck.

flavio81 9y ago
>like every other file based language As I mentioned above, Smalltalk is also file-based; when you distribute a smalltalk program source, you distribute a set of source text files. Just like any other typical programming language.
- gnaritas 9y ago
  I'm a Smalltalk'er, and that's completely disingenuous and frankly intellectually dishonest. What Smalltalk does is not remotely what you do in other languages and when we say file based we're referring to that difference, file oriented programming vs image oriented programming. A Smalltalk program is not a collection of files one works with, it doesn't fit into the standard file based workflow, you cannot without jumping through many hoops, work on a Smalltalk program from your standard editor using your standard unix tools and file based workflow. So when we say file based, it's this we're referring to, do not lie to people and claim Smalltalk is file based, it is not. Smalltalk is image based, you work with its dev tools on a running object model in an image; having the option to export that to a file after the fact is not remotely the same as being file based; that the image stores source code in a changes file, or that we share code between each other with st exports does not a file based language make. St files by the way are a serialization format, they are not meant to be hand editable and are not treated as such and contain all kinds of non-Smalltalk stuff related to the serialization format; we don't edit st files and compile them, we edit in the image and import/export st files to share code between images.
  - flavio81 9y ago
    The IDE keeps the text files, and that's what your source code is made of. Go to any Smalltalk github project and you will find .st files, which are plain text files, and there's your code. I'm a Lisper, i do know what Image-based development is, because that's what I use* You're misunderstanding Smalltalk, probably because of hype mongers like the author of this article. Source is text files as usual. This is not the same as the image. Your environment, and the compiled classes, are contained in the image, but the IDE also keeps the source, text files. >St files by the way are a serialization format, they are not meant to be hand editable and are not treated as such and contain all kinds .st __source__ files are text files. You are confusing them with the image files.
    - gnaritas 9y ago
      No I'm not misunderstanding Smalltalk, that Smalltalk now has a git plugin to be able to expose itself in that manner is exactly the kind of jumping through hoops I was referring to, it's taken many years for that to become stable and most of us still don't use it, we use Monticello. And both of those are for sharing code, not for developing, we don't work on those st files, we export them. Don't tell me what I'm thinking and because of who, I make my living with Smalltalk (Squeak and now Pharo) and have for well over a decade and have done hundreds of millions in revenue through my Smalltalk apps. > .st source files are text files. I didn't say they weren't, they're still a plain text serialization format that is not directly what Smalltalk looks like and we still don't work on code by editing those files. > You are confusing them with the image files. No I'm not, if you actually read what I wrote, you'd see that. Lisp is not Smalltalk, do not confuse how Lisp does image based development with how Smalltalk does it; they are not the same. When you have a few years experience actually working with Smalltalk doing production level stuff, then come talk to me, right now you're repeating nonsense that you're inferring based on apparently some light reading and no actual experience in the culture of and use of an actual Smalltalk.
      - deleted 9y ago
        [deleted]
      - flavio81 9y ago
        Smalltalk's image file(s) contain only the compiled code, not the original source code, which is on the changes and source files. You could decompile the image and get most of the source but not in its original, complete form. If your image crashes it gets reconstructed from those two files. It would be great if you Smalltalk fans would explain its source handling in these terms above, instead of promoting "image based" as some sort of magic where there aren't any text files, because in this forum some programmers are getting (needlessly) scared about the image-based system and (needlessly) fearing it.
        igouy 9y ago
        Correct - and the only time someone would directly interact with the .changes or .sources text files (as-text-files without using the IDE), is in the unlikely event that the image file had become corrupted in some way, and they were trying to recover work that had been done. The .changes and .sources text files are maintained in-the-background by the IDE and kept in-sync with the image file.

What you mean is, why can't you take everything that makes Smalltalk great away, and make it work like every other file based language. The answer is, because then it would suck.

flavio81 9y ago

>like every other file based language As I mentioned above, Smalltalk is also file-based; when you distribute a smalltalk program source, you distribute a set of source text files. Just like any other typical programming language.

gnaritas 9y ago
I'm a Smalltalk'er, and that's completely disingenuous and frankly intellectually dishonest. What Smalltalk does is not remotely what you do in other languages and when we say file based we're referring to that difference, file oriented programming vs image oriented programming. A Smalltalk program is not a collection of files one works with, it doesn't fit into the standard file based workflow, you cannot without jumping through many hoops, work on a Smalltalk program from your standard editor using your standard unix tools and file based workflow. So when we say file based, it's this we're referring to, do not lie to people and claim Smalltalk is file based, it is not. Smalltalk is image based, you work with its dev tools on a running object model in an image; having the option to export that to a file after the fact is not remotely the same as being file based; that the image stores source code in a changes file, or that we share code between each other with st exports does not a file based language make. St files by the way are a serialization format, they are not meant to be hand editable and are not treated as such and contain all kinds of non-Smalltalk stuff related to the serialization format; we don't edit st files and compile them, we edit in the image and import/export st files to share code between images.
- flavio81 9y ago
  The IDE keeps the text files, and that's what your source code is made of. Go to any Smalltalk github project and you will find .st files, which are plain text files, and there's your code. I'm a Lisper, i do know what Image-based development is, because that's what I use* You're misunderstanding Smalltalk, probably because of hype mongers like the author of this article. Source is text files as usual. This is not the same as the image. Your environment, and the compiled classes, are contained in the image, but the IDE also keeps the source, text files. >St files by the way are a serialization format, they are not meant to be hand editable and are not treated as such and contain all kinds .st __source__ files are text files. You are confusing them with the image files.
  - gnaritas 9y ago
    No I'm not misunderstanding Smalltalk, that Smalltalk now has a git plugin to be able to expose itself in that manner is exactly the kind of jumping through hoops I was referring to, it's taken many years for that to become stable and most of us still don't use it, we use Monticello. And both of those are for sharing code, not for developing, we don't work on those st files, we export them. Don't tell me what I'm thinking and because of who, I make my living with Smalltalk (Squeak and now Pharo) and have for well over a decade and have done hundreds of millions in revenue through my Smalltalk apps. > .st source files are text files. I didn't say they weren't, they're still a plain text serialization format that is not directly what Smalltalk looks like and we still don't work on code by editing those files. > You are confusing them with the image files. No I'm not, if you actually read what I wrote, you'd see that. Lisp is not Smalltalk, do not confuse how Lisp does image based development with how Smalltalk does it; they are not the same. When you have a few years experience actually working with Smalltalk doing production level stuff, then come talk to me, right now you're repeating nonsense that you're inferring based on apparently some light reading and no actual experience in the culture of and use of an actual Smalltalk.
    - deleted 9y ago
      [deleted]
    - flavio81 9y ago
      Smalltalk's image file(s) contain only the compiled code, not the original source code, which is on the changes and source files. You could decompile the image and get most of the source but not in its original, complete form. If your image crashes it gets reconstructed from those two files. It would be great if you Smalltalk fans would explain its source handling in these terms above, instead of promoting "image based" as some sort of magic where there aren't any text files, because in this forum some programmers are getting (needlessly) scared about the image-based system and (needlessly) fearing it.
      - igouy 9y ago
        Correct - and the only time someone would directly interact with the .changes or .sources text files (as-text-files without using the IDE), is in the unlikely event that the image file had become corrupted in some way, and they were trying to recover work that had been done. The .changes and .sources text files are maintained in-the-background by the IDE and kept in-sync with the image file.