Smalltalk MT at I/ITSEC 2004

I just came back from boothing at I/ITSEC 2004 (the inter-industry training,
simulation and educations conference). This is THE event for the sim
community (especially military).

I am happy to report that Smalltalk MT was embedded in several applications
showing at the conference. Here are some examples:

1. A collaborative multi-player virtual environment showed off MTs ability
to perform fast network requirements.

2. A LIDAR analysis program showed off MTs ability to utilize DirectX 9 and
a GPU to do huge amounts of feature extraction analysis from a LIDAR image.

3. Military symbols were being shown in other vendors applications by MT.
This is using MTs ability to use SVG (scalable vector graphics) and GDI+.

So while we may not be building whole applications with MT (apart from the
development environment of course), we are demonstrating that Smalltalk can
be used for what it is very good at - MetaData representation. This content
can then be delivered in the form of a DLL or a COM component to other
applications (including other Smalltalks).

So next time you see a GIS application, or military application it may be
Smalltalk MT inside :-)

Dave Anderson
[hidden email]

On Sun, 12 Dec 2004 10:11:54 -0700, DA wrote:

> So next time you see a GIS application, or military application it may
> be Smalltalk MT inside :-)

Maybe we can ape the "Intel Inside" ads. :)

--
-- James Fenimore Cooper
The tendency of democracies is, in all things, to mediocrity, since the tastes,
knowledge, and principles of the majority form the tribunal of appeal.

On Sun, 12 Dec 2004 10:11:54 -0700, "DA" <[hidden email]> wrote:

>I just came back from boothing at I/ITSEC 2004 (the inter-industry training,
>simulation and educations conference). This is THE event for the sim
>community (especially military).
>
[snip]

>So while we may not be building whole applications with MT (apart from the
>development environment of course), we are demonstrating that Smalltalk can
>be used for what it is very good at - MetaData representation.

Could you elaborate on this? O:-)

Dave:

I believe that a computer game was recently released which employs
SmalltalkMT. Is that the case and if so what is the title for said
game.

Finally, are you now running Alienware?

thanks

Charles

DA wrote:
> I just came back from boothing at I/ITSEC 2004 (the inter-industry
training,
> simulation and educations conference). This is THE event for the sim
> community (especially military).
>
> I am happy to report that Smalltalk MT was embedded in several
applications
> showing at the conference. Here are some examples:
>
> 1. A collaborative multi-player virtual environment showed off MTs
ability
> to perform fast network requirements.
>
> 2. A LIDAR analysis program showed off MTs ability to utilize DirectX
9 and
> a GPU to do huge amounts of feature extraction analysis from a LIDAR
image.
>
> 3. Military symbols were being shown in other vendors applications by
MT.
> This is using MTs ability to use SVG (scalable vector graphics) and
GDI+.
>
> So while we may not be building whole applications with MT (apart
from the
> development environment of course), we are demonstrating that
Smalltalk can
> be used for what it is very good at - MetaData representation. This
content
> can then be delivered in the form of a DLL or a COM component to
other
> applications (including other Smalltalks).
>
> So next time you see a GIS application, or military application it
may be
> Smalltalk MT inside :-)
>
> Dave Anderson
> [hidden email]

"Aura - Fate of the Ages" is the game.

We are currently using Shuttles for conferences etc. No Alienware yet.

The AMD 64 shuttle is for Smalltalk MT 64 which is coming along well :-)

Best regards,

dave

"OCIT" <[hidden email]> wrote in message
news:[hidden email]...

The typical focus of Smalltalk is the application. This is because of
Smalltalks roots in a monolithic image.

Smalltalk MT can create small DLLs (or EXEs) which allow the developer to
create components for use with mixed language applications.

The is in line with the modern focus of components for a specific task and
reusable in different environments.

For example, we have a MIL2525B component which converts a 15 character
standard military symbol into its graphic representation. Because this
component uses a COM interface, this component can be used in a Visual Age
application, or from Visual Basic, or from C++, or from .NET, or from a
script language (like ASP). So this component can also be used on a server
to serve up symbols via a web service.

