Can someone read Smalltalk?

[vlad777]

Can you please transcribe what is on the lower right corner on this picture.

I can read what is on the left because it is Pascal , but I can't read low res Smalltalk.

This is from a video on YouTube.
All this is something about using the advantages of collections (although the video goes on about oo design(?) )

Many thanks.

[NivagSwerdna]

create a new bag f.  iterates over string, checks it is a letter, adds 1 to element that is of that character. then prints the bag.

Try scala instead.

 

[tggzzz]

create a new bag f.  iterates over string, checks it is a letter, adds 1 to element that is of that character. then prints the bag.

Try scala instead.

 

Not quite. It iterates over the String. If a character is a letter, it adds the lowercase version of the character to the Bag. The Bag is returned.

Code: [Select]

s := Prompter prompt: 'enter line' default: ' '.
f := Bag new.
s do: [:C| c isLetter ifTrue: [f add: c asLowerCase] ].
^f
It is amazing how Smalltalk is an improvement over most of its successors

[Kalvin]

All three implementation are quite long compared to APL or J. 

[vlad777]

What do the bars on top mean (if they are bars/pipes) ?

[tggzzz]

What do the bars on top mean (if they are bars/pipes) ?

If you mean |s f| then that is simply stating s and f are variables.

You would highlight/select a block of text (e.g. |s ... ^f), click, select "execute", which causes the selected text to be compiled, executed, and the result  (f in this case) shown in an object browser.

If that sounds like what happens in IDEs, you would be right: they all took their inspiration from Smalltalk. As did the entire Sun and Macintosh GUIs, of course.

Smalltalk also invented the "refactoring browser" - but that was relatively recently in the early 90s.

[vlad777]

I'll put your code in a comment bellow the video.

[helius]

What do the bars on top mean (if they are bars/pipes) ?

Those are local variable declarations.
Smalltalk can be confusing out of context, because the source code is not stored in files. It is entered directly into a code browser, for instance, as the implementation of an instance method. So in the screenshot, the name that would be used to call the code is not shown (since it is in the list of the code browser, see below). The Pascal version, by contrast, includes its name: "Program frequency;" You can also execute snippets directly in a text editor, but that doesn't save them for use in other programs.

[tggzzz]

You can play with Smalltalk in your (web)browser at https://squeak.js.org/demo/simple.html There isn't a object "Prompter", so the first code line should be

Code: [Select]

s:='Hello world 123 bye'.
You will find the required mouse actions a little unusual by today's standards. Usability (and familiarity) has improved, but in the early 80s all the concepts were revolutionary. And I don't use the word "revolutionary" lightly.

Now, back to playing with Apple's Smalltalk implementation for the 1MB Fat Mac... Gawd it is sloooooow.

[vlad777]

I can't read that font , it's terrible

[tggzzz]

Don't forget that when that was first used, it was on a 640*480 screen, and most people has access to fonts that were named after the X*Y resolution, e.g. 5*7, and were whatever the glass TTY manufacturer gave you.

That serif font was a revelation, and others are available if you use the menus. Deal with it, and be grateful to the pioneers 😀

[cncjerry]

I was looking for a smalltalk compiler a while back and maybe someone can recommend one?

I've played around with some of the scheme implementations like Pixie Scheme, ISkeme and Ischeme on the ipad.  They seemed very limited.  For goal seeking programs I generally still use Prolog which goes way, way back.  I just used it on the parallel resistor thread last week or so.  I wanted to try smalltalk again, we had a language like it at IBM years ago and actually I can't remember which came first, it might have been a precursor to smalltalk, can't remember.

[tggzzz]

I was looking for a smalltalk compiler a while back and maybe someone can recommend one?

I've played around with some of the scheme implementations like Pixie Scheme, ISkeme and Ischeme on the ipad.  They seemed very limited.  For goal seeking programs I generally still use Prolog which goes way, way back.  I just used it on the parallel resistor thread last week or so.  I wanted to try smalltalk again, we had a language like it at IBM years ago and actually I can't remember which came first, it might have been a precursor to smalltalk, can't remember.

I doubt it was a precursor to Smalltalk. The first Smalltalk was Smalltalk-72 used inside Xerox PARC; the first widely released one was Smalltalk-80, and widely publicised in the August 1981 Byte magazine with Tinney's famous balloon cover. Apple's Smalltalk was released in 1985.

ISTR there is/was a GNU Smalltalk compiler, but any Smalltalk compiler would be useless; you want a Smalltalk image plus virtual machine. There are many around, and I haven't looked recently to see what's available. If you only want to play around, it isn't going to matter which you choose; if you want to do more then my info is too out of date to be of help.

