Previous Next Index Thread

No Subject

 In article <4l746e$m8r@newsbf02.news.aol.com>, jkasunich@aol.com says...
 >
 >
 >Elsewhere in this thread, much has been said about how well,
 >or how poorly, one language or another handles abstraction.
 >My $0.02 on the subject:
 >
 >Every programming language is an abstraction, they just operate
 >at different levels.  I work on motor drives.  The highest level of
 >abstraction for this product is what the customer sees:  a box
 >with a START and STOP botton.  He pushes the buttons, and
 >the motor spins.  He knows nothing else and is happy that way.
 >Then you have the control engineer who sits next to me.  He 
 >looks at the drive as a collection of algorithms that control the
 >voltages, currents, and magnetic fields in the motor to make it
 >generate torque.  His view is much more detailed than the
 >customer's, but still much simpler than the code that implements
 >those algorithms.  Next is the C code, followed by the assembly
 >code that the compiler generates.  Next you have CPU, memory,
 >I/O devices, and so on.  And below that, you have transistors and
 >wires with voltages swinging from 0 volts to 5 volts and back.   
 >
 >Each of these levels has its own 'best' language.  The customer
 >looks at the instruction manual, the control engineer looks at
 >functional block diagrams, the programmers look at C and
 >sometimes assembly code, and the hardware designer looks at
 >hardware block diagrams and schematic diagrams.
 >
 >Arguments about which is the best level of abstraction are 
 >pointless.  Any given problem may involve any or ALL of them.
 >More than once, we have traced a problem seen by a customer
 >down through the control algorithms, the code, and the hardware,
 >to a difference of less than one volt, for a time period of less
 >then 50 nanoseconds, on a wire at the lowest level of abstraction.
 >
 >My main point:
 >
 >     The best engineers are those who move easily from
 >     one level of abstraction to another, and the best tools
 >     are those that allow such movement.  Programming
 >     languages are no exception.
 >
 >The language should let you hide complexity at a lower level, but
 >MUST NOT make it impossible to see that complexity when needed.
 >One of the strengths of C is that you can easily make the transition
 >to the next level down.  One of its weaknesses is that it is often
 >difficult to make the transition to the next level up.  Since I do a 
 >lot of troubleshooting, I would rather be able to move down.  If the
 >problem can be solved by telling the customer to 'Read the manual,
 >dummy', then fine.  If not, I look at the control algorithms.  If they
 >are OK, I look at the C implementation, then either straight to the
 >hardware, or maybe the assembly first, and so on down the line.
 >
 >BTW, the main reason I hate Windows is that Bill G. and company
 >apparently believe that the purpose of software is to conceal and 
 >obfuscate what is going on at the lower levels.  Drives me nuts when
 >something's broke and all I get is an error message intended for
 >kindergarden kids.  Exactly the opposite of 'easy movement between
 >levels of abstraction'.
 >