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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public From: seebs@solutions.solon.com (Peter Seebach) Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/04 Message-ID: <4u1g29$hc0@solutions.solon.com> X-Deja-AN: 171951245 references: <01bb8023$4bfe7a80$96ee6fcf@timhome2> <4u19gq$f1g@solutions.solon.com> <320433CE.6D5A@online.no> organization: Usenet Fact Police (Undercover) reply-to: seebs@solon.com newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-04T00:00:00+00:00 List-Id: In article <320433CE.6D5A@online.no>, Alf P. Steinbach wrote: >The question had nothing whatsoever with the benefits of knowing hex, but >with the absence of knowledge of such a fundamental matter. Knowing that >a car needs gasoline won't buy you anything with respect to driving a >car (when this matter does not make itself important, as the matter of >hex numbers could make itself important, e.g. while designing iostreams). >However, I wouldn't entrust a car to a person not knowing about gasoline. Hex isn't a part of the operation of a computer; it's a possible interface we can use, but we don't have to. I would trust a car to someone who hadn't seen automatic locks, because they don't generally need to know. >I have a really hard time understanding why students should *not* learn >about the physical machine. Because it will incline them to assume that the physical machine is a constant. Beginners are constantly writing programs which assume that you can treat a pointer to int as a pointer to char, and read the bottom 8 bits of the integer out of it. >If they're not able to grasp a simple thing >like hex and binary, then they most certainly will not be able to grasp >abstract datatypes (design, implementation and usage of). Probably. But similarly, no student who can't learn Chinese, Spanish, or German is likely to be able to comprehend abstract data types. This is *not* sufficient reason to require students to learn these languages in the CS major. >Not for lack >of the fundamentals -- as you've pointed out, it is possible to reason >at any given level of abstraction -- but for lack of brains. Any >reasonably intelligent student will understand hex & bin after just a >few minutes of explanation, and will understand conversion methods >after just an hour so of carrying out exercises. If not, then the >person has nothing whatsoever to do studying C.Sc. or programming. True. I would actually be inclined to think that people should be exposed to hex and binary, because these are, themselves, useful *abstractions*. Especially hex. Even binary is a useful abstraction. Thinking about bits is not necessarily bad, and may be helpful. Believing you know where they are is downright dangerous. >So, the cost of learning the fundamentals is very low, while the payoff >is great. It's a simple & fundamental principle of teaching and learning: >build up from the known and concrete, instead of down from airy >abstractions. And I expect you do the same (I do!): when confronted with >some problem which seems too abstract and complicated, I always find it >beneficial to consider a simplified and more concrete version first. Uhm. I prefer to think of simplified and more abstract versions. But then, I was raised by mathemeticians; I consider the physical world to be a special case. :) >Leaving out the fundamentals simply means the student will fill the >vacuum at the bottom with something out of fantasy and intuition. I >can't see any good reason -- or even any reason at all -- for >actively suppressing / leaving out this information. I guess, I distinguish between the fundementals and *any* form of assembly. The fundementals that are worth teaching are the fundementals of *all* machines. I think a study of a Turing machine would be a great thing for students. You could make a turing sim for them. (Obviously, it would only simulate finite machines...) But studying a *specific* architecture, or even two, is very dangerous to young programmers. Young minds are impressionable, and people find it much harder to unlearn than to learn. It took me *years* to get out of some of my early bad habits. A lot of programmers used to habitually use a null pointer as a shortcut for "" for string functions; you'd see if (strcmp(s, 0)) used like if (strcmp(s, "")) because it worked on some machines. For a concrete example, about a year ago someone was writing in about the famed "null pointer assignment" message Borland C would emit after his programs ran. He didn't want to know what caused it; he *knew* what caused it. He wanted to turn it off. See, he'd discovered that if (strcmp(gets(NULL), "hello")) let him save a variable. Students should be kept *away* from the kind of mindset that makes this seem reasonable. That feeling that, now that I know what's happening, I can take advantage of it - heady, but ultimately dangerous. Many books on C encourage beginners to experiment with expressions like a[i] = ++i; and "see what happens". The exercise is generally like "think about this. What do you think will happen? Write a test program to try it. See what really happens. What does this tell you about ..." Ugh! (For those who don't know: The expression is completely devoid of meaning in standard C. There are two obvious interpretations, but in fact, it's not merely a bit odd, but *completely undefined*. A compiler may end up corrupting memory if you pull tricks like this.) (And no, no combination of ()'s, or moving the ++ around, will make that expression valid or meaningful C.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs Unix/C Wizard - send mail for help, or send money for consulting! The *other* C FAQ, the hacker FAQ, et al. See web page above. Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.