Java vs. Smalltalk vs. C++ vs. OO COBOL
Jeff Sutherland
http://www.tiac.net/users/jsuth/smallman.html
The Smalltalk Manifesto: Avoiding RoadKill on the InfoBahn
If you want Smalltalk to survive or build a better Java, you better read
this.
Regards,
--
Jeff Sutherland
VP Product Development, Individual, Inc.
mailto:jeff.su...@individual.com
http://www.tiac.net/users/jsuth/
"Surf first and ask questions later!"
dav...@ibm.net
In <31CC4A...@individual.com>, Jeff Sutherland <jeff.su...@individual.com> writes:
>http://www.tiac.net/users/jsuth/smallman.html
>
>The Smalltalk Manifesto: Avoiding RoadKill on the InfoBahn
>
>If you want Smalltalk to survive or build a better Java, you better read
>this.
>
>Regards,
>--
Quite honestly, I'm waiting for VisualAge Java to appear and then all the C++
and Smalltalk stuff is gone from our company. A java application can run on any
platform where a java viewer is present. No more "cross platform" coding
concerns, etc. True "data independence" for the developer and user. No more
deciding to work with Mr. Bill, Scott or Lou's environment, just code and go.
Dave
More Systems Employee
In article <31CC4A...@individual.com>, jeff.su...@individual.com says...
>
>http://www.tiac.net/users/jsuth/smallman.html
>
>The Smalltalk Manifesto: Avoiding RoadKill on the InfoBahn
>
>If you want Smalltalk to survive or build a better Java, you better read
>this.
I applaud the sentiments expressed in this Manifesto, that the Smalltalk
development community should join forces with Java, rather than fight
against it. By joining forces, the Java community will get the benifits
of decades of top-notch object-oriented programming, and Smalltalk will
get the benifits of running anywhere and doing anything Java can. If
this doesn't happen, Java will be the lesser for it, but it will still
probably crush what is left of Smalltalk for all practical purposes.
That would be a true shame.
I also suggest that anyone who is fond of Perl read this, and think
about it. Java servlets can do just about anything a CGI script can
do, only much faster since it doesn't need to spawn a sub-process.
RMI provides an even more powerful and abstract substitute for CGI.
Perl is the premire regexp language of today, but there are regexp
libraries for Java appearing every day of ever-increasing sophistication.
An implementation of Perl that runs inside a JVM would satisfy
a powerful need in the Java community today, but if it doesn't
show up soon something else will take it's place.
>Regards,
>--
>Jeff Sutherland
>VP Product Development, Individual, Inc.
>mailto:jeff.su...@individual.com
>http://www.tiac.net/users/jsuth/
>
>"Surf first and ask questions later!"
-Eugene
Jason Kratz
dav...@ibm.net wrote:
>In <31CC4A...@individual.com>, Jeff Sutherland <jeff.su...@individual.com> writes:
>>http://www.tiac.net/users/jsuth/smallman.html
>>
>>The Smalltalk Manifesto: Avoiding RoadKill on the InfoBahn
>>
>>If you want Smalltalk to survive or build a better Java, you better read
>>this.
>>
>>Regards,
>>--
>Quite honestly, I'm waiting for VisualAge Java to appear and then all the C++
>and Smalltalk stuff is gone from our company. A java application can run on any
>platform where a java viewer is present. No more "cross platform" coding
>concerns, etc. True "data independence" for the developer and user. No more
>deciding to work with Mr. Bill, Scott or Lou's environment, just code and go.
>Dave
Dave -
Quite honestly I think youre nuts :) Smalltalk is a far superior
language to Java. Unfortunately the only problem is the
platform-dependence. If it were "platform-independent" like Java it
would blow java out of the water.
Jason
Andy Collier
Umm platform independent... add multiple inheritance, capable of merging
threads and working asynchonously outside of its own process space, and
a few other things... (These were problems when I was last working on
a project using ParcPlace and Envy a year ago). Smalltalk is far
from the perfect solution. The best I've seen so far is C++, but it
has such a steep curve to expertise, and a lack of standardization
keeps it from getting the "perfect" label. And I don't like having to
code in C++. Oh well, do what you can with the tools at hand.
Andy C.
Dave Smith
> snip>> Problem is, most PPD customers
> have been saying that THEY PREFER PLATFORM DEPENDENCE SO THAT THEIR APPLICATIONS
> LOOK AND ACT (and interact with the host platform) COMPLETELY NATIVE!
>
> I don't see why "platform independent Java" won't encounter the same customer
> resistance that VisualWorks has on this issue. I refuse to listen to anyone
> slam Smalltalk for being "platform dependent" after all the years I've spent
> apologizing to Windows and Mac bigots for the fact that VisualWorks is so
> very platform INdependent. <<snip
Platform independence has been a programmer issue primarily, not a user issue. It has
little commercial value on the client side. This is what your customer complaints
really amount to--"I don't care if it works on some other machine, on MY machine I
want it to do (platform dependent fill in the blank)". Most people don't have five
brands of computers or five operating systems; they have one. They don't give two farts
if their app might also run on another machine. Historically only developers have a
real interest in cross platform independence. So, Smalltalk portability as it turns out
is totally different in character from Java portability, which is CRITICAL to its whole
functionality. It is NOT critical to smalltalk as a language in any way. This is the
difference. The web protocols require small, portable modules and will continue to do
so until there is radical hardware change in world infrastructure.
Regards,
DS
Tim Menzies
>In <4qs63q$13...@piglet.cc.uic.edu>, dha...@icarus.cc.uic.edu (David James Hanley) writes:
>> But consider all the serious flaws with smalltalk:
>>
>> 1)idiotic lack of static typing.
>> 2)lack of inheretence.
>> 3)poor parameter passing mechanism.
>> 4) etc,etc...
>> :)
>
>1. not a flaw. this point is debatable based on your preferences. I'd rather have
> the dynamic typing that allows for things such as heterogeneous lists...
>2. lack of inheritance? perhaps you mean *multiple* inheritance, which even
> many of the best C++ developers say not to use unless you absolutely have
> to
yes. studies with large c++ libraries show that the average parents per class
is 0.49; i.e. c++ programmers do not make extesnive use of inheritance
in general and multiple inheritance in particular.
also, if we look at the design patterns book, we see that they recommend
more aggregation than inheritance; i.e. oo design theoriests tell us that
the key to intricate object behaviour is not via extensive use
of inheritance.
--
Dr. Tim Menzies | Excuse me, do you know what
ti...@insect.sd.monash.edu.au | time it is?
,-_|\ www.sd.monash.edu.au/~timm | -About Noon.
/ \ Dept. Software Development, | I'd prefer something more
\_,-._/ Monash University, Caulfield, | exact . . .
v Melbourne, Australia, 3145. | -About Noon, Stupid.
+61-3-9903-1033(p)9903-1077(f)|
David Buck
>
> 1)idiotic lack of static typing.
<<soapbox mode on>>
The lack of static typing is onr of the single greatest features of
the Smalltalk language. I'm currently developing an application
in C++ (currently >51,000 lines of code) and the static typing
is seriously hindering the development. Static typing and a
true object-oriented environment are mutually incompatible.
The way that C++ does its method calls is idiotic. It relies on
the static type system to give it the information it needs for
making the call (i.e., the index into the virtual table). This means
that all variables and all parameters must be staticly typed.
When you do this, it makes generalization and specialization
of methods virtually impossible. If I have 200 methods that
all expect to take a particular type of parameter, then I
decide that I want to generalize the parameter to better
isolate the functionality I'm actually using, I have 400 changes
to make throughout the system (the class declaration and
the method itself).
Calls to methods in superclasses should never need to
reference the name of the superclass directly, but in
C++, this is the only way to do it. Again, if I decide to
change the class hierarchy, I have many changes to
make, all of them completely unnecessary if the language
supported a simple 'super'.
Normally, class declarations in C++ are placed in .h files
and code in .cpp files. If I decide to change a .h file to
add one method in (even if it's not called), I must then
re-compile everything that includes that header file
and re-link in order to run. This is the biggest productivity
destroyer of all times. On my system, a 90 MHz Pentium.
to re-compile and re-link all of the code takes ~20
minutes. This delay really destroys any momentum you
develop while coding and is a complete waste of time.
If I was able to develop this application in Smalltalk,
I could probably do it in less than 20,000 lines of code and
it would me MUCH more maintainable. It's no wonder that
people who don't use Smalltalk concentrate so much on
up-front design. The language forces your code to be so
brittle that changes after the fact are virtually impossible.
<<soapbox mode off>>
David Buck
db...@magmacom.com
Dale Stanbrough
"Umm platform independent... add multiple inheritance, capable of merging
threads and working asynchonously outside of its own process space, and
a few other things... (These were problems when I was last working on
a project using ParcPlace and Envy a year ago). Smalltalk is far
from the perfect solution. The best I've seen so far is C++, but it
has such a steep curve to expertise, and a lack of standardization
keeps it from getting the "perfect" label. And I don't like having to
code in C++. Oh well, do what you can with the tools at hand."
Not wanting to start a language war, I'll simply comment that Ada95
is standardized, Object Oriented & free (Gnat95) and has what I consider
to be a much nicer built in multitaksing model. Also a commercial
Ada compiler (Intermetric's AppletMagic) compiles to Java byte code.
Most run time systems don't have garbage collection though, which I think
is almost a must have these days.
Dale
Rolf Breuning
>: Quite honestly I think youre nuts :) Smalltalk is a far superior
>: language to Java. Unfortunately the only problem is the
>: platform-dependence. If it were "platform-independent" like Java it
>: would blow java out of the water.
>
>
> 1)idiotic lack of static typing.
IMHO an advantage of Smalltalk: Polymorphism everywhere
> 2)lack of inheretence.
Only of multiple inheritance.
1) This can be cured properly. I have done an implementation in Visual Smalltalk
(see Tools Europe 96)
2) Even though I implemented it: A language without static typing an with powerfull
mechanisms like message redirection via #doesNotUnderstand: does not need
multiple inheritance as much as other languages. In many cases, MI is used for
typing reasons (to get a common superclass), which is not necessary in ST as
it doesn't have static types. As Bertrand Meyer once put it in news:
"It is possible to do realistic O-O software development without multiple inheritance
if and only if there is no static typing"
> 3)poor parameter passing mechanism.
????
> 4) etc,etc...
????
> :)
As most langauges, most ST dialects *have* weaknesses: E.g.
- handling of OS threads
- large footprint for small projects (not for large ones)
**********************************************************************
* Rolf Breuning br...@rog.rwth-aachen.de *
* Rogowski-Institut / RWTH Aachen *
* Schinkelstr.2, D-52062 Aachen - standard disclaimer - *
**********************************************************************
Rolf Breuning
>Jason Kratz wrote:
..
>VisualWorks already lets you code with about as much platform independence
>as you're going to get. On WinTel (OS/2, Windows XXX), Mac and the major
>Unices (SunOS, Solaris, HP-UX, AIX, Ultrix). Problem is, most PPD customers
>have been saying that THEY PREFER PLATFORM DEPENDENCE SO THAT THEIR APPLICATIONS
>LOOK AND ACT (and interact with the host platform) COMPLETELY NATIVE!
>
>I don't see why "platform independent Java" won't encounter the same customer
>resistance that VisualWorks has on this issue. I refuse to listen to anyone
>slam Smalltalk for being "platform dependent" after all the years I've spent
>apologizing to Windows and Mac bigots for the fact that VisualWorks is so
>very platform INdependent.
The problem of VisualWorks was not that it is platform independent - the problem
was that it let the user *see* this. A proper platform independent environment must
do both:
1) Let you easily run your custom code on different platforms
2) let it - via its VM or built-in class library - on each platform
behave like a native application.
>
>And anyone who honestly believes that each different Java implementation from
>each different Java vendor won't differ in important ways from all the others
>is living in Wonderland. It won't be long before there's a wild market
>frenzy for "Windows-native Java" and "Mac-native Java" so that Java
>applications will be able to fully interoperate with the full rights and
>privileges of native applications. You can take it to the bank.
If Java fails on 2) ...
Daniel J. Long
>
> I CAN'T AFFORD IT. Hell, my COMPANY can't afford it. And as
> for writing applets, not even Bill Gates couldn't afford to
> buy a VisualWorks runtime license for every web browser
> on the internet.
>
The following press release is available at www.parcplace.com:
SUNNYVALE, Calif., - May 7, 1996 - ParcPlace-Digitalk, Inc.
(Nasdaq: PARQ) announced today that the company has eliminated
runtime charges for its VisualWorks product line. VisualWorks
customers will be able to deploy applications that run on Windows,
Windows NT, Macintosh, OS/2 and UNIX free of runtime charges.
Previously VisualWorks customers paid up to several hundred
dollars per user for runtime licensing fees.
James Kanze US/ESC 60/3/141 #40763
|> In article <4qsg8q$6...@news.internetmci.com> jeffre...@mci.com writes:
|> >In <4qs63q$13...@piglet.cc.uic.edu>, dha...@icarus.cc.uic.edu (David James Hanley) writes:
|> >> But consider all the serious flaws with smalltalk:
|> >>
|> >> 1)idiotic lack of static typing.
|> >> 2)lack of inheretence.
|> >> 3)poor parameter passing mechanism.
|> >> 4) etc,etc...
|> >> :)
|> >
|> >1. not a flaw. this point is debatable based on your preferences. I'd rather have
|> > the dynamic typing that allows for things such as heterogeneous lists...
|> >2. lack of inheritance? perhaps you mean *multiple* inheritance, which even
|> > many of the best C++ developers say not to use unless you absolutely have
|> > to
|> yes. studies with large c++ libraries show that the average parents per class
|> is 0.49; i.e. c++ programmers do not make extesnive use of inheritance
|> in general and multiple inheritance in particular.
I suspect that most large C++ libraries are basic class libraries, more
concerned with extending the types (in the classical sense) available
to the implementation. As such, they will typically not be
particularly OO-oriented, any more than is int or double.
If you look at large applications, on the other hand, the statistics
would no doubt be different. If I look at the application I am
currently working on, for example, the average number of parents for
classes in the application domain would be somewhere between 2 and 3,
whereas the average number of parents in the basic classes used to
implement the application would be 0.
|> also, if we look at the design patterns book, we see that they recommend
|> more aggregation than inheritance; i.e. oo design theoriests tell us that
|> the key to intricate object behaviour is not via extensive use
|> of inheritance.
As is often pointed out, multiple inheritance (in C++) may be used for
two distinct purposes: interface and implementation. Since each
individual pattern in the design patters book is concerned with a
single interface, it is understandable that there are no instances of
multiple inheritance of an interface.
Concerning multiple inheritance of implementation, in general, I would
also find aggregation preferrable. Still, however, it is worth looking
at some of the examples in Barton and Nackman; they use multiple
inheritance extensively, and a lot of it is for implementation.
Concerning multiple inheritance of interface, it is, of course, only
necessary if the language requires declaring the interface, and
enforces it with strict static type checking. Which is, of course, the
case of C++, but not of Smalltalk. Even in the case of strict type
checking, multiple inheritance of interface can be simulated with
delegation. This is, however, requires some programmer effort, and a
lot of programmer effort if there is no garbage collection and generic
classes. I would not like to have to do it in C++, although it would
not be anywhere near as difficult in, say, Modula-3.
I would hope that, even though Smalltalk does not support (nor need)
multiple inheritance at the language level, most Smalltalk programmers
will define rigorous interfaces, and document which interfaces a class
implements. (In many ways, I find that the Smalltalk type system
resembles that of C++ templates. When I define a template over class
X, I will specify that this class must support operations o, p and q.
If it doesn't, the compiler will probably complain when it tries to
instantiate the template. In Smalltalk, a similar effect takes place
at runtime. If I define a method taking a parameter, I will require
that the object passed at runtime support certain operations; if it
doesn't, I will get a runtime error. In both cases, the instantiation
class / object passed as parameter must comply to a certain interface.
In neither case is there any way within the language to specify and
enforce this interface.)
--
James Kanze Tel.: (+33) 88 14 49 00 email: ka...@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
-- A la recherche d'une activité dans une region francophone
More Systems Employee
>
>More Systems Employee wrote:
>> It's not because I wouldn't love to have it. It's because
>> I CAN'T AFFORD IT. Hell, my COMPANY can't afford it. And as
>> for writing applets, not even Bill Gates couldn't afford to
>> buy a VisualWorks runtime license for every web browser
>> on the internet.
>
>Only time will tell if the Smalltalk community can get it together
>enough to make Smalltalk a viable alternative to Java.
>I sure hope so.
Hm, that is good news, but what about the price of the
development environment? a free runtime is useless if I can't
afford to make software to run in it. VisualWorks wouldn't
have to be free, but it should be a lot cheaper, and there
should be a half-decent free develoment environment that is
upwards-compatable to VisualWorks if they expect to compete
with Java.
Ideally, smalltalkers should write a smalltalk compiler for
the Java VM, co-operating with sun to enhance the VM if
neccissary. Java could gain a lot from the experience of
the Smalltalk development community, but Smalltalk programmers
could also probably learn a thing or two from Java. Given
a choice between the two, I would love to have both!
In the future, there will always be many languages. Java
the language will never take over the whole world, it just
isn't suited for every possible application. However,
I think the Java VM (or whatever grows out of it) WILL
take over the world. It is the only good way to seperate
software from the ever-changing hardware platforms, and
will save both programmers from hardware dependance and
hardware engineers from backwards compatability.
-Eugene
>-- mike
>
>mkl...@alumni.caltech.edu
dav...@ibm.net
>Quite honestly I think youre nuts :) Smalltalk is a far superior
>language to Java. Unfortunately the only problem is the
>platform-dependence. If it were "platform-independent" like Java it
>would blow java out of the water.
>
>
"Superior" is an opinion and "if" is a big chasm to cross. Java is immature, but
immature or not, it is being embraced by too wide a spectrum of software users
and creators to ignore. Look how popular that DOS/Windows piece of crap is
compared to the other functional and dependable OSs that are out there. The
majority spending the money is what is important, not technical prowess. That's
why Java will steamroller C++ and Smalltalk.
Thierry Thelliez
language is helping.
C++ has multiple inheritance, you can play with pointers and
optimise your routine ? Great for you, but a report
at OOPSLA 95 shown that only 60% of the C++ projects are
successful. The worse is that it's still dropping.
Smalltalk has a nice pure environement ? Great, but nobody can
learn that at school because of the price. For small and medium
projects, the price is a killer (think of few VisualWorks
licences + Envy + Maintenance + eventually VisualWave (>$10K) +...)
Java has a big momentum ? Great. Hoping that one day it becomes
mature (I am doing a Java application. It's a nightmare coming
from Smalltalk !). But do you really think that Java will fit
everything ? Even if Java beats everything today (I am not sure
about that ;-), other ideas will always come to make something
better.
So let's step back and look at what is hapenning. The main success
for Java comes from:
- it's cross-platform virtual machine,
- the immediate world-wide feedback you get doing some applets,
- it's price (~$0) (but your are left with your favorite text editor)
Java has introduced a virtual machine across different platforms
and also in people minds. Smalltalk failed on that (when some
years ago I was talking about VM people were scared. Today it's
ok thanks to Java). C++ is not even a player on this issue.
Maybe you prefer C++, but the point here is that Smalltalk is a
wonderful tool/language that we should not through away for the
latest 'weaving development tool'. Smalltalk should not compete
against Java. Actually I think it's too late (could you imagine
Microsoft accepting Smalltalk VM in their operating System ;-).
Smalltalk should be reimplemented on top of Java.
Here come 2 issues:
1- Instead of pushing for Java (VM + language), Sun should push
for the VM to be embedded on OS or/and hardware (from where
they make money). This would mean to concentrate on the
available bytecodes to make them general enough for different
type of applications or languages. Several vendors could
implement their own OS as long as they provide the same
interface/byte codes.
2- If we want to add the Java advantages to Smalltalk, who is going
to pay for the work ? As said in the previous messages, this
implementation should be available at very low cost, maybe free.
How can PP, IBM, VMark be interested in that ? Where can they make
money from ? Sun plans to make money on hardwares supporting Java.
What about PP ? If I get a free JavaVM-based Smalltalk, why should
I bother buying VisualWorks ? They would have to concentrate on
consulting and added products.
Few other thoughts:
Someone in Germany (sorry I forgot the name) is trying to translate
Smalltalk in Java at the source level. I think he is doing that
in Java.
At the bytecodes level, I was discussing with Jeff the possibility to
write the Smalltalk compiler in Java to produce Java bytecodes.
(like the recent ADA compiler). The problem is the funding...
Another alternative would be to do it in Smalltalk. You would have
to define the Java bytecodes in Smalltalk. This is the way taken
by Applied Reasoning Systems in North Carolina (for the GUI). It's
probably easier to do but then you are missing the Java portability
at the development level. Although what if this could 'loop' ?
(I have to think more about it...)
Thierry
--
.....................................................................
. Thierry Thelliez Los Alamos National Laboratory .
. Email: t...@lanl.gov CIC-15 .
. Voice: (505) 665 8631 MS P954 .
. Fax: (505) 665 0525 Los Alamos NM 87545 .
. URL: http://www.lanl.gov/cgi-bin/phone/113845 USA .
.....................................................................
Thaddeus L. Olczyk
> C++ has multiple inheritance, you can play with pointers and
> optimise your routine ? Great for you, but a report
> at OOPSLA 95 shown that only 60% of the C++ projects are
> successful. The worse is that it's still dropping.
Boy. A long time ago someone told me that figures don't lie, but
that liars sure can figure, but this is really sad.
According to the Gartner group ALL software projects have a failure rate
of about 80%. That means that C++ is only 3 times as efective as the
average. Such a shame that C++ can't be MORE effective, but thats life.
---------------
Thaddeus L. Olczyk
Robert J. Fenney
(David James Hanley) wrote:
> Jason Kratz (jkr...@rummy.aiss.uic.edu) wrote:
> : Dave -
>
> : Quite honestly I think youre nuts :) Smalltalk is a far superior
> : language to Java. Unfortunately the only problem is the
> : platform-dependence. If it were "platform-independent" like Java it
> : would blow java out of the water.
>
> But consider all the serious flaws with smalltalk:
>
> 1)idiotic lack of static typing.
> 2)lack of inheretence.
> 3)poor parameter passing mechanism.
> 4) etc,etc...
> :)
>
> --
> ------------------------------------------------------------------------------
> David Hanley, |______ Computer Science graduate student.
> dha...@lac.eecs.uic.edu |\ ___/__ Martial Artist. Biker. Chess Freak
> www_lac.eecs.uic.edu/~dhanley/| \\ / / Libertarian. Atheist. Bisexual.
> My employer barely KNOWS me. | \/BI/ Aspiring novelist.Joyce Kafka Neitzsche
> -----------------------------------\/-----------------------------------------
> This food product contains a glowing mass that fell from space.
I don't see the flaws were you are looking! The lack of typing is very
powerfull. there is inheritance, but no multiple inheritance which Java
does not have as well! I think the parameter passing mechanism works fine.
What are the etc's? Smalltalk has a high up frunt learning curve, Java has
the same curve because the cost of learning is for the OOPs curve not the
language.
Robert
Robert J. Fenney
dropin for Netscape that has the VM just like Java. You are still going
to have to buy the development environment, and I do agree that the
Smalltalk development environments are way to expensive.
Robert
In article <DtMKF...@world.std.com>, mor...@world.std.com (More Systems
Employee) wrote:
> In article <4qrjrl$e...@piglet.cc.uic.edu>, jkr...@rummy.aiss.uic.edu says...
> >
> >dav...@ibm.net wrote:
> >>Quite honestly, I'm waiting for VisualAge Java to appear and then all
the C++
> >>and Smalltalk stuff is gone from our company. A java application can
run on any
> >>platform where a java viewer is present. No more "cross platform" coding
> >>concerns, etc. True "data independence" for the developer and user. No more
> >>deciding to work with Mr. Bill, Scott or Lou's environment, just code
and go.
> >
> >>Dave
> >
> >Dave -
> >
> >Quite honestly I think youre nuts :) Smalltalk is a far superior
> >language to Java. Unfortunately the only problem is the
> >platform-dependence. If it were "platform-independent" like Java it
> >would blow java out of the water.
> >
> >Jason
>
> Quite honestly, I think Smalltalk would also need to be FREE to
> really compete with Java. ParcPlace VisualWorks is the best
> programming environment I have ever seen, but I don't own a
> copy, and never expect to. Why? It's not because it lacks any
> features I need. It's not because it doesn't run on my hardware.
> It's not because I wouldn't love to have it. It's because
> I CAN'T AFFORD IT. Hell, my COMPANY can't afford it. And as
> for writing applets, not even Bill Gates couldn't afford to
> buy a VisualWorks runtime license for every web browser
> on the internet.
>
> Java isn't as nifty, but it is free, so it's price/performance
> ratio is infinitely superior. That is why Java will succeed where
> Smalltalk has failed, not platform independance.
>
> -Eugene
Robert J. Fenney
Java development environment. What will happen is that there are going to
be two types of programs: netborn and custom system. The problem is that
the users are going to want the speed and look of the system custom and
the easy of the netborn and this may not be possible. They are going to be
very frustrated because they think that they are being promised
imdependance!
Robert
In article <31D1AD...@concentric.net>, "Alan L. Lovejoy"
<alov...@concentric.net> wrote:
> Jason Kratz wrote:
> >
> > dav...@ibm.net wrote:
> >
> > >In <31CC4A...@individual.com>, Jeff Sutherland
<jeff.su...@individual.com> writes:
> > >>http://www.tiac.net/users/jsuth/smallman.html
> > >>
> > >>The Smalltalk Manifesto: Avoiding RoadKill on the InfoBahn
> > >>
> > >>If you want Smalltalk to survive or build a better Java, you better read
> > >>this.
> > >>
> > >>Regards,
> > >>--
> >
> > >Quite honestly, I'm waiting for VisualAge Java to appear and then all
the C++
> > >and Smalltalk stuff is gone from our company. A java application can
run on any
> > >platform where a java viewer is present. No more "cross platform" coding
> > >concerns, etc. True "data independence" for the developer and user. No more
> > >deciding to work with Mr. Bill, Scott or Lou's environment, just code
and go.
> >
> > >Dave
> >
> > Dave -
> >
> > Quite honestly I think youre nuts :) Smalltalk is a far superior
> > language to Java. Unfortunately the only problem is the
> > platform-dependence. If it were "platform-independent" like Java it
> > would blow java out of the water.
> >
> > Jason
>
> VisualWorks already lets you code with about as much platform independence
> as you're going to get. On WinTel (OS/2, Windows XXX), Mac and the major
> Unices (SunOS, Solaris, HP-UX, AIX, Ultrix). Problem is, most PPD customers
> have been saying that THEY PREFER PLATFORM DEPENDENCE SO THAT THEIR
APPLICATIONS
> LOOK AND ACT (and interact with the host platform) COMPLETELY NATIVE!
>
> I don't see why "platform independent Java" won't encounter the same customer
> resistance that VisualWorks has on this issue. I refuse to listen to anyone
> slam Smalltalk for being "platform dependent" after all the years I've spent
> apologizing to Windows and Mac bigots for the fact that VisualWorks is so
> very platform INdependent.
>
> And anyone who honestly believes that each different Java implementation from
> each different Java vendor won't differ in important ways from all the others
> is living in Wonderland. It won't be long before there's a wild market
> frenzy for "Windows-native Java" and "Mac-native Java" so that Java
> applications will be able to fully interoperate with the full rights and
> privileges of native applications. You can take it to the bank.
>
> --
> Alan L. Lovejoy | Would you sign a contract to receive $100k term life
> al...@rwi.com | insurance for a year--for 38% of your annual
income?
> alov...@concentric.net | Then why buy government services on a similar basis?
Jason E. Kratz
>Jason Kratz (jkr...@rummy.aiss.uic.edu) wrote:
>: Dave -
>: Quite honestly I think youre nuts :) Smalltalk is a far superior
>: language to Java. Unfortunately the only problem is the
>: platform-dependence. If it were "platform-independent" like Java it
>: would blow java out of the water.
> But consider all the serious flaws with smalltalk:
> 1)idiotic lack of static typing.
I prefer dynamic typing by far. I cant speak for everyone but dynamic
typing makes programming so much easier. Of course there is a
performance hit but for me the lack in performance is worth the gain
in usablility.
> 2)lack of inheretence.
Smalltalk is an OO language - of course it has inheritance. You
probably mean multiple-inheritance which most programmers tend to
avoid like the plague anyways.
> 3)poor parameter passing mechanism.
Dont know what you mean.
> 4) etc,etc...
> :)
>--
>------------------------------------------------------------------------------
>David Hanley, |______ Computer Science graduate student.
>dha...@lac.eecs.uic.edu |\ ___/__ Martial Artist. Biker. Chess Freak
>www_lac.eecs.uic.edu/~dhanley/| \\ / / Libertarian. Atheist. Bisexual.
>My employer barely KNOWS me. | \/BI/ Aspiring novelist.Joyce Kafka Neitzsche
>-----------------------------------\/-----------------------------------------
You go to UIC huh? So do I. You must not have had Prof. Drake yet :)
If you did you would love Smalltalk after taking his OOP class :)
Jason
Jason E. Kratz
>>Quite honestly I think youre nuts :) Smalltalk is a far superior
>>language to Java. Unfortunately the only problem is the
>>platform-dependence. If it were "platform-independent" like Java it
>>would blow java out of the water.
>>
>>Jason
>>
>"Superior" is an opinion and "if" is a big chasm to cross. Java is immature, but
>immature or not, it is being embraced by too wide a spectrum of software users
>and creators to ignore. Look how popular that DOS/Windows piece of crap is
>compared to the other functional and dependable OSs that are out there. The
>majority spending the money is what is important, not technical prowess. That's
>why Java will steamroller C++ and Smalltalk.
I dont think Java will steamroller anything, especially C++. Java is
not suited to development of everything and never will be. There are
too many people out there who have spent lots of $$ out there on C++
tools and have invested too much time in training, etc. While there
is a lot of money being spent on Java development by various companies
I dont see anyone giving up on development of their C++ environments
just yet. Java hype right now almost makes one want to believe it is
the second coming of Christ. When the smoke clears and all people see
of Java applets are fancy little animations on their web pages people
will think twice. Shit, right now I can't even do a simple little
database applet because of those wonderful security restrictions.
PowerBuilder is the main development tool where I work for doing
client/server programming. Java has a *long* way to go before it even
comes close to the functionality of PB for client/server. I'm not
saying that Java will wink out of existence but eventually people will
return to their senses and realize its not going to save the world.
Jason
Joe Kinsella
>I think the manifesto is right on!
>[Kudos to Mr Sutherland! Bravo!]
I'm not sure what the kudos are for. Essentially this "manifesto"
makes the assertion that Smalltalk must: a) be free, and b) be
implemented using the Java VM.
It seems to me this is nothing more than a clever piece of marketing
("there is not space here to review all the technical problems...").
In fact, the central points of the article are just restatements of
concepts discussed almost a year ago in this forum. Its proposal now
as a "manifesto" seems rather anti-climactic.
This article also fails to offer any compelling reason WHY these 4
points are so absolute that they are a prerequisite to the success of
Smalltalk.
Speaking directly to each point:
1. Smalltalk applets must distribute over the net
Now here is a new idea! Is there a language vendor that is not
working on this?
2. Smalltalk must be free
Good idea, but someone has to pay for something somewhere! Sun can
pay for Java through licensing their VM to software and hardware
manufacturers. Since Smalltalk would sit upon the Java VM, what
exactly would be the product which produces the revenue to support
this market? It is naive to expect masses of programmers to flock to
Smalltalk like they did Java simply because it too is free?
3. Smalltalk must be standard.
Okay, sure, being a standard would be great--but how does this
guarantee the success of the language?
4. Smalltalk development tools must be used to support Java
development.
This seems like a restatement of the implicit objective of the
article--to claim Smalltalk should be implemented using the Java VM.
If we believe in this assertion, OF COURSE Smalltalk tools would be
used to support Java development!
The whole article seemed rather absurd to me...
Steven M. Laskoske
> Jason
I have to agree with this statement. Java, as good as a language as it
is, is not as strong as C++ yet. It's cross-platform power is
unfortunately balanced by the speed of interpreting the bytecode. (Yes,
I know about JIT. As good as it is, it is still not as good as a fully
compiled program.) When languages such as C++ make themselves more
suited for Web programming, I expect that Java will end up taking the
back seat. It has many strengths, but it is still in its early stages.
I feel that it might still point the way for some of the stronger, more
established, and more familiar languages in new ways to take advantage of
programming power. With the Web having grown in strength, new paradigms
in the computer industry are going to have to be made in how we write our
code...and our programming languages.
******************************************************************************
Steven Laskoske * Shakespeare's cry when he can't click an icon:
smla...@cs.millersv.edu * "Mouse of virtue answer me!"
Eternal Student * (Twelfth Night, Act I, Scene 5)
******************************************************************************
Kevin Klein
>
> I dont think Java will steamroller anything, especially C++. Java is
> not suited to development of everything and never will be. There are
> too many people out there who have spent lots of $$ out there on C++
> tools and have invested too much time in training, etc. While there
> is a lot of money being spent on Java development by various companies
> I dont see anyone giving up on development of their C++ environments
> just yet. Java hype right now almost makes one want to believe it is
> the second coming of Christ. When the smoke clears and all people see
> of Java applets are fancy little animations on their web pages people
> will think twice. Shit, right now I can't even do a simple little
> database applet because of those wonderful security restrictions.
> PowerBuilder is the main development tool where I work for doing
> client/server programming. Java has a *long* way to go before it even
> comes close to the functionality of PB for client/server. I'm not
> saying that Java will wink out of existence but eventually people will
> return to their senses and realize its not going to save the world.
I dont think C++ will steamroller anything, especially COBOL. C++ is
not suited to development of everything and never will be. There are
too many people out there who have spent lots of $$ out there on COBOL
tools and have invested too much time in training, etc. While there
is a lot of money being spent on C++ development by various companies
I dont see anyone giving up on development of their COBOL environments
just yet. C++ hype right now almost makes one want to believe it is
the second coming of Christ. When the smoke clears and all people see
of C++ applications are fancy little GUI's on their PC's people
will think twice. Shit, right now I can't even do a simple little
database application because of the lack of built-in ISAM support.
PowerBuilder is the main development tool where I work for doing
client/server programming. C++ has a *long* way to go before it even
comes close to the productivity of PB for client/server. I'm not
saying that C++ will wink out of existence but eventually people will
return to their senses and realize its not going to save the world.
(Ya know, I thought this argument sounded familiar)
The moral of the story:
The marketplace ultimately doesn't give two beans about the technical
merits of one language versus another. If it did, Next would have
purchased Microsoft by now.
-------------------------------------------------------------
Kevin Klein http://www.execpc.com/~kklein
Strong Capital Management mailto:kkl...@execpc.com
Milwaukee, Wisconsin
Peter Day
<kins...@tiac.net> writes.........>
>
>The whole article seemed rather absurd to me...
>
>Joe
>kins...@tiac.net
>
What is all this stuff about 'free' software. Smalltalk will never be
free - and Java won't be free much longer. Sure SUN have an interest in
promoting it so they can sell more servers but who really believes
Microsoft, IBM or anyone else is going to give Java away for free. Once
we see a real price on the stuff we can make meaningful comparisons on
price/performance.
But in reality we now have another language to use for development and
it only serves to make the language wars more ridiculous
Peter Day
Bloomsbury Software
3-6 Alfred Place
London
WC1E 7EB
UK
Phone: +44 171 436 9481
Fax: +44 171 436 0524
http://www.bloomsbury.co.uk/software
IBM BestTeam partners in the UK for IBM Smalltalk & VisualAge for Smalltalk
Smalltalk specialist for over 5 years - we supply and support the software
and provide training and mentoring services
Dave Smith
>
> The biggest problem I have seen on C++ projects is that people expect
> to be able to do too much with C++. In fact, this is evident even in
> the standard libraries and STL. If you use C++ as a notational
> convenience for good design principles you would already have applied
> in C (yes, people write lots of "object oriented" C) and don't try to
> build completely general class libraries for everything, C++ is an
> effective tool (albeit, an enormously complicated one).
I agree with you fully. In the context of this thread, it's interesting that Java (the
monster success story so far--) is really simple (or simplified) compared with C++. It
is the simplification (or purification) which has drawn many, not the portability,
which is only an implementation (tech) issue. Productivity is a powerful engine.
(And Project failure has a funny way of dampening one's enthusiasm for a language!)
I would like to make the case for a _compile-time_ Java. (Not to mention a compile-time
smalltalk translator). Notice that some on this thread have said, in effect, "just wait
until MS gets its hands on Java, the language will be changed, portability destroyed,
etc." But this is only half the story. Strong-Java has a lot of potential, not as an
interpreted language competing with Smalltalk, but perhaps as the destroyer of C/C++.
(I.e., Java will not kill Smalltalk--but perhaps eventually it will finally kill C/C++
--And good riddence!).
Regards,
DS
Marcus Rugger
I like that. That's good.
I don't believe any language will ever replace another. That's not the way
technology works. Languages are tools, nothing more. Perhaps people thought
power saws would replace hand saws, but you can still buy them. Or in the
automobile industry, there are trucks, cars, sports cars...etc. All suiting a
different purpose. When a car is designed to be a good sports car, it's
sacrificed the ability to haul things as well as a truck.
Languages die when they are no longer usefull. Not because another slicker
language comes along.
And too, the end user couldn't give a hill of beans for what programming
language something was written in.
Marcus
Dann Corbit
Look at the 'ancient' languages like BASIC, FORTRAN
and COBOL. They are still being used by millions of
people. C++ has not replaced C. Java will not eliminate
C++. Are you going to write an operating system in Java?
Programming languages are tools to accomplish and end
result. Like any other kind of work, use the right tool for
the right job.
Some tools get thrown to the back of the toolbox. But
when they are needed, we are sure glad they were in there.
> Dave Smith <da...@terracom.net> wrote in article
<31D410...@terracom.net>...
{snippage}
More Systems Employee
>
>Platform independence has been a programmer issue primarily, not a user issue. It has
>little commercial value on the client side. This is what your customer complaints
>really amount to--"I don't care if it works on some other machine, on MY machine I
>want it to do (platform dependent fill in the blank)". Most people don't have five
>brands of computers or five operating systems; they have one. They don't give two
farts
>if their app might also run on another machine.
Each individual user may not understand or care about platform-independance, but
it would be foolish to think that their lack of interest is the same as a lack
of importance. The users of brand X, Y, and Z computers will all get the software
faster, and thus be happier, if the developer can write code for all three at
once. Each user only cares about himself, but in the end it will be the
platform independance that makes them all happier, whether they know or care
why they got the code so fast.
>Historically only developers have a
>real interest in cross platform independence. So, Smalltalk portability as it turns
out
>is totally different in character from Java portability, which is CRITICAL to its
whole
>functionality. It is NOT critical to smalltalk as a language in any way. This is the
>difference. The web protocols require small, portable modules and will continue to do
>so until there is radical hardware change in world infrastructure.
Smalltalk is at least as portable as Java, and it is important to both languages.
Java does seem to have a head-start on loading classes over the network, but
I doubt it would be impossible to add it to Smalltalk. The real killer for
Smalltalk has been the exorbant prices, but that shows signs of changing.
Let's hope it's not too little, too late.
More Systems Employee
>
>1- Instead of pushing for Java (VM + language), Sun should push
>for the VM to be embedded on OS or/and hardware (from where
>they make money). This would mean to concentrate on the
>available bytecodes to make them general enough for different
>type of applications or languages. Several vendors could
>implement their own OS as long as they provide the same
>interface/byte codes.
I agree that the VM is more important than the language, and that
it should be expanded for use by other languages, but there's no
reason not to distribute the language with the VM. The important
thing is to get the VM running everywhere, and including the
language only makes it more accessable.
dav...@ibm.net
>for the VM to be embedded on OS or/and hardware (from where
>they make money). This would mean to concentrate on the
>available bytecodes to make them general enough for different
>type of applications or languages. Several vendors could
>implement their own OS as long as they provide the same
>interface/byte codes.
The new version of OS/2, Merlin, has Java enabled at the operating system level.
Vadim Lebedev
........
>
> Calls to methods in superclasses should never need to
> reference the name of the superclass directly, but in
> C++, this is the only way to do it. Again, if I decide to
> change the class hierarchy, I have many changes to
> make, all of them completely unnecessary if the language
> supported a simple 'super'.
David here's the sample trick which can make your life easier:
class A
{
public:
x();
};
class B: public A
{
typedef B super;
void x() { super::x(); }
}
super is missing from C++ because of MI,
suppose you had a super keyword from C++, what you'll expect
from the following code:
class a1
{
public:
int a;
};
class a2
{
public:
int a;
};
class b: a1, a2
{
public:
int geta() { return super::a; } // ?????
};
Vadim.
Marcus Rugger
>
>>Quite honestly I think youre nuts :) Smalltalk is a far superior
>>language to Java. Unfortunately the only problem is the
>>platform-dependence. If it were "platform-independent" like Java it
>>would blow java out of the water.
>>
>>Jason
>>
>
> but
>immature or not, it is being embraced by too wide a spectrum of software users
>and creators to ignore. Look how popular that DOS/Windows piece of crap is
>compared to the other functional and dependable OSs that are out there. The
>majority spending the money is what is important, not technical prowess. That's
>why Java will steamroller C++ and Smalltalk.
>
Java isn't going to steamroll over any language. And no languages are going
to steamroll over Java. As I said in an earlier post, a particular
programming language is going to be used for as long as it's useful.
C/C++ is useful today and will be for the forseeable future. On any platform,
I don't care what it is or what the OS is, there has to be code that actually
manipulates hardware. That code is either written in C or assembly language
or both. For example, Java makes it extremely simple to write to system out
(System.out.println("Hello World.");). But it's taking advantage of a system
service that's probably written in C.
Somebody else noted that database management isn't spec'ed into the C/C++
language. Ok, true. But in the languages in which it is, those specific
methods/functions are probably making calls to routines that are written in
C/C++.
I'm not belittling any language here, nor am I trying to place C/C++ on an
alter. I'm just saying that languages are tools and you choose the right one
for the job. Java can't and won't replace C/C++, even if java fullfills it's
every dream.
Marcus
Jason E. Kratz
>Jason E. Kratz wrote:
>I dont think C++ will steamroller anything, especially COBOL. C++ is
>not suited to development of everything and never will be. There are
>too many people out there who have spent lots of $$ out there on COBOL
>tools and have invested too much time in training, etc. While there
>is a lot of money being spent on C++ development by various companies
>I dont see anyone giving up on development of their COBOL environments
>just yet. C++ hype right now almost makes one want to believe it is
>the second coming of Christ. When the smoke clears and all people see
>of C++ applications are fancy little GUI's on their PC's people
>will think twice. Shit, right now I can't even do a simple little
>database application because of the lack of built-in ISAM support.
>PowerBuilder is the main development tool where I work for doing
>client/server programming. C++ has a *long* way to go before it even
>comes close to the productivity of PB for client/server. I'm not
>saying that C++ will wink out of existence but eventually people will
>return to their senses and realize its not going to save the world.
You could have made your point in a lot fewer lines. Copying my post
word for word then adding only a few real lines of your own was really
unnecessary. All you did was back up the point I was trying to make.
Try to do it in few less words the next time. And actually C++
doesnt have a long way to go before it comes close to PB. There is
plenty of good stuff out there to do DB apps in C++. But thats
another story..... ;)
>(Ya know, I thought this argument sounded familiar)
>The moral of the story:
>The marketplace ultimately doesn't give two beans about the technical
>merits of one language versus another. If it did, Next would have
>purchased Microsoft by now.
Sure. The marketplace doesnt care. This isnt the marketplace though.
This is a newsgroup that talks about the technical merits of Java
and/or other languages.
>-------------------------------------------------------------
>Kevin Klein http://www.execpc.com/~kklein
>Strong Capital Management mailto:kkl...@execpc.com
>Milwaukee, Wisconsin
Jason
John Whitney
> >Quite honestly, I'm waiting for VisualAge Java to appear and then all the C++
> >and Smalltalk stuff is gone from our company. A java application can run on any
> >platform where a java viewer is present. No more "cross platform" coding
> >concerns, etc. True "data independence" for the developer and user. No more
> >deciding to work with Mr. Bill, Scott or Lou's environment, just code and go.
>
> >Dave
>
> Dave -
>
> language to Java. Unfortunately the only problem is the
> platform-dependence. If it were "platform-independent" like Java it
> would blow java out of the water.
>
> Jason
I love Smalltalk.... But, lets face it, the C++ people are not going to choose
Smalltalk over Java. It doesn't matter how great Smalltalk is technically. It
doesn't matter how wonderful the tools are. I don't even think the cost of the
system is the most limiting factor. The problem is that Smalltalk is too
different from traditional languages, and it is perceived as an old, clunky
language that requires a lot of resources to run. Is it likely that this
perception is going to change? I hope so, but I don't believe it will. I will
be suprised if Smalltalk ever becomes a mainstream language. I hope I'm wrong.
But we cannot under estimate the power of the mass market forces. I think even
the name of the language itself adds to the perception problem as well. Even if
Smalltalk is ported so that it generates Java byte codes, why would a C++
programmer choose it over Java? Java is going to be tremendously successful, not
because it is such an incredible language, but because a huge market is being
created around it and the web. The only way that Smalltalk has a chance is if
many companies are able to make the paradigm shift to OO modeling of their
business. So far, this has not happened in the large. People who love Smalltalk
are the ones that have made the paradigm shift. Unfortunately, very few have
made this shift, and this also is holding the language back. Even though Java is
not ready for prime time today, I believe it will rapidly make this transition
within the next two years. The market support is just too strong. When everyone
does make the OO paradigm shift (which Java will demand), I believe that
Smalltalk will not be the language of choice because the market for Java will be
too strong by that time.
Just my opinions of course, but I think we need a reality check.
--John Whitney
Alan L. Lovejoy
>
> Smalltalk is at least as portable as Java, and it is important to both languages.
> Java does seem to have a head-start on loading classes over the network, but
> I doubt it would be impossible to add it to Smalltalk.
Smalltalk object transport has been done. Many times, even many years ago.
PPD has BOSS and "parcels." QKS has "PIPOs." I believe the other vendors
have similar technologies. I have my own proprietary system, as I know others
do. Sending and receiving objects over the net is just as easy as transporting
raw bytes, once you have a way of encoding/decoding objects as streams of bytes.
Java's only advantage is that it has grabbed prominent "shelf space" on the
Netscape Navigator and in the HTML standard. Smalltalk's problem is not
technical, but rather that it has not been invited to the party by the
current "in" crowd. And although there are many ways--not hard to obtain,
duplicate or invent--for sending Smalltalk classes, methods and other binary
encoded objects over the net, there is no **standard** for it--yet.
Unfortunately, although implementing Smalltalk object transport over the
net may be criminally easy--agreeing on the necessary standards may be
criminally difficult.
>..The real killer for
> Smalltalk has been the exorbant prices, but that shows signs of changing.
> Let's hope it's not too little, too late.
Yep.
jos...@iinet.net.au
>Unfortunately, although implementing Smalltalk object transport over the
>net may be criminally easy--agreeing on the necessary standards may be
>criminally difficult.
Nope. It'd here already.
By the grace of CORBA and the engineers of IBM, it's called SOM/DSOM.
--
Joe Katnic, Perth, Western Australia _--_|\
/ \
Jos...@iinet.com.au -------------------------------------------->\_.--._/
v
Poco...@mail.apci.net
>> Smalltalk is at least as portable as Java, and it is important to both languages.
>> Java does seem to have a head-start on loading classes over the network, but
>> I doubt it would be impossible to add it to Smalltalk.
>
>Smalltalk object transport has been done. Many times, even many years ago.
>PPD has BOSS and "parcels." QKS has "PIPOs." I believe the other vendors
>have similar technologies. I have my own proprietary system, as I know others
>do. Sending and receiving objects over the net is just as easy as transporting
>raw bytes, once you have a way of encoding/decoding objects as streams of bytes.
>
IBM Smalltalk uses an ObjectLoader and ObjectDumper for loading and unloading of
Objects (including Classes). I have not yet tried to use that for loading objects into
an image that did not already have the classes defined in them. Does this work?
If it does, I think it would be not too difficult to work a manner for a page to have a
link to a file that would be your application classes dumped out. Download the
classes and object and import them into your image. A Smalltalk capable browser
that could help automate some of this process would be ideal.
Incidentally, IBM ST also has Distributed Smalltalk. Looking at it's structure, I would say
that this is a more powerful approach to building more robust MIS based Intranet
applications.
I've been thinking that Java is structurtally very similar to ST in certain respects.
The idea of a VM executing a class library (image) being the biggest. One major
advantage of ST (not as a language but as a development tool) is
the maturity of ST itself as well as the depth of the architectures available.
Being used to IBM ST or VisualAge makes Java painful to program in, by
comparison. I would rather see a Web distribution method for Smalltalk
classes/applications than Java.
* more stuff clipped *
>--
>Alan L. Lovejoy | Would you sign a contract to receive $100k term life
>al...@rwi.com | insurance for a year--for 38% of your annual income?
>alov...@concentric.net | Then why buy government services on a similar basis?
James O'Connor
oco...@apci.net
Jeff Sutherland
>
> Dave Smith <da...@terracom.net> wrote:
>
> >I think the manifesto is right on!
>
>
> I'm not sure what the kudos are for. Essentially this "manifesto"
> makes the assertion that Smalltalk must: a) be free, and b) be
> implemented using the Java VM.
>
> It seems to me this is nothing more than a clever piece of marketing
> ("there is not space here to review all the technical problems...").
> In fact, the central points of the article are just restatements of
> concepts discussed almost a year ago in this forum. Its proposal now
> as a "manifesto" seems rather anti-climactic.
>
> This article also fails to offer any compelling reason WHY these 4
> points are so absolute that they are a prerequisite to the success of
> Smalltalk.
>
> kins...@tiac.net
Joe might have been right about this if we still worked together at Easel
or VMARK. What he doesn't realize (maybe) is that I no longer work for a
Smalltalk company. I work for an Internet company where I am driving all
the development towards Java.
I am currently living on Internet time and I can tell you, Smalltalk is
already history. I wish it were otherwise.
The manifesto is a last call to the Smalltalk community. If the troops do
not rally now, it will be too late to resurrect Smalltalk for the Internet
in any significant way.
Joe is right that nothing new is said! I am not trying to say anything
hew. The manifesto is a call to action. The problem is that nothing has
happened. Making something happen would be new and it could save
Smalltalk, or at least the best of it, from the ashbin of history.
--
Jeff Sutherland
mailto:jeff.su...@individual.com
http://www.tiac.net/users/jsuth/
"Check out Freeloader at http://www.freeloader.com/"
Marcus Rugger
<4qrahn$49...@news-s01.ny.us.ibm.net><4qrjrl$e...@piglet.cc.uic.edu>
<DtMKF...@world.std.com><31D1B5...@alumni.caltech.edu>
<Dto2q...@world.std.com><31D30D...@lanl.gov>
<TMB.96Ju...@best.best.com> <31D410...@terracom.net>
<01bb651d.bc032400$fbe3369d@v-cnadc1> wrote:
>In article <01bb651d.bc032400$fbe3369d@v-cnadc1> "Dann Corbit"
> <a-c...@microsoft.com> writes:
>
> It is a myth that a new language will destroy an old one.
> Look at the 'ancient' languages like BASIC, FORTRAN
> and COBOL. They are still being used by millions of
> people.
>
>those languages you mention, Basic, Fortran, and COBOL, have remained
>the same in name only. Even COBOL has acquired lots of advanced
>functional, OO, and message passing functionality through extensions
>like embedded SQL an CICS (albeit with a syntax that only a mother
>could love).
>
> C++ has not replaced C.
>
>old, tired languages don't disappear, but because there are specific
>problems in fully adopting C++ over C, despite all the efforts at
>backwards compatibility to the contrary.
>
> Java will not eliminate C++.
>
>disappears, at least if your company lets it: based on conversations I
>have had with developers at lots of companies, except for Microsoft,
>few large companies are very enthusiastic about C++. C++ clearly can
>be a more effective tool than C, but it is a very complex tool, in
>particular given the only moderate improvement in functionality and
>security it provides over C.
I disagree, no language comes along and replaces an existing one. As I've
said before, a language is a tool, and it will continue to be used for as long
as it's useful. Shifts in programming paradigms is more of what causes an
existing language to become less useful. When this happens, migrations to
newer languages better suiting that paradigm do infact occur. But this
migration will be to many languages, not just to one.
Point and case:
In the early days on the PC when DOS was just a thin layer between the
application and the hardware, C was a very ideal language for sophistated
applications. But today we have OS's that provide many layers of abstraction
between an application and the hardware. Modern OS's provide more system
services than you can shake a stick at. Today, you can write an extremely
sophisticated application that can present a graphical interface to the user,
communicate over the internet, manage extensive databases, print, scan and all
other sorts of tasks and never come close to 'touching' a piece of hardware.
In environments such as this, the low level of control offered by C/C++ simply
isn't needed. The tool is losing it's usefulness for application development.
In other words, where C/C++ is strong, is no longer needed (for application
development).
So it's natural that application developers would begin to choose other
languages that better suited their needs in todays world. Languages that
depend upon all these system services being there.
>
> Are you going to write an operating system in Java?
>
>Why not? The portable semantics of C++ are nearly as strict as those
>of Java. It only happens to be the case that there is a long history
>of de-facto standards for low level, unportable operations in C/C++,
>standards, one might add, Microsoft system- and compiler software has
>found necessary to amend and change in numerous ways anyway. Whether
>that approach is desirable or not in the long run remains to be seen.
>
>Operating systems written in languages analogous to Java, have simply
>taken the approach that unportable operations should be explicitly
>marked as such and be relegated to easily identifiable packages and/or
>named operations. Such an approach also makes it easier to port
>system software between incompatible architectures, compared to the
>C/C++ approach.
Java is very much a language that depends upon all those above mentioned
layers of abstraction being in place. You can't write those layers in a
language that depends upon them already existing. The 'unportable operations
in C/C++' that you mentioned are library routines written (in C) to make it
easier to use platform specific features of an existing OS, not to help write
one. Even the file i/o of the standard C library depends on the OS being
there. In other words, before you can even write the standard C library for
your new OS, a good portion of the OS must already exist. Until then, you're
writing C code that depends on no libraries what so ever, other than what
you've put together.
This is the strength of C, and is why Java is totally incapable of replacing
it. C code (with the aid of a little assembly code) can live in a world with
no system services what so ever. From there, in C, you can build those system
services to the point that you can finally create your standard C library and,
from there, you're off and running. At this point, you could if you desired,
build in the JavaVM (in C) and then develop the higher level code in Java.
But also, at this point, you've got a full fledged OS in place. You've
written code to manage memory, manipulate hard drives, floppy drives, serial
ports, parallel ports, video. On top of that layer you've build another
layer, low level file i/o (the creation of your file system). On top of that
layer you've built another layer, high level file i/o (streams! now you can
finally open file in Java).
This is all a very over simplistic explanation to be sure. But the point is,
before Java code can even be executed, a good amount of OS already has to
exist. And to write that code you need C and/or assembly code.
Marcus
Joe Kinsella
>What he doesn't realize (maybe) is that I no longer work for a
>Smalltalk company.
I realize you are at Individual in Burlington, MA.
>I am currently living on Internet time and I can tell you, Smalltalk is
>already history. I wish it were otherwise.
It seems we agree here. Long before leaving the Smalltalk industry, I
too realized it was doomed. It is a shame since ST is still one of
the finest languages/environments I have used. But I do not believe
its death is in any way related to Java or the Internet. The Internet
is just one of several market opportunities Smalltalk missed over its
lifetime--and Java is just one of the many competitors to show us how
things should have been done.
>The manifesto is a last call to the Smalltalk community. If the troops do
>not rally now, it will be too late to resurrect Smalltalk for the Internet
>in any significant way.
I understand your purpose but I question your reasoning. Do you
honestly feel ANY Smalltalk vendor can act on your recommendation?
And even if they could, what support can you provide that these
changes would result in success? Even if these ideas were productized
in the next six months, I still don't see a business model that could
profitably support this venture.
>The manifesto is a call to action. The problem is that nothing has
>happened. Making something happen would be new and it could save
>Smalltalk, or at least the best of it, from the ashbin of history.
I did feel a faint pulse in the Smalltalk industry in the past couple
months: PPD eliminated runtimes, a new company is releasing a light
weight Windows-only Smalltalk, and PPD is joining the Java craze with
Parts for Java. But as a ST pessimist, I think it is too little too
late. My recommendation for vendors is to treat their market as a
late majority market. There is still significant service revenue
(consulting/training) to squeeze from it in the next several
years--but I would immediately begin to shift development resources
into new, emerging technologies (hey, OO COBOL isn't looking so bad
these days!).
I don't see much hope in saving Smalltalk the language. But I am
certain the "best of it" will never reach the ashbin of history.
Those of us who worked with Smalltalk will bring our experience
forward whereever we work.
Joe
David James Hanley
: As most langauges, most ST dialects *have* weaknesses: E.g.
: - handling of OS threads
That is, I think, implementation-dependant.
: - large footprint for small projects (not for large ones)
Hmm.. I've seem some pretty huge large ST projects. In any
case, don't you feel that this is due to the lack of static typing?
In smalltalk, if we call a foo() method, we must include in our distribution
every possible foo method. In a statically typed system, when we say
car.foo() we only need to include the foo method of car( and it's
descendants ). This can be important when dealing with system libraries.
--
------------------------------------------------------------------------------
David Hanley, |______ Computer Science graduate student.
dha...@lac.eecs.uic.edu |\ ___/__ Martial Artist. Biker. Chess Freak
www_lac.eecs.uic.edu/~dhanley/| \\ / / Libertarian. Atheist. Bisexual.
My employer barely KNOWS me. | \/BI/ Aspiring novelist.Joyce Kafka Neitzsche
-----------------------------------\/-----------------------------------------
All these moments will be lost. Like tears in rain. Time to die.
-Roy Batty "Blade runner"
David James Hanley
: I don't see the flaws were you are looking!
My post was heavily sarcastic, because I was replying to a post
which said, as a blanket statement, that smalltalk is better than java.
: The lack of typing is very
: powerfull.
eek. Still think it's a major flaw.
: there is inheritance, but no multiple inheritance which Java
: does not have as well!
Interfaces are multiple inheretence of interface, which works
fine for me.
: I think the parameter passing mechanism works fine.
: What are the etc's? Smalltalk has a high up frunt learning curve, Java has
: the same curve because the cost of learning is for the OOPs curve not the
: language.
Hmm. Coning from C it's not too bad, because of the similar
syntax. Coming from C++ it's a trivial transition, especially if you are
a C coder that avoided some of the gorier language features. They'd
probably be similarly diffucult languages to learn from scratch.
David James Hanley
: > But consider all the serious flaws with smalltalk:
: >
: > 1)idiotic lack of static typing.
: <<soapbox mode on>>
: The lack of static typing is onr of the single greatest features of
: the Smalltalk language.
Yes. One of the single greatest bad features. :)
: I'm currently developing an application
: in C++ (currently >51,000 lines of code) and the static typing
: is seriously hindering the development. Static typing and a
: true object-oriented environment are mutually incompatible.
Gosh. I never saw that in the oop definition table. Strange,
then, that so much oop code has been written in statically typed systems.
: The way that C++ does its method calls is idiotic. It relies on
: the static type system to give it the information it needs for
: making the call (i.e., the index into the virtual table).
This is the right way to do it. In smalltalk, Everything is
an object of type "foo". When I get a foo, I don't know what the heck it is.
I have no guarantees, and neither does the compiler.
: This means
: that all variables and all parameters must be staticly typed.
: When you do this, it makes generalization and specialization
: of methods virtually impossible.
Gosh. All that staticially typed general code I have must be a
figment of my imagination, then.
: If I have 200 methods that
: all expect to take a particular type of parameter, then I
: decide that I want to generalize the parameter to better
: isolate the functionality I'm actually using, I have 400 changes
: to make throughout the system (the class declaration and
: the method itself).
No excuse for poorly thought-out design.
: Calls to methods in superclasses should never need to
: reference the name of the superclass directly,
Why not? Is this one of the other secret rules of oop I was
otherwise unaware of? :)
: Normally, class declarations in C++ are placed in .h files
: and code in .cpp files. If I decide to change a .h file to
: add one method in (even if it's not called), I must then
: re-compile everything that includes that header file
: and re-link in order to run.
Yes, this is a problem with C++ but it is orthagonal the
the static/dynamic type checking issue.
: This is the biggest productivity
: destroyer of all times.
No, that's DOOM. :)
: On my system, a 90 MHz Pentium.
: to re-compile and re-link all of the code takes ~20
: minutes. This delay really destroys any momentum you
: develop while coding and is a complete waste of time.
That has more to do with the structure of C++ ( headers, templates,
weird syntax, etc ) than any static typing issue. The same code in java
would (on the symantyc compiler) take about 20 seconds to compile.
Modula-3, eiffel, SML, and others are all statically typed languages that
compile very quickly.
: If I was able to develop this application in Smalltalk,
: I could probably do it in less than 20,000 lines of code and
: it would me MUCH more maintainable.
That's true of about any language aside from C++.
: It's no wonder that
: people who don't use Smalltalk concentrate so much on
: up-front design.
because up-front design is a good idea? :)
: The language forces your code to be so
: brittle that changes after the fact are virtually impossible.
uh-huh.
David James Hanley
: I dont think Java will steamroller anything, especially C++. Java is
: not suited to development of everything and never will be.
Java is suited to everything that C++ does, excepting
system-level stuff. Maybe you're thinking of applets instead of
applications?
: There are
: too many people out there who have spent lots of $$ out there on C++
: tools and have invested too much time in training, etc.
Going from C++ to java is trivial.
: While there
: is a lot of money being spent on Java development by various companies
: I dont see anyone giving up on development of their C++ environments
: just yet. Java hype right now almost makes one want to believe it is
: the second coming of Christ. When the smoke clears and all people see
: of Java applets are fancy little animations on their web pages people
: will think twice.
That is not even the case for java applets now, and will become
less the case very soon.
: Shit, right now I can't even do a simple little
: database applet because of those wonderful security restrictions.
Shit, I've already done that. Guess I must be using magic.
: PowerBuilder is the main development tool where I work for doing
: client/server programming. Java has a *long* way to go before it even
: comes close to the functionality of PB for client/server.
I think you're getting development enviornments, libraries,
and language features mixed up.
: I'm not
: saying that Java will wink out of existence but eventually people will
: return to their senses and realize its not going to save the world.
No one said that, but people will also eventually realize it's
vastly better than C++.
Dave Smith
Can you say more about this? I.e., can you tell me where to find out
more?
Regards,
DS
Jason E. Kratz
>Jason E. Kratz (jkr...@tezcat.com) wrote:
>: I dont think Java will steamroller anything, especially C++. Java is
>: not suited to development of everything and never will be.
> Java is suited to everything that C++ does, excepting
>system-level stuff. Maybe you're thinking of applets instead of
>applications?
It doesnt make a difference. And you proved my point. You said that
Java isnt suited to system development stuff.
>: There are
>: too many people out there who have spent lots of $$ out there on C++
>: tools and have invested too much time in training, etc.
> Going from C++ to java is trivial.
The learning curve alone isnt important. You are right - learning
Java itself coming from C++ is trivial. However many dev. houses
wont switch because of the amount of *money* involved in both tools
and training. If you dont think this is true you're deluding
yourself. At this point in time there is no reason to switch because
the tools out there for Java development are horrible. Not to say
they wont get better, I'm sure they will, right now they are crap.
>: While there
>: is a lot of money being spent on Java development by various companies
>: I dont see anyone giving up on development of their C++ environments
>: just yet. Java hype right now almost makes one want to believe it is
>: the second coming of Christ. When the smoke clears and all people see
>: of Java applets are fancy little animations on their web pages people
>: will think twice.
> That is not even the case for java applets now, and will become
>less the case very soon.
It isnt? How come when I go to a site like Gamelan most of the stuff
I see there is used to "pretty up" web pages? How come the only thing
I see on most web pages that are "javatized" are only things that
pretty them up? Until the tools get better thats all that will
happen.
>: Shit, right now I can't even do a simple little
>: database applet because of those wonderful security restrictions.
> Shit, I've already done that. Guess I must be using magic.
You must be if you've done it the way I did it. Try taking the
SimpleSelect.java program from the Sun JDBC stuf and turn it into an
applet. Then use the JDBC-ODBC bridge to access your database. Have
the applet be served from one machine and have the database on
another? Does that make a difference? No - not at all. Loading the
*dll* that is used for the bridge is illegal in current
implementations of Netscape and MSIE. Even if it werent having the
database on one machine and the applet being served from another is
illegal. Until those issues are dealt with its useless in that
respect. Sure I can write my own client-server deal but I said
simple.
>: PowerBuilder is the main development tool where I work for doing
>: client/server programming. Java has a *long* way to go before it even
>: comes close to the functionality of PB for client/server.
> I think you're getting development enviornments, libraries,
>and language features mixed up.
I'm not mixing anything up at all. As a whole Java sucks at this
point. When it gets a little more mature it will probably be good.
Right now it is a nice toy.
>: I'm not
>: saying that Java will wink out of existence but eventually people will
>: return to their senses and realize its not going to save the world.
> No one said that, but people will also eventually realize it's
>vastly better than C++.
No one said that? are you crazy? the hype out there shows that is
*exactly* what people are saying. I'll point out that Java being
vastly better than C++ is your opinion. I have nothing against Java.
I hope it succeeds. What I do have a problem with is people spelling
out the doom of C++ and other languages just because Java is here. It
wont happen. Its about as stupid as people thinking that MS wont be
able to make money off of programs like Word anymore because people
can run Java applets over the web. that is just plain ridiculous.
Jason
Jason E. Kratz
> Interfaces are multiple inheretence of interface, which works
>fine for me.
This makes no sense at all. Interfaces arent multiple inheritance.
They give you multiple inheritance-like features but they are not the
same thing.
Jason
Jason E. Kratz
>: The way that C++ does its method calls is idiotic. It relies on
>: the static type system to give it the information it needs for
>: making the call (i.e., the index into the virtual table).
> This is the right way to do it. In smalltalk, Everything is
>an object of type "foo". When I get a foo, I don't know what the heck it is.
>I have no guarantees, and neither does the compiler.
Wrong wrong wrong wrong wrong. In Smalltalk every object is whatever
you defined it to be. If you are referring to variables every
variable in Smalltalk is a reference to an object. Think of it as
every variable is a pointer to an object. In Smalltalk you always
know what you have. It is stored with each object and you can always
query the object about what its type is. Ex: I have a function that
passes back an object. You can always query the object that was
returned what type it is.
>: This means
>: that all variables and all parameters must be staticly typed.
>: When you do this, it makes generalization and specialization
>: of methods virtually impossible.
> Gosh. All that staticially typed general code I have must be a
>figment of my imagination, then.
You have to do a lot of work to make code in C++ general. In Smalltalk
its trivial because of dynamic typing.
>: If I have 200 methods that
>: all expect to take a particular type of parameter, then I
>: decide that I want to generalize the parameter to better
>: isolate the functionality I'm actually using, I have 400 changes
>: to make throughout the system (the class declaration and
>: the method itself).
> No excuse for poorly thought-out design.
Poor thought-out design has nothing to do with it.
[stuff deleted]
>: It's no wonder that
>: people who don't use Smalltalk concentrate so much on
>: up-front design.
> because up-front design is a good idea? :)
Sure it is a good idea. With Smalltalk you have fewer issues related
to the design to worry about. You spend more time coding and less time
figuring out the details of whats going on behind the scenes.
Jason
Jeff Dege
: > This is the right way to do it. In smalltalk, Everything is
: >I have no guarantees, and neither does the compiler.
:
: Wrong wrong wrong wrong wrong. In Smalltalk every object is whatever
: you defined it to be. If you are referring to variables every
: variable in Smalltalk is a reference to an object. Think of it as
: every variable is a pointer to an object. In Smalltalk you always
: know what you have. It is stored with each object and you can always
: query the object about what its type is. Ex: I have a function that
: passes back an object. You can always query the object that was
: returned what type it is.
Are you aware of how truly evil a construct that is? If I have
code scattered about that queries the type of an object scattered
all over my system, then I have umpteen gadzillion places that
I have to examine for change when I add a new type of object.
--
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
Alan L. Lovejoy
>
> In article <31D4F8...@concentric.net> "Alan L. Lovejoy" <alov...@concentric.net> writes:
>
> Java's only advantage is that it has grabbed prominent "shelf space" on the
> Netscape Navigator and in the HTML standard. Smalltalk's problem is not
> technical, but rather that it has not been invited to the party by the
> current "in" crowd.
>
> support for static typing, the size and complexity of its runtime, and
> the lack of standard thread support. Java, of course, also has its
> share of technical problems. But the market seems to prefer Java's
> problems to Smalltalk's, and that may well be a rational decision.
1) Dynamic typing is a strategic advantage (technically if not politically).
Why do you think HP implemented Distrubuted Smalltalk and not Distributed C++?
2) The size and complexity of the Smalltalk runtime have to do with its
history and tradition, not with any technical constraints. And the new
SmalltalkMT apparently solves this problem. Check out:
http://www.objectconnect.com/intro.htm
3) SmalltalkMT and SmalltalkAgents use standard OS threads. All Smalltalks
have threads (Processes), of course.
Smalltalk has historically had the problem of "rolling its own" GUI/graphics
system, its own thread/process facility, its own Signal/Exception mechanism,
its own virtual machine/bytecode specification, etc, long before these things
became standardidized in the popular operating systems, and then being criticized
by smart alecks later because it's "not standard." I refuse to apologize for
being the first, for being the innovator, for blazing the first trail. On the
other hand, the Smalltalk vendors should have been faster to recognize when it
was time to go with the flow. "You can tell the pioneers because they're the
ones with the arrows in their backs."
Joe Kinsella
"Alan L. Lovejoy" <alov...@concentric.net> wrote:
>Smalltalk's problem is not technical, but rather that it has not
>been invited to the party by the current "in" crowd.
Quite to contrary--Smalltalk would have been invited but it was too
FAT to get through the door!
Let's be honest here: the currently implementations of Smalltalk could
NOT successfully be used as client applications for the Internet. I
can see it now--a million+ Web surfers with 28.8 modems waiting while
their Web browser downloads a 1+MB Smalltalk image that makes a
penguin wave! The Internet would quickly grind to a halt!
This certainly does not prevent someone from producing a light-weight
Smalltalk. But it is just further evidence of how far from reality
Smalltalk vendors have drifted.
The old cry of "memory is cheap" will be replaced by "ISDN/T1s are
cheap."
Marcus Rugger
>C contains no definitions of primitives necessary for writing device
>drivers, accessing absolute memory, accessing I/O ports, or any of
>those things you need to write an OS. C doesn't even have first-class
>argument lists, call stack manipulation, or support for multiple
>calling conventions, something other, higher-level languages offer
>you.
>
>It happens to be the case that a certain set of conventions exists for
>how to do these things in C on some common classes of architectures,
>like the PDP-11, the VAX, the Pentium and 32bit RISC chips,
>conventions that are often not quite compatible.
Ok, sure. I'm not familiar with all these systems, but I am well aware that
when using C in development at this level, some assembly is required. My
experience lies with the PC, C's limitations there are: it can't access I/O
ports, enable/disable interrupts or generate software interrupts. Those are
the ones that come immediately to mind, there may be more, maybe many more. I
haven't developed anything at this level in several years.
Also, I would like to point out that after reading your post here, I see that
I misunderstood the 'unportable operations in C/C++' part of your previous
post. I apologize.
>
>In a language like Java, you can achieve the same effect by adding a
>few functions and datatypes that encapsulate unsafe/low-level
>operations. A simple example would be adding Basic's peek/poke
>operations to Java. In fact, that's the way many successful
>high-level languages have gone, languages that have been used for
>writing operating systems. It's no less unportable than what C gives
>you, and it's actually a whole lot cleaner and easier to maintain.
Until a couple three weeks or so ago, I hadn't taken Java very seriously at
all. I completely misunderstood its capabilities and mistakenly thought that
all that would ever be seen from it is silly animations and some primitive
games. I was wrong (I was shown the light, believe or not, at a Microsoft
teleconfernce). I'm sure my understanding of the language is still throughly
incomplete. But this idea that Java can be used for system development
mystifies me. Perhaps its a mental block. Perhaps I've thought in C for so
long (since 85) I'm blind to other approaches. Perhaps you can show me what I
seem unable to see.
Ok, since the jist of this is writing an OS, let's start out with something
simple, like getting to the I/O ports of a serial port. In C, you can't, some
assembly is required. But it certainly is easy enough to link the assembly
code to the C code that sits on top of it. How is this done with Java
and the JavaVM? Are there byte code instructions for manipulating I/O ports?
If so, how do these byte code instructions get generated? Is there a JavaVM
byte code assembler? Or is a different approach taken? Perhaps the code is
written in machine specific assembly and accessed through a native
method call. My guess is this is more likely the case.
If so, what makes this better than the C approach? Is it because Java
strictly defines it's datatypes, further forcing architecture specific
variations to be dealt with in architecture specific code, thus not polluting
Java?
Or am I still totally missing the point?
>
>Sadly, programmers with your kinds of beliefs about the C programming
>language often go on to writing code that unnecessarily depends on the
>unportable low-level semantics of C.
Actually, we're part of a communist plot to destroy democracy in the free
world.
Marcus
Matt Kennel
Marcus Rugger (rug...@iglou.com) wrote:
: I like that. That's good.
: I don't believe any language will ever replace another. That's not the way
: technology works. Languages are tools, nothing more. Perhaps people thought
: power saws would replace hand saws, but you can still buy them.
But in mechanical industries there's none of this widespread fear to
'upgrade to' power lathes when they're necessary. Nobody puts forth
idiotic arguments like "fumblefingers can't saw anything right no
matter if it's a power saw or hand saw" and go on to erroneously think
that it doesn't matter to their own professional carpenters. (Of course
you can point out how our neandertal ancestors used but sharpened stones
and hand saws are a big improvement, but that isn't considered relevant.)
They don't believe that it will be an enormous expense for "training"
carpenters on power saws and whine "how will we ever find power-saw-trained
carpeneters??", not realizing that their experience in building houses which
stay up and look good is a hell of a lot more important than the ability to
use a power saw, which most can pick up fairly easily.
They point out all the different catalogues full of specialized colored
blades for handsaws (of course the power saws have many of those too but
people don't know about them). They claim that having a fancy grip on the
handle (e.g. "GUI IDE's and tools") is much more important than whether it's a
power tool or not. And finally there is a whole army of consultants and
magazines ("Hand Sawing Professional World") and 'developer programs' from
leading hand-saw manufacturers.
And nobody argues that "since we all know saw-tool decisions are made
by the bean counters in real life" that such is the way things *OUGHT* to be
and we must all accept this fact, and that you must be a wet-behind-the-ears
newbie if you don't give into it and start learning how to hand-saw.
And when the Japanese come marching in with titanic saw-mill factories....
: Marcus
--
Matthew B. Kennel/m...@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility. On account of egregiously vile spamation,
my software terminates all email from "interramp.com" and "cris.com" without
human intervention.
Matt Kennel
David James Hanley (dha...@icarus.cc.uic.edu) wrote:
: : I'm not
: : saying that Java will wink out of existence but eventually people will
: : return to their senses and realize its not going to save the world.
: No one said that, but people will also eventually realize it's
: vastly better than C++.
What's even worse is that Java is but a mediocre weakling as language
design to what already exists, and if *it* is generally considered
'vastly better than C++'.....
Alan L. Lovejoy
It's only evil if it's application code. If it's debugging code, there's
nothing wrong with it at all. And **asking** the class of any object is no
more evil than completely removing the class from the object and putting it
on the variables that hold it. An argument against the one MUST apply also
to the other.
In a dyanamically typed OOPL, the class is encapsulated by the object. In a
statically-typed OOPL, it is not: you only know the class of a value by
inference from the class-constraint declared for the variable or pointer that
refers to it. But the whole point of encapsulation is to make an object a
"black box" that can have any internal implementation its little heart desires,
as long as it conforms to some interface. There are an infinite number of
different classes that can all conform to the same interface. Constraining
the class of the values that a variable can hold is thus a violation of the
encapsulation of an object. Whether the programmer writes code that tests
the class of an object at runtime, or the compiler tests the class at compile
time, the same evil is occurring.
Smalltalk is typesafe, it is strongly typed: type errors cannot occur. The
only difference from a statically-typed language is that type errors are
caught at run time. And if your statically-typed language has pointers and/or
unlimited type casting, then type-errors can occur that will NOT be detected,
regardless of the compiler. This does not apply to Smalltalk, because Smalltalk
objects encapsulate their class.
And despite the protestations of disbelief from the static typing priesthood,
the dynamically-typed Smalltalk baloon does fly safely. It's funny to be up
here flying around while all you Luddites claim it's not possible and can't
be happening. Open your eyes and look up: it **does** fly. Would the financial
community be so hot on Smalltalk if it didn't? Or wasn't sufficiently safe?
The only people complaining about the lack of static typing in Smalltalk are
the ones who haven't really used dynamic typing. You DON'T hear that complaint
from the serious practitioners.
And you don't hear anyone complaining about dynamically-typed Lisp, the darling
of the AI/comp.sci.research community, do you? Why all these attacks on
Smalltalk, when Lisp is just as unstatically-typed as is Smalltalk? Does
Lisp have some sort of indulgence from the Pope, or what?
Matt Kennel
: : On my system, a 90 MHz Pentium.
: : to re-compile and re-link all of the code takes ~20
: : minutes. This delay really destroys any momentum you
: : develop while coding and is a complete waste of time.
: That has more to do with the structure of C++ ( headers, templates,
: weird syntax, etc ) than any static typing issue. The same code in java
: would (on the symantyc compiler) take about 20 seconds to compile.
: Modula-3, eiffel, SML, and others are all statically typed languages that
: compile very quickly.
This is a bit of an exaggeration.
It's certainly true that the dumb lexical structure of C++ and traditional
mode of compilation make good incrementalism very difficult:
compiler knows about only one source file at at time
and only knows about declarations "before" in some model of text file
character location.
Still, a real static type system implies various global properties which
make code generation and consistentcy checking strategies which promote
highly-efficient recompilation in partial opposition to those strategies
which promote highly-efficiently executing object code. Obvious
examples include inlining and the generation of "dispatch tables": efficiently
executing strategies are usually incompatible with localized incremental
recompilation.
If you wanted an Eiffel which ran only as fast as Smalltalk and
deferred some error checking to run time like Smalltalk you could certainly
have a lickety-split fast compiler.
I am a personal fan of good statically typed languages, but a really
high quality compiler which can do both incrementalism and efficient
compilation is quite a nontrivial piece of work.
The best example I know is ISE Eiffel and their 'melting ice' technology,
where you can choose various code generation strategies for the various
parts of the system on the fly.
If you want a full-optimization-on down-to-the-metal code generation
you will have to wait some time. But at least it's possible.
: : The language forces your code to be so
: : brittle that changes after the fact are virtually impossible.
Ah, this is where you want *static type inference* like Eiffel or
Sather (and other more potent examples yet!) which is entirely missing
from C++.
Sherman Wood
In article <31D6F2...@concentric.net>, alov...@concentric.net says...
>
>Jeff Dege wrote:
>>
>> On Sun, 30 Jun 1996 00:22:04 GMT, Jason E. Kratz (jkr...@tezcat.com) wrote:
>> : > This is the right way to do it. In smalltalk, Everything is
>> : >an object of type "foo". When I get a foo, I don't know what the heck
it is.
>> : >I have no guarantees, and neither does the compiler.
>> :
>> : Wrong wrong wrong wrong wrong. In Smalltalk every object is whatever
>> : you defined it to be. If you are referring to variables every
>> : variable in Smalltalk is a reference to an object. Think of it as
>> : every variable is a pointer to an object. In Smalltalk you always
>> : know what you have. It is stored with each object and you can always
>> : query the object about what its type is. Ex: I have a function that
>> : passes back an object. You can always query the object that was
>> : returned what type it is.
>>
>> Are you aware of how truly evil a construct that is? If I have
>> code scattered about that queries the type of an object scattered
>> all over my system, then I have umpteen gadzillion places that
>> I have to examine for change when I add a new type of object.
>
>It's only evil if it's application code. If it's debugging code, there's
>nothing wrong with it at all. And **asking** the class of any object is no
>more evil than completely removing the class from the object and putting it
>on the variables that hold it. An argument against the one MUST apply also
>to the other.
[snip]
I agree with the thrust of Alan's posting, with one comment ....
In Smalltalk, and I would think this applies to any dynamically typed
language, there is a better way to handle polymorphism than checking the class
of an object, and using methods appropriate to the class. Instead, we can rely
on the the fact that an object will have a given interface.
For example, a cashflow has a source, which is polymorphic, and can be a deal,
coupon payment, fee, client payment etc etc, which may or may not be part of
the same inheritance tree. All the cashflow cares about is the fact that the
source object responds to a given interface, such as date, amount, narrative
...
Checking the class of an object is death, as noted in Jeff Dege's posting.
Relying on inheritance in this situation is also death for a system that is
changing over time. Interface conformance as outlined above is a way around
the need for checking classes.
------------------------------------------------------------------
Sherman Wood (sw...@macquarie.com.au)
Project Manager - Distributed Systems
Dilbert's boss says to Dilbert :
I put a timeline together for your project.
I started by reasoning that anything I don't understand is easy
to do.
Phase One : Design a client server architecture for our world wide
operations.
Time : Six minutes
------------------------------------------------------------------
Alan L. Lovejoy
Joe Kinsella wrote:
>
> "Alan L. Lovejoy" <alov...@concentric.net> wrote:
>
> >Smalltalk's problem is not technical, but rather that it has not
> >been invited to the party by the current "in" crowd.
>
> Quite to contrary--Smalltalk would have been invited but it was too
> FAT to get through the door!
Just 'cause the current generation are all heavyweights is no cause to
be ridiculing the weight-challenged :-).
> Let's be honest here: the currently implementations of Smalltalk could
> NOT successfully be used as client applications for the Internet. I
> can see it now--a million+ Web surfers with 28.8 modems waiting while
> their Web browser downloads a 1+MB Smalltalk image that makes a
> penguin wave! The Internet would quickly grind to a halt!
So instead of spending the resources to make a "small" Smalltalk, Sun
spends the resources to make a completely new language. Did they ever
even ASK any of the Smalltalk vendors about doing a lightweight version
of Smalltalk? Of course, Sun didn't get us to this juncture deliberately.
They stumbled into their present success. Reminds one of the original IBM
PC: it, too, took off way beyond its makers original intentions. We're
still paying for the suboptimal shortcomings of the original PC. Will we
still be paying for the shortcomings of Java twenty years from now? Possibly
so, but I hope not.
You can blame the ST vendors for not realizing what opportunity was
available, and you can blame them for having gotten stuck in a rut. But
let's be honest: how many people saw the internet/WWW/Java frenzy coming
with enough advance warning to do anything about it? Did you?
I'm a firm believer in creative destruction. It's diversity that lights
a fire under your butt and focuses your mind on what needs to be done.
I see signs of this at work already.
> This certainly does not prevent someone from producing a light-weight
> Smalltalk. But it is just further evidence of how far from reality
> Smalltalk vendors have drifted.
They aren't the only ones. The True Java Believers are living in
Wonderland, too. They have a rude awakening coming (not that Java
won't be a success, but not to the extent that some people expect).
> The old cry of "memory is cheap" will be replaced by "ISDN/T1s are
> cheap."
Given enough time, bandwidth will be very cheap. The big question is when.
I expect it sooner than Bill Gates would like, but later than the Java
Faithfull believe. Praise the Object and pass the magic cookies. Amen.
Tim Rowledge
In article <4r40a6$2...@news-old.tiac.net>, Joe Kinsella
<mailto:kins...@tiac.net> wrote:
> I don't see much hope in saving Smalltalk the language. But I am
> certain the "best of it" will never reach the ashbin of history.
> Those of us who worked with Smalltalk will bring our experience
> forward whereever we work.
>
pretty much much everyone/everything is claiming to be
'as good as Smalltalk'
'like Smalltalk but...'
and so on.
Even the basics that we take for granted most of the time descend from Smalltalk
work - networks, GUIs ....
Of course, I d' rather win all the battles as well as the moral vistory!
--
Tim Rowledge: rowl...@hooked.net
Dave Smith
Jason E. Kratz wrote:
[RE: Java killing C++]
>> snip
No one said that? are you crazy? the hype out there shows that is
*exactly* what people are saying. I'll point out that Java being
vastly better than C++ is your opinion. I have nothing against Java.
I hope it succeeds. What I do have a problem with is people spelling
out the doom of C++ and other languages just because Java is here. It
wont happen. Its about as stupid as people thinking that MS wont be
able to make money off of programs like Word anymore because people
can run Java applets over the web. that is just plain ridiculous. <<
Without getting into a battle of personalities, let's put this into the Smalltalk
perspective. One of the original design goals for Smalltalk was to combat the
incompehensibility and complexity of then (late 70's) computer technology and
programming. I'm quite convinced I could teach complex concepts like polymorphism and
inheritence to 10 year-old's using Smalltalk; it would be foolhardy to try it with C++.
Now, the question is, how suitable is Java for such an attempt? I.e., does this
language empower a lot of people to do programming? Answer: Yes, I think so, and this
is only going to increase as the environments mature. C++ use is limited to a subset of
engineers and developers for the most part. (Notice, this is the same bunch who used to
own Fortran and Lisp on the mainframe). Not so Java.
There was some mention that all java can do is make "pretty animations on web pages"
well, this might seem true, but then, to put it plainly, that is what a lot of people
want and like--just some typical guy with little programming experience can come with
something like that pretty easily. Sure, there are a lot of "crapplets" out there,
point is, more people than ever are programming, the garage is back, which is good for
everybody. So Java development is surely in line with much of the original Smalltalk
developer's worldview and goals--making the machine accessible and humanizing it as
much as possible.
Regards,
DS
Jeff Dege
On Sun, 30 Jun 1996 14:33:04 -0700, Alan L. Lovejoy (alov...@concentric.net) wrote:
: Jeff Dege wrote:
: > On Sun, 30 Jun 1996 00:22:04 GMT, Jason E. Kratz (jkr...@tezcat.com) wrote:
: > : returned what type it is.
: >
:
: It's only evil if it's application code. If it's debugging code, there's
: nothing wrong with it at all. And **asking** the class of any object is no
: more evil than completely removing the class from the object and putting it
: on the variables that hold it. An argument against the one MUST apply also
: to the other.
Code that depends upon the type of the object that is being passed to it
has to be revisited every time a new type of object is created. This
has _enormous_ implications when it comes to maintenance. It is, in fact,
exactly what OO and polymorphism was supposed to prevent in the first
place.
: Whether the programmer writes code that tests
: the class of an object at runtime, or the compiler tests the class at compile
: time, the same evil is occurring.
The _evil_ is requiring the programmer to revisit every comparison
against type to ensure that a new type is correctly handled. If the
compiler can do this automatically, it isn't evil.
: Smalltalk is typesafe, it is strongly typed: type errors cannot occur. The
: only difference from a statically-typed language is that type errors are
: caught at run time. And if your statically-typed language has pointers and/or
: unlimited type casting, then type-errors can occur that will NOT be detected,
: regardless of the compiler. This does not apply to Smalltalk, because Smalltalk
: objects encapsulate their class.
Type errors are caught in one of three stages: during static checking
during compile, during runtime test, or during normal post-release use.
I've seen enough errors of various types slip by both static checking
and pre-release testing that I take claims that static checking isn't
needed with a large grain of salt.
But this has _nothing_ to do with what I was talking about.
--
You'd think that after all this time
I would have dreamed up a really clever .sig!
Jason E. Kratz
jd...@winternet.com (Jeff Dege) wrote:
>On Sun, 30 Jun 1996 00:22:04 GMT, Jason E. Kratz (jkr...@tezcat.com) wrote:
>: > This is the right way to do it. In smalltalk, Everything is
>: >an object of type "foo". When I get a foo, I don't know what the heck it is.
>: >I have no guarantees, and neither does the compiler.
>:
>: Wrong wrong wrong wrong wrong. In Smalltalk every object is whatever
>: you defined it to be. If you are referring to variables every
>: variable in Smalltalk is a reference to an object. Think of it as
>: every variable is a pointer to an object. In Smalltalk you always
>: know what you have. It is stored with each object and you can always
>: query the object about what its type is. Ex: I have a function that
>: passes back an object. You can always query the object that was
>: returned what type it is.
>Are you aware of how truly evil a construct that is? If I have
>code scattered about that queries the type of an object scattered
>all over my system, then I have umpteen gadzillion places that
>I have to examine for change when I add a new type of object.
I dont believe you understand what I was trying to get at. My point
was this - that in Smalltalk you can always find out of what type an
object is even if you dont already know. The previous poster said
"When I get a foo, I don't know what the heck it is". This is totally
false in Smalltalk. You can always know what that "foo" object is.
Jason
Jason E. Kratz
"Alan L. Lovejoy" <alov...@concentric.net> wrote:
[lots of stuff from a great post deleted to save space]
>Smalltalk is typesafe, it is strongly typed: type errors cannot occur. The
>only difference from a statically-typed language is that type errors are
>caught at run time. And if your statically-typed language has pointers and/or
>unlimited type casting, then type-errors can occur that will NOT be detected,
>regardless of the compiler. This does not apply to Smalltalk, because Smalltalk
>objects encapsulate their class.
Yes, its so wonderful how in C++ you can totally circumvent type
checking by using pointers. Java does not have this problem thank god
(or whoever).
>And despite the protestations of disbelief from the static typing priesthood,
>the dynamically-typed Smalltalk baloon does fly safely. It's funny to be up
>here flying around while all you Luddites claim it's not possible and can't
>be happening. Open your eyes and look up: it **does** fly. Would the financial
>community be so hot on Smalltalk if it didn't? Or wasn't sufficiently safe?
>The only people complaining about the lack of static typing in Smalltalk are
>the ones who haven't really used dynamic typing. You DON'T hear that complaint
>from the serious practitioners.
I took a class last semester that taught Smalltalk and more advanced
C++. After learning and programming in Smalltalk going back to C++
was, well, a really crappy experience. As far as I'm concerned
every language should be dynamically typed and bound. I love not
having to worry about what type my variables are. Lets me think more
about how to code something without having to worry about lots of
stupid details. Of course the wondeful thing about dynamic binding is
being able to edit your code while it is running and have the changes
take effect the next time you reach the edited method.
Great post Alan. Wish I could have said it the same way.
Jason
Florin Mateoc
Alan L. Lovejoy wrote:
> Smalltalk has historically had the problem of "rolling its own" GUI/graphics
> system, its own thread/process facility, its own Signal/Exception mechanism,
> its own virtual machine/bytecode specification, etc, long before these things
> became standardidized in the popular operating systems, and then being criticized
> by smart alecks later because it's "not standard." I refuse to apologize for
> being the first, for being the innovator, for blazing the first trail. On the
> other hand, the Smalltalk vendors should have been faster to recognize when it
> was time to go with the flow. "You can tell the pioneers because they're the
> ones with the arrows in their backs."
I like Smalltalk myself but I am afraid these vendors have given us several
Smalltalks and not just one (competing with Java or C++).
Yes, we have multi-platform Smalltalks and we have distributed objects but
have you ever tried to port an application from one Smalltalk to another ?
In C++ one could modify a class library to be able to compile it with a different
compiler, there are class libraries written for multiple compilers, and even a
standard class library.
Florin Mateoc
Alan L. Lovejoy
Jeff Dege wrote:
>
> On Sun, 30 Jun 1996 14:33:04 -0700, Alan L. Lovejoy (alov...@concentric.net) wrote:
> : > On Sun, 30 Jun 1996 00:22:04 GMT, Jason E. Kratz (jkr...@tezcat.com) wrote:
> : > : returned what type it is.
> : >
> :
> : It's only evil if it's application code. If it's debugging code, there's
> : nothing wrong with it at all. And **asking** the class of any object is no
> : more evil than completely removing the class from the object and putting it
> : on the variables that hold it. An argument against the one MUST apply also
> : to the other.
>
> Code that depends upon the type of the object that is being passed to it
> has to be revisited every time a new type of object is created. This
> has _enormous_ implications when it comes to maintenance. It is, in fact,
> exactly what OO and polymorphism was supposed to prevent in the first
> place.
Yes, my point exactly. Static type checkig is in effect a case statement
in the compiler whose tag value is the object's type or class. One should
not have to hunt through the code to change your case statements and/or
type constraints just because you want to substitute an instance of one
class for another with the same interface--and that won't even work
if you want to use instances of both classes interchangeably at run time!
> : Whether the programmer writes code that tests
> : the class of an object at runtime, or the compiler tests the class at compile
> : time, the same evil is occurring.
>
> The _evil_ is requiring the programmer to revisit every comparison
> against type to ensure that a new type is correctly handled. If the
> compiler can do this automatically, it isn't evil.
Which is why good Smalltalk code NEVER checks the class of an object. You simply
send a message that the object will respond to in some fashion appropriate to its
class. This is no more remarkable than simply assuming that an integer variable
has the correct value. Who would ever ckeck the value of every variable to
verify its correctness:
int index = 0;
if (index != 0) raiseError("gasp: index wasn't zero!");
Of course, in this example, if index wasn't zero and you didn't check, you might
never know. In Smalltalk, if the object does not understand the message, the
event will definitely be reported without having to explicitly code in a
check.
In a dynamically typed OOPL, the class is part of the encapsulated value of the
object. Getting the value right is just part of the programmer's job. It's no
big deal.
As for changes to the interface: when you change a method name (or remove a
method, or change the parameters to a method), you simply ask the system to
list all places in the code where that message is sent. This is vary fast.
You then change each sender to reflect the change you made to the message
selector. I can almost always do this faster than it would take you to
recompile any non-trivial statically-typed program.
The other important point is to be very careful that all methods with the
same message selector have the same semantics, and that all methods with
the same semantics have the same message selector. Do this well, and interface
mismatches will virtually vanish. In fact, static type checking is an aborted
attempt to verify that message sends (or function calls) have the expected
semantics. Unfortunately, it can't do that, because computers and compilers
aren't that smart. Spell-checking and grammar checking are no guarantee that
what is written is worth reading, or makes any sense. Static type checking
is similarly limited. Just because every word in your document is known
to the Oxford English Dictionary does not make it correct. But I've noticed
a trend towards publishing perfectly spell-checked documents with horrible
errors in them that would never have escaped notice had a human looked more
carefully at it. Spell checking and static type checking are a poor substitute
for good writing and design skills.
> : Smalltalk is typesafe, it is strongly typed: type errors cannot occur. The
> : only difference from a statically-typed language is that type errors are
> : caught at run time. And if your statically-typed language has pointers and/or
> : unlimited type casting, then type-errors can occur that will NOT be detected,
> : regardless of the compiler. This does not apply to Smalltalk, because Smalltalk
> : objects encapsulate their class.
>
> Type errors are caught in one of three stages: during static checking
> during compile, during runtime test, or during normal post-release use.
> I've seen enough errors of various types slip by both static checking
> and pre-release testing that I take claims that static checking isn't
> needed with a large grain of salt.
Almost all "message not understood" errors in Smalltalk occur because
a message is sent to nil. The equivalent in C++ would be dereferencing
a null pointer--something that static type checking cannot prevent.
> But this has _nothing_ to do with what I was talking about.
Ok. So what were you talking about?
Alan L. Lovejoy
. wrote:
>
> In article <31D6F2...@concentric.net> "Alan L. Lovejoy" <alov...@concentric.net> writes:
>
> Smalltalk is typesafe, it is strongly typed: type errors cannot occur.[...]
> And despite the protestations of disbelief from the static typing priesthood,
> the dynamically-typed Smalltalk baloon does fly safely.
>
> that you don't get incorrect results by accident. However, runtime
> type exceptions can occur at unexpected places, and can result in
> unrecoverable states (one of the favorite messages of the Lisp machine
> was "NIL is not a number").
Translate "nil is not a number" into the equivalent C or C++ event: dereferencing
a NULL pointer, resulting in "segmentation fault" (or some such) and core dump.
Most "message not understoods" occur because a message is sent to nil. Static
type checking will prevent exactly ZERO such errors.
> Now, you can find those problems with some testing. In fact, in many
> cases, that is perfectly acceptable (I write a lot of code in
> dynamically typed languages). On the other hand, a static type
> checker can greatly reduce the effort you have to spend on testing, in
> particular during code maintenance. For example, if you decide to
> change a name or type in an interface during maintenance, a static
> type checker will tell you with one recompilation what you broke; if
> the change is straightforward, after fixing those, you often need to
> do little or no other testing.
Yes, and Smalltalk's Browser will find all senders of a message faster than
you can compile and link a 1,000 line C program. Probably ten times faster.
You can think of the Smalltalk development environment as a fully interactive
type checking system that works much faster than a compiler's static type
checking.
The suggestion that Smalltalk or Lisp programs (in production) encounter more
runtime errors than programs written in statically typed languages has often
been insinuated but never proven. Put up or shut up: either produce scientific
evidence to prove this claim, or admit you have no objective basis for it.
> And you don't hear anyone complaining about dynamically-typed Lisp, the darling
> of the AI/comp.sci.research community, do you? Why all these attacks on
> Smalltalk, when Lisp is just as unstatically-typed as is Smalltalk? Does
> Lisp have some sort of indulgence from the Pope, or what?
>
> I like having dynamic typing. It greatly simplifies writing a lot of
> code. But I don't think it's an either/or situation. More and more
> languages are giving you both static and dynamic typing (Java,
> Objective-C, C++, SML), in particular languages that are used for
> larger, more complex projects. Smalltalk and Lisp have not kept up
> with this trend, and lack of static typing probably contributes to
> limiting their acceptance in the commercial marketplace.
>
> Thomas.
I think we need to recognize a new phobia: the fear of programming without
statically-checked types.
dav...@ibm.net
> The new version of OS/2, Merlin, has Java enabled at the operating system level.
>
>Can you say more about this? I.e., can you tell me where to find out
>more?
The open beta for Merlin will be available in two or three weeks. You send in
something like $15 and they send you the package. You can check it out for
yourself. You might check with Indelible Blue at 800/776-8284.
Stephen Joy
ObjectLoader/Dumper does work (although it prefers the class(es) of
the instances dumped, to already exist in the image).
3 keys to success for a language: Marketing, Marketing, Marketing?
Poco...@mail.apci.net wrote:
> IBM Smalltalk uses an ObjectLoader and ObjectDumper for loading and unloading of
> Objects (including Classes). I have not yet tried to use that for loading objects into
> an image that did not already have the classes defined in them. Does this work?
> If it does, I think it would be not too difficult to work a manner for a page to have a
> link to a file that would be your application classes dumped out. Download the
> classes and object and import them into your image. A Smalltalk capable browser
> that could help automate some of this process would be ideal.
>
> Incidentally, IBM ST also has Distributed Smalltalk. Looking at it's structure, I would say
> that this is a more powerful approach to building more robust MIS based Intranet
> applications.
>
> I've been thinking that Java is structurtally very similar to ST in certain respects.
> The idea of a VM executing a class library (image) being the biggest. One major
> advantage of ST (not as a language but as a development tool) is
> the maturity of ST itself as well as the depth of the architectures available.
> Being used to IBM ST or VisualAge makes Java painful to program in, by
> comparison. I would rather see a Web distribution method for Smalltalk
> classes/applications than Java.
>
> James O'Connor
> oco...@apci.net
Volker Hetzer
"Alan L. Lovejoy" <alov...@concentric.net> writes:
>Jeff Dege wrote:
>In a dyanamically typed OOPL, the class is encapsulated by the object. In a
>statically-typed OOPL, it is not: you only know the class of a value by
>inference from the class-constraint declared for the variable or pointer that
>refers to it. But the whole point of encapsulation is to make an object a
>"black box" that can have any internal implementation its little heart desires,
>as long as it conforms to some interface.
I don't understand why you think, this works not for statically typed languages.
And what do YOU mean by "interface"? In C++, the class-declaration is the
interface. And if you want several classes sharing (part of) this interface
you use inheritance. Then you have a pointer of the base-class-type pointing
to the several inheritees and that's it.
>There are an infinite number of
>different classes that can all conform to the same interface.
As can be in C++.
>Constraining
>the class of the values that a variable can hold is thus a violation of the
>encapsulation of an object.
No, since you have defined an interface for the object, you should make sure
that you can use this interface to access and modify the object data.
Allowing the object to hold (and therefore be) what it wants would render
the interface useless, because there might not be the data you want to access.
>Smalltalk is typesafe, it is strongly typed: type errors cannot occur. The
>only difference from a statically-typed language is that type errors are
>caught at run time.
So please define "occurance" of a type error.
For me it includes "type error, core dumped" on the screen of a user.
>And if your statically-typed language has pointers and/or
>unlimited type casting, then type-errors can occur that will NOT be detected,
even statically typed lanuages aren't perfect...
Volker
Eric Clayberg
Florin,
> I like Smalltalk myself but I am afraid these vendors have given us several
> Smalltalks and not just one (competing with Java or C++).
> Yes, we have multi-platform Smalltalks and we have distributed objects but
> have you ever tried to port an application from one Smalltalk to another ?
Yes, I have. While not exactly "trivial", I wouldn't say it was a horrible
process either. Certainly no worse than trying to port a MFC C++ app to some
other vendor's C++ GUI library. Almost all of the Smalltalk third party vendors
are in the position of supporting multiple Smalltalk platforms. We have gotten
so adept at it that most of our Smalltalk add-on products share 90-95% common code
between VisualSmalltalk and IBM Smalltalk. Other vendors, like Polymorphic, have
done an even better job and provide add-ons that span VST, IBM/ST and VisualWorks.
I have been personally involved with quite a few customer projects that have
migrated from one vendor's Smalltalk to another. A typical example was one
customer who ported a 200+ screen Smalltalk/V OS/2 w/ WindowBuilder Pro
application to IBM Smalltalk and had it up and running in three weeks with
two people (with one or two days of help from us). Their domain model code
(non-GUI) ported almost flawlessly. Their GUI code ported with very little
effort as well (primarily because they were using the same GUI builder on
both platforms). The hardest part of the port involved their database access
code which they had to totally re-write. Had they been using a portable database
access layer (like ODBCTalk from LPC Consulting), they could have ported that
easily as well.
> In C++ one could modify a class library to be able to compile it with a different
> compiler, there are class libraries written for multiple compilers, and even a
> standard class library.
In this sense, Smalltalk is really no different than C++. There is a "standard"
Smalltalk class library that most vendors already adhere to (and which is being
agreed upon by the ANSI Smalltalk committee). There is nothing that would prevent
you from porting PP-D's GUI class library so that it run on IBM's VM or vice
versa (in fact, OTI has already proven that this could be done several years ago).
As long as the major Smalltalk compilers provide the same services and support
the same syntax, nothing would prevent you (technically as opposed to legally)
from doing exactly what you suggest.
The bottom line is that portability issues in the Smalltalk world are no worse
than in C++ or any other mainstream language. Java can claim better portability
for the time being because it is only provided by one vendor. Just wait and see
what happens when Microsoft comes out with MFC for Java (or some similar
abomination). We are already starting to see Java add-ons and libraries that
are *specific* to a single platform (i.e., Windows 95) and the trend will only
get worse as Java matures.
-Eric
Objectshare
Farshad Nayeri
> In a language like Java, you can achieve the same effect by adding a
> few functions and datatypes that encapsulate unsafe/low-level
> operations. A simple example would be adding Basic's peek/poke
> operations to Java. In fact, that's the way many successful
> high-level languages have gone, languages that have been used for
> writing operating systems.
You can write native unsafe methods that peeks and pokes memory in Java,
but if the Java "model of programming" does not acknowledge the need
for unsafe programming, it is unlikely that the language and the environment
will support your systems programming tasks very well. Recall that the
*garbage-collected*, *multi-threaded* run-time and the *safety-enforcing*
compiler have to make sure to get out of your way of your unsafe code.
Following your proposal, what if, for example, I wanted to make a new
abstraction using the existing primitive "unsafe" methods? What kind
of support do I get from a system that always assumes "safe" operations?
Can I use _any_ of the standard libraries? Adding "peek" & "poke" operations
works in Basic because people programming in basic typically don't care
about abstractions. (Also recall that until recently most basic programming
took place on a non-multitasking setting.) I sure hope Java folks can
do better than that!
I am curious by the way--what are the "many successful high-level
languages [...] that are used for writing operating systems"?
--
Farshad Nayeri
Critical Mass, Inc.
http://www.cmass.com/
David James Hanley
: >: I dont think Java will steamroller anything, especially C++. Java is
: >: not suited to development of everything and never will be.
: > Java is suited to everything that C++ does, excepting
: >system-level stuff. Maybe you're thinking of applets instead of
: >applications?
: It doesnt make a difference. And you proved my point. You said that
: Java isnt suited to system development stuff.
So what do you think that this proves? What percent of industry
work is developing systems software?
: > Going from C++ to java is trivial.
: The learning curve alone isnt important. You are right - learning
: Java itself coming from C++ is trivial. However many dev. houses
: wont switch because of the amount of *money* involved in both tools
: and training.
Sure, and they never switched from C to C++ either. There
are far more benefits from going from c or C++ to java than there ever
were in going from C to C++.
: If you dont think this is true you're deluding
: yourself. At this point in time there is no reason to switch because
: the tools out there for Java development are horrible. Not to say
: they wont get better, I'm sure they will, right now they are crap.
This is simply not true. Have you used symantic cafe, for example?
It's just over $100 dollars, and it makes every C++ enviornment I've ever used
(almost all of them) look like crap.
: > That is not even the case for java applets now, and will become
: >less the case very soon.
: It isnt? How come when I go to a site like Gamelan most of the stuff
: I see there is used to "pretty up" web pages?
because they can. Does the fact that C and C++ are used almost
exclusively by game programmers mean that that is all they are suited
for?
B
: >: Shit, right now I can't even do a simple little
: >: database applet because of those wonderful security restrictions.
: > Shit, I've already done that. Guess I must be using magic.
: You must be if you've done it the way I did it.
No, I just did it correctly.
: >: I'm not
: >: saying that Java will wink out of existence but eventually people will
: >: return to their senses and realize its not going to save the world.
: > No one said that, but people will also eventually realize it's
: >vastly better than C++.
: No one said that? are you crazy? the hype out there shows that is
: *exactly* what people are saying.
No, I'm not crazy. Please quote one source saying that java will
save the world, then we can assume that you are not crazy, nor stupid.
------------------------------------------------------------------------------
David Hanley, |______ Computer Science graduate student.
dha...@lac.eecs.uic.edu |\ ___/__ Martial Artist. Biker. Chess Freak
www_lac.eecs.uic.edu/~dhanley/| \\ / / Libertarian. Atheist. Bisexual.
My employer barely KNOWS me. | \/BI/ Aspiring novelist.Joyce Kafka Neitzsche
-----------------------------------\/-----------------------------------------
I.N.R.I.
Iron nails ran in.
David James Hanley
: > Interfaces are multiple inheretence of interface, which works
: >fine for me.
: This makes no sense at all. Interfaces arent multiple inheritance.
Yes they are. They are multiple inheretence of interface.
Please learn about computer languages before criticizing them.
--
David James Hanley
: >: The way that C++ does its method calls is idiotic. It relies on
: >: the static type system to give it the information it needs for
: >: making the call (i.e., the index into the virtual table).
: > This is the right way to do it. In smalltalk, Everything is
: >an object of type "foo". When I get a foo, I don't know what the heck it is.
: >I have no guarantees, and neither does the compiler.
: Wrong wrong wrong wrong wrong. In Smalltalk every object is whatever
: you defined it to be.
Wonderful fantasy, but but here's an example that shows where
that is terribly wrong. In the real world, most programming efforts are
team-based. Let's say that our team has agreed one an overall structure
and that your module will be getting poo* objects through one method.
In a statically typed language, you will get poo* through there,
guaranteed. Any attempt to pass something else will be caught right away,
at the first attempt to compile the offending code. In a dynamically
yuped language, it potentially might not get caught until late in the
development cycle long after the mistake has been made, when it is hard
to find.
: If you are referring to variables every
: variable in Smalltalk is a reference to an object. Think of it as
: every variable is a pointer to an object. In Smalltalk you always
: know what you have. It is stored with each object and you can always
: query the object about what its type is. Ex: I have a function that
: passes back an object. You can always query the object that was
: returned what type it is.
Oh, wonderful. That is great programming practice. Much more
work than you have to do in any statically typed language, and you have
to go all over and change gobs of code when you change the class
hierarchy. Sounds like a really good idea.
: > Gosh. All that staticially typed general code I have must be a
: >figment of my imagination, then.
: You have to do a lot of work to make code in C++ general. In Smalltalk
: its trivial because of dynamic typing.
False in any case, but once again, for the discussion impared,
I'm not talking about C++, but dynamic vs. static typing.
: >: It's no wonder that
: >: people who don't use Smalltalk concentrate so much on
: >: up-front design.
: > because up-front design is a good idea? :)
: Sure it is a good idea. With Smalltalk you have fewer issues related
: to the design to worry about.
Like you don't have to worry at all that foo has had a bad
object passed to it, right?
: You spend more time coding and less time
: figuring out the details of whats going on behind the scenes.
Like checking the objects returned from functions to be sure
they are valid?
David James Hanley
Matt Kennel (m...@caffeine.engr.utk.edu) wrote:
: : : On my system, a 90 MHz Pentium.
: : : to re-compile and re-link all of the code takes ~20
: : : minutes. This delay really destroys any momentum you
: : : develop while coding and is a complete waste of time.
: : That has more to do with the structure of C++ ( headers, templates,
: : weird syntax, etc ) than any static typing issue. The same code in java
: : would (on the symantyc compiler) take about 20 seconds to compile.
: : Modula-3, eiffel, SML, and others are all statically typed languages that
: : compile very quickly.
: This is a bit of an exaggeration.
<deletia>
: Still, a real static type system implies various global properties which
: make code generation and consistentcy checking strategies which promote
: highly-efficient recompilation in partial opposition to those strategies
: which promote highly-efficiently executing object code. Obvious
: examples include inlining and the generation of "dispatch tables": efficiently
: executing strategies are usually incompatible with localized incremental
: recompilation.
: If you wanted an Eiffel which ran only as fast as Smalltalk and
: deferred some error checking to run time like Smalltalk you could certainly
: have a lickety-split fast compiler.
Why not have the eiffel compiler generate slow code very quickly
during development, and do a long slow build to produce high-quality
code before the final testing and shipping?
: If you want a full-optimization-on down-to-the-metal code generation
: you will have to wait some time. But at least it's possible.
Sure. But we don't need to do this very often, do we?
: : : The language forces your code to be so
: : : brittle that changes after the fact are virtually impossible.
: Ah, this is where you want *static type inference* like Eiffel or
: Sather (and other more potent examples yet!) which is entirely missing
: from C++.
Or sml, for that matter.
Kazimir Majorinc
Hello everybody!
My opinion:
I am C++ programmer and I don't understand how somebody can love C++.
C++ have plenty of good ideas, and plenty of rude concepts. Managing of
that project files and #includes is sooo boring and complicating, and it
is good solution only for small projects. I cant understand how it
happened that people use C++ for serious projects!? I have
not experience with Smalltalk and Modula 3, but what I read, there are
much better. C++ looks to me like Sinclair Spectrum with 8GB hard disk.
If you following this up, please send me e-mail copy, because news expires
from our newsserver very fast.
About Cobol, I don't know? And why Java, also!
Sincerely yours,
__________________________________________________
Author: Kazimir Majorinc, Zagreb, Croatia.
E-mail address: Kazimir....@public.srce.hr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason Kratz
dha...@icarus.cc.uic.edu (David James Hanley) wrote:
>: > This is the right way to do it. In smalltalk, Everything is
>: >an object of type "foo". When I get a foo, I don't know what the heck it is.
>: >I have no guarantees, and neither does the compiler.
>: Wrong wrong wrong wrong wrong. In Smalltalk every object is whatever
>: you defined it to be.
> Wonderful fantasy, but but here's an example that shows where
>that is terribly wrong. In the real world, most programming efforts are
>team-based. Let's say that our team has agreed one an overall structure
>and that your module will be getting poo* objects through one method.
>In a statically typed language, you will get poo* through there,
>guaranteed. Any attempt to pass something else will be caught right away,
>at the first attempt to compile the offending code. In a dynamically
>yuped language, it potentially might not get caught until late in the
>development cycle long after the mistake has been made, when it is hard
>to find.
This is a possibility, not a probability. First off, since we are
talking about Smalltalk, you dont code in modules. Everything in
Smalltalk is an object. In real life an object will have an interface
that has been defined. The whole team will use this interface. Send
a message to the object that it doesnt understand? No problem. It
knows right then and there that it doesnt understand this message.
This will not be caught late in the development cycle - it will be
caught the first time this object is used. If it is late in the
development cycle and the error is first cuaght why is this object
being used in the first place? And its not hard to find. I wonder
just how much experience you really have with Smalltalk. It lets you
know exactly where the error occured when it occurs. Dont blame the
practice of coding bad interfaces on dynamic typing.
>: If you are referring to variables every
>: variable in Smalltalk is a reference to an object. Think of it as
>: every variable is a pointer to an object. In Smalltalk you always
>: know what you have. It is stored with each object and you can always
>: query the object about what its type is. Ex: I have a function that
>: passes back an object. You can always query the object that was
>: returned what type it is.
> Oh, wonderful. That is great programming practice. Much more
>work than you have to do in any statically typed language, and you have
>to go all over and change gobs of code when you change the class
>hierarchy. Sounds like a really good idea.
Who ever said anything about this being a programming practice? I
surely never did. I just used it as an example to refute your
statement about how with a dynamically typed language you never know
what type of object you have. I never said that this should be used.
And what "gobs of code" do you have to change? A imporperly designed
class hierarchy, whether in a statically typed language or dynamically
typed language, will cause lots of problems for both.
>: Sure it is a good idea. With Smalltalk you have fewer issues related
>: to the design to worry about.
> Like you don't have to worry at all that foo has had a bad
>object passed to it, right?
Exactly. What do you think happens in Smalltalk when an object doesnt
understand a message? Do you think the program just continues on its
merry way?
>: You spend more time coding and less time
>: figuring out the details of whats going on behind the scenes.
> Like checking the objects returned from functions to be sure
>they are valid?
As I said before, that was an example. I never said that is was a
programming practice.
Jason
Jason Kratz
dha...@icarus.cc.uic.edu (David James Hanley) wrote:
>Jason E. Kratz (jkr...@tezcat.com) wrote:
>: dha...@icarus.cc.uic.edu (David James Hanley) wrote:
>: > Interfaces are multiple inheretence of interface, which works
>: >fine for me.
>: This makes no sense at all. Interfaces arent multiple inheritance.
> Yes they are. They are multiple inheretence of interface.
>Please learn about computer languages before criticizing them.
My knowledge of cmputer languages is just fine and I'm not criticizing
them. Interfaces might be as you put it "multiple inheritance *of
interface*". They are not multiple inheritance. Multiple
inheritance means having to deal with more than just the interface -
which is probably why Sun decided to have interfaces and not include
multiple inheritance. This is what I am referring to:
->: there is inheritance, but no multiple inheritance which Java
->: does not have as well!
> Interfaces are multiple inheretence of interface, which works
>fine for me.
The text prefaced by -> is a previous poster. Yours is next. He
stated Java does not have multiple inheritance. You replied with a
line about interfaces. This implies that interfaces are multiple
inheritance. They are not. You get a lot of the benefits of multiple
inheritance but they are not multiple inheritance. You think that
lack of multiple inheritance is a flaw of Smalltalk yet the language
that you are baiscally defending (or started to), Java, does not have
multiple inheritance either. Is this a flaw? I think not. Its a
blessing as far as I am concerned.
Jason
Bill Curran
In article <VBJ34DAY...@blmsbury.demon.co.uk>,
Peter Day <pe...@blmsbury.demon.co.uk> has written:
>In article <4qvhgm$c...@news-old.tiac.net>, Joe Kinsella
>What is all this stuff about 'free' software. Smalltalk will never be
>free - and Java won't be free much longer. Sure SUN have an interest in
>promoting it so they can sell more servers but who really believes
>Microsoft, IBM or anyone else is going to give Java away for free. Once
>we see a real price on the stuff we can make meaningful comparisons on
>price/performance.
>
>But in reality we now have another language to use for development and
>it only serves to make the language wars more ridiculous
>
You want free? Try NetRexx from IBM Hursley and Mr. M. Cowlishaw. It is
currently available for OS/2 and Win95/NT and they are working on JIT
and a number of other things (including a WIN3.1 java-enabled browser
using ZIP'd classes to maintain LFNs). Its not hard to figure that if
Mike and his mechanics could get this out quickly, that the same
couldn't be done for Smalltalk.
--
Bill Curran Sysprog - MVS OS/2 xNIX WINx DOS
email : bcu...@stelco.e-mail.com Rexx on every one of them!
http://www.freenet.hamilton.on.ca/~aa131 All Standard Disclaimers Apply
ande...@byu.edu
In <TMB.96Ju...@best.best.com>, t...@best.com (.) writes:
>In article <31D4F8...@concentric.net> "Alan L. Lovejoy" <alov...@concentric.net> writes:
>
> Java's only advantage is that it has grabbed prominent "shelf space" on the
> Netscape Navigator and in the HTML standard. Smalltalk's problem is not
> technical, but rather that it has not been invited to the party by the
> current "in" crowd.
That's because there's not enough salsa'n'chips at the party to
satisfy the big (Small in name only) guy.
Maybe when big parties are cheaper to throw, SmallTalk,
which is the life of any party he's invited to, will
show up more.
Forgive the lame extension of the party analogy.
+---------------------------------------+
| |\
| Kent Anderson |\
| Brigham Young University |\
| Provo, UT |\
| l_kent_...@byu.edu |\
| |\
+---------------------------------------+\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Christopher Sharrer
The point is: it is difficult to to be *sure* that every possible
run-time error has been found, while it is easy to be sure that every
compile-time error has been found.
Just my two-cents.
--
Christopher Sharrer
Luminous Chao, Inc.
Jason Kratz
dha...@icarus.cc.uic.edu (David James Hanley) wrote:
>Jason E. Kratz (jkr...@tezcat.com) wrote:
>: dha...@icarus.cc.uic.edu (David James Hanley) wrote:
>: >: I dont think Java will steamroller anything, especially C++. Java is
>: >: not suited to development of everything and never will be.
>: > Java is suited to everything that C++ does, excepting
>: >system-level stuff. Maybe you're thinking of applets instead of
>: >applications?
>: It doesnt make a difference. And you proved my point. You said that
>: Java isnt suited to system development stuff.
> So what do you think that this proves? What percent of industry
>work is developing systems software?
It proves exactly what I said - that Java isnt suited for everything.
Nothing more nothing less. The percentage of industry doing
system-level development is irrelevant.
>: > Going from C++ to java is trivial.
>: The learning curve alone isnt important. You are right - learning
>: Java itself coming from C++ is trivial. However many dev. houses
>: wont switch because of the amount of *money* involved in both tools
>: and training.
> Sure, and they never switched from C to C++ either. There
>are far more benefits from going from c or C++ to java than there ever
>were in going from C to C++..
The benefits can sometimes be irrelevant. Money is a big issue in
most companies. They will simply not switch over because of money
already invested regardless of what the technical benefits might be.
Its the same issue that has been going on in the Windows world. Lots
of companies have refused to switch over to Windows 95 because of the
cost involved - not only in terms of upgrades of the OS but
applications as well.
>: If you dont think this is true you're deluding
>: yourself. At this point in time there is no reason to switch because
>: the tools out there for Java development are horrible. Not to say
>: they wont get better, I'm sure they will, right now they are crap.
> This is simply not true. Have you used symantic cafe, for example?
>It's just over $100 dollars, and it makes every C++ enviornment I've ever used
>(almost all of them) look like crap.
Symantec Cafe has a *long* way to go before it even comes close to
Borland or MSVC++ in terms of its IDE. I wont even comment on
something like Cafe vs. VisualWorks Smalltalk because it wouldnt be
fair.
>: > That is not even the case for java applets now, and will become
>: >less the case very soon.
>: It isnt? How come when I go to a site like Gamelan most of the stuff
>: I see there is used to "pretty up" web pages?
> because they can. Does the fact that C and C++ are used almost
>exclusively by game programmers mean that that is all they are suited
>for?
Almost exclusively? I guess that means that the Windows (as well as
just about any other platform at this point) application market counts
for very little of the C and C++.
>B
>: >: Shit, right now I can't even do a simple little
>: >: database applet because of those wonderful security restrictions.
>: > Shit, I've already done that. Guess I must be using magic.
>: You must be if you've done it the way I did it.
> No, I just did it correctly.
Haha. Very funny. I love how you edited out the other part of this.
The fact that I was using the JDBC-ODBC bridge dll. Please share your
wisdom on how you got around the security issue of not being able to
load a dll from within an applet. Remember I said a "simple" database
program. Simple does not include writing a server and client in java.
Tell me how you solved the issue of applet security by having the
jdbc-odbc bridge dll on the client machine and how you accessed it.
>: >: I'm not
>: >: saying that Java will wink out of existence but eventually people will
>: >: return to their senses and realize its not going to save the world.
>: > No one said that, but people will also eventually realize it's
>: >vastly better than C++.
>: No one said that? are you crazy? the hype out there shows that is
>: *exactly* what people are saying.
> No, I'm not crazy. Please quote one source saying that java will
>save the world, then we can assume that you are not crazy, nor stupid.
You know very well that I cant quote a source. The rank of stupid
would have to go to you however if you dont see by some of the posts
on this newsgroup and in the media that many people think Java is
going to replace things like native word processors, etc.
Jason
Alan L. Lovejoy
> >In a dyanamically typed OOPL, the class is encapsulated by the object. In a
> >statically-typed OOPL, it is not: you only know the class of a value by
> >inference from the class-constraint declared for the variable or pointer that
> >refers to it. But the whole point of encapsulation is to make an object a
> >"black box" that can have any internal implementation its little heart desires,
> >as long as it conforms to some interface.
> I don't understand why you think, this works not for statically typed languages.
> And what do YOU mean by "interface"? In C++, the class-declaration is the
> interface. And if you want several classes sharing (part of) this interface
> you use inheritance. Then you have a pointer of the base-class-type pointing
> to the several inheritees and that's it.
In Smalltalk, the instances of any two classes that respond to the same messages
are interchangeable--REGARDLESS OF THE INHERITANCE RELATIONSHIPS! The problem
with wrongly using the class definition as an interface specification is that
it improperly forces the inheritance of interface to be identical to the
inheritance of mechanism. The "type" (interface) Dictionary is not the same thing
as any particular mechanism (hash table, sorted list, sorted tree, etc) that
implements it. Classes are mechanisms. Class inheritance is about sharing
algorithms and data structures. So why would a sorted binary tree class need
to share a common superclass with a hash table class? The mechanisms are so
completely different!
> >There are an infinite number of
> >different classes that can all conform to the same interface.
> As can be in C++.
See above.
> >Constraining
> >the class of the values that a variable can hold is thus a violation of the
> >encapsulation of an object.
> No, since you have defined an interface for the object, you should make sure
> that you can use this interface to access and modify the object data.
> Allowing the object to hold (and therefore be) what it wants would render
> the interface useless, because there might not be the data you want to access.
1) You speak as though the variable is the object, instead of the value it
holds being the object. This suggests you don't understand. An object is
**defined** as a value that encapsulates its state ("data structure") and its
behavior (methods, functions, operations, algorithms). If an object is a
**value**, then it can be created, referenced, moved, passed as an argument,
held in a variable and so forth--without losing its value, its identity,
its type or its class (because they're all encapsulated by the object).
The point is that an object's class is part of its value, just like the
exponent of a floating point number is part of the value of the number.
When you assign a floating point value to a variable, the exponent moves
along with the rest of the number. When you assign an object to a variable,
the class of the object moves along with the rest of the object's value.
If that doesn't happen THEN THE OBJECT IS FAILING TO ENCAPSULATE ITS
BEHAVIOR (CLASS)!!! This is just as bad as binding the exponent (but not
the mantissa) of a floating point number to the variable(s) that hold it!
2) I am NOT arguing against the use of **interface** constraints on variables.
But an interface is NOT a class. Java supports interfaces. The big mistake
the Java designers made was in also allowing class names to be used as type
constraints. Once they had put interfaces into the language, they should have
used those EXCLUSIVELY for their type-constraint mechanism. I have an open
mind on the question of whether it is better to have either static checking
for interface conformance or only dynamic typing. But static **class**
constraint checking is evil incarnate. If you need static type checking
for performance reasons, you should NOT be using an OO language. C is a better
C than is C++.
3) Smalltalk objects are encapsulated. You CANNOT access their internal
state. You can only send them messages. And ALL values are objects.
> >Smalltalk is typesafe, it is strongly typed: type errors cannot occur. The
> >only difference from a statically-typed language is that type errors are
> >caught at run time.
> So please define "occurance" of a type error.
> For me it includes "type error, core dumped" on the screen of a user.
Smalltalk does not core dump when a message is not understood. Instead, it
raises an exception. If there is no handler for the "message not undersood"
exception (the usual case), then a "no exception handler" exception is raised.
If there is no handler for that (also the usual case), then the "unhandled
exception handler" handles it. The default "unhandled exception handler"
just puts up an error notifier, which permits you to a) terminate the thread
that caused the exception (the rest of the system is unaffected), or b) to
open up a debugger on the thread that raised the exception. You can define
your own "unhandled exception handler" to do whatever you want (such as
simulate a core dump).
A "message not understood" error is the dynamic detection and prevention of
a type error. If you define the detection of a type error itself as a type
error, then detection of the same by the compiler must also be considered to be
a type error, by the same logic.
Do you also consider run time array bounds checking to be a bad thing? How
can that be good and dynamic type error detection be bad? Should we redesign
our programming languages so that all array index bounds violations can be
detected at compile time? What would be the cost? Would it be worth it?
Jeff Dege
On Mon, 01 Jul 1996 04:52:48 -0700, Alan L. Lovejoy (alov...@concentric.net) wrote:
: Jeff Dege wrote:
: > has to be revisited every time a new type of object is created. This
: > has _enormous_ implications when it comes to maintenance. It is, in fact,
: > exactly what OO and polymorphism was supposed to prevent in the first
: > place.
:
: Yes, my point exactly. Static type checkig is in effect a case statement
: in the compiler whose tag value is the object's type or class.
: > But this has _nothing_ to do with what I was talking about.
:
: Ok. So what were you talking about?
The mechanisms that the language uses in locating code, whether runtime
or compile time, statically checked, dynamically checked, or unchecked,
have no impact on how much code has to be updated by the programmer to
accomodate new types.
If I insert code into a method that says ``if you're a foo, do this, else
if you're a bar, do that'', the _I_, as a programmer, have to go back
to that piece of code when I create a new type to make sure that it
is handled correctly. That a C++ compiler or a SmallTalk runtime will
do something similar when I use polymorphism has both nothing and everything
to do with it. Nothing, because I'm talking about programmer effort and
maintenance issues, not static vs. runtime type checking, and everything,
because it is exactly because both C++ and SmallTalk provide for
polymorphism that I _don't_ have to embed code that depends upon type
in every function that has to handle different types.
Is it clear yet? I'm not arguing SmallTalk vs. C++ when I say you should
be _very_ sure that checking type is necessary. Both provide for a form
of polymorphism, in _either_ language, you should use that polymorphism
when dealing with multiple types. Explicit type checks create unnecessary
and unexpected dependencies, and should be avoided whenever possible.
I'm not at all sure that you disagree with me hear, I think you just read
more into my original post than was intended.
--
Friendship is born at that moment when one person says to another:
"What! You, too? Thought I was the only one."
-C.S. Lewis
Jeff Dege
On Mon, 01 Jul 1996 19:36:41 GMT, Jason Kratz (jkr...@rummy.aiss.uic.edu) wrote:
:
: This is a possibility, not a probability. First off, since we are
: talking about Smalltalk, you dont code in modules. Everything in
: Smalltalk is an object. In real life an object will have an interface
: that has been defined. The whole team will use this interface. Send
: a message to the object that it doesnt understand? No problem. It
: knows right then and there that it doesnt understand this message.
: This will not be caught late in the development cycle - it will be
: caught the first time this object is used.
Say, rather, the first time that object is used by that piece of code.
If your system has heterogenous collections, that may not be for a while.
And if it has persistent heterogenous collections, it may not be for a
_long_ while.
Jeff Dege
On Mon, 01 Jul 1996 04:52:48 -0700, Alan L. Lovejoy (alov...@concentric.net) wrote:
: Jeff Dege wrote:
: > has to be revisited every time a new type of object is created. This
: > has _enormous_ implications when it comes to maintenance. It is, in fact,
: > exactly what OO and polymorphism was supposed to prevent in the first
: > place.
:
: Yes, my point exactly. Static type checkig is in effect a case statement
: in the compiler whose tag value is the object's type or class.
: > But this has _nothing_ to do with what I was talking about.
:
: Ok. So what were you talking about?
The mechanisms that the language uses in locating code, whether runtime
or compile time, statically checked, dynamically checked, or unchecked,
have no impact on how much code has to be updated by the programmer to
accomodate new types.
If I insert code into a method that says ``if you're a foo, do this, else
if you're a bar, do that'', the _I_, as a programmer, have to go back
to that piece of code when I create a new type to make sure that it
is handled correctly. That a C++ compiler or a SmallTalk runtime will
do something similar when I use polymorphism has both nothing and everything
to do with it. Nothing, because I'm talking about programmer effort and
maintenance issues, not static vs. runtime type checking, and everything,
because it is exactly because both C++ and SmallTalk provide for
polymorphism that I _don't_ have to embed code that depends upon type
in every function that has to handle different types.
Is it clear yet? I'm not arguing SmallTalk vs. C++ when I say you should
be _very_ sure that checking type is necessary. Both languages provide
for a form of polymorphism, in _either_ language, you should use that
polymorphism when dealing with multiple types. Explicit type checks
create unnecessary and unexpected dependencies, and should be avoided
whenever possible.
I'm not at all sure that you disagree with me here, I think you just read
more into my original post than was intended.
--
David Buck
dha...@icarus.cc.uic.edu (David James Hanley) wrote:
>Jason E. Kratz (jkr...@tezcat.com) wrote:
>: dha...@icarus.cc.uic.edu (David James Hanley) wrote:
>: >: The way that C++ does its method calls is idiotic. It relies on
>: >: the static type system to give it the information it needs for
>: >: making the call (i.e., the index into the virtual table).
>: > This is the right way to do it. In smalltalk, Everything is
>: >an object of type "foo". When I get a foo, I don't know what the heck it is.
>: >I have no guarantees, and neither does the compiler.
>: Wrong wrong wrong wrong wrong. In Smalltalk every object is whatever
>: you defined it to be.
> Wonderful fantasy, but but here's an example that shows where
>that is terribly wrong. In the real world, most programming efforts are
>team-based. Let's say that our team has agreed one an overall structure
>and that your module will be getting poo* objects through one method.
>In a statically typed language, you will get poo* through there,
>guaranteed. Any attempt to pass something else will be caught right away,
>at the first attempt to compile the offending code. In a dynamically
>yuped language, it potentially might not get caught until late in the
>development cycle long after the mistake has been made, when it is hard
>to find.
This sounds like a wonderful theory, but in practice, it just doesn't
hold. Just because someone inherits from a particular base class
doesn't mean that they implemented all the required operations
in the proper way. In this case, the called method would blow up
as well. It's the same thing as with dynamically typed systems..
The problem is that for type constraints to mean anything at all,
you must specify not only the required operations but also the
proper semantics of these operations. Static type systems can't
do this - there's no technology that allows them. On top of this,
a type system must allow you to break up and combine types.
A method may need only a few of the operations of a particular
type. How can you allow this flexibility without massive changes
throughout the system? Can you indicate that a parameter must
conform to two or more type protocols at the same time? No.
Once again, you're stuck making unneeded classes and massive
system changes.
So, in practice, you have the same problem. Somebody can pass
an object to a method that causes that method to blow up. How
do you prevent it? You could try code correctness proofs. When you
finally manage to do this, your application will be 50 years out of
date. Or, you can count on the developers to follow the rules and
to pass the proper kinds of objects.
I've heard these arguments time and again. I've used both statically
and dynamically typed systems extensively. In my 12 years of
experience in object oriented programming, I've found that
the statically typed systems don't live up to their promises and that
the horribly slow development process just shackles you down so
that when you do need to fix a problem or change a design design
(don't kid yourself - design changes happen), it becomes a nightmare.
The bottom line is this: Programming is hard. Any way to simplify it
leads to better and more robust systems. Statically typed systems
make programming more difficult. Dynamically typed systems make
programming easier. If programming is easier, it's easier to develop
code, test code, find bugs, fix bugs, change architectures (if
needed), and maintain the system in the long run. All of these things
become much more difficult with static type systems.
Software development has created some terrible failures. To prevent
these failures in the future, managers tend to enforce more stringent
controls, more restrictive environments, more shackles on the poor
programmers. They haven't addressed the basic problem: Programming
is hard. If they did, they try to simplify the programmer's life, not
add additional complexity, constraints, and unneeded baggage. It's
no wonder more and more software projects are failing.
Enough said. I will probably never convince you. I suspect that
you've never developed in a dynamically typed object oriented system
so you've never run across this alternative. In any case, I put in my
vote for dynamically typed systems and no type constraints on
variables. For me, simplicity and ease of development far outweighs
any suggested advantages that statically typed systems may offer.
David Buck
db...@magmacom.com
Matt Kennel
. (t...@best.com) wrote:
: In article <31D6F2...@concentric.net> "Alan L. Lovejoy" <alov...@concentric.net> writes:
: Smalltalk is typesafe, it is strongly typed: type errors cannot occur.[...]
: And despite the protestations of disbelief from the static typing priesthood,
: the dynamically-typed Smalltalk baloon does fly safely.
: That's kind of misleading. Yes, type errors cannot occur in the sense
: that you don't get incorrect results by accident. However, runtime
: type exceptions can occur at unexpected places, and can result in
: unrecoverable states (one of the favorite messages of the Lisp machine
: was "NIL is not a number").
: Now, you can find those problems with some testing. In fact, in many
: cases, that is perfectly acceptable (I write a lot of code in
: dynamically typed languages). On the other hand, a static type
: checker can greatly reduce the effort you have to spend on testing, in
: particular during code maintenance.
I think people are missing the real core of static typing.
It is not just a 'hack' to permit faster execution, but pervasive
*assertions* about the intended behavior of the program and, thus implicitly
about the legality of the input data.
A language that doesn't type variables does NOT have the same assertions
provided by the programmer and no compiler will be able to reconstruct them
all, unless you write assert(this) assert(that) assert(the other) all over
the place, which is unidiomatic.
Still, not all static typing need be *explicit* static typing.
If you add static type inference you can simultaneously gain many benefits
of an otherwise fully dynamic environment (rapid prototyping) without losing
static typing of variables.
Finally, I've found static typing much more useful when I come back
to modify a program, as it points out screwups about issues I totally
forgot about, than in initial development when different pieces
fit simultaneously in my head.
: Thomas.
--
Matthew B. Kennel/m...@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility. On account of egregiously vile spamation,
my software terminates all email from "interramp.com" and "cris.com" without
human intervention.
Eric Clayberg
Andy Dent wrote:
> Sorry to cast a dark cloud, but a quick poll at our OOSIG meeting revealed
> that the majority by far found Smalltalk hard to understand.
Smalltalk has got to be one of the simplest, most consistent computer
languages ever developed. I find it hard to believe that any computer
professional would find Smalltalk hard to understand - especially if
they had any OO background at all. Heck, it only has about a half dozen
reserved words, a small number of reserved symbols and a syntax that
can be described on half a sheet of paper.
Did your "quick poll" actually include any folks who had actually used
Smalltalk (let alone actually seen it)? It doesn't seem very likely...
-Eric
Objectshare
Alan L. Lovejoy
Christopher Sharrer wrote:
> The point is: it is difficult to to be *sure* that every possible
> run-time error has been found, while it is easy to be sure that every
> compile-time error has been found.
>
> Just my two-cents.
You can't be sure at compile time that no array index will ever be out of
bounds. By the reasoning above, dynamic array indexing should then not be used.
You're throwing out the baby with the bathwater.
Stefan Matthias Aust
>Few other thoughts:
>Someone in Germany (sorry I forgot the name) is trying to translate
>Smalltalk in Java at the source level. I think he is doing that
>in Java.
I think, that was me. I indeed tried to build a small translator just
to figure out how difficult a real program would be. I've a very first
version that can translate normal Smalltalk code except for most blocks
and that won't translate constants.
"a max: b" is translated correctly as "a.max(b)", but "1+2" translates
to "1.plus(2)", which of course is syntactically wrong. It can be done
better. The real problems are blocks, however. And for a real program,
you would need the usual Smalltalk class library.
I've done it in Smalltalk, not Java, because I found it much easier.
>At the bytecodes level, I was discussing with Jeff the possibility to
>write the Smalltalk compiler in Java to produce Java bytecodes.
That's another solution and in some aspects (constants, blocks) easier
than generating source code, but otherwise you have to conform to a
much more complicated class-file-format and the correctness proof of
the code is more difficult.
bye
--
Stefan Matthias Aust * IC&C GmbH * http://www.io.com/~icc/
Graham Perkins
> : true object-oriented environment are mutually incompatible.
>
> Gosh. I never saw that in the oop definition table.
I agree with Dave JH here .. this kind of assertion (like that hoary
propaganda "flexible organisations need dynamic types") is rarely
supported by rational argument or empirical evidence. Personally
I find Visual Age, ISE Eiffel, O2Database, and Turing educational system
all offer much better environments than Visual Works. The IDE
technology does not seem all that closely related to static/dynamic
type rules of underlying language.
> : The way that C++ does its method calls is idiotic. It relies on
> : the static type system to give it the information it needs for
> : making the call (i.e., the index into the virtual table).
> This is the right way to do it.
Agreed with David JH again. If you have static types, then optimising the
polymorphic method calls is quite useful.
Generalising 200 methods
------------------------
> : If I have 200 methods that
> : all expect to take a particular type of parameter, then I
> : decide that I want to generalize the parameter to better
> : isolate the functionality I'm actually using, I have 400 changes
> : to make throughout the system (the class declaration and
> : the method itself).
>
> No excuse for poorly thought-out design.
Both Davids wrong here. Of course you can't design all future changes
in to start with. OTOH, you may not need 400 changes. That only happens
if you have duplicate method signatures (eg .h and .cpp files in C++) and
crassly stupid development tools. I'd suggest that normally the language
and/or tools would reduce this to 200 changes immediately. Also your tools
ought to provide some global substitution operations, enabling you to make
whole groups of changes at a go - so maybe you can get this down to 30 or
40 changes.
Now let us consider these differences a little more carefully. Suppose
one of our 200 methods dealing with CUSTOMER objects is the ACCOUNT
instance method for attaching an additional customer to an existing account:
[Smalltalk]
attach: aCustomer residingAt: anAddressString
.. some code ..
[Eiffel]
attach( cust:Customer, address:String ) is
.. some code ..
and we decide that in many parts of the system we can use PERSON instead
of CUSTOMER in order to make operations more general. The Eiffel programmer
has to change the method heading to
attach( p:Person, address:String ) is
...
but the Smalltalk programmer edits nothing. BUT BUT BUT are we absolutely
positive that the "..some code" implementation only takes advantage of features
defined in PERSON, or does it do something that is CUSTOMER specific?
The Eiffel programmer will discover any erroneous abstractions to PERSON the
next time he/she does a "melt" (or compile). The Smalltalk programmer will
not find any such mistakes until thorough unit testing of all 200 methods
has been repeated.
And anyhow, how does the client programmer know that
attach: aCustomer residingAt: anAddressString
.. some code ..
can actually be used to attach more general PERSON objects to accounts
rather than specialised CUSTOMER objects? Shouldn't the original programmer
rewrite the method as
attach: aPerson residingAt: anAddressString
in order to make this generalisation more clear? Or is it up to the
client programmer to read the source of the method and all other methods
dependent on its state change to see what other objects will be able to
stand in for Customer without causing problems?
So there you have it. The Eiffel programmer (static types) changes
200 methods by making 30 or so edits, and gets all the changes properly
checked just by recompiling. The Smalltalker either makes no changes
and expects client programmers to fully understand the implementation
of every single class, or makes 200 changes and 200 unit tests.
Static typing keeps the type information in the code, hence allows
evolution. Dynamic typing hides the type information, hence makes
evolution much more error prone.
Change turnaround
-----------------
Slow change turnaround is a matter of development environment technology
and user-interface design, not static vs. dynamic typing. I find Smalltalk
systems quite smart in terms of speed and visibility when starting out with
some new stuff and just trying out some little bits and pieces of classes.
But once I've got a dozen or so classes going and half their methods drafted,
the browsing and melting speed of the ISE Eiffel environment is hugely superior.
Many other systems offer different trade-offs, unrelated to the language
or its type system.
Static Types and C++
--------------------
I agree with David JH again here. David B is rightly laying into C++
for faults, but not really considering the benefits of some of the
better tools and alternative languages around. It is certainly a gross
injustice to attack static typing on the basis of C++ !
--
person: Graham Perkins paper: School of Computing
bits: g...@dmu.ac.uk De Montfort University
voice: +44 190 883 4936 Milton Keynes MK7 6HP
dots: +44 190 883 4948 United Kingdom
Dave Smith
Jason E. Kratz wrote:
>
> "Alan L. Lovejoy" <alov...@concentric.net> wrote:
>
> [lots of stuff from a great post deleted to save space], snip, snip
> >And despite the protestations of disbelief from the static typing priesthood,
> >the dynamically-typed Smalltalk baloon does fly safely. It's funny to be up
> >here flying around while all you Luddites claim it's not possible and can't
> >be happening. Open your eyes and look up: it **does** fly. Would the financial
> >community be so hot on Smalltalk if it didn't? Or wasn't sufficiently safe?
> >The only people complaining about the lack of static typing in Smalltalk are
> >the ones who haven't really used dynamic typing. You DON'T hear that complaint
> >from the serious practitioners.
The problem here is that you're comparing apples and oranges. At the moment I have to
use C++ for school. I have problems with it I wouldn't encounter in ST, but there are
advantages as well. Example: I'm learning how to write a set of Object-oriented DLL's,
something that I couldn't do with Smalltalk. I like having small, more or less
autonomous modules and libraries, not one massive monolith. I like having real control,
in-line ASM, etc. So when you bash static typing I think you're doing a dis-service.
Smalltalk as I have experienced it could probably suffer some added complexity (e.g.,
static types for certain objects) if the net gain were increased system/OS integration
or speed. It's not clear to me that the current incarnations really represent Smalltalk
at its best.
> I took a class last semester that taught Smalltalk and more advanced
> C++. After learning and programming in Smalltalk going back to C++
> was, well, a really crappy experience. As far as I'm concerned
> every language should be dynamically typed and bound. I love not
> having to worry about what type my variables are. Lets me think more
> about how to code something without having to worry about lots of
> stupid details.
I share this point of view, but I need the features of the static-typed language to
achieve the kind of hard-core systems code I want to write.
> Of course the wondeful thing about dynamic binding is
> being able to edit your code while it is running and have the changes
> take effect the next time you reach the edited method.
It's not really clear to me why C++ can't have some sort of incremental
compilation/linking strategy that would wrap over the mess. Why can't the
compilation/link run on a different thread? The environment is not the language.
Regards,
DS
Dave Smith
Marcus Rugger wrote:
>
> In article <TMB.96Ju...@best.best.com>, t...@best.com (.)
> <Dtrvv...@iglou.com> wrote:
> >C contains no definitions of primitives necessary for writing device
> >drivers, accessing absolute memory, accessing I/O ports, or any of
> >those things you need to write an OS. C doesn't even have first-class
> >argument lists, call stack manipulation, or support for multiple
> >calling conventions, something other, higher-level languages offer
> >you.
Huh? Most of Windows 3.1 (and, I believe, System 7) was written in C. Yes, you can
write a VxD in C. Yes, according to BYTE magazine, you can access absolute memory in C.
To read from a hardware port you can call inp(), inport(), inportb(), etc, from the
Standard Library. You can also read disk sectors (not FAT, I'm talking hardware
sectors) or write to them. As far as I know, you can't do ANY of these things with
Smalltalk or Java.
> >In a language like Java, you can achieve the same effect by adding a
> >few functions and datatypes that encapsulate unsafe/low-level
> >operations. A simple example would be adding Basic's peek/poke
> >operations to Java. In fact, that's the way many successful
> >high-level languages have gone, languages that have been used for
> >writing operating systems. It's no less unportable than what C gives
> >you, and it's actually a whole lot cleaner and easier to maintain.
This is bullshit. Win95 was written for the most part in Assembler for practical
reasons. Java as a system is certainly an OS--in theory. Performance issues require
real work with the native assembler, with the hardware. Otherwise, what is the point of
an OS? So to get to that point, Java would have to be burned into ROM or set out as
logic-gates on a wafer.
> Ok, since the jist of this is writing an OS, let's start out with something
> simple, like getting to the I/O ports of a serial port. In C, you can't, some
> assembly is required. But it certainly is easy enough to link the assembly
> code to the C code that sits on top of it. How is this done with Java
> and the JavaVM? Are there byte code instructions for manipulating I/O ports?
> If so, how do these byte code instructions get generated? Is there a JavaVM
> byte code assembler? Or is a different approach taken? Perhaps the code is
> written in machine specific assembly and accessed through a native
> method call. My guess is this is more likely the case.
This is correct--currently Java is implemented like smalltalk, with an abstract engine
that runs using the OS, that runs using a native code base under it. --But that's not
the only way to go. It was the easy way, but not the only way or the best way.
> >Sadly, programmers with your kinds of beliefs about the C programming
> >language often go on to writing code that unnecessarily depends on the
> >unportable low-level semantics of C.
Sadly, programmers who fail to understand the realities of performance issues and real
world development think Java's current performance is acceptable. It isn't.
Regards,
DS
Andy Dent
In article <31D728...@concentric.net>, "Alan L. Lovejoy"
<alov...@concentric.net> wrote:
>So instead of spending the resources to make a "small" Smalltalk, Sun
>spends the resources to make a completely new language.
That's very similar to common languages.
Sorry to cast a dark cloud, but a quick poll at our OOSIG meeting revealed
that the majority by far found Smalltalk hard to understand. People who
zip between PowerBuilder, VB, and other business languages need the base
syntax to be reasonably compatible. This is the big$ market.
Andy Dent, Product Architect, A.D. Software, Western Australia
OOFILE - "the cross-platform OODBMS that speaks c++"
ftp://ftp.highway1.com.au/pub/adsoftware/oofile/
http://www.highway1.com.au/adsoftware/oofile.html
Joe Kinsella
Peter Day <pe...@blmsbury.demon.co.uk> wrote:
>What is all this stuff about 'free' software. Smalltalk will never be
>free - and Java won't be free much longer. Sure SUN have an interest in
>promoting it so they can sell more servers but who really believes
>Microsoft, IBM or anyone else is going to give Java away for free. Once
>we see a real price on the stuff we can make meaningful comparisons on
>price/performance.
What are you smoking crack or something?! I'm not sure what you are
waiting for since t here are a 1/2 dozen sites on the net where you
can buy a Java development environment *NOW* (e.g. Symantec Cafe
$129). There is your price comparison! Sure it's not free--but
compared with the average price of Smalltalk, it might as well be!
>But in reality we now have another language to use for development and
>it only serves to make the language wars more ridiculous
Languages are not created too confuse us or to make us argue more.
Languages are created to fill market opportunities (real or
perceived). The fact Java has been as successful as it has been at
this early stage is a testament to the existence of a market
opportunity. Whether or not Smalltalk could have filled this market
opportunity is irrelevant. It didn't.
David Buck
Christopher Sharrer <ch...@luminous-chao.com> wrote:
>The point is: it is difficult to to be *sure* that every possible
>run-time error has been found, while it is easy to be sure that every
>compile-time error has been found.
Yes it is difficult to insure that every possible run-time error has
been found. Unfortunately, compile-time error reporting isn't
guaranteed to be anything more than an nuisance. Besides,
there are lots of other runtime errors you have to worry about.
Collections indexed out of bounds, null pointers, algorithm problems,
memory leaks - all are problems that need to be found at runtime.
Why are types so different? Having a statically typed system doesn't
eliminate the need for careful testing.
In Smalltalk, I can find and fix runtime errors in a fraction of the
time it takes to even compile in a statically typed language. What's
the big deal about types?
David Buck
db...@magmacom.com
Travis Griggs
Eric Clayberg wrote:
>
> Andy Dent wrote:
> > Sorry to cast a dark cloud, but a quick poll at our OOSIG meeting revealed
> > that the majority by far found Smalltalk hard to understand.
>
> languages ever developed. I find it hard to believe that any computer
> professional would find Smalltalk hard to understand - especially if
> they had any OO background at all. Heck, it only has about a half dozen
> reserved words, a small number of reserved symbols and a syntax that
> can be described on half a sheet of paper.
>
> Did your "quick poll" actually include any folks who had actually used
> Smalltalk (let alone actually seen it)? It doesn't seem very likely...
>
I agree completely Eric. But I personally do NOT find it hard to believe
that any computer profession would find Smalltalk hard to understand. My
experience has been that is exactly those that do consider themselves
"computer professionals" that seem to have a difficult time with
Smalltalk (though not all). Often, that professionalism limits them from
the kind of "out of the box" "take a fresh approach" thinking that is
necessary. I'm of course just generalizing here.
As a self/peer taught C, Smalltalk, Fortran, some Assembly, and a little
C++ person, I love Smalltalk to pieces.
--
Travis Griggs
t...@3-cities.com
(509) 943-4210