Another average post! It's strange that your thoughts completely depend on your surroundings and your own behavior towards the happenings - in the days of failures and misfortunes, man thinks of higher forms of life and when he gets busy in worldly affairs, the thoughts revolve around petty issues of day to day life!
But sometimes specifics are as important as generalizations. So, on with the specifics!
I am taking three courses this quarter: Cryptography, Fault Tolerant Computer Systems and Functional Programming.
Cryptography is about encryption and decryption as most of you might already be knowing. The course covers classical ciphers as well as modern techniques with some basic concepts in cryptanalysis and the related Mathematical background.
Functional Programming, on the other hand, may be completely new for you. It's very different from programming in structured or object oriented languages. It's a declarative kind of programming where you define what you want to do and not how you want to do it. Those who are familiar with Prolog or SQL will be able to grasp the idea fairly easily because they are used to the environment executing things on their behalf. Still, functional programming is neither like Prolog nor SQL. It's Mathematical in nature where you define a Mathematical function for everything. There are no loops or if-then-else; in fact, there is no concept of a "statement" as such. A function may call another function, as usual. Recursion and set builder notation provide functionality similar to loops and iterators, respectively. The language being taught in this course is Haskell - the best compiler of Haskell is maintained by Chalmers itself!
Fault Tolerance may also seem interesting. Actually, there is only a single idea behind the concept of Fault Tolerance: Redundancy. Just as you can have a spare wheel in a car, you can have a redundant computer in safety critical computer systems. Like many other things, I think the pioneers of the field got inspiration from Nature. However, in design faults, where we don't get any guidance from Mother Nature, the idea of redundancy is useless. This is specially true for software. Such kinds of faults can only be tolerated by "n-versoin programming." The idea is to get the same component/ piece of code made by different vendors/ programmers. There is usually a voting mechanism in such a system. For example, in a 3-version system, 3 functions will perform some computation and provide the result to the voting system. The voting system will match and respond with the answer which is same from at least two of the three functions. If you are skeptical like me, you might have guessed that the voting system may itself fail! Unfortunately, like death, there is no way of preventing 100% failures.
Other than me, there is no one from Pakistan in this course. There are two students from India, two from Bangladesh, five from China, one from Taiwan, one from Macedonia, one from Romania and one from Poland. Amongst all these, Danko Ilik from Macedonia and Liang from China seem to be the best! But that would be a very pre-mature statement.
Ah...so you have done it that way! You are a very clever man!
(Daniel, the TA of Functional Programming course, responding to the explanation of my answer)