From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=5.0 tests=BAYES_00,RATWARE_MS_HASH, RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public X-Google-Thread: 10db24,4cf070091283b555 X-Google-Attributes: gid10db24,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public From: "Tim Behrendsen" Subject: Re: What's the best language to learn? [was Re: Should I learn C or Pascal?] Date: 1996/08/17 Message-ID: <01bb8c70$8f711800$87ee6fce@timpent.airshields.com> X-Deja-AN: 174875704 references: <01bb89f1$31be4f60$87ee6fce@timpent.airshields.com> <4v1pnf$8du@zeus.orl.mmc.com> content-type: text/plain; charset=ISO-8859-1 organization: A-SIS mime-version: 1.0 newsgroups: comp.edu,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.unix.programmer Date: 1996-08-17T00:00:00+00:00 List-Id: Bob Gilbert wrote in article <4v1pnf$8du@zeus.orl.mmc.com>... > In article <01bb89f1$31be4f60$87ee6fce@timpent.airshields.com>, "Tim Behrendsen" writes: > > is truly understood or not. Solving a problem is not an > > "abstraction" question, it's a question of breaking it down > > into fundamental steps of data transformations. > > Guess it depends on your definition of "solving a problem". > I see it as defining the problem, which usually requires a > certain amount of abstraction, developing an algorithm which > provides a solution (more abstraction), and finally implementing > the algorithm in the machine (coding/programming). I think you > are placing too much emphasis on the last step. Perhaps, but CS has gone so abstraction-happy that I think it has wandered away from the basic tenet that computers are supposed to *do* something. > > So what? You can always learn languages, but you only have > > one shot at teaching someone to think like a programmer. > > You're loosing me here.. Why only one shot? Because I've found that people tend to stick with the first [dare I use the word] paradigm that they are introduced to. Everything else they learn will be compared against the first thing they learn, and if the first thing they learn is the step-by-step nature of the computer through a simple assembly language (they don't have to start with the sophisticated RISC chip on the planet), then they'll always have that safe, simple place to go back to when trying to understand more sophisticated concepts. > > What gets missed in all this is that *computers are simple*! > > Some (perhaps only a few) computers are simple. While computes are > designed around some basic (simple) concepts, start adding caches, > pipeline architectures, memory paging schemes, multiple register > sets, any of the various DMA capabilities or co-processor's which > provide for some parallelism, etc., and things get very complicated > very quick. There aren't many computers made these days that don't > employ most (and many more) of the above features. To effectively > program in assembly one must fully understand these architectural > issues, and to me that is one of the advantages of teaching a HLL > first as it allows the student to study and understand the development > and implementation of algorithms without being distracted by all the > low level architectural details. But all the caching, etc are all performance optimizations. That is irrelevent to the fact that they're still "load and execute" cycles in the simple case. You don't *have* to start them out with all this. They can learn just as well on a simple processor. > > Look at ol' Darin; if he didn't have enough brainpower left > > to focus on the algorithm at hand, what was he being confused > > by? > > Perhaps an attractive girl in the class :-). > > > I think it was by all the language and abstraction, > > I always though abstraction was used to avoid confusion by > elevating away from all the little low level details. Let's > you see the forest for the trees kind of thing. That is the theory, and that theory *has failed* based on my testing of newly graduated students. What I find interesting is that nobody is defending that newly graduated students are well prepared to program real programs. They just plain aren't. IMO languages such as C are far, far more difficult than assembly language. We've had a few posts during this discussion from people (including myself) who learned assembly early on as their primary language. They all felt that assembly was what crystallized the concept of computers in their mind. This shouldn't be that hard to believe; there aren't that many fundamental instructions in assembly, and nothing about the computer's nature is hidden (or abstracted) away. I'm not sure how this thought that "assembly is hard" came about. The only thing I can think of that so few people learn assembly nowadays that they think it is all black magic, and anything with mystery is assumed to be hard. > > which is not what programming is. > > Right, studing algorithms is not programming. Programming is > implementing algorithms. Agreed. If I had my way, I would give students one very simple program a day to implement in assembly. One after another, just to get them used to implementing an algorithm and *watching it run*. That latter is the most important when learning about the procedural nature of the computer. The most important thing they can learn is that there is nothing "magic" about the computer, it's all take an instruction, execute it, and move on. > > If he had been given a solid > > foundation of the simple nature of the computer, I think he would > > always have a "comfort zone" he could return to whenever he > > didn't understand something, because it's *always* implemented > > in the fundamental terms. > > Sorry, I just don't follow this reasoning. Well, look at OOP. This is another thing that has developed a mythical high level of difficult. What is OOP? It is the most simple concept on earth: Non-OOP: Execute operation on area of memory. OOP: Execute operation abstractly bound to an area of memory (AKA object). That is *all* of it. All of the rest of it (inheritence, etc) are all extensions of the fundamental theory of OOP that we are assigning a set of operations to an area of memory. Now granted, this could be considered an implementation of OOP, but so what? The point is that it's simple to understand, and from there you can on to the "grand generalizations". Now, how is OOP taught now? As far as I can see, they shower a dump-truck full of terms onto the students, and give them a whirlwind of abstractions. If they would focus on the reality of the implementation, we would see far fewer confused students. -- Tim Behrendsen (tim@airshields.com)