One of the hardest areas in modern development environments is the
development of the UI. While Smalltalk was the right tool for this in the
past, today the user interface tool support is better in .NET UI and soon
will be in XAML (an XML description of the UI). Rather than try to compete
with UI development tools, isn't it better to build Smalltalk components and
hook these to the UI (build with whatever is the best tool for the job).

With such components, Smalltalk changes from a monolithic to a portable
solution. Why do we need Smalltalk.NET when Smalltalk MT components can be
integrated easily into a .NET application.

I hope this explains what I mean by "Smalltalk inside"

Regards,

dave

"Fernando" <[hidden email]> wrote in message
news:[hidden email]...

Dave,
> One of the hardest areas in modern development environments is the
> development of the UI. While Smalltalk was the right tool for this in the
> past, today the user interface tool support is better in .NET UI and soon
> will be in XAML (an XML description of the UI). Rather than try to compete
> with UI development tools, isn't it better to build Smalltalk components and
> hook these to the UI (build with whatever is the best tool for the job).

My answer to your question depends on the cicumstances.  Am I dealing
with a customer that insists on building their software that way?  Is
the payoff more than I could make doing my own thing with the same
investment of time?

Not to take away from any success you have had at using Smalltalk for
high-profile jobs, I do not agree that we are unable to compete.  In
fact, I think it is that type of thinking that destroyed Object Share.

Look at what WindowBuilder did 10+ years ago, and then tell me Smalltalk
can't compete on the GUI building front.  One of the deceptive things
about Smalltalk is that power of the tools is "hidden".  Our debuggers
do not have layer upon layer of toolbars, largely because they are not
needed.  I think the reality is that GUI building _looks_ hard to those
not familiar with Smalltalk.  When it is hard, I design tools to
automate it, and I know I am not alone in that approach.

It's great to be able to interact with other languages, but when I have
control of the whole process, it's Smalltalk except where it makes sense
to do otherwise: more C/C++ inside than Smalltalk inside.  Creating a
COM component (and it's evil cousin, the associated statically typed
interfaces) just to avoid some GUI work in a flexible, forgiving
environment is not my first choice of system design.

Happy Smalltalking,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

test

On Sat, 25 Dec 2004 22:13:43 -0700, "Dave Anderson"
<[hidden email]> wrote:

[snip]

>I hope this explains what I mean by "Smalltalk inside"

Hhmm.... Actually, it was the " Smalltalk can be used for what it is
very good at - MetaData representation" sentence that intrigued me.
O:-)

Well, Smalltalk is a great language for many things. However, it is
lacking in many areas... How many Smalltalk CORBA ORBs are out there?
Very few... What about GUI tools? One of the things that sells VB is
the fact that it has great GUI tools. Smalltalk can be competitive but
IMHO, the Smalltalk community has been its own worst enemy. All that
broo ha ha about java... Who cares! Go to a SUN Webstie and look at all
the libraries that exist for Java. Now consider how many developers are
willing to pay for say Visual Works or Visual Age.

I for one don't mind if a component is written in another language. If
it does what I need it to do, then I make use of it. While the ALL
Smalltalk solution is possible, its not the reality. But, thats just my
two cents after seeing Smalltalk succeed and fail in many projects. I'm
sure this happens with other languages, but the focus is Smalltalk.

While Smalltalk has great development environment, there can be a
tendancy to "Over Engineer" a design. This is easier to do in Smalltalk
than in other languages given the dynamic nature of the language and
the development environment.

I would say that Object Shares demise was brought about due to its
prices, management, company direction and weak financials rather than a
narrow minded view of "We Can't Compete". More like "We Don't Know How
to Run a Company/Manage" would be accurate. You hear the same argument
from companies in the Air Line industry about not being able to
compete. All this while companies like Jet Blue and Southwest are
consistently making profits. It's about managing the bottom line and
knowing where your revenues are located. More than anything else,
common sense. For those who say they Can't compete, common sense does
not apply. It's like 7 Up... Never Had it, Never Will...