[nfmax]

You can even try running Smalltalk on a simulated Xerox Alto, using the Contralto simulator: http://www.livingcomputers.org/Discover/News/ContrAlto-A-Xerox-Alto-Emulator.aspx.

[helius]

I was looking for a smalltalk compiler a while back and maybe someone can recommend one?

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk
http://pharo.org

we had a language like it at IBM years ago and actually I can't remember which came first, it might have been a precursor to smalltalk, can't remember.

IBM VisualAge was released in 1995, a little bit later than Smalltalk (originally designed in 1972, and later redesigned in 1980 to be released outside Xerox).

[gmarentette]

IBM also sold VisualAge Java which was developed using VisualAge Smalltalk and had an integrated development environment much like VisualAge Smalltalk. It was great for Smalltalk developers like me transitioning to Java, but I guess there weren't enough of us because they killed it after just a few years.

[cncjerry]

this was long before VisualAge.  It was based on PL/S or PL/1, again, I can't remember which one of those that came first either, probably PL/1 which was Programming Language One.  It was used for the OS on the System/3 variants like the 32 and 34. It wasn't much above Assembler. I remember reading microfiche for debugging.  Then Smalltalk showed up in like 79 or 80, (at IBM) I know it was prior to when I worked on the PC before it came out. I am probably thinking of something else because I then worked with with VMProlog, which is a language I still use, and a LISP interpreter.  I always thought that Smalltalk would be the next and only thing.

[technix]

create a new bag f.  iterates over string, checks it is a letter, adds 1 to element that is of that character. then prints the bag.

Try scala instead.

 

Not quite. It iterates over the String. If a character is a letter, it adds the lowercase version of the character to the Bag. The Bag is returned.

Code: [Select]

s := Prompter prompt: 'enter line' default: ' '.
f := Bag new.
s do: [:C| c isLetter ifTrue: [f add: c asLowerCase] ].
^f
It is amazing how Smalltalk is an improvement over most of its successors

How about Objective-C with Swift extensions?

Code: [Select]

NSDictionary<NSNumber *, NSNumber *> *count(NSString *string)
{
    NSMutableDictionary<NSNumber *, NSNumber *> *counter = [NSMutableDictionary dictionary];
    for (NSUInteger idx = 0; idx < string.length; idx++)
    {
        unichar ch = [string characterAtIndex:idx];
        if (!isalpha(ch)) continue;
        counter[@(ch)] = @(counter[@(ch)].integerValue + 1);
    }
    return counter.copy;
}

[tggzzz]

create a new bag f.  iterates over string, checks it is a letter, adds 1 to element that is of that character. then prints the bag.

Try scala instead.

 

Not quite. It iterates over the String. If a character is a letter, it adds the lowercase version of the character to the Bag. The Bag is returned.

Code: [Select]

s := Prompter prompt: 'enter line' default: ' '.
f := Bag new.
s do: [:C| c isLetter ifTrue: [f add: c asLowerCase] ].
^f
It is amazing how Smalltalk is an improvement over most of its successors

How about Objective-C with Swift extensions?

Code: [Select]

NSDictionary<NSNumber *, NSNumber *> *count(NSString *string)
{
    NSMutableDictionary<NSNumber *, NSNumber *> *counter = [NSMutableDictionary dictionary];
    for (NSUInteger idx = 0; idx < string.length; idx++)
    {
        unichar ch = [string characterAtIndex:idx];
        if (!isalpha(ch)) continue;
        counter[@(ch)] = @(counter[@(ch)].integerValue + 1);
    }
    return counter.copy;
}

While I prefer Objective-C to C++, I don't have any opinion of Swift since I've never used it. I presume that if I ever intended to program for Mac machines, I would use Swift.

Remind me; does Swift have a decent garbage collector, or does it rely heavily on programming Design Patterns to reclaim memory, similar to Apple's Cocoa?

[technix]

create a new bag f.  iterates over string, checks it is a letter, adds 1 to element that is of that character. then prints the bag.

Try scala instead.

 

Not quite. It iterates over the String. If a character is a letter, it adds the lowercase version of the character to the Bag. The Bag is returned.

Code: [Select]

s := Prompter prompt: 'enter line' default: ' '.
f := Bag new.
s do: [:C| c isLetter ifTrue: [f add: c asLowerCase] ].
^f
It is amazing how Smalltalk is an improvement over most of its successors

How about Objective-C with Swift extensions?

Code: [Select]

