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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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: 103376,97188312486d4578 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,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/07 Message-ID: <4uah1k$b2o@solutions.solon.com> X-Deja-AN: 172722951 references: <31FBC584.4188@ivic.qc.ca> <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com> <4u89c4$p7p@solutions.solon.com> <01bb83f5$923391e0$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-07T00:00:00+00:00 List-Id: 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. 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. >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. A student who has memorized the multiplication table for x=1..10, y=1..20, but doesn't know that 5*12 and 12*5 are the same thing, has learned nothing. Learning details and implementation does not help except in so far as they are good examples. >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. Ahh, like C. :) But even then, students should not be thinking in terms of tables of bytes which they manipulate, but in terms of objects which they manipulate. >The problem is that we *can't* think purely abstractly, >otherwise we end up with slow crap code. 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. I've heard that 50% of the articles Byte gets are marginal optimizations to bubblesort. People with a good understanding of what operations they are using to express the algorithm are finding real improvements, frequently 40%. Unfortunately, it's still an N^2 algorithm. The code bloat problem is almost invariably a result of an ill-considered abstraction. Someone comes up with a first approximation of a solution (bubblesort, for the sorting problem). Then management sees that it appears to run, and ships it. Poof! Time that should have been spent writing it correctly, taking advantage of the mistakes made in the prototype, turns into time spent trying desparately to get a fundementally flawed product to market, and keep it running. No one ever gets around to doing a good job of the initial design. >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. >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. -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.