[OT] Teaching OO / Java (was: Concentric Circles Loosing It)

java-programmer, [OT] Teaching OO / Java (was: Concentric Circles Loosing It) Hi !
"Anthony Borla" wrote:
>
> "Alan P" <email***@***.com> wrote in message
> news:br0efp$ola$email***@***.com...
> >
> > I'm a newbie Java student as well, and AFAIK we all start
> > the same way -> by using a 'Turtle' class. Remember those
> > little robot things from infant school, with the penUp(),
> > penDown() etc.
> >
> > The idea is not stunning effects, but an introduction to OOPS
[...]
> I'm just a very firm believer [based mainly anectdotal, not statistical,
> evidence] in teaching programming concepts from first principles which, to
> me, means:
>
> * Teaching the rudiments of console windows / command-line
> usage, which includes the use of editors, compilers, and similar
> tools.

O.k., this is meant to teach the "DE" (leaving out the leading 'I'). But
maybe some people want their students to concentrate on the course theme, so
they decide to use an IDE. Personally, I think one has to know how to deal
with a language without any external (!) IDE, so you should know about
"javac" and "java"...

>
> Taking a Windows environment as an example, all that is needed
> is knowing how to:
>
> - Open up a Command Window
> - Load and use Notepad [or one of its more versatile
> replacements]
> - Invoke javac.exe and java.exe
>
> * Teaching language syntax basics using a serial execution
> programming model, a fancy description for a program
> which executes by starting at point A and proceeding
> downwards towards towards point B e.g.
>
> ...
> public static void main(String[] args)
> {
> // Point A
> ...
> ...
> // Point B
> }
> ...
>
> Once students have grasped the basics of structured / object-based
> programming, all in a serial, non-GUI enviroment, the rudiments of OOP
> [inheritance, polymophism] can be taught.

This will teach students to write programs the serial way first. In my
opinion, it would be the better approach to teach basic OO concepts first
(before even invoking an editor for the first time, maybe using some
pseudo-language).

Using your approach, students would learn how to write an imperative program
frist (one big main() method). Then you would introduce a completely new
paradigm, the structured programming, using functions (other than the main()
method, but still implementing a single class). Later on, you would
introduce yet another paradigm, the object-oriented programming implementing
specialized classes which will focus on certain tasks.

Have you ever tried to teach oo concepts to a - let's say - COBOL programmer
(nothing to say against COBOL programmer, of course, replace with almost any
3GL you (don't) like)? You will have a very hard time unless he (or she)
will understand them, because the imperative paradigm will block their view
onto objects. So I would always prefer to teach the object-oriented way
first. For most people, it will be quite easy to write "one big main()
method" if they are forced to do it, and the oo paradigm will not stand in
their way.

> Once these basics have been
> mastered, the next steps could be taken, which would probably be one, or
> more, of the following:
>
> * Algorithms / Data Structures

Data Structures might well be renamed "Object Oriented Design"... ;-)

> * Concurrent / Advanced Programming
> * Event-driven / GUI Programming
>
> I guess you would describe me as decidedly 'old school' in this regard :)
!
>
> In a nutshell, I'm not comfortable with the notion that GUI's and graphics
> simplify the teaching of very important, fundamental programming ideas,
but
> I probably hold a minority opinion here.
>
> Programming, like mathematics, can be an exciting field. However, much
> effort, most of it in mundane areas, must be expended to satisfactorily
> grasp the basics on which all further learning progress rests. I can
> appreciate course designers wanting to make programming more interesting
or
> accessable, hence the use of GUI's and similar tools, or presenting ideas
in
> graphical form. IMO, though, it is best to avoid such things as they sport
> hidden complexities, and keep things as simple as possible, at least until
a
> firm grounding in the basics has been obtained.

Yes. But one might define "basics" somewhat different. You must not have (I
might even say "should not have") any knowledge about "serial" or
"functional" programming to learn to write good OO programs.

(O.k., I might have started another thread on this, but then...)

Cheers,
Michael

