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: 10db24,4cf070091283b555 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public From: Clayton Weaver Subject: Re: What's the best language to learn? [was Re: Should I learn C or Pascal?] Date: 1996/08/23 Message-ID: X-Deja-AN: 176074040 sender: news@eskimo.com (News User Id) x-nntp-posting-host: eskimo.com references: <4v26j4$hkg@news.csus.edu> <01bb8d2f$351b9500$32ee6fce@timhome2> <4vdon9$8nt@news1.mnsinc.com> content-type: TEXT/PLAIN; charset=US-ASCII organization: Eskimo North (206) For-Ever mime-version: 1.0 reply-to: Clayton Weaver newsgroups: comp.edu,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.unix.programmer originator: cgweav@eskimo.com Date: 1996-08-23T00:00:00+00:00 List-Id: On 21 Aug 1996, Szu-Wen Huang wrote: > Tim Behrendsen (tim@airshields.com) wrote: > : Hmmm... moving a deck of cards around to learn a sorting > : technique. Reducing the problem to a very low-level set of > : movement operations to help in understanding procedurally > : what the computer is doing. Naaah, couldn't work. Much easier > : to focus on the high-level C abstraction of the sorting > : algorithm. ;-> > Lofty, ungraspable concepts like: > void swap(int *a, int *b) > { > int c = *a; > > *b = *a; > *a = c; > } > ... > swap(&a, &b); > ... The cards are more obvious in cs101. You have to learn C to demo the algorithm in C. At that point you are asking students to memorize C syntax, and only some will make the leap to understanding it before seeing algorithmic examples that don't depend on C's particular symbols, which seem quite obscure at first glance even to a Basic programmer. > ? swap(), by the way, is a primitive for just about every algorithms > text I've ever read. Does knowing the computer must: > LOAD r1, a > ADD something_else_totally_unrelated > LOAD r2, b > INC some_counter_from_another_place > STOR r1, b > INC that_same_counter_but_we_just_need_to_fill_the_slot > STOR r2, a > in order to swap two integers aid in the understanding of swap()? > I agree that we need to break an algorithm down to primitives, but > are you actually saying swap(), for instance, isn't primitive enough? This interleaved register example is actually good. I agree with Elmore that beginning education should include assembly. In the above example, you would map out the algorithm in assembly statements as if the register had a single pipeline, to show the algorithm in register terms, and then show the interleave to show how you (or more likely a compiler) arranges code to keep more than one pipeline full. I would take it a bit further than a z80 or 6809, however. Use *more than one* 32-bit processor with protected address spaces, and teach the assembly and some common languages (C; C++; Ada; Basic; Modula-2, Modula-3, or Oberon; Smalltalk; Forth) in *parallel*. Step 2 can be functional languages and logic languages (Prolog, Lisp), still showing how the same code looks in assembler, and perhaps how it looks in each of the languages covered in the previous step. Step 3 is 4gl languages, interpreted prototyping languages, very high level tools like actor languages. Step 4 is specialization, advanced study in whichever of the above looked most interesting or most marketable, depending on the student. So you get a comparative look at cisc, risc, and maybe a hybrid processor, a comprehension of data flow in assembly terms for each architecture, an exposure to the syntax of procedural, OO, logic, functional, and 4gl languages, an insight into how the typical syntax and essential semantics of each actually gets implemented on the hardware, some practical experience in a variety of each type of language in current everyday use in academia and in the programming job market, and a comprehension of algorithms independent of any particular architecture, language type paradigm, or particular language syntax. And the summer after they graduate, you will find any that didn't get hired on the day after graduation to do something else programming in C on linux. Why? Free compiler on a free multi-tasking os that runs on cheap hardware that they already own with a complete set of development tools. Ok, maybe they'll actually use Gnat, Gnu Smalltalk, the Prolog frontend, g++, Oberon for linux, f2c, Modula-3 or some other gcc frontend (or tcl/tk, perl, or java). I can't speak for Gnat, but these others all have some bugs, while the C and libc bugs get rooted out right away by the linux system programmers. So gcc C ends up the most practical choice for most of these programmers, because 99 times out of a 100 you can pin down a bug to your code and not to the compiler or runtime library (i.e, one place to check instead of 3 to determine the cause of an unexpected result). The reality of C and gcc has nothing to do with the theoretical benefits of either educational curricula choices or of language design optimization for programmer convenience. Even if some other language would be more convenient for expressing the solution to a particular programming problem, "if you can do it in C you can do it for free." It will be a boon to type-safe programming if Gnat develops reliability comparable to Gnu C. Regards, Clayton Weaver Transparent Words cgweav@eskimo.com (Seattle) http://www.eskimo.com/~cgweav/