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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, 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/08 Message-ID: <4ue7tm$onn@solutions.solon.com>#1/1 X-Deja-AN: 173034247 references: <4uaqqg$203@mulga.cs.mu.OZ.AU> <01bb8536$892ee260$87ee6fce@timpent.airshields.com> <4ud8oo$61t@solutions.solon.com> <01bb8567$4adddbc0$87ee6fce@timpent.airshields.com> 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-08T00:00:00+00:00 List-Id: In article <01bb8567$4adddbc0$87ee6fce@timpent.airshields.com>, Tim Behrendsen wrote: >Peter Seebach wrote in article ><4ud8oo$61t@solutions.solon.com>... >> Which is exactly what will happen if they code them in assembly; they >> can't possibly be learning how algorithms are created if they start with >> implementing them in a low level language. Algorithms are generally >> written in natural languages, and written on napkins. >What? I guess before HLLs nobody "possibly" learned anything. Probably not. We have *no* evidence that people learned or comprehended *any* algorithms before we developed HLL's. The one I use for more than 90% of my discussion and analysis of algorithms is called "English", though this is arguably a misnomer, as I'm not. >I don't know about you, but I think about algorithms in terms of >data flow and manipulation. HLLs or Assembly don't enter into >either. I think about them in terms of descriptions of rules for behavior. Cantor's diagonal proof is an algorithm. It's trivially unimplementable; however, it's a brilliant algorithm for generating a result from an input, despite the fact that neither the input nor the result could possibly be stored anywhere. >> The details of which bytes move where are *not* part of the algorithm >> itself. >What What? That's what algorithms *are*! What are algorithms >if they aren't black boxes that describe a particular output for >a particular input? I don't know about your I/O, but mine are >in bytes. Exactly. You're thinking of the *implementation*. When you say "swap a and b", it doesn't *MATTER*, in terms of what swapping does, whether this is implemented by 3 xor's, by 3 assigns with a temporary, or by leaving the values where they are and swapping the names of a and b. >I agree that I would rather have the student experiment with >*anything* rather than just crank out homework assignments with >no thought involved. *stunned silence* We agree on something? Someone say the H word, this thread is nearly gone. >We disagree however on the difficulty of assembly. I think it >is *much* easier, albeit more tedious, than a HLL. Huh. Well, see, you're probably comfortable with it. I can't *imagine* being able to keep track of all of that. >> Further, learning about stacks is bad way to learn about computing; >stacks are >> not a universal implementation of computers. Students who learn about >stacks >> early on may start assuming that that's somehow a basic truth of >computing. >> They may do things like assert that the addresses of local variables in >one >> function are always lower than the addresses of local variables in a >function >> "above" it on the stack. Or maybe that should be higher; both kinds >exist. >But that contradicts the C standard. What does? C can be implemented on stack-free machines. Remember, there's no guarantee that the relationals (lt, gt, lte, gte) are meaningful *at all* to pointers not into (or just past the end of) a single object. >You're saying that total >ignorance is better than partial ignorance, and I might >even agree with that. But I don't think it's reasonable to >argue that total ignorance is better than adequate knowledge. No. I just have *very* high standards for the adequate knowledge that makes it safe for a programmer in a high level language to have beliefs about an alleged understanding of "what really happens". >In fact, I might even argue it's better to expose those >mistakes early on, rather than graduate them completely innocent >of these issues, and then when they need to do some assembly, >they pick up the bad habits. If they've been taught well, they'll see how the operations they already understand are happening, rather than use the assembly to fill in holes in an incomplete understanding. -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.