java-programmer >> [OT] Teaching OO / Java (was: Concentric Circles Loosing It) Having tried both approaches, I can tell you that an "objects-first"
approach works much better when teaching an OOP language. Starting
with a procedural approach and then trying to shift to OOP mode later
is counter-productive.

I don't have a problem starting with console windows and a text
editor, in fact I encourage it for the reasons stated below.
Especially in Java, since it doesn't produce native executables, kids
who only use an IDE, have trouble separating the IDE from the
language. If they've never run a program without the IDE, they may
not understand that it CAN run without the IDE.

But that is a separate issue. You can create a GUI program (i.e.
Turtles) in a console window so long as the program runs in a
graphical environment. The Turtle class that I use, will pop open a
nice looking window when executed from the command line. The kids
learn about method calls, subclassing, and objects right from the
get-go. When I introduce primitive elements, like ints, booleans,
etc., they are introduced in a manner that shows how they would be
used in objects and to control objects.

"Michael Voss" <email***@***.com> wrote in message news:<3fd475ea$1@news>...
> Hi !
> "Anthony Borla" wrote:
> >
> > "Alan P" <email***@***.com> wrote in message
> > news:br0efp$ola$email***@***.com...
> > >
> > > I'm a newbie Java student as well, and AFAIK we all start
> > > the same way -> by using a 'Turtle' class. Remember those
> > > little robot things from infant school, with the penUp(),
> > > penDown() etc.
> > >
> > > The idea is not stunning effects, but an introduction to OOPS
> [...]
> > I'm just a very firm believer [based mainly anectdotal, not statistical,
> > evidence] in teaching programming concepts from first principles which, to
> > me, means:
> >
> > * Teaching the rudiments of console windows / command-line
> > usage, which includes the use of editors, compilers, and similar
> > tools.
>
> O.k., this is meant to teach the "DE" (leaving out the leading 'I'). But
> maybe some people want their students to concentrate on the course theme, so
> they decide to use an IDE. Personally, I think one has to know how to deal
> with a language without any external (!) IDE, so you should know about
> "javac" and "java"...
>
> >
> > Taking a Windows environment as an example, all that is needed
> > is knowing how to:
> >
> > - Open up a Command Window
> > - Load and use Notepad [or one of its more versatile
> > replacements]
> > - Invoke javac.exe and java.exe
> >
> > * Teaching language syntax basics using a serial execution
> > programming model, a fancy description for a program
> > which executes by starting at point A and proceeding
> > downwards towards towards point B e.g.
> >
> > ...
> > public static void main(String[] args)
> > {
> > // Point A
> > ...
> > ...
> > // Point B
> > }
> > ...
> >
> > Once students have grasped the basics of structured / object-based
> > programming, all in a serial, non-GUI enviroment, the rudiments of OOP
> > [inheritance, polymophism] can be taught.
>
> This will teach students to write programs the serial way first. In my
> opinion, it would be the better approach to teach basic OO concepts first
> (before even invoking an editor for the first time, maybe using some
> pseudo-language).
>
> Using your approach, students would learn how to write an imperative program
> frist (one big main() method). Then you would introduce a completely new
> paradigm, the structured programming, using functions (other than the main()
> method, but still implementing a single class). Later on, you would
> introduce yet another paradigm, the object-oriented programming implementing
> specialized classes which will focus on certain tasks.
>
> Have you ever tried to teach oo concepts to a - let's say - COBOL programmer
> (nothing to say against COBOL programmer, of course, replace with almost any
> 3GL you (don't) like)? You will have a very hard time unless he (or she)
> will understand them, because the imperative paradigm will block their view
> onto objects. So I would always prefer to teach the object-oriented way
> first. For most people, it will be quite easy to write "one big main()
> method" if they are forced to do it, and the oo paradigm will not stand in
> their way.
>
> > Once these basics have been
> > mastered, the next steps could be taken, which would probably be one, or
> > more, of the following:
> >
> > * Algorithms / Data Structures
>
> Data Structures might well be renamed "Object Oriented Design"... ;-)
>
> > * Concurrent / Advanced Programming
> > * Event-driven / GUI Programming
> >
> > I guess you would describe me as decidedly 'old school' in this regard :)
> !
> >
> > In a nutshell, I'm not comfortable with the notion that GUI's and graphics
> > simplify the teaching of very important, fundamental programming ideas,
> but
> > I probably hold a minority opinion here.
> >
> > Programming, like mathematics, can be an exciting field. However, much
> > effort, most of it in mundane areas, must be expended to satisfactorily
> > grasp the basics on which all further learning progress rests. I can
> > appreciate course designers wanting to make programming more interesting
> or
> > accessable, hence the use of GUI's and similar tools, or presenting ideas
> in
> > graphical form. IMO, though, it is best to avoid such things as they sport
> > hidden complexities, and keep things as simple as possible, at least until
> a
> > firm grounding in the basics has been obtained.
>
> Yes. But one might define "basics" somewhat different. You must not have (I
> might even say "should not have") any knowledge about "serial" or
> "functional" programming to learn to write good OO programs.
>
> (O.k., I might have started another thread on this, but then...)
>
> Cheers,
> Michael

