It's that time again. Time to teach second year EE on programming. This is their first formal course on programming. Perhaps, this is also their last time? I had only one formal course on programming and that was FORTRAN. Anyway, what should I teach?
We already decided that it's object oriented and C++ is going to be used as the language. Walter Savitch's "Problem Solving in C++" is the textbook. There were a lot of discussion before we came to that decision. Unfortunately, I didn't make notes (and am to lazy to write them down). Every year I re-think about it. (Perhaps, it's time to write the arguments down?) Here's an issue that came my mind recently.
High vs low-level programming
UML or higher level "coding." This is great, but I am afraid that my students would not understand low level coding. Remember that they are EE, engineers. They are not computer scientists. They may have to work with devices with low level programming, such as (micro)controllers and stuff. That's why we picked C++. It's not the best language to teach programming, but it can go to low level or high level.
I was looking at Michael Lynn's presentation (on Cisco IOS shellcode) the other day. (It was a huge fiasco.) Many parts of the description have codes in assembly language. Do I have to teach assembly language to my students? (Perhaps in a "core ware-like" game? Suggestion?) How many of you still play (work) with assembly language? Should I even bother? They'll learn it themselves. (Then, what's the purpose of me teaching them programming if they can learn it themselves?)
The most important thing is I have to teach them the logic of programming. BTW, how do I test logic? I want to know if they have the "foundation of programming," but not language-specific (or even paradigm-specific). Should I test them with pseudo code? Flow chart? Stories?
Anyway ... I wish I am allowed to teach programming with perl :)
We already decided that it's object oriented and C++ is going to be used as the language. Walter Savitch's "Problem Solving in C++" is the textbook. There were a lot of discussion before we came to that decision. Unfortunately, I didn't make notes (and am to lazy to write them down). Every year I re-think about it. (Perhaps, it's time to write the arguments down?) Here's an issue that came my mind recently.
High vs low-level programming
UML or higher level "coding." This is great, but I am afraid that my students would not understand low level coding. Remember that they are EE, engineers. They are not computer scientists. They may have to work with devices with low level programming, such as (micro)controllers and stuff. That's why we picked C++. It's not the best language to teach programming, but it can go to low level or high level.
I was looking at Michael Lynn's presentation (on Cisco IOS shellcode) the other day. (It was a huge fiasco.) Many parts of the description have codes in assembly language. Do I have to teach assembly language to my students? (Perhaps in a "core ware-like" game? Suggestion?) How many of you still play (work) with assembly language? Should I even bother? They'll learn it themselves. (Then, what's the purpose of me teaching them programming if they can learn it themselves?)
The most important thing is I have to teach them the logic of programming. BTW, how do I test logic? I want to know if they have the "foundation of programming," but not language-specific (or even paradigm-specific). Should I test them with pseudo code? Flow chart? Stories?
Anyway ... I wish I am allowed to teach programming with perl :)
Comments
tksh -=adnan=-
- acm.uva.es/problemset
- ace.delos.com/usacogate
- www.topcoder.com/tc
Untuk EE students, saya menyarankan agar mereka dapat menguasai bagaimana meng-capture model komputasi ke dalam bahasa pemrograman tsb.
- state-machine -> c, java, perl, dsb.
- dataflow -> c, vhdl
- oo -> c, c++.
Haskell i.e dulu Miranda