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: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public From: ian@rsd.bel.alcatel.be (Ian Ward) Subject: Re: What's the best language to start with Date: 1996/08/07 Message-ID: <4uaf5h$mid@btmpjg.god.bel.alcatel.be> X-Deja-AN: 172760835 distribution: world references: <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com> organization: Alcatel Bell Telephone reply-to: ian@rsd.bel.alcatel.be newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.unix.programmer Date: 1996-08-07T00:00:00+00:00 List-Id: In article 87ee6fce@timpent.airshields.com, "Tim Behrendsen" () writes: >Szu-Wen Huang wrote in article ><4u7grn$eb0@news1.mnsinc.com>... >> Tim Behrendsen (tim@airshields.com) wrote: >> : Maybe I'm weird, but I just don't see assembly as being harder >> : than a HLL, and in fact, it seems to me that it's much easier. >> : The number of fundamental things to learn is *very* small, and >> : I would think that being able to show a problem in terms of the >> : "array of memory" being manipulated would just make it infinitely >> : easier than having to wrestle with all the abstract nonsense. Assembler is easy to understand, it has very simple instructions, this is what makes it so useless at expressing solutions. One needs so much of it to do anything. Besides all the small solutions have already been done. Besides, the second best female software woman I know, who works for Oracle (in support ???? duh.) got a first class honours degree in computing/combined science without knowing what Hex was, and I'd trust her code with my life (but not Oracle's.) Simply because, her course did not require it. If she had the brains to be able to deal with abstract concepts, then she could do the design work, and the simple algorithms could be left to someone else. [That was not what I thought of this at the time mind, I thought she was a stupid bitch, but then in that same year I remember defending Basic _and_ assembler against Pascal, simply because I had not come across a problem that I could not solve (and remember the complete solution months afterward) in my head. I wish I go back then, playing around for four hours a day in college, and then drinking ten pints of lager (56p a pint.) Wall to wall vomitting, best days of your life.] >> >> I know what you're trying to say, but you neglect what the subject >> is trying to teach. I don't need my students to learn how to print >> out a string calling interrupt this function that, or that the >> instruction *after* a branch is always executed (in some pipelined >> RISCs), or you cannot divide by the ZZX register. These will all >> be useless in a few years, perhaps even a few months. I need my >> students to learn when and why quicksort is more efficient than >> bubblesort, and telling them to use assembly sidetracks that effort. > >Let me bring it back full-circle where we started. The reason >I mention assembly in the first place was the number of graduates >coming to me for a job that were failing the test I give >*abysmally*, particularly in the areas of creating an algorithm >for a problem they've never seen before, and doing logical >operations. > There are two fundamental points here which until recently I had not sussed, and which seem to be fighting each other in this thread. 1. Algorithmic problem solving. Tim here suggests that assembler should be used to teach students how to become software engineers, because the simple structure of the assembly language is easy to understand. Students will be able to follow it, etc. Additionally, people studying this, if (and only if) they become good programmers using this method, then they are the type of people who can work things out for themselves. 2. Software engineering. There are two things here, one is abstraction, and the other is best fit solution from multiple points of reference. (The second, I like because it works for me, I always used to call this abstraction, but the whole of the rest of the software engineering community, in fact, do not seem to.) I take no credit for this observation, it is blatantly plagiarised. Abstraction, the software design technique of placing a model for your design which is as wide as possible, (such as designing your car control system to be actually a system which can handle all vehicles up to say, 14 wheels, and then restraining your implementation to a four wheeled vehicle, by parameters) is part of the whole series of modern developments in software engineering, which have been created or refined since early languages were created. It is in these fields that languages such as Ada95 and C++ have advantages over their earlier counterparts. Plagiarism over. We see modern languages providing the means to implement, efficiently (or not), modern design techniques (such as, but not limited to, abstraction) which are the solutions to the increasing varying types of problems that software people now face. These varying different approaches to problem solving are mirrored in modern languages, and by learning (using in the way they were intended.) languages of sufficiently different front end, the methodology rubs off and affects the users thinking. (Of course the methodology shall not rub off, if the programmer writes the new language in the same way as he would have his old language. This is why I always feel you must love the language. This accounts for the experiences of people achieving better solutions in their preferred language, even though it may not be the best language to solve the problem. It also explains why people hate some languages, which of course, they don't, they just resent having to use it.) In contrast : Modern assembler does nothing more clever at the programmer interface than it did twenty years ago, even though they are miles more efficient than they ever were. In my opinion, the main improvements in processor technology have come in the internal way they get their speed. There are, I guess, two exceptions to this, that really affect the programmer, the ability to connect them together, that is multiprocessing... and the useful test and set instructions. -------------------------- ~ ---------------------------- In an interesting post a couple of weeks ago, Robert Dewar, in reply to a post about somebody who said that learning 5 or 6 assemblers 'just for fun' that this kind of experience was not valuable. This fits in with my pet theory on the subject, because all assemblers are basically the same, and they implement clever techniques below the programmer interface, but nothing innovative at it. Tim seems to be of the school that teaching CS should be done in assembler because they don't have to put up with loads of abstractions (read modern methods.) Peter on the other hand basically is disagreeing with him, on the grounds that with exception of new device drivers, all the easy stuff (the stuff that is so easy it can be done in assembler just with simple jumps, adds etc.) has been done. Modern methods have evolved to cope with problems that could not be solved, or at the very least old methods provided unreliable or slowly developing solutions. I do not think problems will converge in there similarity either, by their very nature, the nature of new problems will diverge as ways are found to solve existing ones. I have to agree with Peter in this case. I do not think that assembler is a very useful grounding for programmers, even though Z80 was basically my first language. I think I would have been a better programmer had this not been the case. Just how much speed do we need anyway? Even if hand written assembler was faster than compiled code, which it is not, these things need to be put into perspective. A modern high end desktop PC will be faster than an old Cray One (400Mhz. I think) in _less_ than two years. > >I chalked this up to the lack of the fundamentals being taught, >and the students having their brains filled up so much with >abstractions that they don't understand how to solve problems >anymore. It was probably just lack of what you consider to be fundamental, however, with the very few exceptions, straight assembler will almost totally unused, anywhere, twenty years from now. Furthermore, if students were told that computers implemented, at ground level, say, strings, and all these students' interfaces provided strings, then they would think the bottom level was their provided interface. There is no reason why they need to even know assembler, these days, ten or twenty years from now, there will be even less of a case. > >This is why I think assembly is the better way to teach >algorithms; it's just you and the algorithm. It forces them >to really think about the problem, because they don't have any >"training wheels" to protect them from the problem. > Very few people have good problem solving abilities, I agree but a lot of this minority have developed this ability themselves, or inherited it from their parents (or a bit of both.) Out of these, almost nobody has derived sound software engineering methods from first principles. They have to be taught. >Whatever were doing now is *not working*, let me tell you. Perhaps if you tested people differently, and employed the people who could understand sound abstract concepts, then the solutions your company provides would be designed better originally, rather than having lots of clever bits of algorithmic code to save the inexperienced design these hackers you have employed have made. Then you may see more success, and not feel the situation is so hopeless. :-) Inexperienced (or people with narrow experience) but talented problem solvers, in my experience, often cause more damage than they should, because they are more likely to just say, "I can see how to do it!" and start coding. Yet all these problems, where it is possible to humanly achieve a viable solution using this technique are drying up. Unfortunately, these problem solvers, having relied on their wits since the day they first started to think, are the last people to step back and think, "Is there another way of doing this?" In the rare cases where they do, they, (like ex boy racers turned thirty, with children,) still retain their speed but become the safest people on the road, because they have seen the behaviour of the vehicle beyonds its limits, and they know not only when it is safe to speed, but also when it is not. > >-- Tim Behrendsen (tim@airshields.com) I think Peter is on the right track here. Best regards, Ian. --- Ian Ward's opinions only : ian@rsd.bel.alcatel.be