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: 10db24,4cf070091283b555 X-Google-Attributes: gid10db24,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public From: "Tim Behrendsen" Subject: Re: What's the best language to learn? [was Re: Should I learn C or Pascal?] Date: 1996/08/14 Message-ID: <01bb8a24$88d46fe0$87ee6fce@timpent.airshields.com> X-Deja-AN: 174228999 references: <4u7hi6$s2b@nntp.seflin.lib.fl.us> <01bb8950$2c8dcc60$87ee6fce@timpent.airshields.com> <4urmvu$dfp@solutions.solon.com> <01bb89f1$31be4f60$87ee6fce@timpent.airshields.com> <4ut1sv$ngv@solutions.solon.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-14T00:00:00+00:00 List-Id: Peter Seebach wrote in article <4ut1sv$ngv@solutions.solon.com>... > In article <01bb89f1$31be4f60$87ee6fce@timpent.airshields.com>, > Tim Behrendsen wrote: > >>I am not sure I buy your interpretation. Thinking like a programmer is > >>largely a matter of learning to find useful abstractions. How do you write > >>code to test whether a number is even? Well, you do it by looking at what > >>evenness is, and looking for what characteristics it has that would help you. > > >Solving a problem is not an > >"abstraction" question, it's a question of breaking it down > >into fundamental steps of data transformations. > > No, that's implementing a solution. Different stage. Consider Cantor's > diagonal. A perfectly good algorithm which you *cannot* implement. > > >Testing a > >number as even is transforming a number into a bit based on > >its evenness property. > > But how you do that has *NOTHING* to do with the question of whether or not > you have defined a solution to the problem. > > Whether or not you can do that will answer the question "is my solution going > to work on existing machines". But if you can't, you still have a solution, > it's just not one which meets your requirements. All of that is very interesting in a theoretical sense. But if we're talking about educating a student, you have to start somewhere, and to just hit them full-bore with "abstraction of algorithm" theory, I think you're going to lose of lot of them, *and we are!* It seems to me that that focusing on the more practical aspects of implementation gives them a solid foundation to build the rest of it on, including building up of the concepts of languages and why their valuable. > >So what? You can always learn languages, but you only have > >one shot at teaching someone to think like a programmer. > > Nonsense. People learn new things all the time. I have to disagree; where somebody starts forms the basis of what they compare all the rest of new knowledge to. Once the patterns are set, it's very difficult to re-center someone into another frame of reference. > >*Programming is not languages*. Programming is breaking problems > >down into fundamental steps to achieve a desired result. The > >way the steps are described is not relevent to the general question > >of a solution. When we are talking about teaching a student, > >the less extraneous issues such as languages and the more > >experience we can given them of the fundamental procedural > >nature of the computer, the better. > > I don't really think we are going to convince each other. I believe that > the "fundemental procedural nature of the computer" may not be a permanent > thing. I'd rather teach them to think in the general terms, and see that > procedural nature as just one more current limitation, like computers which > have only 2 MB of RAM. This will better prepare them for techniques that > depend on *not* thinking of the computer as procedural. Look at Icon... > Neat language, but if you think in terms of normal procedural code, it will > never work for you. I think this like a theoretical physicist arguing with an experimental physicist. The theoretician doesn't care about practical results, and the experimental guy sneers at theories that have nothing to do with the real world. :) I am very much a real-world guy, and computers are very much a real-world device. In fact, I think that's where at least some of the problem is; Computer Scientists have been looked down upon by the self-proclaimed "real sciences" for so long (famous joke: "Is Computer Science?" HA HA says the physicicist), that they are trying too hard to make themselves into a "real" science. You only have to look at a few issues of CACM to see this in action; the amount of fancy terminology that's invoked is just amazing. Other sciences have this problem, but CS just seems to go out of their way to do it. > >> You keep using assembly as an example of what the basics of computing are > >> like. Please explain how this is a better model *of the problem domain* > >> than lisp or C. Why should students try to learn machine-level and > >> program-level at the same time? If you want them to start with > >> architectures, don't start them on algorithms, start them on trivial data > >> manipulation in assembly. > > >It's a better model because it's real. C and all languages are > >artificial constructions intended for the maintainance of large > >projects. > > So? They're just as real. *computers* are artificial constructions. But they're not. They are abstractions of machine code, which is what's really execute. Granted, in a strict sense assembly is an abstraction of machine code, but we've been over this ground in another thread. > >What gets missed in all this is that *computers are simple*! > >All they do in the fundamental sense is take a very simple > >instruction, execute it, and repeat very, very fast. If this > >is presented the first day, the student can't help but realize > >the simple nature of the computer, and it loses its mystery. > > I think you underestimate the idiocy of many college students. :) > > Still, why wouldn't, say, scheme, work for this? You can make a *VERY* > simple system - much simpler than assembly for any platform - and show > the students how everything is built on it. > > If all you want to do is show them that the computer is simple, teach them > in Turing machine assembly. :) Well, the thing is that real honest-to-goodness assembly is just not that difficult to learn, and that has built-in practical aspects to it. > >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? I think it was by all the language and abstraction, which > >is not what programming is. > > But it *is* what programming is. Programming is turning a problem > description into a solution description. The implementation is merely > coding. Turning a solution description into a program can be done > by trained monkeys. (Or, emprically, compilers.) But the solution implementation is the "proof" of functionality. As Abrash says in his finger, "I want to live in theory. Everything works in theory." (I like that quote; don't know where he got it). A student could describe everything on paper, but nothing cements it in someone's mind like running the program and seeing the output. Not to mention see it fail, and trying to understand why. > >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. > > But why insist on making the comfort zone so far from the nature of the > task? > > This is like teaching people to drive by starting them out with metallurgy. > Sure, it's fundemental to the operation of the car, *but they don't need to > know it*. It can help, but it's not a good basis for an understanding at > the right level. No, I disagree. It would be like teaching people to drive by starting out teach them mechanics, and I'm not sure that wouldn't be a bad idea. :) Metallurgy would be the equivalent of teach programmers how to melt the silicon, which even *I* think is a little excessive... :) -- Tim Behrendsen (tim@airshields.com)