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=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a9b0810d3106d9b8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sat, 23 Apr 2011 11:42:51 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Fun with C References: <27cf3992-4132-4483-9110-adc7a089cd4a@e8g2000vbz.googlegroups.com> <3ccf18a2-ba10-42bc-aeab-9368749961fb@a11g2000pro.googlegroups.com> <4c2b6a58-e3b6-47da-95e0-64853be5c1f9@v11g2000prb.googlegroups.com> <86748003-860f-4729-ae26-55be1e58ac2b@d27g2000vbz.googlegroups.com> <4b5748dc-60fa-4cec-a317-054626e9a1ca@d19g2000prh.googlegroups.com> <1908th3tyz101.1f6c5w8t9mggy.dlg@40tude.net> <2118e788-7b3e-4d25-8d0f-5e60498e3a3b@cu4g2000vbb.googlegroups.com> <1hnl95prvrt6i$.1s675gncbjxsu$.dlg@40tude.net> <5d44db50-ceff-4f4d-8bc7-714f31fbca06@hd10g2000vbb.googlegroups.com> <1uthrsrabx8di$.8i74uk28axo0.dlg@40tude.net> In-Reply-To: <1uthrsrabx8di$.8i74uk28axo0.dlg@40tude.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <4db29f1b$0$6972$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 23 Apr 2011 11:42:51 CEST NNTP-Posting-Host: 356ff27d.newsspool4.arcor-online.net X-Trace: DXC=Q7ZkX:VlfWh9kIfcjg:0fd4IUKejVhe[0_KkfSTLd4R>1jnQZaHb X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:19005 Date: 2011-04-23T11:42:51+02:00 List-Id: On 4/23/11 9:23 AM, Dmitry A. Kazakov wrote: > On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salomão Helou Neto wrote: >> It is quite different with programming languages, as C is actually >> harder than Pascal, which is a great tool for teaching programming. > > In which sense is C harder? C is harder to learn from the ground up, as your first formalism, when measured by the number of non-intuitive and non-essential fundamental concepts that students must all understand in order to understand and use fundamental ideas of C. Notions are formed by distinction. Formally, each distinction D(n) means another fork in the "tree of rules" that a human mind must climb when trying to understand what's in the leaves. Humans have limited capacity when following decision trees in any case, not just when learning. More so when topics change along the way, as is the case with C, as explained below. Changing topics requires context switching---which is another distinction, thus f(D(n)) where f >= id. Some of C's concepts will draw students of C to syntax, others to operating systems, rather than focusing their attention on what should be a meaningful part of C program text, You might be so familiar with these distinct notions that you have forgotten that it once was difficult to keep them apart: you just saw these different pieces of C text but they all looked alike! Teaching C, then, by force is lacking modularization, in the following sense. For example, C offers distinctions that are non-essential when seen from the viewpoint of teaching programming subjects. Yet, they must be understood by the novices should they need to to write programs, which, I think, they usually do. - The statement and the block (of statements), and why and how to write them Typically, a distraction: Mostly offered when the subject is C's case distinction with if/else. When teaching conditionals, the focus should be on conditional execution. It will easily be on whether or not you need braces, and what the braces mean, and about what happens if you do or don't write "else" and then do or do not write braces, Blocks/statements confront novices with recursion at the level of grammars---when they are trying to understand if/else. But recursive definition is not an easy concept in itself. Observe students (in the general sense of the word "students", i.e. including pupils, or hobbyists) trying to understand mathematical induction, which requires recursive thought. It takes time and practice to become acquainted, and then induction at school was usually about natural numbers, not symbols, or about how you yourself write. Entire books like "The Little Functionaler" by Friedman / Felleisen are all about recursive definitions. They aren't easy. Intrinsically, recursive definitions are very close to circular definition, which, as you know, are vicious. - C's shorthands Too many things in one piece. Professional typists learn how to write first. Shouldn't students of C (as a first language) do this, too? (Typists need to learn the rules of written natural language first. Orthography. Then, I imagine, other practical things about writing.) Only then they, typists, learn how to use shorthands. C culture, I believe, does not call *x++ a shorthand. It calls it an idiom. It is even possible to argue that there is no shorthand at all because everything is (mostly) well defined and not an abbreviation. But this argument misses modularity of attention: one thing at a time. The above expression requires that the student isolates each single effect, and separates it from the others. Then thinks about implicit order and such. Why should beginners in programming become familiar with shorthands so very early? Note how C's shorthands are totally different from the definitions of "A Programming Language", i.e. APL languages. There, TTBOMK, every symbol has one (or two) well defined meaning(s) that do not "abbreviate". Or that could easily be written in another way, as is the case with C when, e.g. isolating the constituent parts of *x++. The sum of 1 .. 100 in APL is +/⍳100 which, in Python, reads reduce(plus, range(101)) where def plus(x, y): return x + y That is not to say that using "/" as reduction operator and not division might not be confusing at first. It is also not to say that ⍳ and the many other operator symbols won't take time to learn. But APL's mode of expression does not conflate so many things into one piece, and fewer of them are about syntax or precedence. - main and its (int argc, char* argv[]), that C shares with Java. You will see lengthy discussions of what these mean. And how they come to be, out of nowhere (known). Or how they could be passed to the program and that argv[0] is of a different quality than argv[n], n > 0. Similarly, about return 0; the teacher will have to explain why in a Boolean context 0 means false but in the context of operating systems, 0 means OK. And what this has to do with the C program in the first place. - file scope. An important feature of C---and its OS... You'll need to know operating system concepts including file system concepts before you can understand program text. What is it that warrants dragging the file systems into it? Why can't we understand the text of programs without the external notion of a file? K&R have no need to ship their book split suitably into files. They don't! I guess I could go on for some time... And I haven't mentioned pointers at all and how they relate to arrays and to the + operator, ... Is this a sense in which C is harder when you want to learn the fundamentals of programming?