NSDictionary<NSNumber *, NSNumber *> *count(NSString *string)
{
    NSMutableDictionary<NSNumber *, NSNumber *> *counter = [NSMutableDictionary dictionary];
    for (NSUInteger idx = 0; idx < string.length; idx++)
    {
        unichar ch = [string characterAtIndex:idx];
        if (!isalpha(ch)) continue;
        counter[@(ch)] = @(counter[@(ch)].integerValue + 1);
    }
    return counter.copy;
}

While I prefer Objective-C to C++, I don't have any opinion of Swift since I've never used it. I presume that if I ever intended to program for Mac machines, I would use Swift.

Remind me; does Swift have a decent garbage collector, or does it rely heavily on programming Design Patterns to reclaim memory, similar to Apple's Cocoa?

Apple tried to play with a garbage collector but killed it in Mountain Lion (and never brought it to iOS.) Now they use the design pattern combined with compile-time static code analysis to do most of the memory management. The LLVM/clang compiler, when called with -fobjc-arc, will use static code analysis based on the design patterns to insert calls to objc_retain and objc_release for you. You still program as if there is a garbage collector, but the resulting code is somehow the same as old style manual memory management.

[tggzzz]

create a new bag f.  iterates over string, checks it is a letter, adds 1 to element that is of that character. then prints the bag.

Try scala instead.

 

Not quite. It iterates over the String. If a character is a letter, it adds the lowercase version of the character to the Bag. The Bag is returned.

Code: [Select]

s := Prompter prompt: 'enter line' default: ' '.
f := Bag new.
s do: [:C| c isLetter ifTrue: [f add: c asLowerCase] ].
^f
It is amazing how Smalltalk is an improvement over most of its successors

How about Objective-C with Swift extensions?

Code: [Select]

NSDictionary<NSNumber *, NSNumber *> *count(NSString *string)
{
    NSMutableDictionary<NSNumber *, NSNumber *> *counter = [NSMutableDictionary dictionary];
    for (NSUInteger idx = 0; idx < string.length; idx++)
    {
        unichar ch = [string characterAtIndex:idx];
        if (!isalpha(ch)) continue;
        counter[@(ch)] = @(counter[@(ch)].integerValue + 1);
    }
    return counter.copy;
}

While I prefer Objective-C to C++, I don't have any opinion of Swift since I've never used it. I presume that if I ever intended to program for Mac machines, I would use Swift.

Remind me; does Swift have a decent garbage collector, or does it rely heavily on programming Design Patterns to reclaim memory, similar to Apple's Cocoa?

Apple tried to play with a garbage collector but killed it in Mountain Lion (and never brought it to iOS.) Now they use the design pattern combined with compile-time static code analysis to do most of the memory management. The LLVM/clang compiler, when called with -fobjc-arc, will use static code analysis based on the design patterns to insert calls to objc_retain and objc_release for you. You still program as if there is a garbage collector, but the resulting code is somehow the same as old style manual memory management.

That confirms my recollection. Another example where Smalltalk is an improvement on its successors.

[technix]

create a new bag f.  iterates over string, checks it is a letter, adds 1 to element that is of that character. then prints the bag.

Try scala instead.

 

Not quite. It iterates over the String. If a character is a letter, it adds the lowercase version of the character to the Bag. The Bag is returned.

Code: [Select]

s := Prompter prompt: 'enter line' default: ' '.
f := Bag new.
s do: [:C| c isLetter ifTrue: [f add: c asLowerCase] ].
^f
It is amazing how Smalltalk is an improvement over most of its successors

How about Objective-C with Swift extensions?

Code: [Select]

NSDictionary<NSNumber *, NSNumber *> *count(NSString *string)
{
    NSMutableDictionary<NSNumber *, NSNumber *> *counter = [NSMutableDictionary dictionary];
    for (NSUInteger idx = 0; idx < string.length; idx++)
    {
        unichar ch = [string characterAtIndex:idx];
        if (!isalpha(ch)) continue;
        counter[@(ch)] = @(counter[@(ch)].integerValue + 1);
    }
    return counter.copy;
}

While I prefer Objective-C to C++, I don't have any opinion of Swift since I've never used it. I presume that if I ever intended to program for Mac machines, I would use Swift.

Remind me; does Swift have a decent garbage collector, or does it rely heavily on programming Design Patterns to reclaim memory, similar to Apple's Cocoa?

