2 more difficult topics for students
I agree with Joel concerning the topic of pointers being a difficult concept for students to pick up. There is also 2 more topics that stump students. These two hit after pointers but still weed the weaker minds.
The first is Object Orientation. There were many students that had a hard time understanding OO and how to correctly use it for developing software. Now I am not talking about UML or any methodology just the basic concepts of escalation, inheritance and polymorphism. Polymorphism was always the hardest one to grasp and I have to admit that it took a few hours for me to total get it. We had many students drop out of computer science at this point.
The other concept that really blew many students away was event driven programming. Most had the linear programming down and could not understand how a program could handle events. The biggest problem was that the instructors didn’t explain the idea of the message queues and how they work.
Thought these might add some more to the pointer topic. Thinking of college and being back for Homecoming last weekend makes me long for the days when all I did was write code and not have to put up with politics and the corporate rat race.
Thursday, October 18, 2001
The other concept that really blew many students away was event driven programming.
This is surprising. Millions of VB programmers use event-driven programming, and they don't have any particular problem with it. Granted, the way VStudio hides the underlying complexity (creating a function which name is made of the object and the event) is clever, but it still boils down to understanding events and responding to events.
Thursday, October 18, 2001
My thinking is that a lot of programming languages have the OO support added as an afterthought.
It's the ambiguity that the students are having difficulties with, not OO concept in general.
Let me give you some example.
but then it is not very distinguishable with plain function declaration. What about declaration of methods within the function? And if you need to write class methods you have to digest the brilliant implemetation details of the language designer in how he designed the "prototype" to work around the problem.
Don't you think a language like Java which is designed from ground up as a OO language is easy to pick up for beginner either. There are so many unnecessary use of overloaded keywords. How to interpret "static" with respect to the context, variables, methods, classes? And the complicated indefinitly flexible inner classes and various short-cut syntax ? Pick up Bruce Eckels' book and walk through his "brain-dump", if you will.
(C# has improved upon Java in using some explicit keywords when necessary like "override", "virtual", "as" but then introduced another set of very confusing syntax)
I assume if I mention C++ this will take up another 2 pages.
To date I still have not seen a "perfect" OO language. I have the pleasure of learning small-talk as my first OO langauge which really helped me pick up the rest a lot!
Don't get me wrong, I'm not saying all of them are crap (I like Java and C# and they are over the par among all the OO languages), I'm just implying that a lot of these OO languages are polluted and are not very straight forward to map the whole OO concept in general.
In functional languages we have some excellent implementation like Scheme and Haskell. I hope that there would be some cleaner OO languages surface in the future.
Friday, October 19, 2001
In a related vein you might want to add "concurrency" to the list of difficult topics. (it took me a lot longer to learn concurrent programming than e.g. OO; but then again maybe that's just me). I assume most CS students would hit this first with interrupts in OS programming, and then maybe in the "real world" with multithreaded apps.
IMHO one big problem is the dearth of good learning resources on concurrent programming. Most sources I come across are fairly slanted towards the side of "multithreading can only improve performance, just stick some locks here & there and you're all set." I rarely see discussion of alternatives to threading, i.e. nonblocking state machines or coroutines*, and non-obvious problems like making libraries threadsafe, avoiding undesirable cache behavior in SMP machines, and managing resources in a multithreaded environment. (the never-ending stream of people on newsgroups asking "how do I terminate a thread asynchronously" proves the latter =).
It also doesn't help that Windows people and UNIX people rarely see eye-to-eye on concurrency, with Windows' heavy emphasis on shared-VM multithreading and UNIX's heavy emphasis on non-shared-VM multiprocessing and nonblocking event handling.
* exploring state machines was an enlightening experience for me, I think because it exposes the complexity of asynchonous event handling in a completely different way than multithreading. I highly recommend anyone who is used to multithreaded code to try state machines at least once (and vice versa).
Sunday, October 21, 2001
Fog Creek Home