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 autolearn=ham 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: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public From: huang@mnsinc.com (Szu-Wen Huang) Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/09 Message-ID: <4ue5l3$frr@news1.mnsinc.com> X-Deja-AN: 173030632 distribution: inet references: <01bb8565$3ea962e0$87ee6fce@timpent.airshields.com> followup-to: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada organization: Monumental Network Systems newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-09T00:00:00+00:00 List-Id: Tim Behrendsen (tim@airshields.com) wrote: : That's fine, anybody can look something up in a book. I want : people working for me that can *think*, not just look it : up in the book. Otherwise, how do you know when a : particular algorithm is appropriate for a particular problem? Because I know the range of performance I can expect from a class of algorithms, expressed in time complexities. In fact, I also know what problems have polynomial-time solutions, and what *don't*. None of the above comes from my expert knowledge of assembly. Are you saying if I don't know assembly I can't pick an algorithm? : When doing large projects, it's not just a matter of reaching : into the bag o' algorithms and pulling it out. Really? When you want a sorting algorithm, I suppose you spend a few weeks thinking about it first? When you want compression, surely you meditate in the mountains? The industry has many many solved problems, some free, some not free. It *is*, as a matter of fact, just a matter of knowing where to look - and when to stop looking. Again, none of these have to do with assembly language. : It takes : careful analysis, and the best way a student learns *that* : is to really go through the process of taking a problem and : seeing how the problem translates into data movement, etc. Data movement, sir, is not restricted to assembly language. Assembly language, in fact, impedes the understanding of data movement because of all the extraneous things that have to be done to make the program work. : What we're doing now is *sure* not working. Because some students graduate without understanding algorithm complexity, not because they graduate without learning assembly language. : > Uhm, theoretically. Somebody with only in-depth knowledge of run- : > length encoding is not very likely to come up spontaneously with : > Huffman or arithmetic compression. : Perhaps not "spontaneously", but you have them thinking about : compression issues. "Thinking" is the key word, not just : memorizing an algorithm that they will forget after the final. I never said anything about a student that forgot everything after an exam. I said, it is better to have *general* knowledge than specific knowledge in intermediate levels. My student would've remembered that he was taught Huffman, which compressed better than RLE. Now, how Huffman works he may not immediately remember, but he would know where to look it up, and that's all he needs. This student with general knowledge can use books to his advantage, while your RLE expert sits in a cubicle and tries to reinvent the wheel. : > Assuming the student doesn't have a deadline and all day to think for : > 40 years. Many algorithms are obvious. Insertion sort, for example, : > is what a human would do (if somewhat parallelized). Quicksort, on : > the other hand, is nowhere near intuitive. Be realistic. : I'm not saying everyone *does* derive all of it, but the : best programmers, even if they can't remember the exact : details of an algorithm, can rederive it by thinking : about the problem. Of course, but we're not talking about the best programmers. We're talking about beginners and intermediates. The best programmers are probably experts in several related fields - the language, the platform, the algorithms, and the tools. Now, without comprehensive knowledge, it is better to be general than specific. : And I wouldn't say Quicksort is not intuitive, it is a logical : extension of recursive tree algorithms. Not obvious, but : not unintuitive. Lempel-Ziv or even the 'diff' algorithm : I might agree. How long did it take you to come up with Quicksort armed with the knowledge from implementing bubblesort in assembly? : Not only am I asserting, let me say in the strongest possible : terms that students are being graduated with CS degrees : that are unable to think. I don't disagree. In fact, I'll give you an example. My students in introductory Pascal courses started programming with Turbo Pascal. If you learned programming earlier, you'll probably be the kind that thinks hard about a problem, goes "eureka" one day in the shower, and then sits down to type. This generation, on the other hand, sits right down and types away and turns in some truly embarrassing solutions to simple problems. I tend to blame the TV. Point, however, is on my side. The students were given tools they could not use properly. The debugger that was so convenient for an expert actually destroyed their will to think about a problem ahead of implementation. Now they just hack together some code and trace through it until they get it right. Assembly will have the same ills. Firstly, they distract the students and force them to implementation details specific to the platform, and secondly is simply too powerful for beginners to use properly. : I hate to keep harping on my : test, but on one particular hiring cycle, out of 50 applicants : 49 were unable to create an algorithm for a problem they had : not seen before. I hired the one guy, and he has been a great : success. I gave the Vernier encoding as a hands-on exam. You are of course familiar with the: A B C D E F G ... Z A A B C D E F G ... Z B B C D E F G H ... A C C D E F G H I ... B . Z Z A B C D E F ... Y table, wherein you ask for a plaintext string and a cipher key, then index the row with plaintext and the column with the key to get the ciphertext. Trivial? None of the ten or so students considered the fact that the table can be expressed as a formula. *All* of them stored this table somewhere. One particularly creative one even read the table from a textfile. I don't think this phenomenon was due to the fact that they didn't know assembly. : > Fundamental understanding of RLE has little, if not nothing, to do : > with Huffman compression. Fundamental understanding of quicksort : > has nothing to do with heapsort either. : That is simply not true. Taking compression; if have done : thorough analysis of RLE, and understand the issues involved : in finding patterns (sequences of common bytes) and replacing : them with another encoded value, that is the basis for : more complex pattern matching/replacement. If the student : is thinking, they will see that a large majority of the : input data is not being compressed, and this leads to wondering : if there is a general way to find more complex patterns in the : data. Even if what you say is true (it's difficult, at best), I still don't see how this student can be a more effective engineer than one who has vague knowledge of both, but distinctly know that something *is* better than RLE. : > : > Teach a man an algorithm and some I/O routines to enter the input : > : > and display the output, then some routines to set up the stack, : > : > then some routines to initialize data, : > : Yes, and wouldn't they truly understand I/O routines and stacks : > : after that? : > They would, but would they understand the algorithm? : Sure; how much time do you think it takes to make one library : call to output data? Push the parameters on the stack and : call 'printf'. Big deal. Then why not use C instead? Realize that you are the one trying to prove that assembly is better for teaching algorithms. If you're going to use library functions extensively, what's wrong with C then? : > It doesn't matter. You are burdening beginners with details that : > you could've avoided by using an HLL. My school was contemplating : > teaching one freshman class Prolog as a first language and another : > Pascal, then switch in their second year to observe which was more : > effective. It's too bad the experiment has practical problems, : > because it would be interesting to see if it's easier for a "recursive- : > minded" student to study iteration or the reverse. In any case, : > you want to train students in problem solving, not why the OS requires : > value X in register Y. : I think you exaggerate the complexity of assembly. This is like : saying "we want to train students in problem solving, not where : the commas go in the syntax." Where the commas go is important, because it is a prerequisite to a correct solution. If we one day can build computer languages that can understand humans better, perhaps we will not care where we put commas. Assembly is not complex per se, but is more complex than HLLs to learn and read, and as such is counterproductive when used as a tool to teach algorithms. You still haven't proven why assembly is necessary, or at least better.