Slashdot Mirror


Convincing Colleges to Upgrade Their Classes?

Pray_4_Mojo asks: "I'm an engineering student at the University of Pittsburgh, and I'm currently taking a required class known as 'Computer Interfacing'. While I enjoy the instructor, I find most of the material to be severely dated. We will spend the majority of the class covering RS232/XMODEM/Token Ring means of computer-to-computer communication. Almost no mention of USB, Firewire, or IRDa is made within the class. I am trying to convince my professor that this material is relevant, as these types of interfaces will be dominate in the world we future grads will be working in. As an example, I demonstrated that the keycard access system to gain access to the Interfacing Lab has a USB port for data download/firmware programming. The professor seems interested, but it seems that I need to convince the department to revise the course requirements. Has anyone attempted to modernize their CS/Engineering program and met with success?"

5 of 115 comments (clear)

  1. The new technologies are bad to learn from by LordNimon · · Score: 4, Interesting
    The newer technologies are much harder to learn from than the older ones. The speeds are much higher, the protocols are more complicated, and the tools are more expensive. For a beginner learning this stuff, you never want to work with the latest technologies.

    If you really want to learn about Firewire, do something with it for your Senior project.

    --
    And the men who hold high places must be the ones who start
    To mold a new reality... closer to the heart
  2. Real experience modernizing curriculum by nellardo · · Score: 4, Interesting
    Back in the day, in the early 90's, I was largely responsible/to blame for switching Brown University's undergraduate first semester programming course to object-oriented programming. It had been teaching structured programming, but industry at that time was following object-oriented design precepts (even if using languages like C). The faculty all firmly believed in OOP, and taught it in all upper-level courses. But it was seen as "too advanced" for beginning students.

    As it turned out, the real problem was not teaching OOP to the students. OOP is easier to explain to new programmers than structured programming (people use real-world objects all the time - not so much real-world procedures). Half-way through the first semester, the students could implement Tetris.

    The real problem was retraining the faculty. Even though they knew OOP was a good thing, it took them a while before they had internalized OOP enough to present, e.g., algorithms and data structures in an object-oriented style. No one believed that you could teach inheritance and polymorphism before you taught loops, conditionals, and arithmetic.

    Faculty teaching the intro courses may be in touch with industry and research. That's not enough. The faculty need to rethink an entire course to present the right academic material in a modern, industry-relevant way. If the faculty can do that (and, make no mistake, it isn't easy), they you'll get a course the students love, that will get them a job, and that will prepare them for a strong academic program as well.

    For the truly curious, the textbook for that course is actually still in print, even though it depended on Borland Pascal, which is long-since defunct.

    --
    -----
    Klactovedestene!
  3. College is not about getting a job by lkaos · · Score: 3, Interesting

    There are two types of jobs out there: 1) ones that require experience and 2) ones that don't want experience because they want groom you.

    For the first group, there is no way that you could possibly gain enough experience in 6-9 hours a week for four years. That's only about 4-6 months of professional experience (about two full-time internships if you're so lucky).

    For the second group, employers are more interested in finding someone who is a good problem solver and has the ability to pick up newer technologies quickly. In a lot of ways, as an employer I'd rather have someone who learned COBOL at school for fear that they'd carry bad habits if they knew C++ or a newer language that I'd expect them to use on the job.

    <Open Source Evangelizing>
    Of course, working on Open Source software can give you the desired experience and prove you have the ability to learn quickly on your own :)
    </Open Source Evangelizing>

    --
    int func(int a);
    func((b += 3, b));
  4. Fake Assembly by jasonrocks · · Score: 2, Interesting

    I started school at BYU this semester. I'm going into CS. The first required class had a horrifying syllabus. We were to learn about C, basic electronics, and assembly language built for a theoretical computer. I was disgusted that we would learn just about NOTHING which would be practical. I transferred out of there so fast. Now, I just hope I can get exempted from that class or take a C++, Java, or X86 assmebly course instead.


    void
    --

    void
  5. You wouldn't benefit anyway this time around by James+Youngman · · Score: 3, Interesting
    I think you don't stand a chance. To get the course material updated, you will have to do one of two things:-
    1. Get the lecturer replaced with someone else - this means someone else has to be willling to teach the course
    2. Find the lecturer a whole lot of free time to revise the course material (which I assume has been generated over a period of years) all at once. This probably means them taking time away from research, which is what you professor probably feels he's there for anyway.
    Even if you succeed, the material won't be updated while you're on the course. At best, the next course would start with the new material.

    (This reflects the situation in the UK, where academic teaching staff in Universities almost always have research commitments (and publications are used as a performance metric).

    Some of the material you are working with is not so bad, either. Learning about RS232 might teach you several things that are generically useful in designing system interfaces :-

    1. It's Not The Hardware, It's The Protocol Design, Stupid
    2. Race conditions between the two ends
    3. Reliability measures (Checksums, CRCs, ACK/NAK, windows)
    4. Resilience versus Bandwidth (e.g. max reliable baud rate ~ 10000/(RS232 cable run in feet))

    It's been a while since I've worked heavily in industrial interfacing, but I'd be surprised if USB is even relevant to that at all. Think more along the lines of RS422, 10baseT, and optical fibre (often carrying converted RS232, in fact).

    I'm not particularly familiar with XMODEM, but I think it's likely to help you undersand valuable facets from the above (bandwidth/reliability tradeoffs, protocol features for catching errors, latency versus throughput, bandwidth-delay products). Token Ring seems an odd choice to me, though. After all the hardware must be tricky to get these days (or perhaps your course has no hands-on component, which would make hardware availability irrelevant).

    One of the most interesting hardware interfacing things I've done was implement both ends of a mostly-symmetrical serial protocol. One end was implemented as a set of four cooperating threads, and the other as a state machine. One way of doing it was (in that case) much much easier than the other (less code and more reliable).