HDTenEightyP/NetNews huggingface dataset:
From: palachar@bert.eecs.uic.edu (Prasad Palacharla)
Subject: Re: QUESTION: Any shareware/Anonymous FTP/... SmallTalk environments?
Organization: University of Illinois at Chicago
Date: Mon, 28 Sep 1992 18:14:02 GMT

Stephen Cooper <stephen@csd.uu.se> writes:

>In article <01GP4HJDJNTY9PMC9D@BNANDP51> beno?t marchal,
>INFSTDMARCH@BNANDP51.BITNET writes:
>>There's Little Smalltalk which, as I know, comes without GUI.

>  Little Smalltalk is a compliment to Tim Budd's excellent book "An
>introduction to Object Oriented Programming" and is described in his book
>"A Little Smalltalk".  There is a (primitive) GUI.  It uses a freeware
>general windowing environment which can compile to several personal
>computer platforms as well as to X.

>  I'll be using Little for a course in OOP I'll be teaching for the first
>time in December.  It looks perfect for education.  A school project I'm
>considering is: "Improve the GUI".  If there's an interest (and I
>remember), I'll summarize my experiences with Little in January.  So far
>I'm reserved, but positive.  Little is definately an implementation meant
>for educational purposes, not commercial.  But then again, it's free.

>  Little can be sent for by mailing to: oopintro@cs.orst.edu and placing
>the word "Little" in the subject line.  Sending for "Help" will describe
>the services available.

>/Stephen Cooper
>-----------------------------------------------------------
>Stephen Cooper  	       	       	+46-(0)18-18 10 73 (voice)
>Computing Science Dept  	       	+46-(0)18-52 12 70 (fax) 
>Uppsala University, Sweden      	stephen@csd.uu.se


I tried to email to oopintro@cs.orst.edu but the message bounces back.  Could you
please help getting Little Smalltalk for using on Sun workstation/ Macintosh.

I appreciate your help.

Prasad Palacharla.
University of Illinois at Chicago.
From: marten@feki.toppoint.de (Marten Feldtmann)
Newsgroups: comp.lang.smalltalk
Subject: ST/V PM 2.0 upgrade -- overpriced ?
Distribution: world
Date: Fri, 02 Oct 92 10:33:54 GMT
Organization: Private OS/2 System

Oh boys, here we are now. The prices for the ST/V-PM 2.0:

Retail price:                       $995
Upgrade price until October 31, 92: $275
Upgrade after this date:            $375

Digitalk is entering a new price region ..... perhaps good for Digitalk,
bad for Smalltalk ....

I'll be interesting to see, if Digitalk (sometimes in the future)
introduces royalities for run-time licences ... just another idea for
making money ..... :-)


