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: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,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/08 Message-ID: <01bb853b$ca4c8e00$87ee6fce@timpent.airshields.com> X-Deja-AN: 172981661 references: <31FBC584.4188@ivic.qc.ca> <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com> <4u89c4$p7p@solutions.solon.com> <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> <4uah1k$b2o@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-08T00:00:00+00:00 List-Id: Peter Seebach wrote in article <4uah1k$b2o@solutions.solon.com>... > In article <01bb83f5$923391e0$87ee6fce@timpent.airshields.com>, > Tim Behrendsen wrote: > >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. > > But your concept of what the "fundemental operations" are is completely tied > up in how specific hardware you've seen operates. Algorithms exist in terms > of abstract operations, not moves and branches. Please name me the hardware that does not use moves and branches. > Something like CWEB might be a good language in which to learn algorithms. > Scheme might too. > > Let's look at a specific algorithm; the infamous gcd(x, y). > > In C, we write > > int > gcd(int x, int y) { > if (y == 0) > return x; > return gcd(y, (x % y)); > } > > or something similar. > > What's important here is not any theories people may have about where the x > and y are stored, or how a stack works, but the concept that you can define an > algorithm in terms of a previous case. Learning that the if() may be > implemented with "a branch" does not help the student understand how the > *algorithm* works, it helps the student understand how the *compiler* works. > These are distinct things. This is an interesting case, because it is somewhat inefficently implemented. If you're interested in speed, you would do... int gcd(int x, int y) { int z; while (y != 0) z = y; y = x % y; x = z; return(y); } Using my AIX compiler, I get a nominal improvement of about 10%, mostly because the speed of the modulo is much slower than the inefficiency of recursion. My point is that how does a C programmer know that recursive implementations are somewhat inefficient? Recently the C/C++ Users Journal had a little bite-sized article about a general looping algorithm, where you could specify the number of nested loops in a dynamic fashion. It was implemented recursively. I wrote a letter back reimplementing the algorithm non-recursively, and got like a 40% increase in speed. These sorts of issues are where code bloat comes from, and it comes from naive implementations of "valid C syntax". > >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. > > But it also prevents them from learning the abstraction, and truly > understanding the *principle* of the solution. If the C abstraction is good, more abstraction must be better then. How about we teach everything in APL, where we can *really* abstract away the details? No data types, full array operations. Talk about easy quicksort! I can write it in one line of code using a handful of operations (my APL is *really* rusty, so I can't give the example). The student learns Quicksort, there is no question about it. But what have they *really* learned? [snip] > Nonsense. A well designed and considered abstraction will generally lend > itself to an efficient and elegant implementation. An ill-considered > abstraction will spend more time on cruft than it will on solving the problem. Like recursive algorithms? [snip] > >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. > > No, but I have never seen a good algorithm that didn't lend itself to elegant > and efficient implementation. If we do decent designs first, and worry about > implementation second, we will find the implementation to be pleasant, easy, > and efficient. Well, now you have (see above) :) > >At least not my world, where I have to pack as many users > >as possible onto one CPU. > > Compare the *efficiency* for this purpose of Unix, which is designed, and > MS-DOS, which has had millions of dollars thrown at making it as efficient as > possible. Compare also things like NT and Berkeley Unix. You *have* to do > your design in theoretical terms before you think about implementation, or you > end up with a system where 32 megs is seen as too small to run multiple users, > and you need a third party add-on to do it anyway. > > The Berkeley people have thrown out more code than the system has in it. The > algorithms are designed based on the *algorithmic* weaknesses of previous > designs. Hardware efficiency is evaluated only after you've found a good > algorithm. And they get excellent performance. Agreed; but there are general principles that can be learned across *all* architectures. See follow up to Dan Pop post for example of this. -- Tim Behrendsen (tim@airshields.com)