Posted: 2003-12-17 21:55:00

java-programmer >> [OT] Teaching OO / Java (was: Concentric Circles Loosing It)
"Michael Voss" <email***@***.com> wrote in message
news:3fd475ea$1@news...
> >
> > "Alan P" <email***@***.com> wrote in message
> > news:br0efp$ola$email***@***.com...
> > >
> > > I'm a newbie Java student as well, and AFAIK we all start
> > > the same way -> by using a 'Turtle' class. Remember those
> > > little robot things from infant school, with the penUp(),
> > > penDown() etc.
> > >
> > > The idea is not stunning effects, but an introduction to
> > > OOPS

Apologies for not having responded earlier [particularly about such an
important issue] - this message somehow remained hidden in my e-mail drafts
folder until now.

<SNIP>
>
> O.k., this is meant to teach the "DE" (leaving out the leading 'I').
> But maybe some people want their students to concentrate on
> the course theme, so they decide to use an IDE. Personally,
> I think one has to know how to deal with a language without
> any external (!) IDE, so you should know about "javac" and
> "java"...
>

I believe programming students, before they can grasp [and meaningfully
apply] abstract ideas like, for example, inheritance and polymophism, should
be knowledgeable of the computer environment, as well as of the practical
aspects of software development. It looks like we both hold similar views
about this.

Given this view, I'd argue that theme-based subjects not be taught until
'the basics' [as previously outlined] have been covered. This is
particularly important, I feel, in effectively teaching programming /
software development.

For example, an approach reliant 'basics first' is the model used to teach
mathematics in schools. Here, 'the basics' are covered in primary / grade
school, and 'themes' [i.e. more abstract areas] are taught in secondary /
high school, if I'm not mistaken ? Themes only make sense once the
groundwork has been covered and mastered. I truly feel this approach is
vital in the teaching of programming.

>
<SNIP>
>
> This will teach students to write programs the serial way
> first. In my opinion, it would be the better approach to
> teach basic OO concepts first (before even invoking an
> editor for the first time, maybe using some pseudo-language).
>

I believe procedural thinking is far more natural or intuitive. Who, for
instance, hasn't followed verbal directions to some destination, or followed
a set of instructions for building a gadget, or for preparing a meal ? I
don't think its difficult to teach imperative / procedural programming
precisely because it follows a thinking model with which we are all,
already, quite familiar.

I think abstract concepts, like OO, have a much better chance of being
understood if they can be linked to more concrete things. For example, the
teaching of imperative / procedural programming would also have introduced
the concept of code resuability - packing code into generic procedures
allows them to be reused in other projects. With students having a solid
grasp of this idea, the concept of inheritance for code resusability becomes
far easier to comprehend, and its benefits more evident.

A key benefit of inheritance is lost on students who have no idea of code
resuability.

>
> Using your approach, students would learn how to write
> an imperative program first (one big main() method). Then
> you would introduce a completely new paradigm, the
> structured programming, using functions (other than the
> main() method, but still implementing a single class). Later
> on, you would introduce yet another paradigm, the
> object-oriented programming implementing specialized
> classes which will focus on certain tasks.
>