Can Smalltalk do better? Hell yes... But, only if the views and
direction of the Smalltalk community support forward thinking rather
than the monolithic approach that Smalltalk can do everything... Thats
like commiting to GemStone Object Database and forgetting about
products such as Oracle, DB2, Access, Fox Pro, SQL Server and MySQL.
Hmmm, virtually all customers know about the latter... Very few and its
a very small, minute few know about GemStone.

Like the language itself, the Smalltalk community has to be more
dynamic in its thinking and approach to projects. If a system has
"Smalltalk Inside" I would say its a good thing. Smalltalk will survive
and flourish as long as fresh ideas come along in the community aka
Dolphin and Squeak. These dialects of Smalltalk are more like the Jet
Blues and Southwest models opposed to the big lumbering versions.
Things will really heat up when Dolphin and Squeak get "real"
distributed computing frameworks. Small/Fast/Efficient/Dynamic and
Managed very well...

Pax

> Well, Smalltalk is a great language for many things. However, it is
> lacking in many areas... How many Smalltalk CORBA ORBs are out there?
> Very few... What about GUI tools? One of the things that sells VB is
> the fact that it has great GUI tools.

Does it?  Seriously.  Yes, they have lots of drag and drop, and the
tools look slick (or did when I last had to use them).  Beyond that, I
will take a reflective system that can "learn" how to build views for me
- THAT'S good GUI tools.

With that said, it would be nice to have a few usability improvements in
Dolphin's ViewComposer, and Squeak would benefit greatly from a slick
widget set (we can differ on whether or not it should be native) and
associated graphical editor for views.

IMHO, to have "good GUI tools", one needs both programmatic and
interactive capabilities.


 > Smalltalk can be competitive but
> IMHO, the Smalltalk community has been its own worst enemy.

Agreed.  It will get worse if we don't keep our collective eyes on what
we do well, and on what is really important to users.


 > All that
> broo ha ha about java... Who cares! Go to a SUN Webstie and look at all
> the libraries that exist for Java. Now consider how many developers are
> willing to pay for say Visual Works or Visual Age.

I am fairly certain I do _not_ follow you here.  Can you clarify it?



> I for one don't mind if a component is written in another language. If
> it does what I need it to do, then I make use of it.

It exists, so we should use it rather than rebuild.  Ok, if it is easier
to connect than it is to rebuild, and/or the result is better than what
we would build.  The meaning of "better" depends on the circumstances,
of course, but I submit that it is a tradeoff each time.  My concern is
that I see a rush to connect w/o acknowledgement, let alone evaluation
of, that tradeoff.  I've been bitten enough times, on both reliablity
and performance metrics, that I've started to pay attention to it.


 > While the ALL
> Smalltalk solution is possible, its not the reality.

I would agree if you are talking about primitives and reasonable hooks
into the host OS.  I start to differ with your opinion if you take it
mean that one must connect to lots of native stuff or lose.  That is
true to a point, but only to a point.



> While Smalltalk has great development environment, there can be a
> tendancy to "Over Engineer" a design. This is easier to do in Smalltalk
> than in other languages given the dynamic nature of the language and
> the development environment.

Converseley, many of "native components" are grossly under engineered;
at least that's my experience.

Are you suggesting that having less helpful tools leads to better
software because it forces one to quit while they're not too far behind?
  Getting a good start takes talent, knowledge, discipline, hard work,
luck, etc.  I submit that a developer with those qualities will realize
when it's time to stop fiddling and get back to work, especially if
there is an accountant around to inject some motivation into the
process.  We don't have to look for ways to make software hard to build.


> I would say that Object Shares demise was brought about due to its
> prices, management, company direction and weak financials rather than a
> narrow minded view of "We Can't Compete". More like "We Don't Know How
> to Run a Company/Manage" would be accurate.

True to a point, but I recall watching in dread as they dumped a
tremendous amount of money into Java development, and it sure seemed
like it was because they felt the sky was falling.  It did, because they
didn't stand their ground.


> Can Smalltalk do better? Hell yes... But, only if the views and
> direction of the Smalltalk community support forward thinking rather
> than the monolithic approach that Smalltalk can do everything...

