On Sun, 12 Jun 2005 19:53:29 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote:
>Andrea Griffini <[EMAIL PROTECTED]> writes: >> On Sat, 11 Jun 2005 21:52:57 -0400, Peter Hansen <[EMAIL PROTECTED]> >> wrote: >> Also concrete->abstract shows a clear path; starting >> in the middle and looking both up (to higher >> abstractions) and down (to the implementation >> details) is IMO much more confusing. > >So you're arguing that a CS major should start by learning electronics >fundamentals, how gates work, and how to design hardware(*)? Because >that's what the concrete level *really* is. Start anywhere above that, >and you wind up needing to look both ways. Not really. Long ago I've drawn a line that starts at software. I think you can be a reasonable programmer even without the knowledge about how to design hardware. I do not think you can be a reasonable programmer if you never saw assembler. >Admittedly, at some level the details simply stop mattering. But where >that level is depends on what level you're working on. Writing Python, >I really don't need to understand the behavior of hardware >gates. Writing horizontal microcode, I'm totally f*cked if I don't >understand the behavior of hardware gates. But you better understand how, more or less, your computer or language works, otherwise your code will be needless thousand times slower and will require thousand times more memory than is necessary. Look a recent thread where someone was asking why python was so slow (and the code contained stuff like "if x in range(low, high):" in an inner loop that was itself pointless). >In short, you're going to start in the middle. I've got "bad" news for you. You're always in the middle :-D. Apparently it looks like this is a constant in our universe. Even counting (i.e. 1, 2, 3, ...) is not the "start" of math (you can go at "lower" levels). Actually I think this is a "nice" property of our universe, but discussing this would bring the discussion a bit OT. >Is it really justified to confuse them all >by introducing what are really extraneous details early on? I simply say that you will not able to avoid introducing them. If they're going to write software those are not "details" that you'll be able to hide behind a nice and perfect virtual world (this is much less true about bus cycles... at least for many programmers). But if you need to introduce them, then IMO is way better doing it *first*, because that is the way that our brain works. You cannot build on loosely placed bricks. >You've stated your opinion. Personally, I agree with Abelson, Sussman >and Sussman, whose text "The Structure and Interpretation of Computer >Programs" was the standard text at one of the premiere engineering >schools in the world, and is widely regarded as a classic in the >field: they decided to start with the abstract, and deal with concrete >issues - like assignment(!) later. Sure. I know that many think that starting from higher levels is better. However no explanation is given about *why* this should work better, and I didn't even see objective studies about how this approach pays off. This is of course not a field that I've investigated a lot. What I know is that every single competent programmer I know (not many... just *EVERY SINGLE ONE*) started by placing firmly concrete concepts first, and then moved on higher abstractions (for example like structured programming, OOP, functional languages ...). Andrea -- http://mail.python.org/mailman/listinfo/python-list
