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.8 required=5.0 tests=BAYES_00,INVALID_MSGID, 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/09/04 Message-ID: <01bb9a1e$24c669e0$32ee6fcf@timhome2>#1/1 X-Deja-AN: 178357196 references: <01bb8df1$2e19d420$87ee6fce@timpent.airshields.com> <4vcac4$gm6@zeus.orl.mmc.com> <01bb8f19$9a89d820$32ee6fce@timhome2> <841797763snz@genesis.demon.co.uk> 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-09-04T00:00:00+00:00 List-Id: Lawrence Kirby wrote in article <841797763snz@genesis.demon.co.uk>... > In article <01bb8f19$9a89d820$32ee6fce@timhome2> > tim@airshields.com "Tim Behrendsen" writes: > > >Bob Gilbert wrote in article > ><4vcac4$gm6@zeus.orl.mmc.com>... > > ... > > >> A very procedural point of view. Many of the proponents of object > >> oriented design might have a problem with this view, and demonstrates > >> my point about allowing the details of implementation to obscure the > >> higher level problem solving process. > > > >There is no other view than the procedural view. > > Some functional language programmers might take issue with that > statement. Prologgers may have a thought or two also. What I mean by that is, for work to get done, the computer must perform transformations of data over time. You can call that an implementation detail if you want, but there simply is no such thing as "instantaneous" algorithms. You can look at a mathematical proof as existing without procedures, in the sense that it simply "exists", as a statement of truth, but algorithms are different. They are, by their nature, a process, and processes require a time axis. Now, there are certain rule-based languages, but these describe a process just like any other language. The different is, rather than describe the process as a set of linear paths, it describes them in a way like a pachinko machine. You have a set of pins, and when you drop a marble at a certain angle, it bounces along the rules defined by the pins, and comes out a certain position. I haven't described a linear procedure for every angle, but I have still defined the process by which data (the marble) flows through the algorithm (the pins). In other words, the purpose of the rules is data flowing through them. > ... > > >How can someone implement *any* sort in assembly language, > >and "learn it but not really understand it"? To implement it, > >you have to do it in great detail, and you simply can't do the > >"push and prod until it works" approach to programming, which > >is what I think a lot of students do. > > Example: once I had an assignment to implement a sort on IBM 360 assembler. > What I learnt to do was convert a sequence of individual operations into > assembler instructions. It didn't teach me a thing about the sort algorithm > (which was merge sort). I find it difficult to believe that you implemented a merge sort in assembly without understanding the merge sort algorithm. > I can't imagine a worse way of teaching an algorithm than using assembly. > It is essential to separate the algorithm from the implementation and > assembly ties you up in knots with implementation specific details > especially when you are just learning 'computing'. Once you've learnt > an algorithm it makes a lot of sense to practice that algorithm by > writing implementations, even in assembly, but you should understand the > algorithm to a reasonable extent *before* attempting that. On the contrary, I think it is essential to focus on the implementation in as much detail as possible. You can pack as much algorithm theory into a student as you want, but they don't really "get it" until they type in a program, and experience it not working, figuring out why, fixing it, and repeating the process until they see the expected output. I think you take how to "think like a programmer" for granted so much that you don't understand that it doesn't come naturally to the average person. The procedural nature of the computer is something to be learned, just like algorithms. -- Tim Behrendsen (tim@airshields.com)