Almost by definition, it can.  The question is whether it should - it's
a fine point that makes a big difference in the debate.  Or, are you
suggesting that a C* system can do something that a Smalltalk program
cannot?  I'm not comparing performance; I have quite a few time-critical
things (mostly numerial analysis) wrapped in DLLs for precisely that reason.

My concern about components is that they cannot exist without
boundaries/interfaces, and with them comes cold hard reality.  Why do
that to yourself unless there is a measurable benefit?  The benefit can
take many forms, but I think components are a win far less often than
the conventional wisdom would suggest.

I was taught how important it was to have DLLs that were replaceable
without disturbing anything, and wasted a lot of time making it work.
Good source management would have been a much bigger aid.  Smalltalk is
an even bigger aid.

One should always ask whether the goal is to get the machine to do
something, or to get it to do something a certain way?



> Thats
> like commiting to GemStone Object Database and forgetting about
> products such as Oracle, DB2, Access, Fox Pro, SQL Server and MySQL.
> Hmmm, virtually all customers know about the latter... Very few and its
> a very small, minute few know about GemStone.

I use MySQL extensively, at least for the stuff that it (or any RDBMS)
does well, and use object serialization to do what it does well.


> Like the language itself, the Smalltalk community has to be more
> dynamic in its thinking and approach to projects.

I'm not convinced that we are so obligated.  It's not harmful to do so,
and probably beneficial, as long as we don't lose ourselves in the
process, which happens quite often in politics.  This discussion really
is about political strategy: it's about getting people do what you want
them to do.  The technology is easy by comparison to politics.


 > If a system has
> "Smalltalk Inside" I would say its a good thing.

Not that you've said I said so, for the record, I didn't say it was bad.
  I said that it is not my first choice when Smalltalk can/should be the
controlling entity.  That's pretty damn often IMHO.


> Smalltalk will survive
> and flourish as long as fresh ideas come along in the community aka
> Dolphin and Squeak. These dialects of Smalltalk are more like the Jet
> Blues and Southwest models opposed to the big lumbering versions.
> Things will really heat up when Dolphin and Squeak get "real"
> distributed computing frameworks. Small/Fast/Efficient/Dynamic and
> Managed very well...

That would be a good thing, but I can guarantee you that it won't "make
them like us" (read flock to Smalltalk in hordes).  The detractors will
_always_ have more reasons not to use something they don't want to use.


Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Bill

>  > All that
> > broo ha ha about java... Who cares! Go to a SUN Webstie and look at
all
> > the libraries that exist for Java. Now consider how many developers
are
> > willing to pay for say Visual Works or Visual Age.
>
> I am fairly certain I do _not_ follow you here.  Can you clarify it?

Just commenting on the reaction of the Smalltalk community with regrad
to Java's entry into the marketplace and all the hype. In my opinion,
Smalltalkers would have been more productive working on web interfaces,
tools etc. Language has always tended to diverge rather than converge.
I never viewed Java as a threat to Smalltalk. Just means that somone
looked at Smalltalk and created a new language that makes use of
virtual machine technology. The arguments about "We had it first"
didn't help the community.

Secondly, the prohibitive costs of VW and VA was a barrier to embracing
Smalltalk. At that period of time (1996) Dolphin was just in it's
infancy and Digitalk/Object Share had seen their respective demise.

On another point, Software companies are beginning to discover that
moving their projects offshore has disadvantages. May be cheaper, but
it doesn't mean that a project will run smooth or not fail.

> Are you suggesting that having less helpful tools leads to better
> software because it forces one to quit while they're not too far
behind?

No, from the development/debugging avenue, Smalltalk tools don't have
to be super sophisticated. However, from the GUI point of view,
Smalltalk would benefit by having better tools.

All I am saying is that given the nature of the development environment
and somtimes the methodology, Smalltalkers can over design a system. At
one location in the east part of the US, I saw classes that had 96
instance variables. They created classes for everything! Even Area Code
and Zipcode objects! Every team of developers implemented event
triggers; no idea how long the app cycled until triggers stoped firing.
Needless to say, it was spaghetti code and the exe was approaching 5
mb. It worked but, an application like that can not be maintained or
documented.