I believe this is a perfectly reasonable approach, though, of course, this
wouldn't be attempted within the one course, but would be covered over a few
semesters as separate subjects.

As a first step you would show students how to write 'executable recipes',
that is, a series of steps that accomplishes some larger task [imperative
programming]. The next step might be to show how this could be improved by
combining steps into procedures [structured programming etc]. Further on
from this you could teach how procedures could be combined into larger units
[modules / objects] whereby each procedure acts on the data within the
module / object [object-based programming]. Next up you could extend this to
include the classic OO concepts of inheritance, and polymorphism, thus
taking you into the realm of object-oriented programming.

It is, I feel, a fairly natural progression from imperative programming to
OOP, and I don't think knowledge of non-OOP programming will interfere with
the learning of these ideas. If anything, it should make them clearer -
students now understand two or more ways of accomplishing the same task, and
can be taught why one way is superior to the other given a particular set of
circumstances.

>
> Have you ever tried to teach oo concepts to a - let's say -
> COBOL programmer (nothing to say against COBOL
> programmer, of course, replace with almost any 3GL
> you (don't) like)? You will have a very hard time unless he
> (or she) will understand them, because the imperative
> paradigm will block their view onto objects.
>

I think your'e underestimating the flexibility of the human mind. I'd say a
student or programmer who had the intellectual nouse to master a 3GL would
also be able to set aside preconceived ideas, and try to understand and
apply the new concepts being taught.

I'd agree with your argument in the case of a professional programmer who is
well schooled in imperative / procedural programming [say, a C programmer],
and is being trained in OOP techniques [being taught C++, or possibly Java].
It is only natural to expect such a person to 'fall back' and use tried and
true programming techniques simply because they are more productive using
them.

Also, I should add that OO extensions have been added to many 3GL's
including COBOL. It is possible, though quite cumbersome, to write OO
programs in COBOL ! I should add that the way these have been grafted onto
such a big, complex language as COBOL, and done so in such an unobstrusive
manner, is IMO, nothing short of brilliant.

>
> So I would always prefer to teach the object-oriented way
> first. For most people, it will be quite easy to write "one
> big main() method" if they are forced to do it, and the oo
> paradigm will not stand in their way.
>

Fair enough. I stand by my previous assertions.

>
> Data Structures might well be renamed "Object Oriented
> Design"... ;-)
>

Yes, and no. A stack, for example, is an abstract machine characterised by
certain behaviours, and one which can be implemented in any paradigm. In
other words, the notion or essence of 'stack' trancends paradigms, and it is
this generality that any 'Data Structures' course should be aiming to
convey. Object oriented design is a restricted type of design since it has
to follow OO rules - data structures are language and paradigm independant.

>
> Yes. But one might define "basics" somewhat different. You
> must not have (I might even say "should not have") any
> knowledge about "serial" or "functional" programming to
> learn to write good OO programs.
>

I believe a firm basis in imperative / procedural programming is essential
in order for most of the other paradigms to make sense. As described
earlier, there seems a fairly natural prograssion from imperative /
procedural programming to OOP. Functional programming, also, can be seen as
a restricted sort of imperative programming, so it would seem appropriate to
cover it before this paradigm as well [you can also *more meaningfully*
present the benefits of a functional approach by showing what it does not do
i.e. no side-effect programming, avoiding pass-by-reference etc].

It seems to me that the only programming paradigm that *can* be taught
without first covering imperative / procedural programming is logic
programming. In fact, it would appear that this be taught in parallel to
imperative / procedural programming as teaching either one first actually
impedes students' understanding of the other [e.g. the notion of 'variable'
in Prolog is so totally different to that in C, Java, or even LISP].

>
> (O.k., I might have started another thread on this,
> but then...)
>

That's perfectly fine - I just wish I'd responded sooner

Cheers,

Anthony Borla

java-programmer >> [OT] Teaching OO / Java (was: Concentric Circles Loosing It) Hi everybody !

"Anthony Borla" wrote:
[...]
> Apologies for not having responded earlier

Apologies from me, too. I was taking an excessive christmas vacation
(no computers or even internet around :-( ), so I was not able to
read and answer your posting before...

[...]
> For example, an approach reliant 'basics first' is the model used to teach
> mathematics in schools.
[...]
> Themes only make sense once the
> groundwork has been covered and mastered. I truly feel this approach is
> vital in the teaching of programming.

This is true for such things as mathematics, as each topic is somewhat based
on those covered before. But it is not necessarily true for programming
paradigms. I am quite sure you will be able to learn, say, LISP and become a
good LISP programmer without knowing anything about imperative programming
in advance. But if you know an imperative language like BASIC before, you
will have to forget a lot of things before you will truly master LISP. This
does not apply to mathematics at all. Each programming paradigm has it's own
groundwork.

[...]
> I believe procedural thinking is far more natural or intuitive.
[...]
> it follows a thinking model with which we are all,
> already, quite familiar.

Yes. And everybody will try do do things in the way that is most familiar to
him / her. So many people will tend to do it "the imperative way" if they
are
familiar with it even in an oo environment.

> I think abstract concepts, like OO, have a much better chance of being
> understood if they can be linked to more concrete things.

To more concrete things, yes. Give your students an example from their well
known environment to work on in an object oriented way...

> For example, the
> teaching of imperative / procedural programming would also have introduced
> the concept of code resuability - packing code into generic procedures
> allows them to be reused in other projects.

Yes. But it does not necessarily teach them to encapsule data and
functionality
and view at it as a unity and to reuse the whole bundle (which we will
eventually call "object" a few lessons later)...

> With students having a solid
> grasp of this idea, the concept of inheritance for code resusability
becomes
> far easier to comprehend, and its benefits more evident.

There is a big difference between code reusability and object oriented
programming. You may split c code into different files, including one or the
other to reuse those functions in another program. Arranging data and
methods
in classes is comlpetely different, and a lot of people will end up writing
one
or two classes with lots of static functions as an result of learning to
reuse
functions in a procedural manner.

>
> A key benefit of inheritance is lost on students who have no idea of code
> resuability.
>

These are two quite different approaches of code reusability: Reusing
objects or
inheriting from existing object on one hand and reusing existing functions
or
procedures ("code libraries") on the other. I don't think one will
necessarily
have to tell one's students that you can use functions stored in code
libraries
if the students are to learn inheritance. Showing them to reuse functions
(or to
use code libraries) may of course help to make them aware of not having to
write
the same piece of code again and again in each program. But I think it is
independent of the paradigm. You will teach your students to look for
objects
already accomplishing the task they have to instead of rewriting them.

[...]
> It is, I feel, a fairly natural progression from imperative programming to
> OOP, and I don't think knowledge of non-OOP programming will interfere
with
> the learning of these ideas. If anything, it should make them clearer -
> students now understand two or more ways of accomplishing the same task,
and
> can be taught why one way is superior to the other given a particular set
of
> circumstances.

This progression represents a part of the development of programming
languages.
Would you start teaching your students programming in assembler first in
order to
teach them oop? I wouldn't, and I am sure most teachers wouldn't, too. Of
course,
the students must be able to write a method. Of course, it helps to be able
to
write an imperative program to accomplish this task.

[...]
> I think your'e underestimating the flexibility of the human mind. I'd say
a
> student or programmer who had the intellectual nouse to master a 3GL would
> also be able to set aside preconceived ideas, and try to understand and
> apply the new concepts being taught.

This will depend on the time one spent using this concept. So I would try to
present these oo concept as quickly as possible to the students, not giving
them
time to get used to the procedural approach.

>
> I'd agree with your argument in the case of a professional programmer who
is
> well schooled in imperative / procedural programming [say, a C
programmer],
> and is being trained in OOP techniques [being taught C++, or possibly
Java].
> It is only natural to expect such a person to 'fall back' and use tried
and
> true programming techniques simply because they are more productive using
> them.

I caught myself doing this lots of times when I started oo programming and
find
myself doing this now and then even after nearly ten years of pure oo
programming
with smalltalk and java.

[...]
> > Data Structures might well be renamed "Object Oriented
> > Design"... ;-)
> >
>
> Yes, and no. A stack, for example, is an abstract machine characterised by
> certain behaviours, and one which can be implemented in any paradigm. In
> other words, the notion or essence of 'stack' trancends paradigms, and it
is
> this generality that any 'Data Structures' course should be aiming to
> convey. Object oriented design is a restricted type of design since it has
> to follow OO rules - data structures are language and paradigm
independant.

That's completely true.

>
> >
> > Yes. But one might define "basics" somewhat different. You
> > must not have (I might even say "should not have") any
> > knowledge about "serial" or "functional" programming to
> > learn to write good OO programs.
> >
>
> I believe a firm basis in imperative / procedural programming is essential
> in order for most of the other paradigms to make sense. As described
> earlier, there seems a fairly natural prograssion from imperative /
> procedural programming to OOP. Functional programming, also, can be seen
as
> a restricted sort of imperative programming, so it would seem appropriate
to
> cover it before this paradigm as well [you can also *more meaningfully*
> present the benefits of a functional approach by showing what it does not
do
> i.e. no side-effect programming, avoiding pass-by-reference etc].

I see your point. But as stated earlier, in my opinion the time between the
introduction of the oo paradigm should be rather short...

>
> It seems to me that the only programming paradigm that *can* be taught
> without first covering imperative / procedural programming is logic
> programming. In fact, it would appear that this be taught in parallel to
> imperative / procedural programming as teaching either one first actually
> impedes students' understanding of the other [e.g. the notion of
'variable'
> in Prolog is so totally different to that in C, Java, or even LISP].

Yes, that would be a very good idea, but you rarely have the chance do do
this.

[...]
> That's perfectly fine - I just wish I'd responded sooner
[...]

Same applies to me, again.

Sorry for responding late,
Michael

java-programmer >> [OT] Teaching OO / Java (was: Concentric Circles Loosing It)
"Anthony Borla" <email***@***.com> wrote:

<SNIP>

> Apologies for not having responded earlier [particularly about such an
> important issue] - this message somehow remained hidden in my e-mail
drafts
> folder until now.

Well, I thougth I posted another reply on this nerly two weeks ago, but
since I don't see it in this thread, i'll just post another one. Hope you
don't mind.

<SNIP>
> For example, an approach reliant 'basics first' is the model used to teach
> mathematics in schools. Here, 'the basics' are covered in primary / grade
> school, and 'themes' [i.e. more abstract areas] are taught in secondary /
> high school, if I'm not mistaken ? Themes only make sense once the
> groundwork has been covered and mastered. I truly feel this approach is
> vital in the teaching of programming.

Yes, but then, you will not be able to perform diofferential calculus
without being able to add and subtract properly, whereas I think one may
well write good oo programs without knowing anything about imperative
programming.

<SNIP>
> I believe procedural thinking is far more natural or intuitive. Who, for
> instance, hasn't followed verbal directions to some destination, or
followed
> a set of instructions for building a gadget, or for preparing a meal ? I
> don't think its difficult to teach imperative / procedural programming
> precisely because it follows a thinking model with which we are all,
> already, quite familiar.

I agree. Many people will try to use these familiar patterns of imperative
programming even when using an oo language, as a result.

>
> I think abstract concepts, like OO, have a much better chance of being
> understood if they can be linked to more concrete things. For example, the
> teaching of imperative / procedural programming would also have introduced
> the concept of code resuability - packing code into generic procedures
> allows them to be reused in other projects. With students having a solid
> grasp of this idea, the concept of inheritance for code resusability
becomes
> far easier to comprehend, and its benefits more evident.

Again, I agree. But I think these "concrete things" should rather be good
real-world examples. There is a fundamental difference in code reusability
between procedural and object-oriented programming. The oo way will be
mastered a lot easier if the student will not try to write a function and
reuse it file in another program merely by including it's source file.

>
> A key benefit of inheritance is lost on students who have no idea of code
> resuability.

Of course, students have to know that they won't have to reinvent the wheel
each and every time they write a program.

<SNIP>
>
> I believe this is a perfectly reasonable approach, though, of course, this
> wouldn't be attempted within the one course, but would be covered over a
few
> semesters as separate subjects.

Have you experienced students getting used to the procedural paradigm during
those semesters, thus writing worse oo programs ? Or can they switch between
these paradigms well ?

>
> As a first step you would show students how to write 'executable recipes',
> that is, a series of steps that accomplishes some larger task [imperative
> programming]. The next step might be to show how this could be improved by
> combining steps into procedures [structured programming etc]. Further on
> from this you could teach how procedures could be combined into larger
units
> [modules / objects] whereby each procedure acts on the data within the
> module / object [object-based programming]. Next up you could extend this
to
> include the classic OO concepts of inheritance, and polymorphism, thus
> taking you into the realm of object-oriented programming.
>
> It is, I feel, a fairly natural progression from imperative programming to
> OOP, and I don't think knowledge of non-OOP programming will interfere
with
> the learning of these ideas. If anything, it should make them clearer -
> students now understand two or more ways of accomplishing the same task,
and
> can be taught why one way is superior to the other given a particular set
of
> circumstances.

Yes, but with the danger of falling back to the easier way of writing some
functions and a main program instead of defining proper objects and giving
them the proper methods to perform their tasks.

<SNIP>
> I think your'e underestimating the flexibility of the human mind. I'd say
a
> student or programmer who had the intellectual nouse to master a 3GL would
> also be able to set aside preconceived ideas, and try to understand and
> apply the new concepts being taught.
>
> I'd agree with your argument in the case of a professional programmer who
is
> well schooled in imperative / procedural programming [say, a C
programmer],
> and is being trained in OOP techniques [being taught C++, or possibly
Java].
> It is only natural to expect such a person to 'fall back' and use tried
and
> true programming techniques simply because they are more productive using
> them.
>
> Also, I should add that OO extensions have been added to many 3GL's
> including COBOL. It is possible, though quite cumbersome, to write OO
> programs in COBOL ! I should add that the way these have been grafted onto
> such a big, complex language as COBOL, and done so in such an unobstrusive
> manner, is IMO, nothing short of brilliant.
>
<SNIP>
> >
> > Data Structures might well be renamed "Object Oriented
> > Design"... ;-)
> >
>
> Yes, and no. A stack, for example, is an abstract machine characterised by
> certain behaviours, and one which can be implemented in any paradigm. In
> other words, the notion or essence of 'stack' trancends paradigms, and it
is
> this generality that any 'Data Structures' course should be aiming to
> convey. Object oriented design is a restricted type of design since it has
> to follow OO rules - data structures are language and paradigm
independant.

Of course!
>
> >
> > Yes. But one might define "basics" somewhat different. You
> > must not have (I might even say "should not have") any
> > knowledge about "serial" or "functional" programming to
> > learn to write good OO programs.
> >
>
> I believe a firm basis in imperative / procedural programming is essential
> in order for most of the other paradigms to make sense. As described
> earlier, there seems a fairly natural prograssion from imperative /
> procedural programming to OOP. Functional programming, also, can be seen
as
> a restricted sort of imperative programming, so it would seem appropriate
to
> cover it before this paradigm as well [you can also *more meaningfully*
> present the benefits of a functional approach by showing what it does not
do
> i.e. no side-effect programming, avoiding pass-by-reference etc].

But your students will not have to learn assembler before starting C, won't
they ;-)

>
> It seems to me that the only programming paradigm that *can* be taught
> without first covering imperative / procedural programming is logic
> programming. In fact, it would appear that this be taught in parallel to
> imperative / procedural programming as teaching either one first actually
> impedes students' understanding of the other [e.g. the notion of
'variable'
> in Prolog is so totally different to that in C, Java, or even LISP].
>
<SNIP>

Maybe it could be a good approach to teach all of these three paradigms in
parallel, but this might lead to a total confusion.

Sorry for respondig so late,
Michael