why not Smalltalk?
Rick Giles
ivan....@acadiau.ca
Thanks.
*********
In a major recent survey (OOPSLA 95), IT industry practitioners predominantly
recommended Smalltalk as the first programming language for computer science
programs switching to the OO paradigm.
Can you comment why universities have not followed this recommendation?
Ivan Tomek
School of Computer Science
Acadia University, Canada
*******
--
Rick Giles "Question everything you learn."
email- rick....@acadiau.ca - anon.
www- http://dragon.acadiau.ca/~giles/home.html
Thierry Thelliez
I was at OOPSLA and although people were really pushing for Smalltalk, I
have
not seen this survey. I will be very interested to show that to my
managers !
Thanks
Thierry
--
.....................................................................
. Thierry Thelliez Los Alamos National Laboratory .
. Email: t...@lanl.gov CIC-15 .
. Voice: (505) 665 8631 MS M982 .
. Fax: (505) 665 8633 Los Alamos NM 87545 .
. URL: http://www.lanl.gov/cgi-bin/phone/113845 USA .
.....................................................................
Dan
>In a major recent survey (OOPSLA 95), IT industry practitioners predominantly
>recommended Smalltalk as the first programming language for computer science
>programs switching to the OO paradigm.
>Can you comment why universities have not followed this recommendation?
>Ivan Tomek
>School of Computer Science
>Acadia University, Canada
Hi,
I graduated last year from Cardiff University, where I learnt both
Eiffel and Smalltalk. I am now currently supporting Smalltalk
Developers using VMarks ObjectStudio product. While I am a big fan of
Smalltalk and thoroughly recommend it as a development language, I
must admit I found the transition to OO alot easier with Eiffel than
Smalltalk. Both are pure OO languages, and strict to the paradigm,
but Eiffel *looked* more procedural than Smalltalk, and hence there
was something familiar about it that made it seem less daunting. Even
after learning Eiffel, Smalltalk wasn't a completely straightforward
transition. With Smalltalk there's some important fundamental
concepts and, once you have that ah-ha moment, everything suddenly
becomes extremely obvious and easy, and you start getting that
beautiful Smalltalk productivity/expressiveness, but until then
everything can seem very confusing.
I am in now way implying that one language is better that than the
other, since I am very keen for both of them, but from my experience
of OO in an academic and industrial environment, I found Eiffel
easier to learn than Smalltalk. The main reason being that the
paradigm shift is smoothed/shortened/made easier by the *look*/syntax
of Eiffel.
Thanks
Dan
ObjectStudio Support Analyst
My opinions are my own and not those of my employers.
Graham Perkins
> In a major recent survey (OOPSLA 95), IT industry practitioners predominantly
> recommended Smalltalk as the first programming language for computer science
> programs switching to the OO paradigm.
>
> Can you comment why universities have not followed this recommendation?
Here at De Montfort University (Milton Keynes and Leicester sites) we have
mostly stuck with Modula-2 for intro
teaching, but have experimented with C++, Smalltalk, and Eiffel as alternatives,
usually by piloting a proposed intro. module at second year level. We have
had variable levels of success with all. But the people who run the courses
and make the decisions are not the same as those who teach the material, and
the people who teach often disagree about the teaching experience anyhow.
There has been a proposal to move over to Smalltalk for introductory teaching.
But one of the pilot runs did not go very well, and this may scupper the chances.
Another proposal (this site only) is to teach apps. development rather than
programming, and move over to Delhpi as the teaching system.
One of the courses is moving over to C++ as the intro. language. Interestingly,
it is the course with the least able students and the most disastrous pilot
run of C++ teaching. It is also the course with the lowest level of software
and hardware (ie, stand-alone PCs with shareware).
A large section of the "object" crowd who previously backed C++ or Smalltalk
have now moved over to Java and are very keen to introduce Java teaching in
a major way.
There is near-universal consensus that students need some C++ skills by the
time they graduate. There is also widespread (but not so universal) agreement
that they need proper OO development skills rather than just C++ syntax. Thus
many people believe that we should use C++ all the way through, or possibly
Java followed by C++. Few see Eiffel or Smalltalk as viable alternative
introductions.
My personal prejudice is that Smalltalk introduction would not give much
in the way of transferable skills. The language is not very object-oriented
in itself, and the Visual Works system is very poor in its support for
OO development at the introductory level. A course delivering Smalltalk at
the start would have to restart practically from the beginning when it later
moved over to Java/C++/Eiffel. We also have a problem with resources at my
particular site, with not enough PCs powerful enough to run VW and no decent
projection facilities in the labs. This is a particular handicap when trying
to teach a system that depends on highly dynamic, interactive, iterative mode
of learning and usage. Group work, distance learning, and part-time education
all seem incompatible with Visual Works Smalltalk.
NB those of my colleagues who do have opinions on these issues do not agree
with me over the above points.
--
person: Graham Perkins paper: School of Computing
voice: +44 (0)1908 834936 De Montfort University
dots: +44 (0)1908 834948 Milton Keynes MK7 6HP
bits: g...@dmu.ac.uk United Kingdom
Colin James III (The Rt Rev'd)
>Here at De Montfort University (Milton Keynes and Leicester sites) we have
>mostly stuck with Modula-2 for intro
>teaching, but have experimented with C++, Smalltalk, and Eiffel as alternatives,
...................................................................^^^^^^^^^^^^
options?
>usually by piloting a proposed intro. module at second year level. We have
>had variable levels of success with all.
The current thinking among the educators I know is that C++ should be relegated to
graduate level courses, only.
> But the people who run the courses
>and make the decisions are not the same as those who teach the material, and
>the people who teach often disagree about the teaching experience anyhow.
Yes, the typical British educational system: one is graded on how well one parrots
back material to the lecturer; hence, good students take shorthand faster. This
was not the way things were run at Mansfield College (Oxon) when I was there.
>
>There has been a proposal to move over to Smalltalk for introductory teaching.
>But one of the pilot runs did not go very well, and this may scupper the chances.
>
>Another proposal (this site only) is to teach apps. development rather than
>programming, and move over to Delhpi as the teaching system.
>
>One of the courses is moving over to C++ as the intro. language. Interestingly,
>it is the course with the least able students and the most disastrous pilot
>run of C++ teaching. It is also the course with the lowest level of software
>and hardware (ie, stand-alone PCs with shareware).
Typical British philosophy of education: if the intro course to beginners of a
graduate level topic does not work, it is the parrots fault, never the master.
>
>A large section of the "object" crowd who previously backed C++ or Smalltalk
>have now moved over to Java and are very keen to introduce Java teaching in
>a major way.
>
>There is near-universal consensus that students need some C++ skills by the
>time they graduate. There is also widespread (but not so universal) agreement
>that they need proper OO development skills rather than just C++ syntax. Thus
>many people believe that we should use C++ all the way through, or possibly
>Java followed by C++. Few see Eiffel or Smalltalk as viable alternative
>introductions.
>
>My personal prejudice is that Smalltalk introduction would not give much
>in the way of transferable skills. The language is not very object-oriented
>in itself, and the Visual Works system is very poor in its support for
>OO development at the introductory level. A course delivering Smalltalk at
>the start would have to restart practically from the beginning when it later
>moved over to Java/C++/Eiffel. We also have a problem with resources at my
>particular site, with not enough PCs powerful enough to run VW and no decent
>projection facilities in the labs. This is a particular handicap when trying
>to teach a system that depends on highly dynamic, interactive, iterative mode
>of learning and usage. Group work, distance learning, and part-time education
>all seem incompatible with Visual Works Smalltalk.
Stop your whining, Graham.
>
>NB those of my colleagues who do have opinions on these issues do not agree
>with me over the above points.
Ugh. That is understandable.
Rolf Breuning
.. many other thoughts skipped
>My personal prejudice is that Smalltalk introduction would not give much
>in the way of transferable skills. The language is not very object-oriented
>in itself, and the Visual Works system is very poor in its support for
>OO development at the introductory level. A course delivering Smalltalk at
>the start would have to restart practically from the beginning when it later
>moved over to Java/C++/Eiffel. We also have a problem with resources at my
>particular site, with not enough PCs powerful enough to run VW and no decent
>projection facilities in the labs. This is a particular handicap when trying
>to teach a system that depends on highly dynamic, interactive, iterative mode
>of learning and usage. Group work, distance learning, and part-time education
>all seem incompatible with Visual Works Smalltalk.
This is in fact the first time that I've read
'Smalltalk is not very object-oriented'
If you consider the fact you will notice, that in Smalltalk everything, even an integer or a boolean
is an object of a certain class and their behavior can be changed by editing the class. Even classes
are again objects. Thus, many people call Smalltalk a 'pure' object oriented language as it doesn't
mix objects with other concepts.
Could you please elaborate on what part of oo you are missing in ST ?
'not enough PCs powerful enough to run VW'
This may well be a problem, however, modern C++ environments with comprehensive class
libraries - as in Smalltalk - consume a similar space. (E.g. IBM VisualAge / C++ ).
Perhaps you might consider something like an older version of Smalltalk/V for OS/2 or Windows
which runs with less memory.
**********************************************************************
* Rolf Breuning br...@rog.rwth-aachen.de *
* Rogowski-Institut / RWTH Aachen *
* Schinkelstr.2, D-52062 Aachen - standard disclaimer - *
**********************************************************************
Scott Wheeler
writes:
> This was not the way things were run at Mansfield College (Oxon) >
> when I was there.
FWIW, Mansfield is not part of Oxford University.
Scott
Scott Wheeler
writes:
> This was not the way things were run at Mansfield College (Oxon) when
I was there.
Apologies to CJ - I mistakenly said that Mansfield College was not part
of Oxford University (I was thinking of Manchester College, just down
the road). However Mansfield is a Non-Conformist theological college
i.e. none of its output are "Right Reverend". Curiouser and curiouser.
Scott
Graham Perkins
Rolf Breuning wrote:
> This is in fact the first time that I've read
> 'Smalltalk is not very object-oriented'
> If you consider the fact you will notice, that in Smalltalk everything, even an
> integer or a boolean is an object of a certain class and their behavior can be
> changed by editing the class.
PROPAGANDA
There is some glib circularity in the standard "smalltalk small simple and
pure" propaganda. Of course by writing and Object Engine as the base Smalltalk
system, and calling all the things it works with objects, you can easily
argue that everything is an object.
If you look at Eiffel program text you will notice that it contains only strings
of characters. Thus Eiffel is a String Oriented Language?
OBJECTS ONLY
> Even classes are again objects. Thus, many people
> call Smalltalk a 'pure' object oriented language as it doesn't mix objects with
> other concepts.
Almost agreed: Smalltalk is a pure object mechanism. Actually, a method call is
not an object. But classes are objects, not classes.
EDUCATIONAL GOALS
> Could you please elaborate on what part of oo you are
> missing in ST ?
I will explain some. But please understand that as an educator I am not
necessarily interested in the full gamut of Object Technology which Smalltalk
systems support and very well too. I prefer to focus on the elements of
the OO paradigm - at least at introductory level - in order to give students
the right foundation to extend their knowledge through experience and
investigation.
CLASS AS ABSTRACTION
Perhaps I am mistaken, but I have come to OO through the Abstract Data Type
approach and feel that a class as an abstraction of a set of objects is what
OO languages ought to provide. But a Smalltalk class is an object, must have
exactly one instance present at runtime, and contains variables and routines
accessible to all data items it produces. Class objects interact with each
other and with their instances without any encapsulation protection.
You cannot design and implement object systems in Smalltalk without
understanding the runtime mechanism that keeps class objects connected
in their hierarchy and connected as un-encapsulated suppliers to all
the class object instances they produce.
In other words, a Smalltalk class is not an abstraction or specification
of all its instances, but is in fact a module object.
INHERITANCE MODIFYING ABSTRACTION
Another view (eg mine or Bertrand Meyer's) of OO is that inheritance and
generics are notations allowing you to adapt existing classes to build
new classes. Strict adherence to this principle has led to an inheritance
system in Eiffel which "liquidates the ancestry". Thus the programmer can
switch a class viewing tool into "flat" mode to see the full specification
taking inheritance and generics into account. This cannot be done in Smalltalk
because of what a class is, nor can it be done in Java or C++ due to
their particular versions of classes and inheritance.
ENVIRONMENT INTEGRATION
I want my language and tools to be separate from my application at runtime.
And please don't say, "Aha, but a debugger is an object and everything in
Smalltalk is an object and all objects are in Smalltalk and so it's all
very simple and pure ...etc"
Lisp and Oberon systems can be built like that, and it's nothing to do
with object-orientation. And it all introduces a lot of dangerous holes
that students fall down.
If you think OO is anything to do with scoping and visiblity control, then
actually allowing an application program to alter or destroy its own
specification dynamically could be considered a failure.
SCOPE AND VISIBILITY
object/self/super access to instance/class/class-instance variables
and methods is too complicated. So many scopes introduce coupling rather
than expressive power.
No visibility control. All methods visible, all attributes hidden.
Even creation method cannot access attributes, so they have to be
exposed via get/set methods. So programmer has to explicitly un-encapsulate
the objects!
GLOBALS
Some say this is nothing to do with OO. But it is. A global object
is just a supplier object being shared by several clients, where "several"
is allowed to become "all" on some occasions. Ordinary shared objects
cannot be destroyed or replaced by clients, and retain their own control over
initialisation.
Why provide a special mechanism for that case where "several may share"
becomes "all may share" and then throw away the initialisation control
and reference integrity?
Disciplined sharing of objects minimises all forms of data and temporal
coupling, whereas the presence of globals almost mandates such dependencies.
Or was I mistaken in thinking that OO was about minimising coupling and
maximising cohesion?
INHERITANCE
I'm on the multiple inheritance side. Not that I want to teach it, even
in Eiffel, to beginners. But I think learners should be exposed to MI
best practice quite soon after single inheritance. (The multiply derived
data structures in the Eiffel libraries are superb examples). If inheritance
is about conformance (which it is in static typed languages) then single
inheritance is just an arbitrary restriction. Particularly if you want to
allow conformant and adaptive inheritance.
Of course, Smalltalk dynamic typing makes it all less relevant. And that is
a minus point for introductory teaching, since I would like students to
see how MI and static typing can be deployed effectively. Actually, digging
around my VW system I've found several classes that seem to be in the "wrong"
place simply because they really wanted two parents. There is also no
consistency as to whether inheritance is being used for subtyping or for
adaptation (not that there needs to be, but it does confuse beginners). And
what is "variableSubclass:" if not MI?
GENERICS
Uniform generics are essential to safe use of reusable software components.
And they are central to the power of many commercially distributed software
libraries. So I think we should be using them in intro OO teaching. Or
was "re-use" another misconception I had about object orientation ? ;-)
MACHINE POWER
> 'not enough PCs powerful enough to run VW'
> This may well be a problem, however, modern C++ environments with comprehensive class
> libraries - as in Smalltalk - consume a similar space.
I know. But those in favour of C++ have no qualms about making their case
on the basis of free GNU software.
EDUCATION AND BRITAIN
I think I had better resign my teaching post and abandon my nationality as I
have now come to appreciate the wisdom and insights of that great source of
helpful advice and constructive comment, a certain Colin James. Us Brits with
our British education really should all think again. But wait! I'm part
Scottish, part Indian, and educated in England, USA, and Nigeria! Am I a
Celt or a UK or a Brit or none?
Please help,
Confused of Milton Keynes
Jared Richardson
The details differ somewhat,
but this is very similar to my experience.
Maybe Eiffel should be the intro language
and SmallTalk the next step?
It would be a very nice language set to
graduate with.
Dan wrote:
>
> gi...@dragon.acadiau.ca (Rick Giles) wrote:
>
> >In a major recent survey (OOPSLA 95), IT industry practitioners predominantly
> >recommended Smalltalk as the first programming language for computer science
> >programs switching to the OO paradigm.
>
> >Can you comment why universities have not followed this recommendation?
>
Rolf Breuning
>[some headings to split things up, hope capitals don't irritate]
>
>Rolf Breuning wrote:
>> This is in fact the first time that I've read
>> 'Smalltalk is not very object-oriented'
>> If you consider the fact you will notice, that in Smalltalk everything, even an
>> integer or a boolean is an object of a certain class and their behavior can be
>> changed by editing the class.
>
>PROPAGANDA
>There is some glib circularity in the standard "smalltalk small simple and
>pure" propaganda. Of course by writing and Object Engine as the base Smalltalk
>system, and calling all the things it works with objects, you can easily
>argue that everything is an object.
>
>If you look at Eiffel program text you will notice that it contains only strings
>of characters. Thus Eiffel is a String Oriented Language?
>
hope you didn't want to characterize my text above as 'propaganda'. I really can't find
anything in it which isn't simply a fact. In Smalltalk an integer or a boolean have
their own classes, you may add methods to these classes etc. I myself added a class
for infinite number to the system. You send messages to an integer or a boolean as
you do to any other Smalltalk object. Thus, the Smalltalk programmer more than
the programmer of most other languages can handle an integer or a boolean in
the same way as he handles any other object.
As I'm not arguing at the source code level, so I really can't see what you want to say
with your Eiffel example.
>OBJECTS ONLY
>> Even classes are again objects. Thus, many people
>> call Smalltalk a 'pure' object oriented language as it doesn't mix objects with
>> other concepts.
>
>Almost agreed: Smalltalk is a pure object mechanism. Actually, a method call is
>not an object. But classes are objects, not classes.
>
>EDUCATIONAL GOALS
>> Could you please elaborate on what part of oo you are
>> missing in ST ?
>
>I will explain some. But please understand that as an educator I am not
>necessarily interested in the full gamut of Object Technology which Smalltalk
>systems support and very well too. I prefer to focus on the elements of
>the OO paradigm - at least at introductory level - in order to give students
>the right foundation to extend their knowledge through experience and
>investigation.
>
>CLASS AS ABSTRACTION
>Perhaps I am mistaken, but I have come to OO through the Abstract Data Type
>approach and feel that a class as an abstraction of a set of objects is what
>OO languages ought to provide. But a Smalltalk class is an object, must have
>exactly one instance present at runtime, and contains variables and routines
>accessible to all data items it produces. Class objects interact with each
>other and with their instances without any encapsulation protection.
In my Smalltalk dialect (Visual Smalltalk), classes can not 'interact with each other
and with their instances without any encapsulation protection' - and I'd be
surprised if this was possible in other Smalltalk dialects.
The usual instance variables (which C++ calls 'data members') of objects are
encapsulated. There is no special mechanism which allows the class of an object
to access the instance variables of the object.
If you refer to class variables: They do not belong to a certain object, but are
shared among a class all its subclasses and their instances. Thus, they are
properly understood as global variables with a restricted scope. They are used
when - in other languages - you would use a global variable.
>
>You cannot design and implement object systems in Smalltalk without
>understanding the runtime mechanism that keeps class objects connected
>in their hierarchy and connected as un-encapsulated suppliers to all
>the class object instances they produce.
????
For some years, I'm introducing students into Smalltalk which do also programming
work for me. They learn to use the syntax, the concepts and the class library.
None of them needed from the start an explanation of how Smalltalk realizes a class
hierarchy - they start with the knowledge that there are classes, and how they can
change these or add new subclasses.
Only the most advanced students needed to get involved in the inner structure of
Smalltalk classes.
>
>In other words, a Smalltalk class is not an abstraction or specification
>of all its instances, but is in fact a module object.
>
>INHERITANCE MODIFYING ABSTRACTION
>Another view (eg mine or Bertrand Meyer's) of OO is that inheritance and
>generics are notations allowing you to adapt existing classes to build
>new classes. Strict adherence to this principle has led to an inheritance
>system in Eiffel which "liquidates the ancestry". Thus the programmer can
>switch a class viewing tool into "flat" mode to see the full specification
>taking inheritance and generics into account. This cannot be done in Smalltalk
>because of what a class is, nor can it be done in Java or C++ due to
>their particular versions of classes and inheritance.
No problem to do that in Smalltalk. I've myself seen a Smalltalk browser which listed
all the variables and methods defined for a certain class. Give me some short time and
I write my own one which lets you also switch on and off notification from which class
each certain variable or method has been inherited. In no way the Smalltalk language
or its classes prohibits you from getting this view of a class.
I can't see any reason in C++ or Java which could make such a tool impossible.
>
>ENVIRONMENT INTEGRATION
>I want my language and tools to be separate from my application at runtime.
Ok, we all have our preferences. I myself like a language where I may change
the tools using the same mechanisms as when I write an application. But I
agree, this is my preference.
>And please don't say, "Aha, but a debugger is an object and everything in
>Smalltalk is an object and all objects are in Smalltalk and so it's all
>very simple and pure ...etc"
You said it so I don't have to :-)
>
>Lisp and Oberon systems can be built like that, and it's nothing to do
>with object-orientation. And it all introduces a lot of dangerous holes
>that students fall down.
>
>If you think OO is anything to do with scoping and visiblity control, then
>actually allowing an application program to alter or destroy its own
>specification dynamically could be considered a failure.
Or an extension to dynamically change applications while they are running.
Actually my own work is concerned with changing / debugging programs via
a network without having to leave them. What you call a failure is necessary
for my work.
>
>SCOPE AND VISIBILITY
>object/self/super access to instance/class/class-instance variables
>and methods is too complicated. So many scopes introduce coupling rather
>than expressive power.
>
>No visibility control. All methods visible, all attributes hidden.
True. I also would like Smalltalk to have 'private' methods.
>Even creation method cannot access attributes, so they have to be
>exposed via get/set methods. So programmer has to explicitly un-encapsulate
>the objects!
I absolutely agree with you that writing get and set methods hurt encapsulation !
Get and set methods are in fact not the way Smalltalk programmers should handle
object creation. If you create a new object and have to initialize it using e.g. other
objects, you will use a single initialize instance method which will accept all the
objects as parameters and initialize your object. No need to write several set methods
an absolutely no need to write get methods.
(
BTW, in my opinion using get methods is even worse than set methods from the
encapsulation point of view.
In a set method, the object has the opportunitiy to test the given parameter. It may
even raise an error if the object already has been set, thus avoiding a double initialization.
When using a get method, you give an external object away without any control. The only
thing you may do in some cases is, to return a copy of your internal object
)
>
>GLOBALS
>Some say this is nothing to do with OO. But it is. A global object
>is just a supplier object being shared by several clients, where "several"
>is allowed to become "all" on some occasions. Ordinary shared objects
>cannot be destroyed or replaced by clients, and retain their own control over
>initialisation.
>
>Why provide a special mechanism for that case where "several may share"
>becomes "all may share" and then throw away the initialisation control
>and reference integrity?
Which mechanism do you mean ?
Smalltalk provides you with global variables with different scopes.
Global variables - Can be used by all objects.
Class variables - Used by (objects of ) a class and its subclasses.
Pool dictionaries - A pool dictionary is a sets of named variables.
These variables can be used by all objects whose
class definition mentions the pool dictionary name.
>
>Disciplined sharing of objects minimises all forms of data and temporal
>coupling, whereas the presence of globals almost mandates such dependencies.
>Or was I mistaken in thinking that OO was about minimising coupling and
>maximising cohesion?
See the facts above, no sarcasm necessary.
>
>INHERITANCE
>I'm on the multiple inheritance side. Not that I want to teach it, even
>in Eiffel, to beginners. But I think learners should be exposed to MI
>best practice quite soon after single inheritance. (The multiply derived
>data structures in the Eiffel libraries are superb examples). If inheritance
>is about conformance (which it is in static typed languages) then single
>inheritance is just an arbitrary restriction. Particularly if you want to
>allow conformant and adaptive inheritance.
>
>Of course, Smalltalk dynamic typing makes it all less relevant. And that is
>a minus point for introductory teaching, since I would like students to
>see how MI and static typing can be deployed effectively. Actually, digging
>around my VW system I've found several classes that seem to be in the "wrong"
>place simply because they really wanted two parents. There is also no
>consistency as to whether inheritance is being used for subtyping or for
>adaptation (not that there needs to be, but it does confuse beginners). And
>what is "variableSubclass:" if not MI?
OK, Smalltalk does not have MI. I had a paper on the last Tools Europe (96)
which introduced MI in a new way to Smalltalk. It also explained why MI is
less important to ST than to other languages. You already mentioned one
of the reasons - dynamic typing.
#variableSubclass: is misunderstood. It has nothing to do with MI. It defines a class
of objects which besides a fixed number of named variables can have a *variable*
number of indexed variables. Array for instance is a variable subclass.
Just a little bit 'digging around' is not always enough to come to valid conclusions.
>
>GENERICS
>Uniform generics are essential to safe use of reusable software components.
>And they are central to the power of many commercially distributed software
>libraries. So I think we should be using them in intro OO teaching. Or
>was "re-use" another misconception I had about object orientation ? ;-)
I would like you to provide an example of what mechanism you're looking for
>
>MACHINE POWER
>> 'not enough PCs powerful enough to run VW'
>> This may well be a problem, however, modern C++ environments with comprehensive class
>> libraries - as in Smalltalk - consume a similar space.
>
>I know. But those in favour of C++ have no qualms about making their case
>on the basis of free GNU software.
Valid point. There is a free Smalltalk, but I also would like to see the big vendors to
offer stripped down educational versions which would really be cheap enough for
students and run fast on every students computer.
>
>EDUCATION AND BRITAIN
>I think I had better resign my teaching post and abandon my nationality as I
>have now come to appreciate the wisdom and insights of that great source of
>helpful advice and constructive comment, a certain Colin James. Us Brits with
>our British education really should all think again. But wait! I'm part
>Scottish, part Indian, and educated in England, USA, and Nigeria! Am I a
>Celt or a UK or a Brit or none?
No comment on this :-)
As a native German, I don't seem to be involved in this battle.
Rolf Breuning
>
>Rolf Breuning wrote:
>> This is in fact the first time that I've read
>> 'Smalltalk is not very object-oriented'
>> If you consider the fact you will notice, that in Smalltalk everything, even an
>> integer or a boolean is an object of a certain class and their behavior can be
>> changed by editing the class.
>
>PROPAGANDA
>There is some glib circularity in the standard "smalltalk small simple and
>pure" propaganda. Of course by writing and Object Engine as the base Smalltalk
>system, and calling all the things it works with objects, you can easily
>argue that everything is an object.
>
>If you look at Eiffel program text you will notice that it contains only strings
>of characters. Thus Eiffel is a String Oriented Language?
>
hope you didn't want to characterize my text above as 'propaganda'. I really can't find
anything in it which isn't simply a fact. In Smalltalk an integer or a boolean have
their own classes, you may add methods to these classes etc. I myself added a class
for infinite number to the system. You send messages to an integer or a boolean as
you do to any other Smalltalk object. Thus, the Smalltalk programmer more than
the programmer of most other languages can handle an integer or a boolean in
the same way as he handles any other object.
As I'm not arguing at the source code level, so I really can't see what you want to say
with your Eiffel example.
>OBJECTS ONLY
>> Even classes are again objects. Thus, many people
>> call Smalltalk a 'pure' object oriented language as it doesn't mix objects with
>> other concepts.
>
>Almost agreed: Smalltalk is a pure object mechanism. Actually, a method call is
>not an object. But classes are objects, not classes.
>
>EDUCATIONAL GOALS
>> Could you please elaborate on what part of oo you are
>> missing in ST ?
>
>I will explain some. But please understand that as an educator I am not
>necessarily interested in the full gamut of Object Technology which Smalltalk
>systems support and very well too. I prefer to focus on the elements of
>the OO paradigm - at least at introductory level - in order to give students
>the right foundation to extend their knowledge through experience and
>investigation.
>
>CLASS AS ABSTRACTION
>Perhaps I am mistaken, but I have come to OO through the Abstract Data Type
>approach and feel that a class as an abstraction of a set of objects is what
>OO languages ought to provide. But a Smalltalk class is an object, must have
>exactly one instance present at runtime, and contains variables and routines
>accessible to all data items it produces. Class objects interact with each
>other and with their instances without any encapsulation protection.
In my Smalltalk dialect (Visual Smalltalk), classes can not 'interact with each other
and with their instances without any encapsulation protection' - and I'd be
surprised if this was possible in other Smalltalk dialects.
The usual instance variables (which C++ calls 'data members') of objects are
encapsulated. There is no special mechanism which allows the class of an object
to access the instance variables of the object.
If you refer to class variables: They do not belong to a certain object, but are
shared among a class all its subclasses and their instances. Thus, they are
properly understood as global variables with a restricted scope. They are used
when - in other languages - you would use a global variable.
>
>You cannot design and implement object systems in Smalltalk without
>understanding the runtime mechanism that keeps class objects connected
>in their hierarchy and connected as un-encapsulated suppliers to all
>the class object instances they produce.
????
For some years, I'm introducing students into Smalltalk which do also programming
work for me. They learn to use the syntax, the concepts and the class library.
None of them needed from the start an explanation of how Smalltalk realizes a class
hierarchy - they start with the knowledge that there are classes, and how they can
change these or add new subclasses.
Only the most advanced students needed to get involved in the inner structure of
Smalltalk classes.
>
>In other words, a Smalltalk class is not an abstraction or specification
>of all its instances, but is in fact a module object.
>
>INHERITANCE MODIFYING ABSTRACTION
>Another view (eg mine or Bertrand Meyer's) of OO is that inheritance and
>generics are notations allowing you to adapt existing classes to build
>new classes. Strict adherence to this principle has led to an inheritance
>system in Eiffel which "liquidates the ancestry". Thus the programmer can
>switch a class viewing tool into "flat" mode to see the full specification
>taking inheritance and generics into account. This cannot be done in Smalltalk
>because of what a class is, nor can it be done in Java or C++ due to
>their particular versions of classes and inheritance.
No problem to do that in Smalltalk. I've myself seen a Smalltalk browser which listed
all the variables and methods defined for a certain class. Give me some short time and
I write my own one which lets you also switch on and off notification from which class
each certain variable or method has been inherited. In no way the Smalltalk language
or its classes prohibits you from getting this view of a class.
I can't see any reason in C++ or Java which could make such a tool impossible.
>
>ENVIRONMENT INTEGRATION
>I want my language and tools to be separate from my application at runtime.
Ok, we all have our preferences. I myself like a language where I may change
the tools using the same mechanisms as when I write an application. But I
agree, this is my preference.
>And please don't say, "Aha, but a debugger is an object and everything in
>Smalltalk is an object and all objects are in Smalltalk and so it's all
>very simple and pure ...etc"
You said it so I don't have to :-)
>
>Lisp and Oberon systems can be built like that, and it's nothing to do
>with object-orientation. And it all introduces a lot of dangerous holes
>that students fall down.
>
>If you think OO is anything to do with scoping and visiblity control, then
>actually allowing an application program to alter or destroy its own
>specification dynamically could be considered a failure.
Or an extension to dynamically change applications while they are running.
Actually my own work is concerned with changing / debugging programs via
a network without having to leave them. What you call a failure is necessary
for my work.
>
>SCOPE AND VISIBILITY
>object/self/super access to instance/class/class-instance variables
>and methods is too complicated. So many scopes introduce coupling rather
>than expressive power.
>
>No visibility control. All methods visible, all attributes hidden.
True. I also would like Smalltalk to have 'private' methods.
>Even creation method cannot access attributes, so they have to be
>exposed via get/set methods. So programmer has to explicitly un-encapsulate
>the objects!
I absolutely agree with you that writing get and set methods hurt encapsulation !
Get and set methods are in fact not the way Smalltalk programmers should handle
object creation. If you create a new object and have to initialize it using e.g. other
objects, you will use a single initialize instance method which will accept all the
objects as parameters and initialize your object. No need to write several set methods
an absolutely no need to write get methods.
(
BTW, in my opinion using get methods is even worse than set methods from the
encapsulation point of view.
In a set method, the object has the opportunitiy to test the given parameter. It may
even raise an error if the object already has been set, thus avoiding a double initialization.
When using a get method, you give an external object away without any control. The only
thing you may do in some cases is, to return a copy of your internal object
)
>
>GLOBALS
>Some say this is nothing to do with OO. But it is. A global object
>is just a supplier object being shared by several clients, where "several"
>is allowed to become "all" on some occasions. Ordinary shared objects
>cannot be destroyed or replaced by clients, and retain their own control over
>initialisation.
>
>Why provide a special mechanism for that case where "several may share"
>becomes "all may share" and then throw away the initialisation control
>and reference integrity?
Which mechanism do you mean ?
Smalltalk provides you with global variables with different scopes.
Global variables - Can be used by all objects.
Class variables - Used by (objects of ) a class and its subclasses.
Pool dictionaries - A pool dictionary is a sets of named variables.
These variables can be used by all objects whose
class definition mentions the pool dictionary name.
>
>Disciplined sharing of objects minimises all forms of data and temporal
>coupling, whereas the presence of globals almost mandates such dependencies.
>Or was I mistaken in thinking that OO was about minimising coupling and
>maximising cohesion?
See the facts above, no sarcasm necessary.
>
>INHERITANCE
>I'm on the multiple inheritance side. Not that I want to teach it, even
>in Eiffel, to beginners. But I think learners should be exposed to MI
>best practice quite soon after single inheritance. (The multiply derived
>data structures in the Eiffel libraries are superb examples). If inheritance
>is about conformance (which it is in static typed languages) then single
>inheritance is just an arbitrary restriction. Particularly if you want to
>allow conformant and adaptive inheritance.
>
>Of course, Smalltalk dynamic typing makes it all less relevant. And that is
>a minus point for introductory teaching, since I would like students to
>see how MI and static typing can be deployed effectively. Actually, digging
>around my VW system I've found several classes that seem to be in the "wrong"
>place simply because they really wanted two parents. There is also no
>consistency as to whether inheritance is being used for subtyping or for
>adaptation (not that there needs to be, but it does confuse beginners). And
>what is "variableSubclass:" if not MI?
OK, Smalltalk does not have MI. I had a paper on the last Tools Europe (96)
which introduced MI in a new way to Smalltalk. It also explained why MI is
less important to ST than to other languages. You already mentioned one
of the reasons - dynamic typing.
#variableSubclass: is misunderstood. It has nothing to do with MI. It defines a class
of objects which besides a fixed number of named variables can have a *variable*
number of indexed variables. Array for instance is a variable subclass.
Just a little bit 'digging around' is not always enough to come to valid conclusions.
>
>GENERICS
>Uniform generics are essential to safe use of reusable software components.
>And they are central to the power of many commercially distributed software
>libraries. So I think we should be using them in intro OO teaching. Or
>was "re-use" another misconception I had about object orientation ? ;-)
I would like you to provide an example of what mechanism you're looking for
>
>MACHINE POWER
>> 'not enough PCs powerful enough to run VW'
>> This may well be a problem, however, modern C++ environments with comprehensive class
>> libraries - as in Smalltalk - consume a similar space.
>
>I know. But those in favour of C++ have no qualms about making their case
>on the basis of free GNU software.
Valid point. There is a free Smalltalk, but I also would like to see the big vendors to
offer stripped down educational versions which would really be cheap enough for
students and run fast on every students computer.
>
>EDUCATION AND BRITAIN
>I think I had better resign my teaching post and abandon my nationality as I
>have now come to appreciate the wisdom and insights of that great source of
>helpful advice and constructive comment, a certain Colin James. Us Brits with
>our British education really should all think again. But wait! I'm part
>Scottish, part Indian, and educated in England, USA, and Nigeria! Am I a
>Celt or a UK or a Brit or none?
No comment on this :-)
Patrick Logan
Graham Perkins wrote:
> ...But the people who run the courses and make the decisions are not
> the same as those who teach the material...
Don't feel bad. I know some highly successful corporations run the
same way.
> Another proposal (this site only) is to teach apps. development rather than
> programming, and move over to Delhpi as the teaching system...
Because Delphi is the only language that can create "apps"???
> There is near-universal consensus that students need some C++ skills by the
> time they graduate. There is also widespread (but not so universal) agreement
> that they need proper OO development skills rather than just C++ syntax...
Why bother with development skills???
(Well, sure, if all they want to do is train kids to build "apps".)
> My personal prejudice is that Smalltalk introduction would not give much
> in the way of transferable skills...
After all, it doesn't have C++ syntax???
Sounds like this is a training program for junior software "coders" rather
than a university for learning computer science.
--
Patrick...@ccm.hf.intel.com
"OO is a tool, not a religion, and not a philosophy."
-Robert C. Martin
The Right Reverend Colin James III
| In Article <4lgvrt$k...@mtinsc01-mgt.ops.worldnet.att.net> The Rt Rev'd
| writes:
| > This was not the way things were run at Mansfield College (Oxon) >
| > when I was there.
|
| FWIW, Mansfield is not part of Oxford University.
|
| Scott
|
It was when I was there !
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Re-usable, patented financial software for the Stock Market
Colin James III, cja...@cec-services.com & http://www....
CEC Services, LLC, 2080 Kipling St, Lakewood, CO 80215-1502
Tel: 303.231.9437; Facs: 303.231.9438; Data: 303.231.9434
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
The Right Reverend Colin James III
| In Article <4lgvrt$k...@mtinsc01-mgt.ops.worldnet.att.net> The Rt Rev'd
| writes:
| > This was not the way things were run at Mansfield College (Oxon) when
| I was there.
|
| Apologies to CJ - I mistakenly said that Mansfield College was not part
| of Oxford University (I was thinking of Manchester College, just down
| the road). However Mansfield is a Non-Conformist theological college
| i.e. none of its output are "Right Reverend". Curiouser and curiouser.
|
| Scott
Mansfield College is not an Anglican Seminary per se, but it offers the
same core theological training (such as Classical Hebrew and New Testament
Greek) as do the "conforming" Anglican colleges at Oxford University.
There are many Anglicans who have attended Mansfield College, for lack of
space at the other colleges at Oxford University, notably Americans, for
which the University is greatly appreciative because solid US dollars
coming into the system tend to keep tuition down for English citizens.
Clearly Wheeler is not a Churchman, or he would not spout his
non-conformist rhetoric which is beside the point and begs the question of
ignorance: Holy Orders are not conferred by one's college, by academic
examination, or by theological degree, but rather by the hands of Bishops
of the Historic Church.
(The written form of address of "The Right Rev'd", abbreviated, simply
means the designee is an Anglo-Catholic Bishop in the tradition of the
Anglican Communion, verbally addressed as "Your Grace" or "Bishop", and in
fact considered a peer in the UK (such as are Canterbury, Lincoln, and
York, among others, for example). ["peer" means they are verbally addressed
identically as a Duke of the realm.])
What is "curiouser and curiouser" is that Scott Wheeler would choose to
bore the computing community by attempting to attack and discredit one of
my usenet articles, which related to C, C++, Eiffel, and Smalltalk, in
these news groups by bringing up irrelevant trivia.
Piercarlo Grandi
>>> <patrick...@ccm.hf.intel.com> said:
patrick_d_logan> The following is a flame...
patrick_d_logan> Graham Perkins wrote:
Graham> There is near-universal consensus that students need some C++
Graham> skills by the time they graduate. There is also widespread (but
Graham> not so universal) agreement that they need proper OO development
Graham> skills rather than just C++ syntax...
patrick_d_logan> Why bother with development skills??? (Well, sure, if
patrick_d_logan> all they want to do is train kids to build "apps".)
That's indeed the case, the consensus on the need for this is not at all
universal.
Employers hire people who have *alread* demonstrated their ability to
build "apps" in C++, and they word job requirements as "knows C++, has
built apps", not "understands OO, has language independent development
skills, can build apps and much else beside".
Graham> My personal prejudice is that Smalltalk introduction would not
Graham> give much in the way of transferable skills...
patrick_d_logan> After all, it doesn't have C++ syntax???
Exactly: from the point of view of an employer seeing "has Smalltalk
experience" in the CV is about as interesting as seeing "fluent in
Tajik". At least in this country employers want people who can start
coding in C++ the day after they are hired, because employers hire to
cover positions in specific projects, that have budgets and deadlines,
they don't hire people and then decide how to train and where to deploy
them.
patrick_d_logan> Sounds like this is a training program for junior
patrick_d_logan> software "coders" rather than a university for learning
patrick_d_logan> computer science.
Perhaps you are taking not so seriously the very difficult problem of
the balance between vocational and educational content at universities.
Here in the UK companies are overwhelmingly interested in vocational
content, and don't hire computer scientists, which they usually try to
avoid like the plague, but C++ coders.
This creates a hell of a problem for curriculum planning. Your facile
comments are no help in understanding and solving it (if there *is* any
solution).
As Graham correctly points out "students need some C++ skills by the
time they graduate." as their real objective is to get a job, rather
than get an education as a goal in itself, and UK (at least) employers
as rule (with almost no exceptions) don't care at all about "proper OO
development skills" which cannot be measured but rather "just C++
syntax" which can be tested for (and yes, in many interviews
questionnaries on C++ syntax feature prominently). In other words local
employers don't care at all about capability, they care only about
experience as a proxy for it.
At least in the UK there is actually a two tier university system:
some employers do actually care about capability, and for those few
positions that require flexible computer scientists rather than C++
coders they will hire from one of three universities, and won't
usually even look at a graduate from any other...
Some academics in their ivory towers do care about teaching students
"proper development skills rather than just C++ syntax", but that is
often considered an elitist attitude that does not help getting a
graduate-level job, and students, when choosing a university, often look
at the percentage of graduates of a department that have got a job a few
months after graduation.
Additional Disclaimer: even this is articles comes from a UK university
account, I am not at all involved in teaching or research here, I am
just somebody who knows a bit of both the commercial and the academic
world.
Paul Griswold
: In a major recent survey (OOPSLA 95), IT industry practitioners predominantly
: recommended Smalltalk as the first programming language for computer science
: programs switching to the OO paradigm.
At Georgia Tech, the sophomore object-oriented programming class that all
CS majors have to take is done in Smalltalk, namely VisualWorks. C++ is
also covered, but only briefly.
--
==============================================================================
= Paul Griswold http://www.prism.gatech.edu/~gt8020b =
= gris...@cc.gatech.edu =
==============================================================================
Ell
Graham Perkins (g...@dmu.ac.uk) wrote:
:...
: CLASS AS ABSTRACTION
: Perhaps I am mistaken, but I have come to OO through the Abstract Data Type
: approach and feel that a class as an abstraction of a set of objects is what
: OO languages ought to provide. But a Smalltalk class is an object, must have
: exactly one instance present at runtime, and contains variables and routines
: accessible to all data items it produces. Class objects interact with each
: other and with their instances without any encapsulation protection.
:
: You cannot design and implement object systems in Smalltalk without
: understanding the runtime mechanism that keeps class objects connected
: in their hierarchy and connected as un-encapsulated suppliers to all
: the class object instances they produce.
:
: In other words, a Smalltalk class is not an abstraction or specification
: of all its instances, but is in fact a module object.
Also see Coplien's Advanced C++ Exemplar chapters for more on this. Some
languages have single, and others dual hierarchies. Single hierarchy
languages involve objects only, whereas dual hierarchy languages have both
classes, and objects. Classes are types and objects their instantiation
in dual hierarchy languages. Generally in single hierarchy languages
"prototype" objects are the model, or starting point for constructing
other objects.
Elliott
Oliver Elphick
Piercarlo Grandi wrote:
> At least in the UK there is actually a two tier university system:
> some employers do actually care about capability, and for those few
> positions that require flexible computer scientists rather than C++
> coders they will hire from one of three universities, and won't
> usually even look at a graduate from any other...
Which ones are these, please? (I have a son who wants to do a degree
in computer science in a year or two...)
--
Oliver Elphick ol...@enterprise.net
LFIX Ltd Tel/Fax: 01865 200200
Oxford, England Mobile: 0976 218316
Patrick Logan
> Graham Perkins (g...@dmu.ac.uk) wrote:
> : In other words, a Smalltalk class is not an abstraction or specification
> : of all its instances, but is in fact a module object.
A Smalltalk class *is* a specification of the class' instances.
*And* it is an object itself. Both are true.
Ell wrote:
>
> ...Some
> languages have single, and others dual hierarchies. Single hierarchy
> languages involve objects only, whereas dual hierarchy languages have both
> classes, and objects. Classes are types and objects their instantiation
> in dual hierarchy languages. Generally in single hierarchy languages
> "prototype" objects are the model, or starting point for constructing
> other objects.
Either these terms are misunderstood from the source, or they are used
differently from the way I have seen them used. I have read
definitions of these terms where "single hierarchy" refers to languages
like Smalltalk, C++, and Eiffel where the inheritance relationship
inherits implementations (i.e. code and state). While "dual hierarchy"
refers to languages that have two different inheritance relationships:
one for implementation as just described, and one for "interface" or
"type" inheritance. There was an ACM article some years ago from
Carleton U. about an "exemplar"-based Smalltalk. I think it supported
the "dual" notion. I guess Java approximates this concept with its
"interface" specifications. But I don't know enough to say how well
it fits any well accepted formal definition of "dual hierarchy", if
there is one.
Graham Perkins
Patrick Logan wrote:
me: In other words, a Smalltalk class is not an abstraction or specification
me: of all its instances, but is in fact a module object.
him: A Smalltalk class *is* a specification of the class' instances.
him: *And* it is an object itself. Both are true.
A Smalltalk class object is nearly a Smalltalk object like the other
Smalltalk objects. However, class objects lose their state encapsulation
in their links with descendant class objects and instance objects. Thus a
Smalltalk class object may be altered by other objects by means other than
through its method interface.
A Smalltalk class object *is not* a specification of all the class instances,
but *contains* such a specification. It also contains other material. Instance
objects, when created, are state-encapsulated against other instance objects
but may alter class object states. Thus a class object defines a scoped data
coupling between instance objects, as well as defining the instances themselves.
tray...@pcix.com
In <31860D...@dmu.ac.uk>, Graham Perkins <g...@dmu.ac.uk> writes:
>Patrick Logan wrote:
>me: In other words, a Smalltalk class is not an abstraction or specification
>me: of all its instances, but is in fact a module object.
>him: A Smalltalk class *is* a specification of the class' instances.
>him: *And* it is an object itself. Both are true.
>
>A Smalltalk class object is nearly a Smalltalk object like the other
>Smalltalk objects. However, class objects lose their state encapsulation
>in their links with descendant class objects and instance objects. Thus a
>Smalltalk class object may be altered by other objects by means other than
>through its method interface.
Please, produce the smalltalk code that demonstrates this.
>A Smalltalk class object *is not* a specification of all the class instances,
>but *contains* such a specification. It also contains other material. Instance
You are really splitting hairs. In order for the specification to be
mutable it must exist in the system as an object. By your reasoning the
specification object is not a specification but contains it instead.
>objects, when created, are state-encapsulated against other instance objects
>but may alter class object states. Thus a class object defines a scoped data
They can only alter class variables, which are not the same as class
instance variables. Class variables are variables that are visable to
all instances of the class and subclasses but they are not part of the
class state description.
>coupling between instance objects, as well as defining the instances themselves.
===========================================================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk *Breakpoints* and *Watchpoints* for
19 Tilley Ave. VW and Envy
Newport, RI 02840
(401) 846-6573 tray...@pcix.com
<a href="http://www2.pcix.com/~traymond/"> Crafted Smalltalk</a>
===========================================================
Richard Riehle
On Mon, 29 Apr 1996, Oliver Elphick wrote:
> Which ones are these, please? (I have a son who wants to do a degree
> in computer science in a year or two...)
With the advent of the first ISO/ANSI standard Object-Oriented
Programming language, Ada, his school should definitely be offering Ada
as one of the alternatives. Of course, many in academia are not yet
up-to-date on ISO standard Ada 95.
Richard Riehle