About Our Lab

Since it's inception in the 1980s, the goal of the department has been to produce (high) quality software professionals (skilled programmers) for the industry as well as people tuned towards research in computing. A quick scan through our history shows that we have been successful in this endeavour. A major factor in this success was breaking down the artificial barrier between 'theory' and 'practice/practicals' and creating a computing laboratory environment which supports it. A copmuting laboratory which hums with activity ( not like a fish market ) but one in which students are working on programs along with interactions leading to exchange of ideas, fostering growth and learning. So, how is this engineered ?
(Almost) from day one students are expected to put the 'theory' learnt into practice, viz. programs. After the first baby steps of writing their first functions the students move onto larger and more complex programs across their stay here. Good practices of the 'programming' trade are picked up from the teachers, seniors and no doubt by burning their fingers by making mistakes. It helps in appreciating and cementing the theory put across in teaching program corrcetness and proving them as far as theory permits. This is complemented by exposing students to the works (source code) of the programming greats/masters which are available in open source. Not only is exposure provided, they are encouraged to modify and experiment, to test alternative designs. Failures, when they do occur are used to show up inadequacies in the design or invalidate proposed hypothesis, in turn leading to better designs or a better hypothesis. Fear of failure disappears. An additional benefit of making students work on large codebases is that it prepares them for the kind of work they will have to do in the software industry where the codebase may be open source or otherwise.
The computing laboratory and it's attendant software/services are dovetailed in the direction given above, viz. all software has to be open source so as to enable experimentation, modification and sharing with the community at large, excepting in the case of those few devices where the datasheet and/or programming interface has not been provided by the device manufacturer/vendor in which case a blob may be used instead. Software which does not meet the abovementioned requirements gets filtered out.
One class of computing devices (and it's bundled software ) are made for the 'end user' where it is assumed that the end user is not a programmer and using the device should be easy, intuitive to use and require negligible or no training where usage is very much limited. The other category are devices and software made for the programmer, the people who are expected to develop software for the above. The computing devices and their software for our computing laboratory naturally fall into the "for the programmer" category. The software products provided by technology companies are aimed at turning unsuspecting students into what is popularly termed as "coding-coolies" and/or "coding junkies" in the industry, hence we reject/avoid such software in our lab and in our teaching-learning environment.