Note: This post is a continuation of post-comment: CS & IT Academia: Serious Systemic Problems?-ChittarComment
Thank you so much for your valuable comments, Chittar.
I am out of touch with industry picture nowadays but even when I was in the industry around a decade back there were Application Software (IT) jobs where a mix of domain knowledge of application and simpler programming skills were needed. Pointers, recursion, linked list manipulation etc. in languages like C & C++ were not needed for these kind of jobs. And Application Software (IT) was the biggest part of programming work in India.
I guess nowadays it must be similar with web/mobile programming (ASP.Net, Java, PHP etc. with databases like Oracle, SQL Server, mySQL) and Component Based Development using tools like Joomla, Drupal etc. being an important chunk of the application software business market.
But I think we also have significant amount of System Software (CS) jobs - even more than we had a decade back. And for these jobs far more solid programming knowledge is needed like pointers, recursion, linked list manipulation etc. in languages like C & C++. Of course other areas of knowledge like OOAD, databases etc. may also be vital depending on the work area.
I agree with you when you say, "I feel it is perfectly possible to maintain a balance between both theory and practice - after all - what one practices is better if it is based on solid theory." In the ideal case, both system and application software programmers should have a solid theoretical base - though this theoretical base would be different for system software and application software programmers.
While I was teaching in academia I was focusing on teaching programming courses only (Lab. courses) [my lack of appropriate academic qualifications did not permit me to teach theory courses and I was very happy with that as I enjoy teaching practical programming courses and am relieved that I did not have to teach theory courses :-)].
As you know, I learnt programming on the job. I started programming by learning and programming in COBOL in 1984. My first and most important system software programming language teacher, a year and a half or so later, was K&R 'The C programming language'. I read and re-read and re-read ... it over a period of years in parallel to me doing industry system software programming in C. I did read other books on algorithms, operating systems, computer architecture, object oriented analysis & design, databases etc. some of which, I found when I moved to Academia after 18+ years of industry experience, were still being used as textbooks for Computer Science theory courses.
But I have to thank the K&R C book for being the one that broke me into "solid systems programming" along with the superb programming style that it illustrated. By solid systems programming I do not mean writing production-quality OS kernels or a compiler or a TCP/IP protocol stack - availability of such work is pretty limited to few companies and an elite few work on it - I refer to possibly simpler but still systems programming stuff like writing production-quality SMTP gateways or process control simulators.
I have a statement to make [I don't think it is a confession but some CS puritans may feel that it should be one :-)]. I still don't know about Turing machines! I mean, I can learn about it if I want. But I have never felt the need to do so for my system software programming work. And, I think I was a decent programmer. With the huge amount of stuff that I had to learn to stay abreast in the ever-changing software field I generally followed a "need to know" basis about what I needed to study to get my job done decently. That policy gave me spare time to do other things in life as well.
Perhaps, even today, there are many software guys like me. They may be as good a programmer or even a better one as compared to a CS graduate who may be steeped in theory but lacks practical knowledge depth. The software companies choose whoever they feel are good enough to do the job and that's what matters, isn't it? If they choose wrongly they pay with poorer software solutions and may get creamed by the competition.
Okay, having mentioned my background, let me get on to what I think are the challenges for Academic CS & IT departments (in India) in terms of teaching programming. Design is also important but let me focus on programming - let's look at this MASSIVE challenge one step at a time :-).
Now I am not considering the elite technical institutions like IITs. They get the cream and so they can teach algorithms & data structures and allow the students to choose their own programming language and not teach programming languages. The students are very smart and so can, in all probability, pick up a lot of stuff on their own.
AICTE/UGC have the HUGE responsibility for setting guidelines/norms for vast number of mostly non-elite engg. & science universities & colleges in the country. I think it must be a very, very difficult task to come up with norms for a wide variety in terms of quality of students and teachers. Most CS departments of engg. & science universities in the country simply cannot take the elite techie universities like IIT approach and expect students to pick up computer languages on their own. I think it is very sensible for most CS depts in most universities in the country to teach a programming language course at the beginning of the curriculum.
'C' programming is taught by many CS departments as the first programming course at under graduate level. Many of the students are quite raw. I mean they have to be taught what is a memory location, a variable, program statement etc. They also need time to get familiar with using an OS like Linux (assuming C is taught on that). BTW many colleges still use TURBO 'C' to teach 'C' programming! [If you don't believe me, see the initial posts in this forum: http://cboard.cprogramming.
'C' is taught for 2 semesters. BUT typically a student may have to do many courses per semester - don't know the exact figure but could be five minimum. [I have taught programming courses primarily at M.Sc. & M.Tech. level and so am not exposed to UG - B.E./B.Tech./B.C.A./B.Sc. - curriculum so much.] 'C' programming will be a 'lab' course and other courses will typically be theory courses. Typically there are theory courses like Introductory Algorithms & Data Structures course taught at the same semester/year that 'C' programming is taught. These courses complement the 'C' programming course. However please note that students write 'paper exams' to pass the Introductory Algorithms & Data Structures course as it is a 'theory' course.
While I think the importance of this first programming course is recognised quite well by CS academia, the problem is that it is just one of so many courses. So time available for the course is not much even though it is a 2 semester course typically (e.g. 'C' & 'Advanced C'). And usually students are given liberal marks in 'Lab' courses and so some tend to take it easy. But they have to be scared about theory courses as they have to write many paper examinations on it. Can't really blame the students - in the student mindset, passing examinations are the key goals to be achieved - that earns parental approval - how much they really learn about 'C' programming does not matter so much, and, in fact, is even quite irrelevant as they get a decent grade in 'C' programming anyway, in terms of the overall academic evaluation system and, therefore, parental approval. You may be shocked but that's the way the CS/IT academic system in most engg. & science universities in the country works.
Topics like Pointers and recursion are certainly covered but I think most students do not do enough assignments on them. So their knowledge is quite sketchy and unsure about such topics.
Students think that such 'C' knowledge is enough and tend to concentrate on theory subjects (as tough exams have to be cleared there). Teachers may like to teach more but where is the time? Sometimes teachers themselves may not be really strong on complex topics like pointers & recursion. Anyway 'C' programming etc. is taught by junior teachers as CS professors have to focus on teaching theory subjects and research publications output and can't be bothered by trivial subjects like programming!
So students move through the system to the next year with assumptions being made that enough time has been spent on teaching them 'C' as well as introductory algorithms & data structures. Now they have to be taught other things in programming like an object oriented language, say, C++. The C++ teacher has to focus on features of C++ that are not available in 'C' and cannot spend much time on problem-solving or algorithm implementation aspects of programming - there is not enough time and that is supposed to have already been done in the 'C' programming 2 semester course and other theory courses like the introductory algorithms & data structures course, and so it is not the C++ teacher's job to focus on them!
Eventually the students may do a multi-threaded programming course and learn stuff like pthread prog. library and mutexes and condition variables. But they may still not be able to do K&R C programming problems involving intricate aspects of 'C' like pointers and recursion! That explains what you mentioned in your response. That is the unfortunate reality.
Is there any solution? I feel that lack of importance to Design & Code in CS & IT academia is the root problem. If Design & Code skills in CS & IT academicians is rewarded appropriately then we may have academicians themselves changing the system so that students learn programming better. The change has to come from within - UGC/AICTE policy makers have to facilitate that change happening by altering the REWARD/RECOGNITION system for CS/IT academicians. If the mindset changes then many possibilities can came into play - for example:
a) University CS teachers mastering 'C' and problem solving with 'C' language.
b) Senior university CS teachers teaching 'C' programming
c) If academia has shortage of teachers skilled in 'C' programming then AICTE/UGC norms being changed for CS/IT to allow non-research-oriented industry experts to become university teachers.
d) Time allotted for 'C' programming doubling so that students have ample time for learning and solving many complex programming assignments/problems. The additional time could be made available by dropping two theory courses.
e) Evaluation of 'C' programming courses becoming strict. Students may stop thinking that just 'traveling through' the course is enough to get a decent grade! If they are not upto the mark they could even be failed.
With these measures I think chances of students becoming quite proficient in 'C' programming and problem solving with it is quite high. Instead of 'C', the first programming language could be some other one but the issues raised & solution proposed would roughly be the same. I do not have any exposure to IT academia but perhaps they may prefer Java or maybe even HTML/PHP/JavaScript as the first programming language/language-set to teach.
Once the first programming language and problem solving with that language has been reasonably mastered then the student is truly ready for Advanced Algorithms (Design & Analysis of Algorithms), Operating Systems, Parallel Programming etc. theory courses. He can understand concepts of such courses more easily and he can read & write code to check out the concepts. Whereas if he does not have the programming language grasp, he understands the concepts of these kind of theory subjects at a much more superficial level and fails to translate the superficial knowledge of these concepts into understanding code or writing code - which is a terrible, terrible failure of the CS academic system. I am quite sure the IT academic system will have similar failures.
Now I must clarify that I am not against theory courses neither am I against research. I think theory is very important. But there has to be a balance between theory and practise - currently the CS/IT academic system is skewed heavily towards theory - this has to be corrected.
You wrote, "Defect-free programming by Design rather than by testing - and also do solid research in parallel, commercialise it and patent it. This for me is the proof of the pudding of balance. "
Very well put. But that is your view in your position in industry. Academia may have a different view.
IMHO, research is vital for society. Academic researchers and Industry researchers make tremendous contributions to society. But an academician's research interests or research goals should not come in the way of his duty as a teacher. Naive students should not be coaxed to do research as part of their CS/IT Bachelor's or Master's projects just because it will help the image of the academic institution that they are studying in. The students should be given complete freedom to choose to pursue a technology implementer/software engineering interest or a research interest. And some students may want to have both.
So, out of free choice, CS/IT Bachelor and Master degree students should get into two main groups categorised by their objective, namely:
a) "Defect-free programming by Design rather than by testing" with no research interest
b) "Defect-free programming by Design rather than by testing" as well as research interest
And for both groups. theory subjects (theoretical) knowledge is VITAL.
Some may say "Original Research" only with no or limited design/programming should be a third group. I feel that may be acceptable for a Ph.D. (or M.Phil. perhaps - I don't know much about M.Phil.). But, to me, a Master's CS/IT student doing "original research with limited design/programming" in academia would result in the student's exposure to "Defect-free programming by design rather than by testing" to be pretty low, which is highly undesirable.
I also feel that excellence in design & programming may be extremely helpful in CS/IT research. Just like vocabulary proficiency helps in fluent expression of ideas in a human language, research ideas in CS/IT can be fluently expressed into software with results to show, if the researcher is proficient in design & programming. But then that is my non-Ph.D, non-researcher view of the matter. A researcher may choose to dismiss my view as I do not belong to his Ph.D./researcher club :-).
Thank you so much for your valuable comments, Chittar.
I am out of touch with industry picture nowadays but even when I was in the industry around a decade back there were Application Software (IT) jobs where a mix of domain knowledge of application and simpler programming skills were needed. Pointers, recursion, linked list manipulation etc. in languages like C & C++ were not needed for these kind of jobs. And Application Software (IT) was the biggest part of programming work in India.
I guess nowadays it must be similar with web/mobile programming (ASP.Net, Java, PHP etc. with databases like Oracle, SQL Server, mySQL) and Component Based Development using tools like Joomla, Drupal etc. being an important chunk of the application software business market.
But I think we also have significant amount of System Software (CS) jobs - even more than we had a decade back. And for these jobs far more solid programming knowledge is needed like pointers, recursion, linked list manipulation etc. in languages like C & C++. Of course other areas of knowledge like OOAD, databases etc. may also be vital depending on the work area.
I agree with you when you say, "I feel it is perfectly possible to maintain a balance between both theory and practice - after all - what one practices is better if it is based on solid theory." In the ideal case, both system and application software programmers should have a solid theoretical base - though this theoretical base would be different for system software and application software programmers.
While I was teaching in academia I was focusing on teaching programming courses only (Lab. courses) [my lack of appropriate academic qualifications did not permit me to teach theory courses and I was very happy with that as I enjoy teaching practical programming courses and am relieved that I did not have to teach theory courses :-)].
As you know, I learnt programming on the job. I started programming by learning and programming in COBOL in 1984. My first and most important system software programming language teacher, a year and a half or so later, was K&R 'The C programming language'. I read and re-read and re-read ... it over a period of years in parallel to me doing industry system software programming in C. I did read other books on algorithms, operating systems, computer architecture, object oriented analysis & design, databases etc. some of which, I found when I moved to Academia after 18+ years of industry experience, were still being used as textbooks for Computer Science theory courses.
But I have to thank the K&R C book for being the one that broke me into "solid systems programming" along with the superb programming style that it illustrated. By solid systems programming I do not mean writing production-quality OS kernels or a compiler or a TCP/IP protocol stack - availability of such work is pretty limited to few companies and an elite few work on it - I refer to possibly simpler but still systems programming stuff like writing production-quality SMTP gateways or process control simulators.
I have a statement to make [I don't think it is a confession but some CS puritans may feel that it should be one :-)]. I still don't know about Turing machines! I mean, I can learn about it if I want. But I have never felt the need to do so for my system software programming work. And, I think I was a decent programmer. With the huge amount of stuff that I had to learn to stay abreast in the ever-changing software field I generally followed a "need to know" basis about what I needed to study to get my job done decently. That policy gave me spare time to do other things in life as well.
Perhaps, even today, there are many software guys like me. They may be as good a programmer or even a better one as compared to a CS graduate who may be steeped in theory but lacks practical knowledge depth. The software companies choose whoever they feel are good enough to do the job and that's what matters, isn't it? If they choose wrongly they pay with poorer software solutions and may get creamed by the competition.
Okay, having mentioned my background, let me get on to what I think are the challenges for Academic CS & IT departments (in India) in terms of teaching programming. Design is also important but let me focus on programming - let's look at this MASSIVE challenge one step at a time :-).
Now I am not considering the elite technical institutions like IITs. They get the cream and so they can teach algorithms & data structures and allow the students to choose their own programming language and not teach programming languages. The students are very smart and so can, in all probability, pick up a lot of stuff on their own.
AICTE/UGC have the HUGE responsibility for setting guidelines/norms for vast number of mostly non-elite engg. & science universities & colleges in the country. I think it must be a very, very difficult task to come up with norms for a wide variety in terms of quality of students and teachers. Most CS departments of engg. & science universities in the country simply cannot take the elite techie universities like IIT approach and expect students to pick up computer languages on their own. I think it is very sensible for most CS depts in most universities in the country to teach a programming language course at the beginning of the curriculum.
'C' programming is taught by many CS departments as the first programming course at under graduate level. Many of the students are quite raw. I mean they have to be taught what is a memory location, a variable, program statement etc. They also need time to get familiar with using an OS like Linux (assuming C is taught on that). BTW many colleges still use TURBO 'C' to teach 'C' programming! [If you don't believe me, see the initial posts in this forum: http://cboard.cprogramming.
'C' is taught for 2 semesters. BUT typically a student may have to do many courses per semester - don't know the exact figure but could be five minimum. [I have taught programming courses primarily at M.Sc. & M.Tech. level and so am not exposed to UG - B.E./B.Tech./B.C.A./B.Sc. - curriculum so much.] 'C' programming will be a 'lab' course and other courses will typically be theory courses. Typically there are theory courses like Introductory Algorithms & Data Structures course taught at the same semester/year that 'C' programming is taught. These courses complement the 'C' programming course. However please note that students write 'paper exams' to pass the Introductory Algorithms & Data Structures course as it is a 'theory' course.
While I think the importance of this first programming course is recognised quite well by CS academia, the problem is that it is just one of so many courses. So time available for the course is not much even though it is a 2 semester course typically (e.g. 'C' & 'Advanced C'). And usually students are given liberal marks in 'Lab' courses and so some tend to take it easy. But they have to be scared about theory courses as they have to write many paper examinations on it. Can't really blame the students - in the student mindset, passing examinations are the key goals to be achieved - that earns parental approval - how much they really learn about 'C' programming does not matter so much, and, in fact, is even quite irrelevant as they get a decent grade in 'C' programming anyway, in terms of the overall academic evaluation system and, therefore, parental approval. You may be shocked but that's the way the CS/IT academic system in most engg. & science universities in the country works.
Topics like Pointers and recursion are certainly covered but I think most students do not do enough assignments on them. So their knowledge is quite sketchy and unsure about such topics.
Students think that such 'C' knowledge is enough and tend to concentrate on theory subjects (as tough exams have to be cleared there). Teachers may like to teach more but where is the time? Sometimes teachers themselves may not be really strong on complex topics like pointers & recursion. Anyway 'C' programming etc. is taught by junior teachers as CS professors have to focus on teaching theory subjects and research publications output and can't be bothered by trivial subjects like programming!
So students move through the system to the next year with assumptions being made that enough time has been spent on teaching them 'C' as well as introductory algorithms & data structures. Now they have to be taught other things in programming like an object oriented language, say, C++. The C++ teacher has to focus on features of C++ that are not available in 'C' and cannot spend much time on problem-solving or algorithm implementation aspects of programming - there is not enough time and that is supposed to have already been done in the 'C' programming 2 semester course and other theory courses like the introductory algorithms & data structures course, and so it is not the C++ teacher's job to focus on them!
Eventually the students may do a multi-threaded programming course and learn stuff like pthread prog. library and mutexes and condition variables. But they may still not be able to do K&R C programming problems involving intricate aspects of 'C' like pointers and recursion! That explains what you mentioned in your response. That is the unfortunate reality.
Is there any solution? I feel that lack of importance to Design & Code in CS & IT academia is the root problem. If Design & Code skills in CS & IT academicians is rewarded appropriately then we may have academicians themselves changing the system so that students learn programming better. The change has to come from within - UGC/AICTE policy makers have to facilitate that change happening by altering the REWARD/RECOGNITION system for CS/IT academicians. If the mindset changes then many possibilities can came into play - for example:
a) University CS teachers mastering 'C' and problem solving with 'C' language.
b) Senior university CS teachers teaching 'C' programming
c) If academia has shortage of teachers skilled in 'C' programming then AICTE/UGC norms being changed for CS/IT to allow non-research-oriented industry experts to become university teachers.
d) Time allotted for 'C' programming doubling so that students have ample time for learning and solving many complex programming assignments/problems. The additional time could be made available by dropping two theory courses.
e) Evaluation of 'C' programming courses becoming strict. Students may stop thinking that just 'traveling through' the course is enough to get a decent grade! If they are not upto the mark they could even be failed.
With these measures I think chances of students becoming quite proficient in 'C' programming and problem solving with it is quite high. Instead of 'C', the first programming language could be some other one but the issues raised & solution proposed would roughly be the same. I do not have any exposure to IT academia but perhaps they may prefer Java or maybe even HTML/PHP/JavaScript as the first programming language/language-set to teach.
Once the first programming language and problem solving with that language has been reasonably mastered then the student is truly ready for Advanced Algorithms (Design & Analysis of Algorithms), Operating Systems, Parallel Programming etc. theory courses. He can understand concepts of such courses more easily and he can read & write code to check out the concepts. Whereas if he does not have the programming language grasp, he understands the concepts of these kind of theory subjects at a much more superficial level and fails to translate the superficial knowledge of these concepts into understanding code or writing code - which is a terrible, terrible failure of the CS academic system. I am quite sure the IT academic system will have similar failures.
Now I must clarify that I am not against theory courses neither am I against research. I think theory is very important. But there has to be a balance between theory and practise - currently the CS/IT academic system is skewed heavily towards theory - this has to be corrected.
You wrote, "Defect-free programming by Design rather than by testing - and also do solid research in parallel, commercialise it and patent it. This for me is the proof of the pudding of balance. "
Very well put. But that is your view in your position in industry. Academia may have a different view.
IMHO, research is vital for society. Academic researchers and Industry researchers make tremendous contributions to society. But an academician's research interests or research goals should not come in the way of his duty as a teacher. Naive students should not be coaxed to do research as part of their CS/IT Bachelor's or Master's projects just because it will help the image of the academic institution that they are studying in. The students should be given complete freedom to choose to pursue a technology implementer/software engineering interest or a research interest. And some students may want to have both.
So, out of free choice, CS/IT Bachelor and Master degree students should get into two main groups categorised by their objective, namely:
a) "Defect-free programming by Design rather than by testing" with no research interest
b) "Defect-free programming by Design rather than by testing" as well as research interest
And for both groups. theory subjects (theoretical) knowledge is VITAL.
Some may say "Original Research" only with no or limited design/programming should be a third group. I feel that may be acceptable for a Ph.D. (or M.Phil. perhaps - I don't know much about M.Phil.). But, to me, a Master's CS/IT student doing "original research with limited design/programming" in academia would result in the student's exposure to "Defect-free programming by design rather than by testing" to be pretty low, which is highly undesirable.
I also feel that excellence in design & programming may be extremely helpful in CS/IT research. Just like vocabulary proficiency helps in fluent expression of ideas in a human language, research ideas in CS/IT can be fluently expressed into software with results to show, if the researcher is proficient in design & programming. But then that is my non-Ph.D, non-researcher view of the matter. A researcher may choose to dismiss my view as I do not belong to his Ph.D./researcher club :-).
Great to hear your views. I guess we do not have much differences there. Just wanted to mention a few things:
ReplyDelete1) Having done almost all kinds of software development - applications, systems, backend, gui, analytics etc - I feel that the core element of all is simply PROGRAMMING - which subsumes analysis and design.
2) It is not necessary to know Turing machines or any similar theory to do excellent programming - defect free by design and computationally efficient.
3) But knowing Turing machines (Theory of Computation) brings a better understanding of what is possible and what is not - and ties algorithms down to their foundations - where one does not then worry about C or C++ or Java and whether any of them is superior to another or not.
4) The theory of Computational Complexity is a must for getting provably demonstrable efficiencies in execution - a context in which I can declare whether my program is efficient or not.
5) Extending the theory of Computation - one can understand and appreciate the genesis of loops or recursion in different models of computation and how they are equivalent to each other - and their strengths and limitations. For instance - though C is an outcome of the Turing machine model - it supports recursion which is borrowed from the Lambda calculus model and which does not come naturally on a Turing machine. Similarly, Loops of any kind are not possible in the Lambda model - and on which recursion comes naturally.
Advait, my elder son, is now in the first year of BE - and they begin programming in C. I have purchased K&R for him and told him to immerse himself in it. But apparently his lecturers view C - and programming - rather superficially. I hope I am able to guide him to understand and appreciate the beauty of this subject of Computation - theory and/or practical - and put it to use in his career.
I too belong to a non-PhD background - not even an engineer - just an ordinary BSc. And I have chosen to strive for the balance - irrespective of whether academia or industry approve of it or not.
I love the theory of Computation in all its aspects - and I love taking it further to solve practical problems of the industry.
Interesting comments about Theory of Computation and Theory of Computational Complexity. As of now I don't think I need to know them. This does not mean that knowing them will not help me - it is just a time vs. benefit issue for me. If I get the time and the inclination I surely will look them up. Of course, students in a CS course MUST study these subjects and also learn programming well.
ReplyDeleteAbout Advait's lecturers apparently viewing C and programming rather superficially - I think that is the impact of the serious systemic problem in CS/IT academia that I am writing about in these blog posts. I hope he does not become very strong in Theory of Computation but at the expense of being weak in C programming! The ideal situation would be a balanced strength in both Theory of Computation and 'C' programming.
Friend1 wrote (edited version):
ReplyDelete@Rajendra, your explanation of how Turing machines and in general models of computation matter was insightful. Thanks.
I'm with Ekalavya Sai that design is far more widely used and therefore important to teach than algorithms.
Programming Languages are equally important, too, because you want a powerful medium to express your ideas in. I disagree with the conventional wisdom that it doesn't matter what language you use. Paul Graham has an insightful essay on this: http://www.paulgraham.com/avg.html
From personal experience at work (and college projects), I'd much rather program in Java or Objective C than C++. After all, C is more productive a language than assembly, C++ perhaps more than C, and Java more than C++, so why would you think it stops there? To me an ideal CS curriculum would include one language per semester: start with Scheme (everything is a list), then Smalltalk (perhaps the most powerful and purest OO language), then Erlang (parallelism and fault tolerance), perhaps Haskell (lazy evaluation), Joy [http://en.wikipedia.org/wiki/Joy_(programming_language)] (why do functions need arguments?) and Forth [http://en.wikipedia.org/wiki/Forth_(programming_language)] (the stack is all you need). --- snip ---
Extremely important stuff to know, if you're laying the foundation for a career and preparing students for more than a code monkey kind of job. Not that every student must learn this stuff, but some should. The split between IT and CS matters here.
Advanced languages should be taught in college -- students are not going to go and learn them, because they are most likely not going to use them once they graduate.
As for AICTE/UGC setting norms, why don't they leave it to the universities? --- snip ---
I found your comment insightful -- the one about students neglecting C because profs go easy, are junior, or it's looked down upon compared to the more academic-sounding, stuff, etc.
Eklavys Sai' responded:
@Friend1: Scheme, smalltalk, Erlang ... I think you are a very intelligent person and so your views reflect a very elitist mind-set. I think that established mainstream languages like Java, C & C++ is what the non-elite CS/IT teaching institutions are comfortable with and can teach the average student. Can these institutions take up languages that you mentioned and throw out Java/C/C++??? I have serious doubts. Campus recruitment, I believe, is vital for most such institutions. Java,C, C++ skill set is acceptable, I think, to most 'bulk recruiters' like software consultancy companies. Besides, CS/IT academia worldwide use these languages extensively.
But elite tech. institutions may find your views interesting and may be able to follow them. I don't know enough about these languages or of the elite tech. institutions teaching environment and student capabilities to be able to comment any further.
Friend1 wrote:
ReplyDeleteI didn't know you were trying to drive policy change in a practical sense, with your blog.
Eklavya Sai responded:
I think my efforts to get influential CS/IT academic policy makers and ---snip --- to read the views on this blog post make me very careful about respecting POWER. Don't know whether I will succeed in academic policy makers viewing these blog posts. BTW I had anonymously (eklavyasai@gmail.com) mailed AICTE, UGC, NASSCOM, TCS & Infosys as well as Prof. Stroustrup the link of the first CS/IT post in this blog - no comments then - but I did not receive any response.
Now there is more relevant material on the blog with views from a few quarters - and there is some variance in the views too (tech. elitist, tech. commoner (or should I say, less elitist) educational institution etc.). At an appropriate time I intend to try again with Prof. Stroustrup (I have had an interesting mail exchange with him on his ACM article, in and around January 2010) and maybe a few others like Mr. Narayan Murthy/ Mr. Nandan Nilekani. If the latter do view the posts and agree with some of the views, then they may be in a position to put in a word to the AICTE/UGC bigwigs. Once again, I must mention that I really don't know whether I will succeed in getting Mr. Narayan Murthy/ Mr. Nandan Nilekani to read these posts.
Friend1 wrote:
ReplyDeleteAs for being elitist, yes, I was referring to IITs and the top tier of academic institutions (Stanford, MIT, etc). I wasn't saying that the average student be taught Smalltalk.
When I said that a CS curriculum should include Smalltalk, Scheme, etc, I was referring to a world where 95% of students would do IT and go on to take jobs at Infosys, etc, whereas 5% would take CS and work at Apple, Google, Microsoft, Facebook, Twitter, etc. But whether we want to call it CS or IT is not important (you can use whatever term you like :)). My core idea was that the best students should get a better education, to get a solid intellectual foundation for a career.
If anything they'll be in a better position jobs-wise, since a person who deeply understands Smalltalk, Scheme, Haskell and Erlang will easily learn Java in a couple of weeks at most, and probably have a deeper understanding of the language, too. Because these languages are the conceptual and intellectual peaks, and C++ and Java are just a watered-down Smalltalk, as I understand (I don't know Smalltalk, but do a bit of Ruby and Objective C, which are perhaps closer to smalltalk than java).
I didn't mean to say that C++/Java are useless in a practical sense. I agree that these are the appropriate languages to use 9 times out of 10, in industry, for reasons we both know. I was just referring to laying an intellectual foundation for brilliant students to build a career on top of, and my point is that Smalltalk better serves that purpose than Java.
Peter Norvig wrote this insightful review of a top-tier Scheme book: http://www.amazon.com/review/R403HR4VL71K8 It's only a page long, so I'd encourage you to read it. It captures better what I have in mind.
Eklavya Sai responded:
Could not squeeze the time to read the Scheme review link. Also, as mentioned earlier I do not know Smalltalk, Scheme, Haskell and Erlang. But I think you have put forward a pretty good case for brilliant students learning them instead of Java/C/C++. And maybe that would be around 5% of students. And so, it may make real sense for elite techie institutions to look at these suggestions.
But my suggestions are for the non-elite techie institutions! I think that is a crucial point. This is where AICTE/UGC norms are VITAL. In an earlier comment you had asked, "As for AICTE/UGC setting norms, why don't they leave it to the universities? ". My understanding is that AICTE/UGC have the HUGE, DIFFICULT and VERY UNENVIABLE task of improving the quality of teaching in the vast number of engg. & science universities & affiliated colleges in the country.
If universities were given unbridled freedom or just loose rules, given the great money maker that university education has become, the vast market of students, and the Indian penchant for bending the rules, you can well imagine the havoc that can occur in the country at large. I mean, degrees could get sold for money with everything else getting 'fixed'. That is the reality of our country.
So I think the system is that AICTE/UGC fix tough norms that universities have to follow to have AICTE/UGC (govt.) recognition. That's probably the only reasonable way for a hugely populated country like ours.
And AICTE/UGC policy makers have to worry about the 95 % of CS/IT students that you are not bothered with. And you cannot limit CS course to only 5 % brilliant students!
My posts and comments are about the 95% of students. I am not really interested in what should be taught to the 5 % elite students [and most of the elite students/elite techies may not be interested in my views either :-)]. There are others who cater to them like the IITs with MASSIVE government funding.
I guess you are an elitist techie and I am a commoner techie :-)
This post refers to a fantastic paper by Bjarne Stroustrup on teaching programming in academia: Texas A&M University's Approach to Teaching Programming in (US) CS Academia.
ReplyDeleteI was passed on a very interesting article, Teaching Programming to a Highly Motivated Beginner by a correspondent. The article is a fascinating one about an experienced teacher of programming teaching programming to an entrepreneur with experience in marketing, sales etc. but no computer programming experience.
ReplyDeleteSome points I particularly noted (and largely agree with based on my experience as a teacher/mentor of programming):
1. Approach of making Brian a pragmatic amateur programmer than an erudite computer science scholar.
2. Project-based learning being immensely effective as Brian cared deeply about his own fledgling creation.
3. The best way to internalize knowledge is first struggling for hours and becoming emotionally distraught and only then being helped by a mentor.
4. The mentor knowing that he has succeeded when his student realizes that he no longer needs the mentor as a tutor.