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: 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: "Tim Behrendsen" Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/07 Message-ID: <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> X-Deja-AN: 172566716 references: <31FBC584.4188@ivic.qc.ca> <01bb8342$88cc6f40$32ee6fcf@timhome2> <4u7grn$eb0@news1.mnsinc.com> <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com> <4u89c4$p7p@solutions.solon.com> content-type: text/plain; charset=ISO-8859-1 organization: A-SIS mime-version: 1.0 newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-07T00:00:00+00:00 List-Id: Peter Seebach wrote in article <4u89c4$p7p@solutions.solon.com>... > In article <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com>, > Tim Behrendsen wrote: > >Let me bring it back full-circle where we started. The reason > >I mention assembly in the first place was the number of graduates > >coming to me for a job that were failing the test I give > >*abysmally*, particularly in the areas of creating an algorithm > >for a problem they've never seen before, and doing logical > >operations. > > These are fundementally abstract operations. Generalization is the core of > algorithm design; you must abstract what the problem is, what a solution looks > like, and what their relationship is. Logic is entirely an abstract beast. > > >I chalked this up to the lack of the fundamentals being taught, > >and the students having their brains filled up so much with > >abstractions that they don't understand how to solve problems > >anymore. > > The entire concept of a solution to a problem, rather than the answer to a > question, is a matter of abstraction. I agree; my point is that I think the student learns more if they are thinking purely in terms of fundamental operations (which are still abstractions above the raw hardware components), rather than layers and layers of syntax that hide the essential essence of what the computer is doing. The people I saw could quote me book definitions of C syntax. But they had very little knowledge of what it really meant, and how to use it. If programming is reduced to fundamentals of move, arithmetic, test, branch, etc it prevents the student from leaning on the abstraction rather than truly understanding the solution to the problem. In other words, if they can express it in the above terms, you *know* they understand the solution. > >This is why I think assembly is the better way to teach > >algorithms; it's just you and the algorithm. It forces them > >to really think about the problem, because they don't have any > >"training wheels" to protect them from the problem. > > But the training wheels protect them, not from the problem, but from the > implementation. > > Consider string searching. > > An *algorithm* for searching strings has nothing to do with whether you can > use a postdecrement or postincrement addressing mode. > > An assembly program for doing so may well *have to* consider these issues. True; there is assembly syntax that could be considered irrelevent to the central issues. I really don't see that as a big problem compared to the much larger problem of the brain-damaged students that are asking me for jobs. Perhaps the solution is a middle ground one; rather than "real" assembly for students, maybe what they need is a "MIX" kind of thing where it is reduced to fundamental elements, an assembly abstraction if you will. That way, "dangerous" concepts such as post-increment, etc. can be safely hidden away, but we can still give allow them to think in pure data manipulation terms. > >Whatever were doing now is *not working*, let me tell you. > > What we're doing now is exactly what we do in every other field; we give them > lists of desired answers. Most math programs would be just as bad if math > were as high paying and easy to get a job in as CS. > > I've seen *very* few good teachers in any field, especially ones which require > abstraction. > > The problem I've seen is that students think too much about how to implement, > and not enough about the abstract design. I have this problem, even. I spend > way too much time, during designs, thinking about what the data type will need > to look like, rather than what it will need to be able to do. This frequently > turns into extra time about halfway through the implementation, because I > didn't think enough about the *abstract* part of the problem. > > I haven't even thought about memory layouts, and I'm *still* too specific and > not abstract enough. The problem is that we *can't* think purely abstractly, otherwise we end up with slow crap code. It is simply not possible to ignore the way code is structured, and completely depend on the compiler to save us. That is just not the real world. At least not my world, where I have to pack as many users as possible onto one CPU. -- Tim Behrendsen (tim@airshields.com)