For me, the age old addage of KISS still applies. The forementioned is
an extreme example. Definately not what is meant by "Extreme
Programming" (grins). There are other cases as I am sure most Smalltalk
contractors have seen at least one example of something being
over-engineered.

There are those who predicted the demise of Smalltalk but, it hasn't
happened. In fact, by losing the brain trust of Digitalk and Object
share, the community gained Squeak and Dolphin. Free market operations
at its best.

Now if the federal government would stop bailing out poorly managed air
lines...

I think we are on the same page here, just commenting with a different
perspective. I agree that politics aside, Smalltalk should continue to
be Smalltalk rather than trying to be like "them". However, Smalltalk
would IMHO benefit from better GUI tools and software frameworks.

Yes, its difficult when you have a "Bean Counter" aka Accountant
telling you "We need this in 8 months" and "It can't cost any more than
$XYZ". This is one reason why software has bugs. It's inevitable when
the development process has to operate under such constraints. It
guarantees shortcomings that are blamed on the development team or the
choice of language. In reality, any project regardless of language will
have shortcomings with these types of constraints.

PAX

> Just commenting on the reaction of the Smalltalk community with regrad
> to Java's entry into the marketplace and all the hype. In my opinion,
> Smalltalkers would have been more productive working on web interfaces,
> tools etc. Language has always tended to diverge rather than converge.
> I never viewed Java as a threat to Smalltalk. Just means that somone
> looked at Smalltalk and created a new language that makes use of
> virtual machine technology. The arguments about "We had it first"
> didn't help the community.

Very true.  Though, Java was a threat, but only in the sense that the
community reacted so badly to the vapor ware aspects of Java.


> Secondly, the prohibitive costs of VW and VA was a barrier to embracing
> Smalltalk. At that period of time (1996) Dolphin was just in it's
> infancy and Digitalk/Object Share had seen their respective demise.

I'm going to get in trouble for this<g>, but my favorite was when the VW
guys started asking "well, what's it worth to you?".  Unreal.  I know
it's easier to work when there is a revenue stream, but that was very
poor judgement.


> On another point, Software companies are beginning to discover that
> moving their projects offshore has disadvantages. May be cheaper, but
> it doesn't mean that a project will run smooth or not fail.

Examples?



> No, from the development/debugging avenue, Smalltalk tools don't have
> to be super sophisticated. However, from the GUI point of view,
> Smalltalk would benefit by having better tools.

No question.  I am writing some IDE extensions with that in mind, but
not much in the VC, with the exception of Wizardry.  I suppose there
would be some room for a dialog to set a few common aspects of any
particular view, probably dispatched through the latter.  In general
though, I like Dolphin's VC.  For a while, I was concerned about a
slicker way to set tab orders, and then I discovered the up/down toolbar
buttons - I withdrew the enhancement request :)


> All I am saying is that given the nature of the development environment
> and somtimes the methodology, Smalltalkers can over design a system. At
> one location in the east part of the US, I saw classes that had 96
> instance variables.

That's a code smell.  But it sounds like under-, not over-engineering.


 > They created classes for everything! Even Area Code
> and Zipcode objects!

Is that bad design, or gifted insight?  It sounds goofy, I'll admit.


 > Every team of developers implemented event
> triggers; no idea how long the app cycled until triggers stoped firing.

I worry about that too.  A few well-chosen back-pointers can avoid a lot
of suffering.  At one point, I "learned" that back-pointers lead to GC
problems.  Maybe they did at the time I "learned" that.  Unlearning it
has helped, as has gaining years of experience looking at Smalltalk
errors and knowing what I probably did wrong to cause this or that type
of trouble.

Another crucial lesson is to make as much as possible testable without a
running GUI.  Sadly, many developers know no other way than to create a
directory, create a project, draw a GUI, and then eventually get around
to putting something "under the controls".  It's a lot slicker to create
a few (or many) classes and begin to drive them from workspaces and/or
evolving tests.  I fear that most "visual" programming leads to very
poor practice.


> Needless to say, it was spaghetti code and the exe was approaching 5
> mb. It worked but, an application like that can not be maintained or
> documented.

Just a hunch: with the same developers, it would be worse in any other
language, if it worked at all.


