HDTenEightyP/NetNews huggingface dataset:
From: rhorn@csws17.ic.sunysb.edu (Robert Horn)
Newsgroups: comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Date: 3 Oct 92 17:06:23 GMT
Organization: State University of New York at Stony Brook

In article <TMB.92Oct2224235@arolla.idiap.ch> tmb@idiap.ch writes:
>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".
>
>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.

Isn't this just a little bit paranoid? I can see making it difficult
to examine the contents of a frob by never documenting its structure,
but must you code defensively against idiots who go out of their way
to cause trouble for themselves?
-- 
rhorn@ic.sunysb.edu           Never choose a college because it has a duckpond.
Xref: sparky comp.lang.smalltalk:2024 comp.lang.eiffel:1229 comp.object:3834
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
Subject: Re: comparing object-oriented platforms
Date: 4 Oct 92 01:52:46 GMT
	<ken8Xe_00awRQ5OHYd@andrew.cmu.edu>
	<1992Oct3.015535.20096@jetsun.weitek.COM>
Reply-To: tmb@idiap.ch
Followup-To: comp.lang.smalltalk
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: nadja@jetsun.weitek.COM's message of 3 Oct 92 01:55:35 GMT

In article <ken8Xe_00awRQ5OHYd@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>Static type checking makes it harder to develop code in limited
>time (prototype doesn't have to be bug free, nor fast, nor complete)

In my experience, static type checking _in a polymorphic type system
with type inference_ makes it easier and faster to get code working;
it doesn't make it harder. As an added bonus, it does help reduce the
frequency of bugs, and it does help make your code run faster.

If you don't have a polymorphic type system with type inference, then
I agree that static type checking is a bother.

					Thomas.
From: podenski@bcsaic.boeing.com (Patrick Podenski)
Newsgroups: comp.lang.smalltalk
Subject: Re: Is Smalltalk the language for us?
Date: 27 Sep 92 21:15:55 GMT
Organization: Boeing Computer Services AI Center, Seattle

In article <1992Sep25.231021.16406@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
>I noticed the "LookPreferences" in 4.1, which seems to me to be a
>hook to fix this problem.  The idea is that you can redefine 
>LookPreferences to change the look and feel.  Has anybody done this?
>Does ParcPlace sell kits to give you Mac l&f, Windows l&f, Motif l&f?
>If not, they are missing a great opportunity, and someone else should
>grab it.

Apparently ParcPlace is coming out with a new product to address the
look and feel issues. 
Xref: sparky comp.lang.smalltalk:1957 comp.lang.eiffel:1187 comp.object:3763
From: 88600044s@csghsg5a.bitnet
Newsgroups: comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Date: 2 Oct 92 08:23:49 GMT
Organization: University of St.Gallen, Switzerland

In previous postings it has been said that Smalltalk is
both slow and too big. I agree that the file of the final
executable can be much bigger than appropriate. Now there
is Envy/Developper that steps through all of your code of
your application and removes all code from the image that 
is not needed in your application. This process can take
over a night to finish but the result is a minimum possible
executable file.

Second, there is Smalltalk/V PM v2.0 waiting. It will be
truly 32-bit and therefore also significantly faster. It
will also be truly multi-threaded (v1.4 does only have two
threads: a background and a foreground one).

Nevertheless, I agree that a Smalltalk app is not that fast
as one written in C/C++. But now with Envy/Developper and
SMalltalk/V PM v2.0 think oops tings aren't that easily as
before. Smalltalk does have catched up as what speed is concerned.
If I had to write Lotus 1-2-3 (of which I m not capable of)
I would do it in C/C++ (or in Eiffel if a usable system
were existing), but for in-house applicatins there is no 
better thing than Smalltalk.

/Olli Plohmann
Newsgroups: comp.lang.smalltalk
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
Date: Fri,  2 Oct 1992 13:37:46 -0400 
From: Stefan Monnier <osoelgaultier+@CMU.EDU>
Subject: Re: comparing object-oriented platforms
	<1992Oct2.002527.8671@actrix.gen.nz>

Excerpts from netnews.comp.lang.eiffel: 2-Oct-92 Re: comparing
object-orient.. Des.Kenny@bbs.actrix.gen (2292)
>   I guess we are talking about specific implementations of a language
>   in this context.

>   In addition to the time it takes to edit a module of an application
>   and test the result. There are also other important software engineering
>   issues for large systems in industry to consider.

>   In ISE Eiffel 3 we still have static type checking even with an 
>   interpreter/compiler mix. This may be more important for the quality
>   of a system in the longer term. Rapid development of modules with
>   no static type checking may risk type failure in production. So what
>   is really rapid about having to fix type errors at the production stage?
>   I am sure there are some Smalltalk developers who rarely allow type
>   errors into production. But is it not better to let these errors be
>   eliminated by the development tool before production? I prefer the
>   environment to help me as much as possible with quality assurance
>   as early as possible in the lifecycle.


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)

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.

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)

