Pharo, the Modern Smalltalk

Post by dragonwriter » Wed, Oct 04, 2017, 9:46 PM UTC

spc476 wrote: post #100

shalabhc wrote: post #76

Earlier quoted context omitted.

This may not be immediately apparent, but I discovered that Smalltalk did not fit into the 'programming language' concepts in my head. I think of a typical bytecode VM language as [source code] -> [interpreter] -> [running program] Instead Smalltalk is more like [running program] + [auto persistence] + [editing tools] So you don't modify large gobs of source code files, you modify the running program from within - ak…

So, how do you distribute the program you've just written? That's the issue I have with image based languages.

Post by ScottBurson » Wed, Oct 04, 2017, 9:47 PM UTC

radiowave wrote: post #87

theamk wrote: post #38

Earlier quoted context omitted.

That image environment sounds scary to me. I used to do a lot of hardware development, and what I love most about software is that you can always restart from the clean plate (by restarting the program) and/or undo your previous work (with version control). From what I understand, none of this applies to Smalltalk. You always modify code on the fly, so you may end up with properties which exists, but no current code…

That can happen, but typically you're not keeping state around for huge periods of time (though you can if you want ), it's just a convenience while you rapidly iterate on the design of the code. Once you've got code that seems to hang together well, it's time to start thinking about what the right way to instantiate the objects, to consistently bring them to a correct state. Unit tests are useful for this, and with…

Post by igouy » Wed, Oct 04, 2017, 10:14 PM UTC

zerr wrote: post #91

otakucode wrote: post #26

Earlier quoted context omitted.

I've always found the 'image' environment to be far more interesting than the language of Smalltalk itself. If you do find just code snippets, you're missing out on what I, at least, see as the most significant feature of the whole thing. The way it goes about defining the code is clunky, but the overall structure of 'images' and the workflow involved with them is fascinating. I could easily see something similar bei…

Opposite feeling here - mutable/persistent images kept me away from Smalltalk.

Post by [deleted] » Wed, Oct 04, 2017, 10:20 PM UTC

throwaway7645 wrote: post #92

jhbadger wrote: post #33

Earlier quoted context omitted.

Lots of other languages work/worked that way. System images were a common feature of many Lisp systems and some Forth systems in the 1980s.

The image is just one reason why compiling an SBCL executable results in such a large file. It has state as well...or so I've read.

Post by gnaritas » Wed, Oct 04, 2017, 10:25 PM UTC

int_19h wrote: post #109

gnaritas wrote: post #103

Earlier quoted context omitted.

Well, I'll be that guy, I don't care what inspired Bjarne, Simula created the idea of an object, but it wasn't until Smalltalk that object orientation became a paradigm: Smalltalk created OO, not Simula. Object != Object Orientation, Simula was and is a procedural language with objects bolted on after the fact. C# is a Java clone so I need only address your Java misstatement, Java was far more influenced by Objective…

If you look at the actual semantics of classes and objects in C++ and Java, they're arguably closer to Simula than they are to Smalltalk. In C++, this is even more evident by the fact that even some of the syntax is reused, such as "virtual" (although in Simula it originally meant what we today call "abstract"). The difference between the two is that Smalltalk methods semantics are message passing . In Simula, method…