:-((((((((

 MF


--
Marten Feldtmann,     Kieler Str. 29,       2300 Kiel 14,    Germany
E-Mail: marten@tpki.toppoint.de, FAX possible
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
From: steinman@is.morgan.com (Jan Steinman)
Subject: Nadja is a Newsgroup Virus
Organization: Morgan Stanley & Company
	<1992Sep25.225827.12732@m.cs.uiuc.edu>
	<1992Sep28.224954.20370@jetsun.weitek.COM>
Date: Tue, 29 Sep 1992 13:54:37 GMT

I think we should all calm down a bit. Nadja suddenly appeared here
from the constant flame wars in comp.lang.c++ or someplace similar,
and it is apparent that her preferred mode of communication is
unidirectional. One of the things I value most about this newsgroup is
the generally civil discourse, and those who feel the same should
ignore agents provocateur.

Nadja obviously knows all there is to be known about large,
commercial, real-time applications, while also knowing all there is to
be known about Smalltalk, C++, life, the Universe, and everything.

It behooves the rest of us, who are still struggling with relatively
trivial things like distributed objects, object typing techniques, and
large, commercial transaction processing systems, to simply ignore
her, since she exists on a higher plane, and will only confuse we poor
mortals.

Other theories: Nadja (AKA Bertrand, Bjarne, or Brad) is a plant from
a competing newsgroup, intending to be provocative so as to keep us
from sharing information among ourselves, Nadja is an alien spy --
their culture determined that Smalltalk was superior, and they intend
to keep us backward with disinformation, Nadja is Elvis, and will have
no talk of another King, Nadja is Dan Quayle, and heard that "small
talk" destroys Family Values, Nadja is Murphy Brown, and is just plain
irratating...

We all know how to use our kill files, don't we?

--
: : Jan Steinman	   steinman@is.morgan.com		 Bytesmiths : :
: : 2002 Parkside Court				   West Linn, OR 97068-2767 : :
: : 503/657-7703					       212/956-8722 : :
Newsgroups: comp.lang.smalltalk
From: cantwell@vuse.vanderbilt.edu (Jeff Cantwell)
Subject: Re: Is Smalltalk the language for us?
Organization: CIS, Vanderbilt University
Date: Mon, 28 Sep 1992 17:17:32 GMT

In article <2952@news.cerf.net> mike_r@nic.cerf.net (Mike Roberts) writes:
>In article <Bv5KJD.IDC@vuse.vanderbilt.edu> cantwell@vuse.vanderbilt.edu (Jeff Cantwell) writes:
>>We recently created an application for a Fortune 500 Co. in PPR4. To
>>sum up our experience briefly, the most frequent complaints about the
>>system were:
>>
>>1. It takes too much memory.  Our application required 8 mb of RAM to
>>run.  Even then we still occasionally ran out of memory. Our platforms
>>were about 50% Mac, 45% PC, and 5% Unix.  People with a PC or Mac
>>think the 8 mb requirement is ridiculous. Two, maybe even 4 mb is ok,
>>but 8 is not. I don't see how you can reduce this requirement by much,
>>given that the basic PPR4 system requires 4 mb to run. We did use the
>>stripper to reduce the size of our image.
>>
>
>With the current PC memory prices (<$40 per Meg) I don't think that this
>is a valid critisism. People are used to spending $500 on a single user
>licence. $300 for memory dosn't seem such a great price to pay ......
>
>BTW, could you give some indication of the size (lines of code, number
>of methods, number of classes) of of your application. A comparison
>with the V products would be most interesting.
>
>Mike
>MediaShare Inc
>

I think for most users, the inconvenience of needing the extra memory
outweighed the cost factor. However, cost was significant when
higher-level decision-makers became involved. When you are talking
about spending an additional $200 or $300 a head for a single
application, this can add up quickly, say for 1000 or even 10000
users.


-- 
Jeff Cantwell, Vanderbilt U. CIS Box 1804, Sta. B Nashville, TN 37235 
  Internet: cantwell@vuse.vanderbilt.edu Bitnet: CANTWEJR@VUCTRVAX
	Phone: (615) 322-0110  Fax: (615) 343-6449
       2 Cor. 12:9 "Power is perfected in weakness."
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
From: jungclau@ips.cs.tu-bs.de (Ralf Jungclaus)
Subject: Re: comparing object-oriented platforms
Organization: Database Group, Tech. Univ. Braunschweig (FRG)
Date: Tue, 6 Oct 1992 13:52:18 GMT

In article <1992Oct5.202526.5574@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
>
>I strongly disagree with the above philosophy. I think that static
>type checking helps you to build programs faster, because the compiler
>catches all those stupid errors right at the start.
>
>I also don't believe that  "prototype now, debug later"  is a good
>approach to writing software. 
>
>As a book on time management said: 
>
>   "If you don't have time to do it right,
>       when will you have time to do it over."
>
>
>...richie

... who could not agree..????

Ralf



-- 
Ralf Jungclaus
    Abt. Datenbanken                | INTERNET:  jungclau@idb.cs.tu-bs.de  
    TU Braunschweig, P.O.Box 3329   | Voice: (..49/0)531-391-7443 or -7442  
    D-3300 Braunschweig, Germany    | FAX: (..49/0)531-391-3298
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
From: jungclau@ips.cs.tu-bs.de (Ralf Jungclaus)
Subject: Re: comparing object-oriented platforms
Organization: Database Group, Tech. Univ. Braunschweig (FRG)
Date: Mon, 5 Oct 1992 09:35:31 GMT

In article <ken8Xe_00awRQ5OHYd@andrew.cmu.edu> Stefan Monnier <osoelgaultier+@CMU.EDU> writes:

>Getting a working application in a limited time is not just 
>done for pleasure: customer generally wants to see a working 
>prototype of the application to be sure it can be done, to see how
>it's gonna work and so on.
>Static type checking makes it harder to develop code in limited
>time (prototype doesn't have to be bug free, nor fast, nor complete)
>

As I understand the process of software development in practice, the
prototype (having been validated by the customer) is taken and you put
some nice user interface on top of it and that's it. Do you really
want a prototype to have severe errors when it is presented to the
customer with such a perspective in mind?? I wouldn't want to. 

>What is needed is a language that permits you to write 'free code'
>(without too much verification done by the language) to start 
>fast and get a working prototype in very short time. And then
>add type constraints (etc...) to get to a 'bug-free' (grin) stable
>application.
>
OK, that really might help in some cases. But it should be an
*exception*, not the usual case, and thus there shouldn't be a
compiler option but a language feature to turn it off for just an
exceptional case ...

BUT anyway, prototyping should take place on a very high level of
abstraction, i.e.\ we should take a conceptual model or an
object-oriented *specification* and prototype it. If you have to
prototype a program, then it's either too late or you didn't invest
much work in the analysis and design phase --- but that's *absolutely
essential*!!

>Sure debugging is easier with static type checking, but this help
>sometimes turns out to be a hassle: it should be possible to turn
>it off (completely or partly)

And if you have some tool that supports the generation of code from a
specification, then you (hopefully) do not have to debug at all ....
(a bit idealistic, I know, but we're working on it ...) 

Ralf




-- 
Ralf Jungclaus
    Abt. Datenbanken                | INTERNET:  jungclau@idb.cs.tu-bs.de  
    TU Braunschweig, P.O.Box 3329   | Voice: (..49/0)531-391-7443 or -7442  
    D-3300 Braunschweig, Germany    | FAX: (..49/0)531-391-3298
From: fellin@sumax.seattleu.edu (Phillip Fellin)
Newsgroups: comp.lang.smalltalk
Subject: ParcPlace listening???
Date: 29 Sep 92 03:59:08 GMT
Distribution: usa
Organization: Seattle University, Seattle WA

I am interested in finding out information 
about your entire product line, including
priceing and support.  I have tried with not
much success the info@parcplace.com.  If you
get this, please e-mail.
Thanks

Xref: sparky comp.lang.smalltalk:1934 comp.object:3748 comp.lang.objective-c:559
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.objective-c
Subject: Re: MVC shortcommings
Date: 28 Sep 92 21:16:36 GMT
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

frerk@informatik.uni-kl.de (Frerk Meyer) writes:

>MVC is a White Box as opposed to a Black Box.

This is much less true of the MVC in R4.0 (and R4.1) than it was
in 2.5.  As often happens with frameworks, MVC is becoming more
and more black-box.  And the original question was about the MVC
*paradigm* (whatever that is), so one could take any criticism
of the *implementation* and just say that it is bug waiting to be
fixed, not really a problem with the paradigm

I agree that black box frameworks are easier to reuse.  The use of
Wrappers in 4.1 makes user interface components much more composable
and means you have to understand less about their implementation.

-Ralph Johnson
Xref: sparky comp.lang.smalltalk:1964 comp.lang.eiffel:1191 comp.object:3772
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
Subject: Re: comparing object-oriented platforms
Date: 29 Sep 92 21:47:12 GMT
Article-I.D.: arolla.TMB.92Sep29174712
	<#qjz+#j@rpi.edu> <1992Sep29.104419.26934@actrix.gen.nz>
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.smalltalk
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: Des.Kenny@bbs.actrix.gen.nz's message of 29 Sep 92 10:44:19 GMT


     The system has to respond at the 20ms level.

     It is a safety critical application. A runaway 1/3 of a ton robot is
     no joke! 

     It is using four T800 Transputers and two datalinks that have transfer rates
     of 200MB/second.

     So this is real time with Eiffel. I do not know how exactly
     they are using the garbage collector. I will let you know when I find out.
     But you can be sure that they can not afford a memory seizure of a mobile
     1/3 ton beastie!

     They have a spectrum of choices from no garbage collection, to tuned
     collection to full system default collection. It will be very interesting to
     see how they are approaching this issue.

Assume I have a program that never has more live data than, say, 45%
of real memory. Does your Eiffel implementation guarantee that every
request for memory has a small bounded latency, and does it guarantee
at the same time that my program will never run out of memory?

I am all for GC, even in real-time applications. Furthermore, you can
do real-time GC "right", meaning, you can guarantee (small) bounded
latencies for all operations that would have bounded latencies in the
absence of GC.

However, your descriptions of "turning off GC" or "tuning your
application" sound like the Eiffel implemention you are talking about
isn't getting it right. "Turning off GC" means that you will
potentially run out of memory, which is probably even more dangerous
than garbage collecting for a little while. "Tuning your application"
means that you are hacking around without knowing whether your code
actually has a bounded latency.

So which is it? If there were a commercial implementation of a
real-time GC for a general purpose language, I'd definitely like to
know about it. Otherwise, Eiffel doesn't seem to be any more suitable
than run-of-the-mill CommonLisp implementations for real-time
programming, which have lots of facilities for "tuning". In fact,
using facilities such as weak references and pools, I suspect that a
run-of-the-mill CommonLisp implementation might even be better suited
(relatively speaking) to real-time programming than Eiffel.

					Thomas.
Xref: sparky comp.lang.smalltalk:2011 comp.lang.eiffel:1224 comp.object:3828
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
Subject: Re: comparing object-oriented platforms
Date: 3 Oct 92 02:42:35 GMT
	<TMB.92Sep29101816@arolla.idiap.ch>
	<1992Sep30.031100.7446@actrix.gen.nz>
	<TMB.92Oct1180516@arolla.idiap.ch> <kemtuha00awA8FZnhw@andrew.cmu.edu>
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.smalltalk
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: osoelgaultier+@CMU.EDU's message of 2 Oct 92 00:58:21 GMT

In article <kemtuha00awA8FZnhw@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:

   Excerpts from netnews.comp.lang.eiffel: 1-Oct-92 Re: comparing
   object-orient.. Thomas M. Breuel@arolla. (3014)

   > What you are arguing for is opacity. Opacity can be achieved in many
   > programming languages, including C and C++, without even ever using
   > any OO techniques. That is, you can define a datatype in C/C++ such
   > that you are guaranteed that no user of that datatype manipulates it
   > without going through the interface that has been provided by the
   > author of the datatype.

   Sorry, it must be an error: You seriously mean you can write code
   so that noone can use your datatype directly ?  Show me how !

Usual C approach (frob.h):
   
   typedef struct _frob *frob;
   
   frob frob_make();
   void frob_destroy(frob);
   int frob_extract_some_field(frob);
   void frob_add_something(frob,int);
   
Note that there is no definition for "struct _frob" around. In fact,
the only place that definition would be given would be inside the
file(s) that define the above functions. Without knowing the actual
definition, you can't access the internal representation of a "frob".

Usual FORTRAN approach (albeit, also written in C):

   typedef int frob;

   frob frob_make();
   void frob_destroy(frob);
   int frob_extract_some_field(frob);
   void frob_add_something(frob,int);

Essentially, a "frob" is an offset to some internal table inside the
"frob" library. This absolutely guarantees that you can't get at the
representation of a "frob" without going through the defined
interface; not even guessing and casting will help you.  Sadly, you
lose static type checking this way. On the other hand, this kind of
interface is easier to use if you mix languages.

					Thomas.

PS: Some people like to quibble that the "C" approach lets you get at
the bits of a frob via casting. Note that this is not a problem with
the "FORTRAN" approach. If you absolutely want to make sure that
casting doesn't work _and_ you want static type checking, you can
combine the two and have "struct _frob" contain an internal offset.
Newsgroups: comp.lang.smalltalk
Newsgroups: comp.lang.smalltalk
Subject: Pointer to microfocus ?
From: dugerdil@uni2a.unige.ch
Date: 2 Oct 92 14:13:23 +0200
Organization: University of Geneva, Switzerland

In article <gr8nykg.peterg@netcom.com>, peterg@netcom.com (Peter Goodall) writes:
> Microfocus has a product, (the name might be Cobol Workbench) that includes
> Smalltalk/VPM. I believe it is specifically for migrating cobol system
> front-ends onto PC workstations. I don't know any more detail.
> 
> Peter Goodall -- peterg@netcom.com

Peter,
Could you give me a pointer to Microfocus (phone, fax, email). The product
you mentionned seems very interesting.

Thanks.

Philippe Dugerdil

Newsgroups: comp.lang.smalltalk
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Subject: Re: Is Smalltalk the language for us?
Organization: WEITEK Corporation, Sunnyvale CA
Date: Mon, 28 Sep 92 22:49:54 GMT

In article <1992Sep25.225827.12732@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
>nadja@jetsun.weitek.COM (Nadja Adolf) writes:
>
>>But smalltalk has its own problems. If you call a member function
>>on an object under construction, the member function acts as if the
>>object had already reached its destination subclass if it is not
>>yet completely constructed. This can be a really hard bug to find if
>>multiple people are working on multiple parts of a program at the same
>>time. In C++, the object is handled at the actual stage.

>Spoken like a true C++ programmer.  I remember the time (summer '89
>I believe) when I realized that calling a virtual function in a
>constructor would not call the member in the class of the object
>being created, but in the class of the calling constructor.  This
>seemed to completely violate the purpose of virtual functions, but
>it is exactly the behavior Nadja wants.  This is why Smalltalk programmers
>write

>new
>  ^ super init

>once in a superclass and then just redefine the init method in
>subclasses.  Of course, a C++ programmer says that you should write
>init code in the constructor, but what if you want to be able to
>reinitialize an object?  You have to end up duplicating the code.
>No, I prefer the way Smalltalk does it, and I've done it both ways
>a lot.

Really? If you have to duplicate the code, you aren't much of a C++
programmer. :-)

>If I were not a C++ programmer I would probably not know what he was
>talking about.  He is talking about the code inside an init method,
>and complaining that it is possible to invoke a subclass method by
>sending a message to self *before* you have completely initialized
>all the instance variables.  Horrors!  And it is possible to return
>from init without initializing all the instance variables, too.  Gee,
>I bet you could do that in C++, too!    :-) for those who need it.

He is a she. :-) Seriously, if for some reason the smalltalk object hasn't
reached the final subclass, there can be some very dangerous behavior.
This is a major problem when writing things that are running asynchronously
on more than one host. C++ provides ways in which each machine can verify
object status quickly and with few problems.


>I disagree.  Moreover, the Smalltalk programming environment makes
>debugging a lot easier than in C++.

Seen SGI yet?

>There is no such thing as a "resurrection bug".  I suppose there is a
>thing such as "giving someone rope to hang himself by".  That is one
>of the reasons that I never teach "allInstances" to beginners.  In
>general, stay away from metaprogramming with beginners.

All instances isn't the only way. Having a program that runs simultaneously
across platforms does it just as well. Since there is no behavior at
destruction, it requires creating additional smalltalk subclasses to notify
the other platforms.



-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
From: mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner)
Newsgroups: comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Date: 6 Oct 92 20:13:09 GMT
Organization: DB and ES Subdivision, TU Vienna

From article <1992Oct6.173956.16792@netcom.com>, by nagle@netcom.com (John Nagle):
>       There are Modula 2 systems, such as Topspeed Modula-2, that
> remove all unreachable methods at link time with a "smart linker".
> This takes a few seconds, not overnight.  There's something wrong
> with the approach if it takes hours.

This may depend on the degree of precision with which the system
works.  I don't know Envy/Developer, but if it works on programs that
contain calls to "perform" (i.e., metalevel calls with a mapping from
variables to method names), then I would not be surprised at the slow
speed (indeed, I'd be surprised that it works at all).  Perhaps
someone can comment on this.

Apart from that possibility, it is not surprising that programs in a
language with strong typing and lack of overloading would be much
easier to process along these lines (this is not intended as defense
of Smalltalk since overnight still is a very long time in any case.
I'm merely pointing out possible reasons that come to mind).
-- 
Markus Stumptner                                mst@vexpert.dbai.tuwien.ac.at
University of Technology Vienna                 vexpert!mst@relay.eu.net
Paniglg. 16, A-1040 Vienna, Austria             ...mcsun!vexpert!mst
Newsgroups: comp.lang.smalltalk