I'm sure this kind of Smallfel (or is it Eifftalk ?) is coming
and will be very nice (I like to dream, you know)

	Stefan

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
From: ab@ersys.edmonton.ab.ca (Allan Brockman)
Newsgroups: comp.lang.smalltalk
Subject: Q: where can I get sumula for the atariST ?
Date: Sun, 04 Oct 92 21:31:23 MDT
Organization: Edmonton Remote Systems #2, Edmonton, AB, Canada

  where can I get sumula ( an OOP lang mentioned in a prievously
 posted message in this echo/room/sig ) for the atariST ?

Allan Brockman              ab@ersys.edmonton.ab.ca 
Newsgroups: comp.lang.smalltalk
From: bernard@is.morgan.com (Bernard Horan)
Subject: Code to keep DialogViews to the front
Organization: Morgan Stanley - IS
Date: Mon, 28 Sep 1992 16:28:51 GMT

Subject: Code to Keep dialogs at the front
Keywords: 

One of the problems with the current version of PPS Smalltalk is the 
disjunction between Smalltalk's window manager (ControlManager) and the
host window manager. This is most noticeable when using dialogViews
(the YesNo and FillInTheBlank type), as they can easily get lost behind
larger Smalltalk windows and consequently give the impression to the
average user (and some programmers) that the system has hung.

Included below is a fix for the problem, it has only been tested
on OpenWindows, and I would appreciate any reports of bugs etc. before
I submit it to the goodies archive. This fix doen't overcome the
problem of menus also disappearing in a similar manner, but I reckon
that's less common anyway.

Bern

'From Objectworks\Smalltalk(R), Release 4.1 of 15 April 1992 on 28 September 1992 at 9:11:11 am'!



!StandardSystemController methodsFor: 'accessing'!

unknownEvent: anEvent
	"do nothing"! !


!DialogController methodsFor: 'accessing'!

unknownEvent: anEvent 
	"Some unknown window manager event has happened, let's assume it 
	means 
	that we need to bring my window back to the front. 
	Bernard Horan, 28 September 1992"

	self view isNil ifFalse: [self view raise]! !


!ScheduledWindow methodsFor: 'events'!

processEvent: anEvent 
	"Dispatch the event to the appropriate method."

	anEvent key == #resize ifTrue: [self extentEvent: anEvent value].
	anEvent key == #close ifTrue: [self controller close].
	anEvent key == #eventUnknown ifTrue: ["Send the event as argument, just in case I ever get to understand its significance" self controller unknownEvent: anEvent]! !
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Newsgroups: comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Date: 5 Oct 92 18:22:41 GMT
Organization: WEITEK Corporation, Sunnyvale CA

