On Tue, 14 Jun 2005 16:40:42 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote:
>Um, you didn't do the translation right. Whoops. So you know assembler, no other possibility as it's such a complex language that unless someone already knows it (and in the specific architecture) what i wrote is pure line noise. You studied it after python, I suppose. >> or, even more concrete and like what I learned first >> >> lda $300 >> clc >> adc $301 >> sta $302 >> >> is simpler to understand. > >No, it isn't - because you have to worry about more details. In assembler details are simply more explicit. Unfortunately with computers you just cannot avoid details, otherwise your programs will suck bad. When I wrote in an high level language or even a very high level one the details are understood even if I'm not writing down them. After a while a programmer will even be able to put them at a subconscius level and e.g. by just looking at O(N^2) code that could be easily rewritten as O(N) or O(1) a little bell will ring in you brain telling you "this is ugly". But you cannot know if something is O(1) or O(N) or O(N^2) unless you know some detail. If you don't like details then programming is just not the correct field. In math when I write down the derivative of a complex function it doesn't mean I don't know what is the definition of derivative in terms of limits, or what are the conditions that must be met to be able to write down it. Yet I'm not writing them every time (some times I'll write them when they're not obvious, but when they're obvious it doesn't mean I'm not considering them or, worse, I don't know or understand them). If you don't really understand what a derivative is and when it makes sense and when it doesn't, your equations risk to be good just for after dinner pub jokes. >In particular, when programming in an HLL the compiler will take care of >allocating storage for the variables. In assembler, the programmer has >to deal with it. These extra details make the code more complicated. Just more explicit. So explicit that it can become boring. After a while certain operations are so clearly understood that you are able to write a program to do them to save us some time (and to preventing us to get bored). That's what HLL are for... to save you from doing, not to save you from understanding. What the HLL is doing for you is something that you don't do in the details, but that you better not taking without any critic or even comphrension, because, and this is anoter very important point, *YOU* will be responsible of the final result, and the final result will depend a lot (almost totally, actually) on what you call details. Just to make another example programming without the faintes idea of what's happening is not really different from using those "wizards" to generate a plethora of code you do not understand. When the wizard will also take the *responsability* for that code we may discuss it again, but until then if you don't understand what the wizard does and you just accept its code then you're not going to go very far. Just resaying it if you don't understand why it works there is just no possibility at all you'll understand why it doesn't work. Think that "a = b + c" in computes the sum of two real numbers and your program will fail (expecting, how fool, that adding ten times 0.1 you get 1.0) and you'll spend some time wondering why the plane crashed... your code was "correct" after all. >For instance, whitesmith had a z80 assembler that let you write: > > a = b + c > >and it would generate the proper instructions via direct >translation. To use that I've to understand what registers will be affected and how ugly (i.e. inefficient) the code could get. Programmin in assembler using such an high level feature without knowing those little details woul be just suicidal. >Also, you can only claim that being closer to the chip is "simpler" >because you haven't dealt with a sufficiently complicated chip yet. True that one should start with something reasonable. I started with 6502 and just love its semplicity. Now at work we've boards based on DSP TMSC320 and, believe me, that assembler gives new meanings to the word ugly. >> But saying for example that >> >> del v[0] >> >> just "removes the first element from v" you will end up >> with programs that do that in a stupid way, actually you >> can easily get unusable programs, and programmers that >> go around saying "python is slow" for that reason. > >That's an implementation detail. It's true in Python, but isn't >necessarily true in other languages. Yeah. And you must know which is which. Otherwise you'll write programs that just do not give the expected result (because the user killed them earlier). >Yes, good programmers need to know that information - or, >as I said before, they need to know that they need to know >that information, and where to get it. I think that a *decent* programmer must understand if the code being written is roughly O(n) or O(n^2). Without at least that the possibility of writing useful code, excluding may be toy projects, is a flat zero. Looking that information later may be just "too" late, because the wrong data structure has already been used and nothing can be done (except rewriting everything). >That may well be true of the standard C++ library - I don't write >it. But it certainly doesn't appear to be true of, for instance, >Python internals. I've never seen someone explain why, for instance, >string addition is O(n^2) beyond the very abstract "it creates a new >string with each addition". No concrete details at all. The problem is that unless you really internalized what that means you'll forget about it. Don't ask me why, but it happens. Our mind works that way. You just cannot live with a jillion of unrelated details you cannot place in a scheme. It doesn't work. One would do thousand times the effort that would be done using instead a model able to justify those details. >> The problem with designing top down is that when >> building (for example applications) there is no top. > >This is simply false. The top of an application is the >application-level object Except that the marketing will continuosly shift what you application is supposed to do. And this is good, and essential. This is "building". Sometimes marketing will change specifications *before* you complete the very first prototype. For complex enough projects this is more the rule than the exception. In the nice "the pragmatic programmer" book (IIRC) is told that there's no known complex project in which specification was changed less than four times before the first release... and the only time they were changed just three times it was when the guy running with the fourth variations was hit by a lightning on the street. >> Unfortunately sometimes there >> is the OPPOSITE problem... we infer general rules >> that do not apply from just too few observations. > >Your opposite problem is avoided by not teaching the details until >they are needed, and making sure you teach that those are >implementation details, so they student knows not to draw such >conclusions from them. What you will obtain is that people that will build wrong models. Omitting details, if they can really affect the result, is not a good idea. This is completely different from omitting details that no one without a 3km particle accellerator could detect to kids in 4th grade school. >>>The critical things a good programmer knows about those >>>concrete details is which ones are platform specific and which aren't, >>>and how to go about learning those details when they go to a new >>>platform. >> >> I never observed this problem. You really did ? > >As mentioned, you see it all the time in c.l.python. People come from >other languages, and try to write Python as if the rules for that >other language apply. That's exactly because they don't know the details of any of the languages you used. Someone knowing the details would be curious to know *how* "del v[0]" is implemented in python. Actually it could be changed easily in an O(1) operation with just a little slowdown in element access (still O(1) but with a bigger constant). This is a compromise that has not been accepted and this very fact is important to know if you plan to use python seriously. >It can be fixed from the start by teaching the student the difference >between abstract programming concepts and implementation details. Sorry, but I really don't agree that big O is a "detail" that could be ignored. Only bubble-and-arrow powerpoint gurus could think that; I'm not in that crew. Ignore those little details and your program will be just as good as ones that don't even compile. >It tackled abstract problems like "sorting". The students I'm talking >about never dealt with anything that abstract. Sorting is abstract ? >> Pairing this with that teaching >> abelian groups first to kids (why not fiber spaces then ?) >> and that TAOCP is too "abstract" tells me that apparently >> you're someone that likes to talk just for talking, or >> that your religion doesn't allow you to type in smileys. > >Now you're resorting to straw men and name-calling. That's an >indication that you no longer have any real points. I'll blame my bad english for understanding that you said that abelian groups should be taught before relative numbers (somehow I crazily thought the point of discussion was what's the correct order of learning how to program), that TAOCP is too abstract (a book where every single code listing is in assembler!) and that big-o when programming is a detail that can be safely ignored (good luck, IMO you'll need hell a lot of it). Andrea -- http://mail.python.org/mailman/listinfo/python-list
