Smalltalk - distributing Smalltalk programs

Author

distributing Smalltalk programs

Lex Spoon

2004-03-30, 2:40 pm

Darin Johnson <darin_@_usa_._net> writes:
> Lex Spoon <lex@cc.gatech.edu> writes:
>
>
> Smalltalk doesn't really have "run anywhere" executables.

I don't understand your issue. C does not have "run anywhere"
executables, either. But people still manage to distribute
cross-platform programs written in C.

You can prepare a cross-platform distribution of a Smalltalk program
just as you'd prepare a cross-platform distribution of a C, C++, or
Java program. It's actually easier with Smalltalk, because the
program will reliably behave the same on the other platforms.

> Sure, if you ensure that all customers have the same Smalltalk
> variant and you only ship source code, but that's not the same
> thing. I know of no other language with the wide availability of
> Java where it produces system independent byte codes that are easily
> run anywhere; even by non-techies, in the case of applets.

I don't agree that Java meets your criterion. In my experience, Java
programs frequently do *not* behave the same; I've downloaded multiple
Java programs that have bugs only on Linux. Further, I have several
times experienced having to dig up a new Java VM or Java library in
order to run a program that's been given to me. To add to all this, I
hear reports of people on some platforms where many Java programs
cannot be run at all, no matter how many VM's, etc., you upgrade.

Thus, Java jar files do not seem like a reliable way to deliver
cross-platform programs right now. For a reliable distribution, you'd
want to include the proper Java VM along with your JAR file and
anything else you need.

-Lex

Darin Johnson

2004-03-30, 7:37 pm

Lex Spoon <lex@cc.gatech.edu> writes:

> I don't understand your issue. C does not have "run anywhere"
> executables, either. But people still manage to distribute
> cross-platform programs written in C.

Basically, no one has run-anywhere executables anymore anyway, since
Java has gotten so complex and has abandoned the idea. The idea was
that you could grab an executable piece of code and it would run
everywhere. And it ran everywhere because the runtime environment was
ubiquitous (ie, if you had a browser you could run the code). You
didn't have to navigate a web site to find the version for your OS, or
be told "non-Windows support forthcoming". And the byte codes would
run reliably and identically everywhere, or that was the idea anyway.

It's a feature that no one in the Windows world cares about, which
means IT doesn't care about it, and ISPs don't care about it, and
corporations don't care about it. And the browsers didn't agree
with each other, and Sun kept introducing incompatible VM's (not
just bug fix releases), etc. So the concept doesn't exist anymore.

--
Darin Johnson
"Look here. There's a crop circle in my ficus!" -- The Tick

Andre Schnoor

2004-03-31, 5:43 am

>>>For a reliable distribution, you'd want to include
the proper Java VM along with your JAR file and
anything else you need.<<<

That's exactly what is included in a Smalltalk
distribution image: Everything. So people should stop
complaining it's a few megs of size.

I still like the concept of monolithic blocks, because
they are the only way to make sure that your customer
is missing nothing. For enterprise-scale solutions this
might be inappropriate, but for consumer apps it's still
the most convenient and secure way.

Andre

Lex Spoon

2004-03-31, 4:35 pm

"Andre Schnoor" <andre.schnoor@web.de> writes:

> the proper Java VM along with your JAR file and
> anything else you need.<<<
>
> That's exactly what is included in a Smalltalk
> distribution image: Everything. So people should stop
> complaining it's a few megs of size.
>
> I still like the concept of monolithic blocks, because
> they are the only way to make sure that your customer
> is missing nothing. For enterprise-scale solutions this
> might be inappropriate, but for consumer apps it's still
> the most convenient and secure way.

It depends on the OS. With Debian, for example, one can rely on the
package dependency mechanisms, and so you could deliver separate VM
and image packages. This is done regularly with other languages on
Debian already.

-Lex

Lex Spoon

2004-03-31, 5:45 pm

Darin Johnson <darin_@_usa_._net> writes:
> Lex Spoon <lex@cc.gatech.edu> writes:
>
>
> Basically, no one has run-anywhere executables anymore anyway, since
> Java has gotten so complex and has abandoned the idea.

I believe you have misunderstood the history. Java was never in a
state where there was a reliable, current VM on a large number of
platforms. I remember the Squeak people joking in '98 or so that
Squeak ran on more platforms that Java, and that it did it bit-for-bit
identically. While Java is on more platforms now, you still cannot
expect a Java program on one platform to just run on a different one.

