Smalltalk

[CD]

I doubt this is the correct group to post this in, but since I couldn't find
a better place, here goes.

Smalltalk is a very mature, highly portable pure object language. From my
view of it, it lacks the development and marketing support that a company
like Microsoft can supply.

Why hasn't Microsoft looked at Smalltalk products like Visualworks and
considered taking them over? I know that this language has a huge potential
given a company that can really bring it to market.

Thanks

[Frank Lesser [LSW]]

Hi,

I shall try to give a more technical answer:

there are two big language groups
Algol ( to which Microsoft's languages C, C++, C# belong )
Lisp ( to which I would sort Smalltalk )

programs in Algol languages **desribe** (object models) where Lisp like languages are used to modify object-models.
In Algol like languages you have to compile and run your program, in Lisp like languages you just modify classes & methods ( they
are first class objects ) themselves.

Algol like languages are traditionally used to implement Operating-Systems where Microsoft come from.

Lisp like languages can be viewed as (Operating)Systems themselves.
They require a Virtual-Machine and it is difficult to compile them down to machine-code.
This makes Lisp like languages less performant than their Algol like competitors.
And it is more difficult to interface with an Operating-System. OS-Functions require recursive callback.
So early Smalltalk Language implementations ignored the part of OS ( GUI widgets ) which requires requires Callbacks or emulated
them - which was ok in the early days of Windows.

Smalltalk lost its premier position when Java appeared.
Microsoft has invited some well known Smalltalkers to participate on the design of the CLR (e.g. a known Virtual-Machine engineer
from Parcplace-Digitalk and the creator of Smallscript )
But creating a Smalltalk on top of the CLR is a very difficult task ( I know what I say because we do it since several years now )

I like that Smalltalk and it has created a nice market niche for small firms. I am personally afraid of the idea that Microsoft gets
hands on it.
We have created a Tool for .NET ( LSW DotNet-Lab ) which is written in Smalltalk and will bring some features of a
Smalltalk-Development Environment to .NET.

with best regards, Frank Lessser, www.lesser-software.com

[CD]

Frank,
I am not, nor have I ever professed to be, anything other than a business
app developer. Nor am I am scholar on languages.

With that in mind, I've found Smalltalk to be extremely productive for the
applications I develop (complex derivative trading systems). In fact, given
the opportunity, I would choose the language again. My systems deal with
complexity and can be modified very quickly, due to the nature of the
language and the development tools.
The problems I have with the language stem from it not being a high-profile
language and the fact that I do not think the language have enough vendor
support. Meaning they do not have the resources behind them to clean up some
of the aspects of the environment that have become old, namely the GUI. I
would not expect Microsoft to use it in OS developemnt, as I would not expect
VB to be used in OS code. I am just hoping that a vendor with some resources
would jump in and build it up. It really is a nice language. I've worked in
the development area for 20+ years now.

As for Java, I cannot comment directly on it since I have not used it a lot.
From what I understand, some of it derives from Smalltalk. I also understand
that it still has a lot of maturing to do.

I am not afraid of a Microsoft takover, because the language needs a boost.

Regards,
Chip

[Frank Lesser [LSW]]

Chip,

The problem which Smalltalk has to fight with is exactly the GUI and the lack of integration with the Windows-OS.
I agree with you that Smalltalk is extremely productive - I also used it for more than 20 years now - just that every change is
immediatley visible the powerful debugging features
all that I don't want to miss - But when you have to interface with other components - to integrate with modern GUI you start to
loose all the advantages.
We had to create our own implementation to overcome the GUI and other problems.

What Smalltalk had from the very beginning ( e.g. change code while debugging is right now introduced in a very limited way compared
to Smalltalk as Edit-and-Continue in .NET language environments )
For Windows Desktop Development I would regard to today only Dolphin and Smalltalk-MT as possible environments. Both implementations
are from small firms. VW is still using emulated widgets - Pollock and Chagall ( Native Widgets ) are in development - Cincom is not
a small firm. Smallscript as a Smalltalk superset with integration into Visual-Studio will be the .NET Smalltalk ( but with the loss
of everything is an object feature ). VMX Smalltalk is a nice Interpreter on top of the CLR ( loss of performance )

[Moe Green]

Bill Gates on smalltalk:

From the back of an old Digitalk Smalltalk/V PM manual, 1990:
"This is the right way to develop applications for OS/2 PM. OS/2 PM
is a tremendously rich environment, which makes it inherently complex.
Smalltalk/V PM removes that complexity and lets you concentrate on
writing great programs. Smalltalk/V PM is the kind of tool that will
make OS/2 the successor to MS/DOS".

http://www.quotesandsayings.com/gbillgates.htm
Frank Lesser [LSW] wrote:

Chip,

The problem which Smalltalk has to fight with is exactly the GUI and the lack of integration with the Windows-OS.
I agree with you that Smalltalk is extremely productive - I also used it for more than 20 years now - just that every change is
immediatley visible the powerful debugging features
all that I don't want to miss - But when you have to interface with other components - to integrate with modern GUI you start to
loose all the advantages.
We had to create our own implementation to overcome the GUI and other problems.

What Smalltalk had from the very beginning ( e.g. change code while debugging is right now introduced in a very limited way compared
to Smalltalk as Edit-and-Continue in .NET language environments )
For Windows Desktop Development I would regard to today only Dolphin and Smalltalk-MT as possible environments. Both implementations
are from small firms. VW is still using emulated widgets - Pollock and Chagall ( Native Widgets ) are in development - Cincom is not
a small firm. Smallscript as a Smalltalk superset with integration into Visual-Studio will be the .NET Smalltalk ( but with the loss
of everything is an object feature ). VMX Smalltalk is a nice Interpreter on top of the CLR ( loss of performance )
.
With appearance of .NET the Situation of Smalltalk became even worse. Because Smalltalk is based on its own Virtual-Machine and JIT
which is incompatible with
.NET it is almost impossible to transport Smalltalk to .NET CLR without loosing performance and/or its basic features.
For our ( Win32 based ) Smalltalk we have choosen to create an interface to.NET. ( Smalltalk primitives can invoke .NET methods ) -
Also our pure .NET implementation does not integrate with the .NET object model and it uses its own JIT technology.

I guess that I need not to be afraid - Microsoft's CLR and Smalltalk are so incompatible today that MS will not take hands on that
language.
However they will take more and more features ( e.g. Object-Browser / Refactoring ) which have their origins in Smalltalk and add
them to their development environments.

Frank

[CD]

Moe,
You'd think Bill would have jumped right on that wouldn't you? What's the
deal Bill?

Frank,
I'm with you on what you are saying. I've been bitching at Cincom for years
to fix the GUI. They've implemented some nice stuff, but unfortunately, it is
the GUI that gives the first impression and that kills things from the start.
I've been working closely with an engineer there and from what I gather,
Cincom is squeezing everything out of these guys that they can. Although I do
not have a count, I do not think that the number of real developers there are
many.

I'm starting to teach myself C# now, as a hedge in the job market, but I
find it hard to concentrate on the application logic without some of the
tools and features of Smalltalk. I've gotten so used to just placing a halt
in an empty method and coding "on the fly" while running. The whole build and
run thing is hard to go back to. Also, I can't remember the last time I lost
code because of an exception, or even a crash of a machine. The
transactioning of code in VW blows people away when I show them. I've gotten
very used to "dumping" my image in order to back out of changes and just
reapplying the change log up to a specific point. I'n not familiar with
recent releases of Visual SourceSafe, but I doubt that it approaches the
functionality of the Store repository. I could go on and on about stuff like
the TimeProfiler and Refactory Browser.

It's a real shame to see a language like this just standing on the sideline.

Chip

"Moe Green" wrote:

Bill Gates on smalltalk:

From the back of an old Digitalk Smalltalk/V PM manual, 1990:
"This is the right way to develop applications for OS/2 PM. OS/2 PM
is a tremendously rich environment, which makes it inherently complex.
Smalltalk/V PM removes that complexity and lets you concentrate on
writing great programs. Smalltalk/V PM is the kind of tool that will
make OS/2 the successor to MS/DOS".

http://www.quotesandsayings.com/gbillgates.htm
Frank Lesser [LSW] wrote:

Chip,

The problem which Smalltalk has to fight with is exactly the GUI and the lack of integration with the Windows-OS.
I agree with you that Smalltalk is extremely productive - I also used it for more than 20 years now - just that every change is
immediatley visible the powerful debugging features
all that I don't want to miss - But when you have to interface with other components - to integrate with modern GUI you start to
loose all the advantages.
We had to create our own implementation to overcome the GUI and other problems.

What Smalltalk had from the very beginning ( e.g. change code while debugging is right now introduced in a very limited way compared
to Smalltalk as Edit-and-Continue in .NET language environments )
For Windows Desktop Development I would regard to today only Dolphin and Smalltalk-MT as possible environments. Both implementations
are from small firms. VW is still using emulated widgets - Pollock and Chagall ( Native Widgets ) are in development - Cincom is not
a small firm. Smallscript as a Smalltalk superset with integration into Visual-Studio will be the .NET Smalltalk ( but with the loss
of everything is an object feature ). VMX Smalltalk is a nice Interpreter on top of the CLR ( loss of performance )
.
With appearance of .NET the Situation of Smalltalk became even worse. Because Smalltalk is based on its own Virtual-Machine and JIT
which is incompatible with
.NET it is almost impossible to transport Smalltalk to .NET CLR without loosing performance and/or its basic features.
For our ( Win32 based ) Smalltalk we have choosen to create an interface to.NET. ( Smalltalk primitives can invoke .NET methods ) -
Also our pure .NET implementation does not integrate with the .NET object model and it uses its own JIT technology.

I guess that I need not to be afraid - Microsoft's CLR and Smalltalk are so incompatible today that MS will not take hands on that
language.
However they will take more and more features ( e.g. Object-Browser / Refactoring ) which have their origins in Smalltalk and add
them to their development environments.

Frank

[Frank Lesser [LSW]]

"Moe Green" <mo*@vegas.west> wrote in message news:33*************@individual.net...

Bill Gates on smalltalk:

From the back of an old Digitalk Smalltalk/V PM manual, 1990:
"This is the right way to develop applications for OS/2 PM. OS/2 PM
is a tremendously rich environment, which makes it inherently complex.
Smalltalk/V PM removes that complexity and lets you concentrate on
writing great programs. Smalltalk/V PM is the kind of tool that will
make OS/2 the successor to MS/DOS".

http://www.quotesandsayings.com/gbillgates.htm

unfortunatley Smalltalk/V died.
Smalltalk/V and its successor Visual-Smalltalk ( VSE ) were long time ago the best development tool available under Desktop OS'es.

again a technical answer on the problems of V/Win32 VSE.
Due to the lack of outer Callback support ( Recursive Callbacks could not be debugged ) a hack was introduced
( whenValidPerform: ) - Dolphin has solved this problem at the VM-Level ( Recursive Callbacks can be debugged ).
Smalltalk/V / VSE used some very unusual way of handling certain WM_ messages due to the Outer Callback-Problem.

This made the language incompatible and further problems apeared due to the "wrong" handling of OS-Events.
This was the technical dead of Smalltalk/V / VSE.
VSE COM / OLE support framework is huge but still inomplete ( no full Unicode support ) and imperformant.
The Prototyping environment and Visual-Programming PARTS was not accepted by the Smalltalk Community.
Big efforts where made to create a Java Development environment ( PARTS for Java 1999 ) which was implemented in VSE using a socket
connection to JVM.
It was imperformant and could only be used with JDK 1.0
Most Smalltalk's are not fully Unicode capable.

[Frank Lesser [LSW]]

Chip,

regarding the framework development it IMHO it doesn't count whether you have a big or small development team.
Ours is small - it is important that you make the right decisions at the very beginning.
Just a decision would be -
(1) ignore Microsoft technically we support every OS - big Smalltalk Vendors went this way ( VAST uses a Motif layer to bind to the
GUI functionality which is a disaster under Windows )
(2) try to support Microsoft as good as possible ( Dolphin and ST/MT go this way - they have not made their .NET decisions public
yet )

we are also trying to support Microsoft's OSes in our Smalltalk - it is a big effort but IMHO the only way to survive with a
language implementation.

also Java has ignored the Desktop - a decision similar to the disastroes Smalltalk decision was made to ignore Windows - now Java is
weak on the desktop and strong on servers. A good luck for Java that the consumer & cellphone market is not dominated by MS.

Frank

[Joe]

CD (NNNNN NNNN) wrote:
....

I'm starting to teach myself C# now, as a hedge in the job market, but I find it hard to concentrate on the application logic without some of the tools and features of Smalltalk. I've gotten so used to just placing a halt in an empty method and coding "on the fly" while running. The whole build and run thing is hard to go back to. Also, I can't remember the last time

I lost

I'm an old Smalltalk guy myself, but working in C# doesn't have to be
that bad.

In Smalltalk I used to do a lot of unit testing in the transcript. In
..Net a unit test program takes the place of the transcript (for me at
least). I use the one called NUnit, available at SourceForge. What you
do is write small snippets of test code, which NUnit will keep
organized and run for you on demand.

Use Visual Studio to attach to an NUnit process containing the code you
want to debug. Set a breakpoint in your code. In NUnit, run the method
you want to debug. The debugger pops up when you hit the code in NUnit.
Make any desired modifications. Rebuild the assembly in Visual Studio.
Pop the NUnit window back to the front. The run button will be disabled
until the project finishes rebuilding at which point NUnit
automatically reloads the assembly you recompiled. The whole process
only takes maybe 15 seconds for perform a complete test,edit,compile
round trip. Note that you don't have to reattach to the process being
debugged. Been doing it for 3 years now.

Now for web pages and the like I usually just attach directly to those
using Vistual Studio. But for back-end code I always debug using NUnit.

As far as stability, for me Visual Studio rarely crashes. There are a
couple of things to avoid,though. For instance, if I inspect too many
SqlDateTimes, VS will lose its marbles after a few minutes. I've
learned dump such stuff out to the console when I want to take a look
at it. I pray this glitch is fixed with this year's release.

I will agree with you that SourceSafe stinks, but it does the job
(barely). I often find myself wistfully daydreaming about how much
easier life was with Team/V or Envy.
It ain't Smalltalk but it ain't that bad.