In article <ken8Xe_00awRQ5OHYd@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>Static type checking makes it harder to develop code in limited
>time (prototype doesn't have to be bug free, nor fast, nor complete)

I thought about this over the weekend, and realized that one thing really
bothers me here. It is amazing how little of a smalltalk program has to
be present for it to appear to 'work.'

One gets the demo up, it appears to work, and the managers/moneyfolk don't
realize that one is nowhere near a product yet... and anticipate a totally
unrealistic schedule...



-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
Newsgroups: comp.lang.smalltalk
From: tmhoff@oogoody.Corp.Sun.COM (Todd Hoff)
Newsgroups: comp.lang.smalltalk
Subject: Re: Is Smalltalk the language for us?
Date: 29 Sep 1992 05:13:17 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: tmhoff@oogoody.Corp.Sun.COM
NNTP-Posting-Host: oogoody.corp.sun.com

>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 ....

This is somewhat naive. On an individual basis you are quite correct. Now
think about a corporation with hundreds of computers. The cost of the memory
is nolonger trivial nor is the person power to install the memory.
From: gregb@gout.austin.ibm.com
Newsgroups: comp.lang.smalltalk
Subject: Re: ST/V PM 2.0 upgrade -- overpriced ?
Date: 5 Oct 92 13:10:12 GMT
Reply-To: gregb@pro-lep.cts.com
Organization: IBM, Austin
News-Software: IBM OS/2 PM RN (NR/2) v0.14 by O. Vishnepolsky and R. Rogers

In  <9210021940.AA04644@data.src.honeywell.com>  bergstro@src.honeywell.com (Pete Bergstrom) writes:
>From: marten@feki.toppoint.de (Marten Feldtmann)
>> [ prices deleted]
>
>I've fired off an unhappy note to the compuserve address asking them
>to clarify this situation.
>
>In fact, I'm not mad, I'm pissed.
>
>Pete

I agree.  I recently gave these boneheads a hundred bucks to
upgrade to 1.4 (after several previous upgrades - I've been
with V/PM since 1.0).  Now they've doubled the retail, and
tripled the upgrade cost (almost).  Not a business practice
that I'm willing to underwrite - they've lost a long-time
customer with this one.

Could you post that compuserve address?
__________________________________________________________
Greg Bryant                                 (512) 795-0323
Delta Music Systems                             Austin, TX
INET: gregb@pro-lep.cts.com
ARPA: wixer!pro-lep!gregb@cs.utexas.edu
Just consulting.   Not an employee.   Not representing IBM
Newsgroups: comp.lang.smalltalk
From: bergstro@src.honeywell.com (Pete Bergstrom)
Subject: Re: comparing object-oriented platforms
To: comp.lang.smalltalk
Posted-Date: Mon, 5 Oct 92 15: 21:11 CDT
Organization: Honeywell Systems & Research Center
Date: Mon, 5 Oct 1992 20:21:11 GMT
Received-Date: Mon, 5 Oct 92 15: 21:12 CDT

nadja@jetsun.weitek.COM (Nadja Adolf) wrote:
>
>In article <ken8Xe_00awRQ5OHYd@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>>Static type checking makes it harder to develop code in limited
>>time (prototype doesn't have to be bug free, nor fast, nor complete)
>
>I thought about this over the weekend, and realized that one thing really
>bothers me here. It is amazing how little of a smalltalk program has to
>be present for it to appear to 'work.'
>
>One gets the demo up, it appears to work, and the managers/moneyfolk don't
>realize that one is nowhere near a product yet... and anticipate a totally
>unrealistic schedule...

Do you mean to say that you don't use prototypes to explore
requirements and design tradeoffs?  I'm currently working on a
prototype (it happens that I switched from C to Smalltalk) for the
express purpose of figuring out how to write an interactive financial
modeling application.  

The problem that I'm trying to solve has very loosely specified
requirements that my "client" (a friend) wanted to see.  He has some
half-baked ideas that have slowly been firming up as we proceed.

If your requirements have been fully explored and you have a set of
constraints cast in iron, then I agree that you might want to use some
language optimized for the machine.

As far as the misperceptions of "managers/moneyfolk" go, you have to
keep some sense of credibility.  If it's not even close to being done,
you shouldn't allow them the impression that it is.  (Once you've said
so, it's beyond your control what they do.)

Pete
From: Stephen Cooper <stephen@csd.uu.se>
Newsgroups: comp.lang.smalltalk
Subject: Re: Little Smalltalk - Mac version?
Date: 29 Sep 1992 08:04:57 GMT
Organization: Uppsala University
Distribution: world
NNTP-Posting-Host: mac-5.csd.uu.se
X-UserAgent: Nuntius v1.1.1d7
X-XXDate: Tue, 29 Sep 92 08:04:55 GMT

In article <4296@moscom.com> Tom Maszerowski, tcm@moscom.com writes:
>Background:
>
>   I am taking an object-oriented programming course and we are currently
>using Little Smalltalk v3 from Tim Budd. We are using the UNIX version.
>The documentation states that it will compile on the Mac as well, but the
>version I have available doesn't seem to have that in it.
>
>Question:
>
>   Is Little Smalltalk available anymore and does it still support the
>Mac, even minimally? I have THINK C 5 and can owrk from source code if
>need be.

  Little hasn't gone beyond v 3.0 (unfortunately), and source code is
available via anonymous ftp at cs.orst.edu as /pub/budd/smallv3.tar.  Or
you can mail to oopintro@cs.orst.edu with the subject line "Little".  The
subject line "Help" will tell you what's available for e-mail.  Mostly
suppliments to Budd's book "An Intro. to OOP".

  The GUI used is Guido van Rossum's standard window package, see archie
stdwin for a ftp server near you.  Guido's stdwin compiles to the
following platforms:  X11 on various archetectures, Atari, PC, Mac, and
others.

  The other alternative for shareware/freeware smalltalk is gnu
smalltalk.  The latest version I've seen is 1.1.1.  See archie smalltalk
for a location near you.

  I've answered this question so often in the past few days, that I
propose that this be added to the FAQ list -- if it isn't already there.

  /Stephen
-----------------------------------------------------------
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
Newsgroups: comp.lang.smalltalk
From: golovch@phoenix.rose.utoronto.ca (Gene Golovchinsky)
Subject: Re: dynamically dropping views in PPST4.1
Organization: University of Toronto, Department of Industrial Engineering
Date: Mon, 5 Oct 1992 18:22:45 GMT

scrl@otter.hpl.hp.com (Simon Lewis) writes:

>To do this kind of thing, I always keep a handle on the view I want to
>remove, as well as the container.  When the time comes to remove the view
>I send the container the message remove: myView.  Worked under 4.0, still
>works under 4.1.  (Might be removeComponent: or something like that.)

I tried sending the removeComponent: message to the ComposedView that contains
my view, passing the wrappper that contains the view as a parameter.  The
problem remained, however, that once the view is removed, the SystemController
still insists on talking to it, resulting in messages being sent to nil.

I am at a loss to explain why the controller still knows about the existence
of the view, especially given that the view no longer exists!

 2
G
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Newsgroups: comp.lang.smalltalk
Subject: Re: Nadja is a Newsgroup Virus
Date: 29 Sep 92 23:20:09 GMT
Organization: WEITEK Corporation, Sunnyvale CA

In article <STEINMAN.92Sep29085437@hawk.is.morgan.com> steinman@is.morgan.com (Jan Steinman) writes:
>
>We all know how to use our kill files, don't we?

Jan, what a pleasant change from email letter bombs and threats thereof...
I am glad to see that you have moved from the 2 year old level of threats
of virtual violence to the three year old level of calling people who
don't agree with you doodoo heads. :-)



-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.objective-c
From: brad@boole.uucp (Brad Schoening)
Subject: Re: MVC shortcommings
Organization: Boole & Babbage, Inc.
Date: Sat, 3 Oct 1992 09:38:23 GMT

In <1992Sep28.211636.14778@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) 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

When I re-wrote our 4.1 scrolling views we achieved a 50% reduction in
the amount of subclass code we wrote.   It took some time & work but
basically 4.1 scroll wrappers reduced some of our most critical, bug 
prone code by 50%.  Perhaps we are an exception, but I was impressed
with the results.

I think that Ralph is right.  We're getting better frameworks from the
vendors and are reducing the amount of low-level code we have to write.
BTW, I'm still fixing scrolling bugs in our ParcPlace 2.5 version that
I'll probably never have to worry about in 4.1 because the framework
supports better abstractions.

----------------------------------------------------------------
brad schoening		boole and babbage, inc.		408 / 524 - 3281
Newsgroups: comp.lang.smalltalk
From: bergstro@src.honeywell.com (Pete Bergstrom)
Subject: Re: ST/V PM 2.0 upgrade -- overpriced ?
To: comp.lang.smalltalk
Posted-Date: Mon, 5 Oct 92 15: 02:39 CDT
Organization: Honeywell Systems & Research Center
Date: Mon, 5 Oct 1992 20:02:39 GMT
Received-Date: Mon, 5 Oct 92 15: 02:40 CDT

gregb@gout.austin.ibm.com writes:
>In  <9210021940.AA04644@data.src.honeywell.com>  bergstro@src.honeywell.com (Pete Bergstrom) writes:
>>From: marten@feki.toppoint.de (Marten Feldtmann)
>>> [ prices deleted]
>>
>>I've fired off an unhappy note to the compuserve address asking them
>>to clarify this situation.
>>
>>In fact, I'm not mad, I'm pissed.
>>
>>Pete
>
>I agree.  I recently gave these boneheads a hundred bucks to
>upgrade to 1.4 (after several previous upgrades - I've been
>with V/PM since 1.0).  Now they've doubled the retail, and
>tripled the upgrade cost (almost).  Not a business practice
>that I'm willing to underwrite - they've lost a long-time
>customer with this one.
>
>Could you post that compuserve address?
>__________________________________________________________
>Greg Bryant                                 (512) 795-0323
>Delta Music Systems                             Austin, TX
>INET: gregb@pro-lep.cts.com
>ARPA: wixer!pro-lep!gregb@cs.utexas.edu
>Just consulting.   Not an employee.   Not representing IBM

The address on the letter from the president of Digitalk inside my
package says that Compuserve 71361,1636 and Applelink DIGITALK and 
BIX BARBARAN and GEnie DGOLDMAN are all valid electronic communication
accounts.

To write to the Compuserve address, use 71361.1636@compuserve.com.

Pete
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: Request: SimTalk info
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 2 Oct 1992 21:45:22 GMT

SimTalk was once sold by Tektronix.  Tektronix has lost all
interest in Smalltalk (a sign of senility, I believe) and
may or may not still be selling it.  There are still a few
people using it, but since nobody is trying to keep it up
with the latest version of Smalltalk, it has a poor future.
SimTalk was written in Tektronix Smalltalk by Verna Knapp,
who just posted here, and was ported to ParcPlace Smalltalk
release 2.5.  As far as I know (and I don't know much) it
was never ported to 4.0.  However, there are still at least
a few people using it productively.

Here is the promo for SimTalk:

SimTalk is a discrete event simulation system that exists
within Smalltalk-80.  Using SimTalk, you can model environments
ranging from a communication network to a factory floor, and you can
experiment with the vehaviro of any and all entities within those
environments.  Defining complex simulations is facilitated, because
SimTalk provides a large number of classes of predefined objects for
your use.  Your simulation inherits full-blown capabilities that
include graph and histogram displays, animation controllers, random
number generators, and probability distributions.

Verna is vernak@fenris.com if you want to talk to her directly.

Ralph Johnson -- University of Illinois at Urbana-Champaign