Ian Bicking: the old part of his blog

Comment

>You can't easily map C or other libraries into Smalltalk

Looks like you never really looked at Smalltalk and it's flexibility.

Some examples: VisualWorks has DLLC-Connect to easily import and wrap
C functions into Smalltalk. Smalltalk MT, a windows based Smalltalk can import
any C DLL and you can call it in any Smalltalk method with Smalltalk Objects
as arguments using the WINAPI as receiver. So you can easily write:

|result|
result := 100 factorial.
(WINAPI MessageBox: NULL
with: result asString
with: 'Can you do this in another language'
with: MB_YESNO | MB_ICONHAND)

But it's alway better to encapsulate this API call in a class method (for instance
as #owner:text:title:style: method in the class MessageBox) so you can write it
more readable:

|result|
result := 100 factorial.
MessageBox owner: NULL
text: result asString
title: 'Can you do this in another language?'
style: MB_YESNO | MB_ICONHAND

The keyword message tell you what the arguments are, this is much more readable.
Or have a look at the new S#/Smallscript language. Internally it's a normal Smalltalk
which is able to support different syntax styles, so you can either write:

User32::MessageBox(NULL,'Hello','World',0)

which is more C-Style or

MessageBox
owner: NULL
text: 'Hello'
title: 'World'
style: 0

which is Smalltalk style. More C-Style in Smallscript:

stdout << 'Hello' << 'World'

or the Smalltalk way

stdout
nextPutAll: 'Hello';
nextPutAll: 'World'

You may say that the C-Style is shorter, but Smalltalk is more readable (even
to non programmers who dont know about the "<<" operator)

Since the Smalltalk language is defined in itself you are able to add
syntax suggar to any Smalltalk language out there - but typically you
dont want to mix C-like syntax with the much easier Smalltalk style ("Object
receives message"). Most ST systems hide API stuff in designated classes
to get independent from the underlying system and stay portable.

Another example:

C/C++ and Smalltalk have no "repeat until" language construct by default
(even if it can be simulated with other language constructs, there is no
repeat until keyword). The Pascal language has one.
If you want it too in Smalltalk you are able to change you Smalltalk system
just by adding a method #repeatUntil: in the block closure class.
Now you are able to write:

|count|
count := 0
[ Transcript show: count printString.
count increment ]
repeatUntil: [ count = 3 ].

You should also note that a smalltalk block ([...]) is a normal object so you
can construct and call it at runtime!

To get support for a new language construct in other languages you typically
have to change the parser/compiler or ask the vendor to do that.

Another example:
Most commercial Smalltalk systems dont support Interfaces (as Java does).
But if you need them you change the system or install the "SmallInterfaces"
package and you can work with them in Smalltalk too.

People switch from language A to B because they like a new feature in B.
They start to port all their code to language B and feel happy until
language C appears.

The main problem is that the IT continuously start to solve problems with
new languages instead of focusing on the problem they want to solve.

People will never get the power of Smalltalk if the continue to compare
it with A, B or C or lament about it's syntax.

Smalltalk is not only a language - it's language is mapped to a dynamic
object system. So if you need Interfaces, Enums, Structs, Pre-/Postconditions,
new language constructs, ... you can easily add them if you need.

If you talk about Smalltalk using an image, I can just quote Kent Beck:
"Source code in files. How quaint.".

Bye
Torsten


Comment on Where Smalltalk Went Wrong
by Torsten Bergmann