* Re: What's the best language to start with @ 1996-08-13 0:00 Alexander E. Kopilovitch 0 siblings, 0 replies; 14+ messages in thread From: Alexander E. Kopilovitch @ 1996-08-13 0:00 UTC (permalink / raw) In <dewar.839812305@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >>I did not say that software engineers are incompetent and I did not say that >>"programmers" are more competent than "software engineers". The difference >>between these terms (or labels, if you want) doesn't directly relate to >>some general competence. These "labels" can designate different _priorities_. >>And you could not expect the same profile of competence from people with >>substantionally different priorities. > >Well I can't reconcile these two paragraphs, perhaps it is a language >problem, or perhaps there are two Alexanders :-) Maybe language problem exists, which makes last 2.5 lines of my (cited) text invisible. >In the first paragraph you say that incompetence (of this kind) is >characteristic of a "substanional" part of the growing mass of these >brave software engineers, and then in the second paragraph you >said that you were not commenting on relative competence associated >with the two labels. I repeat in hope that you can see these lines written in capital letters: LABELS "PROGRAMMER" AND "SOFTWARE ENGINEER" CAN DESIGNATE DIFFERENT PRIORITIES. THESE DIFFERENT PRIORITIES OFTEN LEAD TO DIFFERENT PROFILES OF COMPETENCE. >You seem to definitely have some derogatory reaction to the term SE, No, I have no negative reaction to the term SE when it is used properly. I have no negative reaction to the phrase "Windows 95 is an operating system", but I become angry when I hear that "Operating systems are variations of Windows 95". > which you are certainly entitled to, You guess is wrong until now. Thanks God. In my current conditions I cannot be good SE, if I'm SE then I'm poor SE. But in the same time I can be good programmer, and I hope I am. And I can emulate poor SE if it is needed. > but >for me a software engineer is merely a programmer who takes an organized >engineering perspective to the job of producing code, The point is "organized engineering perspective". Good thing. If you can follow it without substantional hazards for final effect - very good. But if there is an alternative... maybe you cannot imagine it ... or maybe you think that such alternatives may appear only for very stupid people... well, if there is such an alternative then the choice of SE and the choice of programmer probably would be opposite. >... one >of the things we learn from the engineering disciplines is a respect for >the body of knowledge associated with an engineering field. Completely agree. ------------------------------------------------------------ Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with @ 1996-08-12 0:00 Alexander E. Kopilovitch 1996-08-11 0:00 ` Robert Dewar 0 siblings, 1 reply; 14+ messages in thread From: Alexander E. Kopilovitch @ 1996-08-12 0:00 UTC (permalink / raw) In <dewar.839694958@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >>It means that this "programmer" is not programmer indeed, but software >>engineer. The combination of "careful and well written implementations" and >>"completely absurd algorithms" is characteristic for substantional part of >>the growing mass of these brave software engineers. >... there is no >distinction of this kind in the terms as normally used here. You can >find incompetent and competent people under all labels! I did not say that software engineers are incompetent and I did not say that "programmers" are more competent than "software engineers". The difference between these terms (or labels, if you want) doesn't directly relate to some general competence. These "labels" can designate different _priorities_. And you could not expect the same profile of competence from people with substantionally different priorities. ------------------------------------------------------------------------- Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-12 0:00 Alexander E. Kopilovitch @ 1996-08-11 0:00 ` Robert Dewar 0 siblings, 0 replies; 14+ messages in thread From: Robert Dewar @ 1996-08-11 0:00 UTC (permalink / raw) I did not say that software engineers are incompetent and I did not say that "programmers" are more competent than "software engineers". The difference between these terms (or labels, if you want) doesn't directly relate to some general competence. These "labels" can designate different _priorities_. And you could not expect the same profile of competence from people with substantionally different priorities. Well I can't reconcile these two paragraphs, perhaps it is a language problem, or perhaps there are two Alexanders :-) In the first paragraph you say that incompetence (of this kind) is characteristic of a "substanional" part of the growing mass of these brave software engineers, and then in the second paragraph you said that you were not commenting on relative competence associated with the two labels. Anyway the bottom line is that I think the distinction that you are trying to make is absurd. There is no connection between incompetence of this kind and the choice of label by either the programmer/SE themselves or the outside perception of the terms. You seem to definitely have some derogatory reaction to the term SE, which you are certainly entitled to, but for me a software engineer is merely a programmer who takes an organized engineering perspective to the job of producing code, and using "completely absurd algorithms" is NOT part of such a perspective. On the contrary one of the things we learn from the engineering disciplines is a respect for the body of knowledge associated with an engineering field. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <199608110535.WAA18572@pioneer.nevada.edu>]
* Re: What's the best language to start with [not found] <199608110535.WAA18572@pioneer.nevada.edu> @ 1996-08-11 0:00 ` Tim Behrendsen 1996-08-13 0:00 ` Frank Manning 1996-08-14 0:00 ` Robert Dewar 0 siblings, 2 replies; 14+ messages in thread From: Tim Behrendsen @ 1996-08-11 0:00 UTC (permalink / raw) On Sat, 10 Aug 1996, DAVID A MOLNAR wrote: > In article <01bb8540$59ac8420$87ee6fce@timpent.airshields.com> you wrote: > : I should say that my test had them render solutions in C. I > : gave them a moderately easy but not trivial algorithm to > : implement, and they just plain couldn't do it. > I'm not a CS grad, but I can't help wondering what is considered > a moderately simple algorithm at this level. What sort of description > would you give to a person in that position? I would imagine that a fair > level of mathmatical literacy might be expected, not to mention some > acquaintance with the field you are hiring for... > May I respectfully ask what kind of an algorithm it is/was? If > you're still using it as a test for job applicants, I understand if you > don't wish to disclose the particulars. I only ask because I am currently > finishing up a CS1/CS2 sequence and have been following this debate with > increasing interest. Although I can't help but wonder why no one has yet > mentioned Scheme (my own 'first'). :-) It's caused me to take a look at > what I have and have not learned in the year or so that I've been taking > classes...and what I need to learn in the future. Fortunately, I have > some years yet until graduating from college. :-) I have been intentionally not giving my problems away, because it's hard to think of good solid problems that can be solved in a reasonable amount of time that doesn't get too much into specialized knowledge that would make them unfair. Basically, I have a problem that is arithmetic oriented, to see if someone can think mathemetically; a logic problem to see if they understand bits and logic; stuff like that. I will tell you one "bonus" problem that I give to see if they are paying attention; I don't really factor it in much when I decide to hire someone or not because it's not really a fair question. I love the problem, though, because it's a pure "thinking" problem. ---- You are writing a preprocessor program that takes C source as its input. The preprocessor replaces all variables and symbols in the program with unique names of the form VARxxxxxx, where "xxxxxx" is an incrementing decimal number. Describe what is needed to handle the case where the input source file already contains a variable of that form. ---- I would say about 95-98% of the applicants get this question wrong. I have had people I respect give the "obvious" wrong answer, though, so it's mostly a matter of not really thinking about it before answering. You should see some of the answers I get that are WAY off, though. It's really scary. At least 20% of the answers are some form of "I've never done a C preprocessor before, so I don't know." Yes, these are people with full-blown degrees. -- Tim Behrendsen (tim@airshields.com) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-11 0:00 ` Tim Behrendsen @ 1996-08-13 0:00 ` Frank Manning 1996-08-13 0:00 ` Tim Behrendsen 1996-08-14 0:00 ` Robert Dewar 1 sibling, 1 reply; 14+ messages in thread From: Frank Manning @ 1996-08-13 0:00 UTC (permalink / raw) In article <Pine.A32.3.91.960811134122.76393A-100000@wc.airshields.com> Tim Behrendsen <tim@airshields.com> writes: [ Bonus interview question ] ---- > You are writing a preprocessor program that takes C source as > its input. The preprocessor replaces all variables and symbols > in the program with unique names of the form VARxxxxxx, where > "xxxxxx" is an incrementing decimal number. Describe what is > needed to handle the case where the input source file already > contains a variable of that form. ---- OK, I'll bite. I'd say that particular case is handled just like any other case. The input variable/symbol is a completely separate entity from output string "VARxxxxxx" you replace it with, except for the 1:1 mapping of input vs. output strings. Examples: INPUT OUTPUT abc VAR000001 Color_Value VAR000002 VAR000001 VAR000003 VAR000004 VAR000004 X_Prime VAR000005 Nah...that was too easy. I musta missed something... -- Frank Manning ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-13 0:00 ` Frank Manning @ 1996-08-13 0:00 ` Tim Behrendsen 1996-08-15 0:00 ` Bob Kitzberger 0 siblings, 1 reply; 14+ messages in thread From: Tim Behrendsen @ 1996-08-13 0:00 UTC (permalink / raw) Frank Manning <frank@bigdog.engr.arizona.edu> wrote in article <4up0ar$pim@news.ccit.arizona.edu>... > In article <Pine.A32.3.91.960811134122.76393A-100000@wc.airshields.com> > Tim Behrendsen <tim@airshields.com> writes: > > [ Bonus interview question ] > > ---- > > You are writing a preprocessor program that takes C source as > > its input. The preprocessor replaces all variables and symbols > > in the program with unique names of the form VARxxxxxx, where > > "xxxxxx" is an incrementing decimal number. Describe what is > > needed to handle the case where the input source file already > > contains a variable of that form. > ---- > > OK, I'll bite. I'd say that particular case is handled just like any > other case. The input variable/symbol is a completely separate entity > from output string "VARxxxxxx" you replace it with, except for the > 1:1 mapping of input vs. output strings. Examples: > > INPUT OUTPUT > > abc VAR000001 > Color_Value VAR000002 > VAR000001 VAR000003 > VAR000004 VAR000004 > X_Prime VAR000005 > > Nah...that was too easy. I musta missed something... Nope, you got it. :) The typical wrong answer (when they make an answer at all) is to start describing a list they keep of the ones that are already of the form, etc. Occasionally I'll get someone go off the deep end and describe incredibly elaborate data structures. Heh heh. I don't count it too much, because it's so stacked to lead the person down the wrong path. "Trick" questions rarely tell you anything significant, except where the "wrong" answer is really confused. -- Tim Behrendsen (tim@airshields.com) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-13 0:00 ` Tim Behrendsen @ 1996-08-15 0:00 ` Bob Kitzberger 0 siblings, 0 replies; 14+ messages in thread From: Bob Kitzberger @ 1996-08-15 0:00 UTC (permalink / raw) Tim Behrendsen (tim@airshields.com) wrote: > You are writing a preprocessor program that takes C source as > its input. The preprocessor replaces all variables and symbols > in the program with unique names of the form VARxxxxxx, where > "xxxxxx" is an incrementing decimal number. Describe what is > needed to handle the case where the input source file already > contains a variable of that form. Do they get extra credit if they hand-optimize to take into account paging locality, compiler optimizations, etc.? :-) -- Bob Kitzberger Rational Software Corporation rlk@rational.com http://www.rational.com http://www.rational.com/pst/products/testmate.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-11 0:00 ` Tim Behrendsen 1996-08-13 0:00 ` Frank Manning @ 1996-08-14 0:00 ` Robert Dewar 1996-08-14 0:00 ` Tim Behrendsen 1 sibling, 1 reply; 14+ messages in thread From: Robert Dewar @ 1996-08-14 0:00 UTC (permalink / raw) Tim says "I would say about 95-98% of the applicants get this question wrong. I have had people I respect give the "obvious" wrong answer, though, so it's mostly a matter of not really thinking about it before answering." I can't see an obviously wrong answer, only a trivially right one, so perhaps you should tell us the mysterious obviously wrong answer. I tried this on a few people around here and they were all as puzzled as I was. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-14 0:00 ` Robert Dewar @ 1996-08-14 0:00 ` Tim Behrendsen 0 siblings, 0 replies; 14+ messages in thread From: Tim Behrendsen @ 1996-08-14 0:00 UTC (permalink / raw) Robert Dewar <dewar@cs.nyu.edu> wrote in article <dewar.840032915@schonberg>... > Tim says > > "I would say about 95-98% of the applicants get this question > wrong. I have had people I respect give the "obvious" wrong answer, > though, so it's mostly a matter of not really thinking about it > before answering." > > I can't see an obviously wrong answer, only a trivially right one, so > perhaps you should tell us the mysterious obviously wrong answer. I tried > this on a few people around here and they were all as puzzled as I was. Well, it seemed obvious to me, too when I heard it the first time (A friend of mine's father used it as an intelligence test to programmers), but I guess that shows the general level of competence in the world. The typical wrong answer (if I get an answer at all) is to describe some elaborate data structure to keep track of the "duplicates". Here's a couple of examples [pulling off the "reject" stack]: ----------- "The basic need for the program is to replace the input, given from a C source, with a unique name of "VARXXXXX". The main body of this program would simply read in data (in c) and replace it with a variable name. In order to make sure any one input source did not have the same variable name (as what it might be replaced with) we would simply have to add a condition to our loop. The program would be set up in the form of a _loop_ where a variable is read _AND_ check that the unique name it will be replaced with is not the same as the input source file and then proceed to replace the variables. In the case where the input file did have the same variable, a new variable name would have to be used." [Underlines were the applicant's] ------------------- - or - "I guess it depends on the requirements, performance, but you could read the code first, save all the variables in a list, then read the code a second time, then you replace the variable to a new name, you can check to see if exists already." Without mentioning the school, this last graduated with a 3.5 and a Dean's Honor List distinction. Completely unable to think. --------------------- I wasn't intentionally picking the most lame ones, BTW; these were pretty much the ones on the top of the (reject) stack. Also to be fair, I make them hand-write the solutions, which is why the grammar is often not perfect (although, still pretty lame). -- Tim Behrendsen (tim@airshields.com) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with @ 1996-08-10 0:00 Alexander E. Kopilovitch 1996-08-10 0:00 ` Robert Dewar 0 siblings, 1 reply; 14+ messages in thread From: Alexander E. Kopilovitch @ 1996-08-10 0:00 UTC (permalink / raw) In <dewar.839593445@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >Over and over again I see cases of careful and well written implementations >of completely absurd algorithms for standard problems, where quite >obviously the programmer was simply unaware that there are much better >solutions known. It means that this "programmer" is not programmer indeed, but software engineer. The combination of "careful and well written implementations" and "completely absurd algorithms" is characteristic for substantional part of the growing mass of these brave software engineers. > For >instance, if you want to compute eigenvalues of a large matrix, then >you CERTAINLY do not try to invent your algorithm, and you probably don't >even go and look up an algorithm, instead you use a standard library. Not CERTAINLY. In most cases - yes, but not certainly, as you are programmer, not software engineer. Definitely, you have no chance to invent general algorithm for computing of eigenvalues better then already published ones, but sometimes you have a chance to discover that computing of eigenvalues aren't really needed to solve the problem, but much simpler task may be performed instead. >Reuse, of both code in standard libraries, and of ideas, in the form of >published algorithms, is a key, perhaps *the* key, tool in a programmers >arsenal. All these are tools for local optimizations of the problem solution. They can produce global optimum if you have guessed proper overall structure of the program/problem. --------------------------------------------------------------- Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-10 0:00 Alexander E. Kopilovitch @ 1996-08-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 14+ messages in thread From: Robert Dewar @ 1996-08-10 0:00 UTC (permalink / raw) Alexander says "It means that this "programmer" is not programmer indeed, but software engineer. The combination of "careful and well written implementations" and "completely absurd algorithms" is characteristic for substantional part of the growing mass of these brave software engineers. " Well I can't easily tell if this is just a language problem (maybe the terms in Russian have different implications), or out and out flame bait. Probably the latter -- but in any case it is certain that there is no distinction of this kind in the terms as normally used here. You can find incompetent and competent people under all labels! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?]
@ 1996-08-06 0:00 Tim Behrendsen
1996-08-07 0:00 ` What's the best language to start with Ian Ward
0 siblings, 1 reply; 14+ messages in thread
From: Tim Behrendsen @ 1996-08-06 0:00 UTC (permalink / raw)
Szu-Wen Huang <huang@mnsinc.com> 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.
>
> 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.
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.
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.
Whatever were doing now is *not working*, let me tell you.
-- Tim Behrendsen (tim@airshields.com)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-06 0:00 What's the best language to start with? [was: Re: Should I learn C or Pascal?] Tim Behrendsen @ 1996-08-07 0:00 ` Ian Ward 1996-08-08 0:00 ` Tim Behrendsen 0 siblings, 1 reply; 14+ messages in thread From: Ian Ward @ 1996-08-07 0:00 UTC (permalink / raw) In article 87ee6fce@timpent.airshields.com, "Tim Behrendsen" <tim@airshields.com> () writes: >Szu-Wen Huang <huang@mnsinc.com> 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-07 0:00 ` What's the best language to start with Ian Ward @ 1996-08-08 0:00 ` Tim Behrendsen 1996-08-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 14+ messages in thread From: Tim Behrendsen @ 1996-08-08 0:00 UTC (permalink / raw) Ian Ward <ian@rsd.bel.alcatel.be> wrote in article <4uaf5h$mid@btmpjg.god.bel.alcatel.be>... > 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. What I'm really saying is I want students to get the feel for algorithmic analysis, and it seems to me that it's better to "mix the fundamental ingredients" to learn to cook than it is to reheat a frozen dinner. Yes, both are technically cooking, but I married the former. :) > [interesting stuff snipped] > 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 don't think there's much of anything that really needs to be done in assembler, but I think there is no beating it when it comes to getting the "feel" of how computers really work. > >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. I should say that my test had them render solutions in C. I gave them a moderately easy but not trivial algorithm to implement, and they just plain couldn't do it. > >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. Electronic Engineering seems to do pretty well from "first principles". I would say the average competency level of an EE grad is *much* higher than the average CS grad. > [more interesting stuff snipped] > >Whatever were doing now is *not working*, let me tell you. >[snip] > 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?" I completely disagree! Someone who is an "algorithm memorizer" is *much* less likely to go back and think "Is there another way to do this," because they by definition do not think about their solutions. They simply look them up in the book, and if the book says that's the best, well, no need to go further. Take John Carmack, the 3D game engine programmer of Doom and Quake. An astoundingly talented guy, and definitely of the "talented problem solver" class. According to a mag article, he has written over 20 gaming engines in search of the most optimal implementation. -- Tim Behrendsen (tim@airshields.com) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What's the best language to start with 1996-08-08 0:00 ` Tim Behrendsen @ 1996-08-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 14+ messages in thread From: Robert Dewar @ 1996-08-09 0:00 UTC (permalink / raw) Tim said "I completely disagree! Someone who is an "algorithm memorizer" is *much* less likely to go back and think "Is there another way to do this," because they by definition do not think about their solutions. They simply look them up in the book, and if the book says that's the best, well, no need to go further." This seems like a pretty extreme case of NIH syndrome. Any competent programmer MUST be an "algorithm memorizer" in the sense that if you have a complex algorithmic problem, then you should at LEAST know where to go and look up appropriate solutions. In other than trivial cases, you are very unlikely to be able to cough up on the spot solutions that compare to the combined knowledge represented by 30 years of research by thousands of researchers. Over and over again I see cases of careful and well written implementations of completely absurd algorithms for standard problems, where quite obviously the programmer was simply unaware that there are much better solutions known. Suppose for example you need a fast in place sort with bounded time behavior (i.e. you are concerned with worst case performance). A good programmer knows immediately that treesort3 or some variation of it (Knuth likes to call this algorithm heapsort) is the natural choice. You are NOT about to invent this on your own. You don't necessarily need to recall the details, but you should certainly know where to look up this algorithm, and then be able to code from that description, or in some environments you can of course short circuit this by using standard libraries. For instance, if you want to compute eigenvalues of a large matrix, then you CERTAINLY do not try to invent your algorithm, and you probably don't even go and look up an algorithm, instead you use a standard library. Reuse, of both code in standard libraries, and of ideas, in the form of published algorithms, is a key, perhaps *the* key, tool in a programmers arsenal. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~1996-08-15 0:00 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-08-13 0:00 What's the best language to start with Alexander E. Kopilovitch -- strict thread matches above, loose matches on Subject: below -- 1996-08-12 0:00 Alexander E. Kopilovitch 1996-08-11 0:00 ` Robert Dewar [not found] <199608110535.WAA18572@pioneer.nevada.edu> 1996-08-11 0:00 ` Tim Behrendsen 1996-08-13 0:00 ` Frank Manning 1996-08-13 0:00 ` Tim Behrendsen 1996-08-15 0:00 ` Bob Kitzberger 1996-08-14 0:00 ` Robert Dewar 1996-08-14 0:00 ` Tim Behrendsen 1996-08-10 0:00 Alexander E. Kopilovitch 1996-08-10 0:00 ` Robert Dewar 1996-08-06 0:00 What's the best language to start with? [was: Re: Should I learn C or Pascal?] Tim Behrendsen 1996-08-07 0:00 ` What's the best language to start with Ian Ward 1996-08-08 0:00 ` Tim Behrendsen 1996-08-09 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox