[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [seul-edu] Language to teach 10 year olds
At 10:58 PM 07/14/2001 +0000, you wrote:
>On Sat, 14 Jul 2001, Michael Viron wrote:
>> >Here I have to disagree. Programming is a practical thing, not
>> >a theoretical thing, like walking. Children learn walking by
>> >trying to walk, till they don't try they don't learn.
>> >
>> Actually, programming is a theoretical thing --
>> otherwise Universities
>
>Well, on one hand we hand the design of algorithms and technics
>for such task like: divide and conquer or incremental programming,...
>Anyway algorithm is always expressed in a language, even if
>it's seudocode or natural language, which in these case is
>a kind of imperative language.
I would tend to think that neither "pseudocode" nor "natural language" are,
in fact, programming languages. I would also argue that both the "divide
and conquer" and "incremental" design methodologies are not restricted only
to programming languages. They can be used equally well with databases,
networks, english papers, and so forth.
>
>> would not have a "Programming Languages" (or similar) course which focuses
>> heavily on the theory behind various programming languages.
>
>Nobody will understand what an object is, till a couple of objects
>are described in Smaltalk, Ada or Python,... the same with
>'exceptions' or 'variable assignment'... You can focus only
>in the set of available operations and concept without writting
>ever a large programm, but I guess this is boring and pointless.
In that case, what do you mean by a "large" program? A couple thousand
lines? a couple hundred? I would have to say that I would hope you
wouldn't have to write a large program in an assembler language (either x86
/ 68000), as it quickly becomes very frustrating to use 30 or more
instructions (provided of course that one can even figure out what to do)
to do something that would take something like 4 or 5 lines in C or Pascal.
It is much better to have a single program that you build on during the
course of a semester as you learn new techniques and learn about re-using
functions and so forth, then to have to write several large programs that
don't even tie into one another.
I would also beg to differ that noone can understand what an "object" is
before it is described in a programming language. The first time I started
learning about objects was my Software Engineering I class, where we
discussed "Object Oriented Software Engineering Methodologies". A class in
which we very rarely wrote code, except as part of our semester project. I
also heard it in conjunction with Database systems before I ever started
thinking of programming in an object-oriented language.
>> This is
>> because it is much easier to "learn" a new language if you have a basic
>> understanding of the key "abstract" concepts that are common between
>> languages. Nor would CS / CIS degree plans include more "theoretical"
>> courses (such as Networking, Database Systems, Operating Systems, and so
>
>And on the other hand, well, when explaining such courses you explain
>examples of design
>of decission for every subject: like Novell, satellite network,
>Ethernet, hierarchical data bases, ... You can't fully explain
>OSI model if you ellude mentioning that Ethernet deals with the
>lower levels and TCP is a transport level thing.
>In computer science, theoretical is based in very specific things,
>if you think about it, carefully.
>To put it short, the examples are what make the theory, the theory
>is just a classification of the "examples".
Actually, Software Engineering (I and II), Introduction to Operations
Research, Networks, Operating Systems, and Database Systems are theoretical
courses. This does not mean that these courses do not use examples to
assist in learning the different theorys, but you end up with far more
"theoretical" than "practical" knowledge out of such classes. It is not
until you apply such theoretical knowledge that you actually end up with
the practical knowledge that companies are looking for.
Michael