Loading ...
Sorry, an error occurred while loading the content.

Re: [hackers-il] Re: Re: Technion Computer Science Anomalities

Expand Messages
  • Adi Stav
    On Sun, Sep 23, 2001 at 04:17:15PM +0300, Shlomi Fish wrote: [snip] ... It sounds like both of these problems are related to being used to Perl already. The
    Message 1 of 19 , Sep 23, 2001
    • 0 Attachment
      On Sun, Sep 23, 2001 at 04:17:15PM +0300, Shlomi Fish wrote:
      > > > I do not recommend Perl as a first programming language. But then again I
      > > > would not recommend LISP either, and I have very serious doubts regarding
      > > > Python. (note that I don't know the latter too well)
      > >
      > > I don't know LISP. Why not Python?
      > >
      > Well, I had (and still have) to write and maintain a python script, and
      > despite the fact that I know Perl, C, C++, Scheme, etc. very well, I had
      > quite a lot of problems with it. I admit that I did not read von Russom's
      > intro from the beginning to the end, but rather was looking for quick and
      > dirty solutions.
      > In any case, I found out that a lot of things did not behave as I expected
      > them. For instance, the fact that by default a print appends a newline to
      > its output. Or the fact that "shift" is "pop(0)". In any case, I assume a
      > newbie will encounter such mishaps too, if he is taught Python as a first
      > programming language.

      It sounds like both of these problems are related to being used to
      Perl already. The pop/shift problem is a purely syntactic issue
      regarding which a programming novice will have no biases. I consider
      both of the names equally unnatural. Regarding print, I *really* don't
      think the expectation of an unexperienced programmer would be for
      print to add no leading newline. This would only be expected by a
      programmer who is familiar with basic I/O principles.

      > Like I said earlier, I do not know Python well enough to testify for its
      > suitability as a first programming language. So let's drop this
      > discussion.


      > > But I doh't agree with this approach to start with. Every (good)
      > > language is based on certain key CS principles, in this case objects.
      > > Once you choose principles to teach programming by, you should stick
      > > to them. It is counter-productive to explain those principles by
      > > other, new principles and confuse the students. I don't see why a
      > > hash table is any less magical than a plain object. What is less
      > > magical in foo["bar"] than in foo.bar? The two are almost completely
      > > equivalent semantically and are very similar syntactically. A student
      > > had better first learn the normal way to do things -- the dynamic
      > > nature of Perl and Python is very valuable to programmers who wish
      > > to access members whose names are not known in advance, but I don't
      > > think novices should learn this feature before mastering the proper
      > > way to do things. This is the same reason why I don't think "goto"
      > > should be taught before "for", even though the second is implemented
      > > using the first.
      > >
      > I do believe associative arrays (or dictionaries or maps or whatever you
      > wish to call them) are more basic perceptually than objects.

      The teacher chooses the basic perceptions. Some things might be
      simpler or easier, but what is basic depends on the fundamentals
      initially chosen. If you teach objects, then later hash tables
      can be "just like objects but dynamic", or implemented using
      objects. The first is no more true than the second.

      > A smart
      > student can create a non-optimal implementation of an associative array
      > himself. A teacher can take some time to ask the students how an
      > associative array may be implemented. He need delve to specific
      > details about hashes.

      Implementation is irrelevant to understanding. You don't necessarily
      need to know about vtables and garbage collection in order to
      understand the essentially simple basic nature and use of
      polymorphism or references. Their implementation is an advanced topic
      that possibly belongs in a completely different subject.

      > Object on the other hand is not exactly an Abstract Data Type but rather a
      > programming tool. It is important for students to realize that there's
      > nothing magical about its implementation, but rather that it is
      > implemented in some manner by the compiler or interpreter.

      You don't need to teach students about multiple inheritance right
      from the start. In fact you don't need to teach inheritance at all
      in order to teach the concepts of abstraction and encapsulation.
      Advanced OOP topics require not only more abstract thinking about
      programming, but also the ability to handle the more complicated
      programs in which they make sense.

      At the level of simply declaring objects, an object is not that
      different from a hash table at all. It is less dynamic -- which is
      good to study with. But it can also use to access methods very
      naturally, which you cannot do through hash tables without first
      teaching the more advanced notion of function references. The fact
      that a concept has a simple and integrated beauty does not
      necessarily mean it will make good material for the very first
      lesson. Separation of code and data is important to understand
      before learning how to blur the difference.

      > > (Another thing is that hash table is not necessarily the right
      > > way to implement objects. For higher-performance, less-dynamic
      > > languages such as C++, an object is implemented using memory offsets
      > > and the string name does not survive the compilation stage. So showing
      > > students that objects are really hash tables don't teach them much
      > > about the inherent nature of objects. But I agree this is still
      > > an arguable point because one can always say that the compiler DOES
      > > keep a hash table of all the members, and that the translation of this
      > > hash table into offsets is just an implementation detail.)
      > >
      > I did not say that a hash table was the ideal way to implement an object.
      > I am aware of the offsets' implementation and realize both hashes and
      > offsets have their advantages and disadvantages.
      > Pardon a perl programmer for using hash where associative
      > array/dictionary/map would have been more in place.

      I don't mind either. If at all, "hash" is short and simple.
    Your message has been successfully submitted and would be delivered to recipients shortly.