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: 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: wheeler@aphrodite.csed.ida.org (David Wheeler) Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/02 Message-ID: <4ttdlg$2pr@news.ida.org> X-Deja-AN: 171597317 references: <01bb73e3.1c6a0060$6bf467ce@dave.iceslimited.com> <1996Jul20.124025.122789@kuhub.cc.ukans.edu> <01bb7b06$311fabc0$87ee6fce@timpent.airshields.com> <01bb7da1$323102a0$96ee6fcf@timhome2> followup-to: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada organization: IDA, Alexandria, Virginia newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-02T00:00:00+00:00 List-Id: Tim Behrendsen (tim@airshields.com) wrote: : Robert Dewar wrote in article : ... : > Tim recommends : > : > "Assembly -> C [non-GUI] -> C-GUI -> C++ : > : > Assembly: Learn what's *really* going on. The most important." : > : > I strongly disagree. A student treading this path will have a hard time : > learning what abstraction is all about. : I arrived at this conclusion based on the students that were coming : to me to be hired. I give a standard test to all my applicants that : tests two primary attributes, : 1) How well they understand what's *really* going on; the best : programmers have a solid foundation. : 2) How well the can take a problem they've (probably) never seen : before and generate a solution. I strongly agree with points 1 and 2. The best programmers understand how things really work, and are able to generate a solution from a problem. Makes sense to me. We just disagree on how to get there. : I was shocked at the results. I had people with Masters and : Doctorates who were completely incapable of creating new solutions : that they had never seen before. I also agree that many people are coming out of schools and are incapable of creating new solutions. I've met them myself. The biggest problem I encounter is not that they don't understand the first principles. The problem is that they don't understand how to break a problem into parts, and then solve the problem. It's a problem in _abstraction_, not in understanding how the pieces work. : It's like graduating someone with a writing degree who is : illiterate. Continuing your analogy, what they really need is experience in writing seriously-size software -- and a CRITIQUE of their work by good writers. I haven't seen much in the way of critique in universities, and students tend to work with tiny problems (because nobody wants to evaluate big ones). This is an area where things really break down; it's possible to get a Master's or PhD and not write anything longer than a thousand lines, and with no feedback from experienced people. : I had people, with *degrees* now, : tell me "convert argument to binary" as one of the steps on a : logical operation problem! The latter are people who are ground : in the "abstraction" of an integer, but are completely clueless : that the computer works in binary. How can a student get a : full-blown degree, and not understand a computer works in binary? That's pretty clueless. However, depending on how well they understood their programming language, they might still produce a reasonable result. Why? Because, although they may not realize that some of these "conversion" operations have no run time impact, they may know how to combine the features of their language to produce solutions. And it's the solutions, not the knowledge, that you're paying for. I agree with you, though, you don't want such clueless people working for you. The clueless ones won't know how to write high-performance software where it's needed. You want people who understand the underlying technology _AND_ how to apply it. But don't assume that the former implies the latter. In fact, given someone who knows how to apply the technology, I can quickly get them up to speed on how it works. : Bottom line, a student cannot fundamentally understand an : abstraction until they understand the abstraction : in terms of the fundamental components of programming; again: : Move, Arithmetic, Test, Branch, and Logicals. Any professional developer must understand several assembly languages, and how they work in general. I think that goes without saying. That doesn't mean it should be their first language. There are various pedagogical approaches, and I haven't seen any strong evidence for this approach. I think assembly language is excessively difficult as a first step, and it obfuscates other necessary skills (like learning how to abstract things). A short course in how they work might be okay, but serious work starting with assembly would IMHO be a disservice. The language you use also determines the amount of detail you need to know about the underlying machine abstraction. When you're using C or C++, you really need to know how the underlying assembly language works. Why? Because pointer arithmetic makes little sense if you don't, and tracking down rogue pointers overwriting your local stack values and other nasties is impossible if you don't understand how underlying machines work. Most of the basic C/C++ operations are defined as "whatever your local machine does", so it's really part of the C/C++ definition. A professional developer using other languages should still know this level of detail, but it's frankly less important in Java, Ada 95, Eiffel, and Smalltalk (among others). Who cares that "if" becomes a branch instruction? Unless you call outside the language, you won't even get to see how some capabilities are implemented in some languages. The result: the detail you need to know to solve a problem shrinks. Thus, you can concentrate on learning how to abstract - the real problem. In the immortal words of managers everywhere: Who cares how the underlying system works? When will the code be ready? : CS is currently taught the way you describe. Why do you think : it's so hard to teach abstractions at the elementary level? It's not clear it's REALLY taught that way. Lots of schools just give a quick intro to a programming languages or two, and then show other people's abstractions (instead of teaching how to abstract). Besides, many students just "get by" instead of learning, and many people find abstraction really hard to grasp. : This is what convinced me that our CS education is being done : completely wrong. I've said this before [excuse my repetition]; : it would be as if EE students were taught IC design in the first : course, and were only given resisters, capacitors, ohm's law, : etc. in their senior year, almost as an afterthought! But even you are suggesting that there be an abstraction for software developers. Computers use resistors and capacitors, too. Why not require a full EE degree? The answer: because you don't REALLY need to know that level of detail; an abstraction of a computer is good enough. I've got a EE and CS degree; given sand and enough time I could build a computer, and then build an operating system and compiler on top of it. But in most of my work I don't need that level of low-level understanding. What I do need to know is how to abstract a problem into parts so I can solve it. I agree with Mr. Dewar - abstraction is most important, worry about that first. Thus: If solving problems is the key skill, start with a high-level language that lets you concentrate on learning how to solve problems. --- David A. Wheeler Net address: wheeler@ida.org