الم تتلق العلم في معاملي، وتضحك وتبكي بين جدراني؟
إذن اخبرهم كم أنا جميلة!
كم أنا ذكية!
فقط أحتاج لمن ينفض التراب عن وجهي...
من يجدد شبابي...
ArchitectureThere's a book called "
The elements of computing systems" that attempts to go through all layers of a computer: starting from logic gates and building the hardware, assembler, compiler, operating system, and finally a Tetris game on top. The book even has prepared course material to teach with.
Will it be good? Will it be possible to give in a semester? I don't know, but seems worth examining.
Python, computer vision, and scientific computingThe problem with computer vision/image processing is that the set-up takes much longer than the fun parts. Students spend too much time learning how to load images, access pixels, do transformations,...etc
Python is a very high-level language, with very readable syntax (looks like pseudocode) and a lot of libraries. It currently has a gained a lot of users in the scientific community and got some excellent high-performance, high-quality libraries in these domains. It might be much easier to use in imaging/scientific computing than the current tools (C++, C#) and
some researchers are even using it instead of Matlab.
This is a list of common Python libraries for imaging/SC. The most famous is
SciPy, described as having "... modules for linear algebra, optimization, integration, special functions, signal and image processing, statistics, genetic algorithms, ODE solvers, and others. "
Another is
VTK (visualization toolkit), described as "an open source, freely available software system for 3D computer graphics, image processing, and visualization used by thousands of researchers and developers around the world."
Also, there's
SimpleCV, a set of Python libraries to make computer vision easy and straightforward. You can look at their
demos if you like.
Perhaps someone can have some experiments with these libraries and try to make use of them in FCIS subjects and/or projects.
Algorithm animation toolkitI don't know how useful algorithm animation would be in teaching algorithms, but it could be quite useful (algorithm animation = drawing each step in the algorithm one after the other while showing state of variables, content of arrays, ...etc).
I suggest creating a generic algorithm animation kit: it would be an interpreter for a small language (perhaps C-like), the TA would write the algorithm in that language and the interpreter (which knows how to draw an array, a tree, graph...etc) would run each step, visualizing along the way.
It's not that hard a project for someone who knows compilers. By the way it might be even more useful in the data structures course (e.g to explain insertion in a binary search tree) than algorithms.
First year & programmingLet's be honest: there are too many 3rd year students who barely know how to code (probably a lot of 4th year too). Even worse:
they haven't learned to make it easy for themselves.
What do I mean, not make it easy? I don't mean object oriented design or such, I mean the really simple things:
- Indenting code to know where each loop or if statement ends, to have no statement in the wrong place (e. outside the if instead of outside the while).
- Passing values as parameters instead of storing them as global variables or fields in the class.
- Giving variables meaningful names. I can't remember how many times I've seen variables called a, a1, c, instead of pixelsPerCentimeter, nameToEmployeeMap,...etc
- Not trying to really understand the problems, instead randomly changing things until the program seems to run.
- Not trying to plan their work: no sketching of solutions, no equations before coding, nothing but opening the editor and typing.
These things do not even require practice or extreme intelligence, they simply need to be
done.
So how do I suggest solving those problems? We could at least start by:
- Having TAs talk about these issues.
- Having TAs code in front of new programmers. All crafts are learned by watching: a young carpenter learns by watching older carpenters. A mechanic learns from his master. Programming might be a science but - like it or not - it's also a craft.
There is this belief among beginners that code is the final product: As if a programmer should read the problem, think real hard about it, and then write the code correctly. In such an imaginary world there is no need to indent code or give variables good names: the code is for the compiler to translate, not for a human to read.
In the real world you'll spend 10 or 20 times as much debugging the code as you wrote it. You'll ask TAs to debug the code with you. Neither you nor the TA wants to get lost in x,c,i,j or wonder where the while loop ends among those braces, or discover that the function depends on a global or member that he forgot about.
Just do what you can to make life easier.Structured programming: the subject that isn't :(I have a feeling that structured programming has never been taught in the faculty: they always would teach loops or pointers or the like: this is not SP! this is just
programming language features.
Real structured programming is about code having structure, i.e being decomposed into smaller components, being able to reason about each component separately of the others, then combining them into a larger program.
This is a sample of the stuff that should be taught in such a course:
- Decompose programs into functions
- Functions should be like mathematical functions: takes input from parameters and returns values. Do not call a function by first writing to a global var, calling it, and letting it read from the global.
- Don't let the function doing the calculation open a file, let each function do a specific job.
- Don't mix user interface (console or GUI) with the logic. This prevents reuse, among other things.
- A function should map to a unit of meaning in the problem (e.g draw_character, determine_if_monster_is_dead). Reading code should sound - in your head - like reading the solution of a problem.
- Think hard about the data, and also decompose it into structs, arrays,...etc. Those should also map to units of meaning in the program (car, deck_of_cards, salary).
Object oriented programmingAmong the syntax, the static methods, the class definitions, public & private,...the most important concept is forgotten:
objects.
Basically, the idea is that when a program runs, a lot of objects will be created in memory and will interact with each other by method calls. This simple idea - believe it or not - is virtually unknown to a large portion of students.
Don't believe me? Here are the signs:- It is very hard to explain to students what static is, even if it means just "Doesn't work on a particular object".
- It's very hard to explain the 'this' keyword, even if it just means "The object on which the method is called".
- Students try to call methods on C# forms without having a reference to the form. If compilation fails they create a new form instance instead of acquiring a reference to the active form.
- They have difficulty getting constructors, which are ways to create objects.
Basically, the students mostly memorize certain shapes of code and write them as-is. So how to solve the problem?
You can start by making sure the basic concept is understood: forget encapsulation, forget inheritance, forget public/private. First you got to make sure they get it:
- When the program runs, objects are created. They call methods upon each other.
- An object is not the class; the class is simply an 'algorithm' to create similar objects. All real work is with the objects.
- When writing a class, think about how the objects created from it will behave.
(This is similar to functions actually: a functions is separate from its activation. This is why the same function can have multiple activations in e.g recursion).
Also, before making them define their own classes, let them use existing classes in the standard library to do basic object operations: creating them, calling methods, setting them as fields in other objects, learn about references...etc
The advice that I just gave can be applied to all subjects in all years: Start with the simplest, most essential concept (structured = decomposition, OOP = objects...) & make sure they learn it before you continue.
Graduation project supervisionIt pains me to think about how much knowledge is
created, then destroyed all along the years in FCIS.
Think about how many times e.g Ahmed Salah supervised a GP related to computer vision: He recommends papers to students to learn imaging from, then more specialized papers related to the project's domain, then tutorials to Matlab. And then next year students come and he has to repeat the whole cycle again. The day he leaves for his Phd is the day less students will be able to work on CV projects.
Why does it have to be like that??Come on people! I'm not asking for some big, systemic change! Can't we have a Google document online for all TAs to copy & paste the names of papers that they gave to the students?
Then along the years, new students can be pointed to them to learn about the GP domain, interested people like me can use them to learn about new subjects. The information in preserved when the TA is away. New papers would be added if the existing ones get out of date. Wouldn't it be awesome?
The same can be said about code & documentation: We should sort the copyright issues then have all code and docs posted online, and enable searching for projects by name, problem domain (e.g augmented reality) or year. This would solve problems like
- "Has my project idea been done before?"
- "Why aren't more projects continued on and improved?"
- "We want a list of interesting projects to tell TV reporters, to make FCIS more known to society"
What I'm proposing here is
accumulated knowledge: Recording previous valuable knowledge so that it can be reused in the future. This is for example why books are such an important part of human progress.
Themes for graduation projectsIn 2010/2011 I
tried to introduce the idea of themes: a lot of GPs in the same general domain. The aims were:
- Encourage multiple teams to cooperate on common problems (e.g share papers that introduce NLP).
- Plant a seed of research groups in the faculty, when some of those students become TA. This would form research groups naturally instead of by fiat from management.
I think this idea should be revisited. Have two or three themes each year, and let TAs announce in a session 10 ideas or so for each theme (but allow students to freely work outside them).
ObservationDuring my last months as a TA, and in the summer training after I quit, I did something new to myself: I began observing.
I'd sit with the students during a lecture that another TA is giving and see how they react to different styles, or even when do they focus and when they're distracted. If I would do that now I'd also go to the labs and watch how they actually try to program and the things that are repeatedly not understood by different groups of people.
Perhaps as educators we need to take a more scientific approach to teaching, & base our decisions on data instead of personal opinions.
Speaking of scientific, perhaps we could look at research about the topic of teaching programming. For example there's an ACM special interest group called
SigCSE (special interest group, computer science education) where relevant papers are published. Also a lot of educators have blogs on the internet, and sometimes they write gems
like this for example.
Know your goalsRarely has an FCIS student been told: what is the purpose of your faculty, and why give those subjects in particular.
To improve the situation, I created this presentation: a tour of almost all FCIS subjects and the purpose of each, both science-wise and market-wise. If you haven't seen it already,
I suggest doing so.
EpilogueI hope some of those ideas turn out to be practical and useful. I think there's much more to be said in this area, and I might write a part II of this article someday :)