Apple tried to play with a garbage collector but killed it in Mountain Lion (and never brought it to iOS.) Now they use the design pattern combined with compile-time static code analysis to do most of the memory management. The LLVM/clang compiler, when called with -fobjc-arc, will use static code analysis based on the design patterns to insert calls to objc_retain and objc_release for you. You still program as if there is a garbage collector, but the resulting code is somehow the same as old style manual memory management.

That confirms my recollection. Another example where Smalltalk is an improvement on its successors.

Actually to my best knowledge this compile-time static code analysis based approach to memory management is better than any garbage collector. Garbage collectors' behavior can be chaotic based on implementation. This "automatic reference counting" static code analysis method is actually deterministic and you know exactly when, where and how memory management is going to happen. Also you can optionally switch it off for certain parts of the code to optimize the heck out of it.

[tggzzz]

create a new bag f.  iterates over string, checks it is a letter, adds 1 to element that is of that character. then prints the bag.

Try scala instead.

 

Not quite. It iterates over the String. If a character is a letter, it adds the lowercase version of the character to the Bag. The Bag is returned.

Code: [Select]

s := Prompter prompt: 'enter line' default: ' '.
f := Bag new.
s do: [:C| c isLetter ifTrue: [f add: c asLowerCase] ].
^f
It is amazing how Smalltalk is an improvement over most of its successors

How about Objective-C with Swift extensions?

Code: [Select]

NSDictionary<NSNumber *, NSNumber *> *count(NSString *string)
{
    NSMutableDictionary<NSNumber *, NSNumber *> *counter = [NSMutableDictionary dictionary];
    for (NSUInteger idx = 0; idx < string.length; idx++)
    {
        unichar ch = [string characterAtIndex:idx];
        if (!isalpha(ch)) continue;
        counter[@(ch)] = @(counter[@(ch)].integerValue + 1);
    }
    return counter.copy;
}

While I prefer Objective-C to C++, I don't have any opinion of Swift since I've never used it. I presume that if I ever intended to program for Mac machines, I would use Swift.

Remind me; does Swift have a decent garbage collector, or does it rely heavily on programming Design Patterns to reclaim memory, similar to Apple's Cocoa?

Apple tried to play with a garbage collector but killed it in Mountain Lion (and never brought it to iOS.) Now they use the design pattern combined with compile-time static code analysis to do most of the memory management. The LLVM/clang compiler, when called with -fobjc-arc, will use static code analysis based on the design patterns to insert calls to objc_retain and objc_release for you. You still program as if there is a garbage collector, but the resulting code is somehow the same as old style manual memory management.

That confirms my recollection. Another example where Smalltalk is an improvement on its successors.

Actually to my best knowledge this compile-time static code analysis based approach to memory management is better than any garbage collector. Garbage collectors' behavior can be chaotic based on implementation. This "automatic reference counting" static code analysis method is actually deterministic and you know exactly when, where and how memory management is going to happen. Also you can optionally switch it off for certain parts of the code to optimize the heck out of it.

If you can do static compile-time analysis then, by definition, you neither have nor need a garbage collector.

The C-based garbage collectors (e.g. Hans Boehm) get it almost right, most of the time - but have to let the heap silt up because they are conservative. Fundamentally they are guaranteed to be a boneheaded heroic failure, a castle built on sand.

[technix]

If you can do static compile-time analysis then, by definition, you neither have nor need a garbage collector.

The C-based garbage collectors (e.g. Hans Boehm) get it almost right, most of the time - but have to let the heap silt up because they are conservative. Fundamentally they are guaranteed to be a boneheaded heroic failure, a castle built on sand.

Now how does Smalltalk perform garbage collection then? So far all modern Smalltalk implementations I have seen borrows the static analysis memory management from Objective-C. (Folks call Objective-C a simple union of Smalltalk and C for a reason)

[tggzzz]

If you can do static compile-time analysis then, by definition, you neither have nor need a garbage collector.

The C-based garbage collectors (e.g. Hans Boehm) get it almost right, most of the time - but have to let the heap silt up because they are conservative. Fundamentally they are guaranteed to be a boneheaded heroic failure, a castle built on sand.

Now how does Smalltalk perform garbage collection then? So far all modern Smalltalk implementations I have seen borrows the static analysis memory management from Objective-C.

I very much doubt that, except possibly w.r.t. objects in an "eden space" that haven't yet become "tenured"! There are many many many GCs, and I don't know which are used in different implementations. There has been continual research and refinement over the past 35 years, but quite frankly the best are now found in Java. Henry Baker made many advances, so did L Peter Deutsch.

(Folks call Objective-C a simple union of Smalltalk and C for a reason)

Indeed. But GC isn't part of the reason!