So there has always been lag between naming a new Java spec and
getting it spread around to a variety of platforms. The fact that new
specs keep coming out means that the problem persists, not that it
is a new problem.

> It's a feature that no one in the Windows world cares about, which
> means IT doesn't care about it, and ISPs don't care about it, and
> corporations don't care about it. And the browsers didn't agree
> with each other, and Sun kept introducing incompatible VM's (not
> just bug fix releases), etc. So the concept doesn't exist anymore.

Don't despair! There are still many people who do care about portability.

Also, why is the extreme of no-change drop-in portability so
important? Variety is essential for progress in the long term, and I
certainly don't want to standardize on *anything* on computers that is
out there right now. People use different platforms because there is
something about those platforms they like.

-Lex

Darin Johnson

2004-04-01, 12:39 am

Lex Spoon <lex@cc.gatech.edu> writes:

> Also, why is the extreme of no-change drop-in portability so
> important?

I'd like to write programs for my friends to use. Ie, utilities for
board game night, etc. They use Macs, Palms, Linux, and Windows.
In the commercial world, the problem is solved: be arrogant and don't
deal with customers that aren't set up to run your programs :-)

--
Darin Johnson
My shoes are too tight, and I have forgotten how to dance -- Babylon 5

Andre Schnoor

2004-04-01, 4:21 am

> > Also, why is the extreme of no-change drop-in portability so
>
> I'd like to write programs for my friends to use. Ie, utilities for
> board game night, etc. They use Macs, Palms, Linux, and Windows.
> In the commercial world, the problem is solved: be arrogant and don't
> deal with customers that aren't set up to run your programs :-)

Oh no, that won't work for me. Example: I'm operating in a field
where there are 80% Macs and 20% PCs. I can't afford to ignore
those 20% and can't afford to maintain two different implementations
either. So, a working platform transparency is mandatory for me.
This transparency even goes down to the ANSI C level for specific
interfaces in external libraries that compile on all platforms.

If you are aiming at a market with 50,000+ installations, you
have to optimize your internal product cycles to the absolute
maximum in order to get your business effective in a small
company. Full platform transparency is the most powerful
feature to achieve this. That's also why VW is my current favorite.

Andre

Bob Nemec

2004-04-01, 9:46 am

<...>
>
> I believe you have misunderstood the history. Java was never in a
> state where there was a reliable, current VM on a large number of
> platforms. I remember the Squeak people joking in '98 or so that
> Squeak ran on more platforms that Java, and that it did it bit-for-bit
> identically. While Java is on more platforms now, you still cannot
> expect a Java program on one platform to just run on a different one.

Just to show you how far ahead of its time VW was: in 1994 (VW had been out
for several years at this point) I was on a team at EDS working for GM in
Flint, MI on a stamping plant process control system. The development team
was using Windows 3.11 (ouch) and the runtime was deployed on Windows and
Sparc workstations: same image, loaded from a common network share.

There was *one* method that checked which OS the client was running on. It
had to select a \ or / in order to generate a proper local filename.

The original VW team was mind bogglingly good.
--
Bob Nemec
Northwater Objects

Lex Spoon

2004-04-01, 3:39 pm

"Andre Schnoor" <andre.schnoor@web.de> writes:
> If you are aiming at a market with 50,000+ installations, you
> have to optimize your internal product cycles to the absolute
> maximum in order to get your business effective in a small
> company. Full platform transparency is the most powerful
> feature to achieve this. That's also why VW is my current favorite.

Right -- notice managing distribution of the VW runtimes does not add
a horrible burden. The code can stay the same, or at least very
close, and that's the important thing. Managing distribution of the
runtimes is just a matter of assembling a separate package for each
supported platform. It's not a ton of work, especially in the context
of a large project, and most of that effort is a fixed cost: you can
reuse your packaging scripts on future distributions.

-Lex

James A. Robertson

2004-04-02, 11:36 am

On Wed, 31 Mar 2004 11:43:18 +0200, "Andre Schnoor"
<andre.schnoor@web.de> wrote:

>the proper Java VM along with your JAR file and
>anything else you need.<<<
>
>That's exactly what is included in a Smalltalk
>distribution image: Everything. So people should stop
>complaining it's a few megs of size.
>

See

http://www.cincomsmalltalk.com/BottomFeeder

for an example

>I still like the concept of monolithic blocks, because
>they are the only way to make sure that your customer
>is missing nothing. For enterprise-scale solutions this
>might be inappropriate, but for consumer apps it's still
>the most convenient and secure way.
>
>Andre
>

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

Sponsored Links