> For me, the age old addage of KISS still applies. The forementioned is
> an extreme example. Definately not what is meant by "Extreme
> Programming" (grins). There are other cases as I am sure most Smalltalk
> contractors have seen at least one example of something being
> over-engineered.

If you count shameless hacks in there, then all you need to do is look
around just about any Smalltalk image.  Somewhere, there is likely to be
some truly ugly procedural mess.  However, as long as it works, and is
not showing up in my profiling results<g>, it probably doensn't hurt
anything provided it is not wide spread.



> Now if the federal government would stop bailing out poorly managed air
> lines...

As an aside, Neal Boortz wrote a great set of conditions for airlines
wanting aid.  It was FUNNY, and very much on the mark.


> I think we are on the same page here, just commenting with a different
> perspective. I agree that politics aside, Smalltalk should continue to
> be Smalltalk rather than trying to be like "them".

Fair enough.


 > However, Smalltalk
> would IMHO benefit from better GUI tools and software frameworks.

Of course.  Perhaps we should use a Wiki somewhere to draft lists for
both Dolphin and Squeak.


> Yes, its difficult when you have a "Bean Counter" aka Accountant
> telling you "We need this in 8 months" and "It can't cost any more than
> $XYZ".

Actually, I was crediting our accountant with getting it about right,
but I know precisely what you mean about problems coming from too much
attention to financial concerns at the expense of doing the job.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

On Tue, 28 Dec 2004 16:08:26 -0500, Bill Schwab
<[hidden email]> wrote:


>Another crucial lesson is to make as much as possible testable without a
>running GUI.  

Is there any tutorial or guide to  SUnit and "XP for the single
developer"?

Fernando,

>>Another crucial lesson is to make as much as possible testable without a
>>running GUI.  
>
> Is there any tutorial or guide to  SUnit and "XP for the single
> developer"?

The Guzdial and Rose book on Squeak has a chapter on it, and that might
even be available for download, if only in draft form.  Google will turn
up others.  Actually, SUnit is pretty simple.  Subclass TestCase, and
add methods named #test*.  Right click on the class and choose from the
Tests menu (you do have the SUnit Browser loaded, right<g>).

You can get a small productivity boost via my filtered browser, and the
Acme Filter Store in particular.  Note the two sets of three buttons on
the toolbar; the run button will load the SUnitBrowser on tests
associated with the selected filter or filter set.

My code generator goodie includes an IDE extension that proposes chunks
for tests - nothing big, but it can save a few clicks and (more
importantly) some navigation.  On the latter, note the Browse from
image... command in the code generator preview shell's list box.  Also
note that you can drag classes from the CHB to the filter store, adding
a filter to the selected set.  Suggestions for improvements are welcome,
of course.

What do you put in the tests?  That depends.  When you "know the answer"
you can write a test that specifies it and keep entering the debugger
until you solve it.  Even just something that creates new instances and
sends some messages can be helpful in catching gross errors.  The best
source of tests is "today's bug".  Write a test that reproduces and
complains about it; then fix it.  Keep doing that, you end up with a set
of constraints that give you confidence in altering your code.  Note
that if your tests are too granular, you end up maintaining them along
with the code :(  Test the important ones ("entry points") and you have
soething.

FWIW, I am a _big_ believer in automated testing.  I am not a fan of XP.
I see great value in much of what it teaches, but I consider the whole
to be misguided.  There is indeed such a thing as a method that is too
short, comments are important, and formatting of code, much as phrasing
in music, can add meaning beyond the sum of the parts.  Let go of too
much of that, IMHO, you're asking for trouble.

Do I comment every accessor?  No.  I try to comment "constructor"
methods, as they tend to exist for a reason.  I make a lot of use of
month/year dated comments, and leave things (commented out) in place, at
least until they begin to interefere with understanding.  More than
once, I've had comments from 18, 12, and 6 (give or take) months earlier
point to a trend that showed what was clobbering me.

Look at the "four byte bug" in the archives.  Patched by a user
(Chris??) using a commented line that was not removed.  Under XP, the
tests passed, so the line would have been gone.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]