William, > I sometimes wonder a little when "industrial relevance" comes up as an > argument for or against a teaching language ... is "industrial relevance" > desired for the sake of maintaining the students' interest, or for preparing > them for the "real world" (by which people normally mean the commercial world)?
In my experience it is both. "industrial (aka commercial) relevance" is basically a label for is this used by lots of people to create software. Using a programming language that is in plentiful use has the benefit that students appreciate the training they are getting. Also it allows examples that relate to the real world to be constructed easily and therefore avoid the problem of artificial examples -- which seem to be the biggest turn off for everyone, being able to see a connection to the world as it is is a powerful tool. The choice of programming language must be a balance between education and training. The language must allow the curriculum to be progressed naturally. This is why I moved from Pascal to C++ in 1985/6 despite the clear problems of the C++ language at that time. The issue was that I was having to pervert the curriculum because of the lack of features of Pascal. C++ allowed the education to happen and had the added benefit of being "industrially relevant". [...] > Even a new greenfield web project may involve all of Java, JavaScript, PHP, > Perl, SQL, and perhaps Flash. I think the issue here is that programming curricula must use more than one language if at all possible and further that programming with compiled and interpreted languages is different. Scripting with the UNIX shell is different from using Perl which is different from Usign Java which is different from using C++. Many of the same techniques and idioms are used but competance is in the ability to use all of them. > So to an extent, I agree with Ruven Brooks' assertion that the ability to > learn new languages is more important than a knowledge of particular ones that > are deemed "industrially relevant". This is absolutely correct. Real competance is to know the underlying principles in a way that can be applied using any programming language. This implies that C++, Java, Clean, Perl/Python, Makefiles, shell is an instance of a set of languages representing: compiled efficient procedural / object oriented, interpreted dynamically bound procedural / object oriented, declarative, programming scripting, job control declarative / procedural, job control scripting. It is a pity so many computer science departments focu on one programming language to try and teach everything. > However, it seems to me [pure opinion here] that the part of the issue lies > with recruitment -- for a programmer, picking up a new language is often > really quite easy; but HR departments tend to look for "X years Java > experience" on a CV, and recruitment agencies have been known to make an > initial sort of CVs simply by searching for the number of occurrances of the > technology they want (without reading the CVs at all at that stage). While > "industrial relevance" of teaching languages arguably might not be a factor in > a student's skills, is it a factor in the student's future employment > prospects? Interestingly the Association of C and C++ Users (ACCU) mailing list has just had a flurry on hiring and interviewing -- and what the questions should be to try and find out if the person is good or not. I myself have 4 months ago just gone through a hiring phase. It is clear that sifting CVs is a keyword search problem. There is also a look and feel problem. Because our primary programming language is a proprietary one that know one outside the company is allowed to know about (!) we cannot ask for X years experience. We are critically reliant on people ability to learn a new language and this is effectively our primary concern. For our environment we build using C++, Perl, Java, Makefiles, Assembler, Yacc/Lex (Bison/Flex) (and will get into VHDL and Verilog sometime soon) so we have to use this as the platform on which to assess people. It is the case that the more of these mentioned in a CV the more we have looked. The issue was to separate those who were being honest about their use of the keywords from those who were not. As we say in interview we have a model of a software developer and these are the skills but no one we interview will have all of them but we are looking for some now and all later, i.e. the person must first and foremost be a learner. We have found that performance in interview rather than any particular CV structure is the best indicator. How a person addresses questions relating to programming, programming languages and the challenge of learning a new language seems to have become our favoured metric. Of course this means ability to communicate is as important an issue along with ability to learn new languages as experience is. This leads to a need for computer science curriculum to be concerned with breadth as well as depth. I have always found it irritating that courses in comparative programming languages got dropped ostensibly due to lack of industrial relevance. I think too often the courses were either far too short introductions to each language or far too detailed in terms of the syntax and semantics of the language. I see the need for courses that compare how to solve certain problems in the different languages. What language can solve what problem. What different solution techniques are best used in certain programming languages. What is it about the computational model of a language that makes it suitable for certain solutions to certain problems and what solutions or problems are not possible with certain computational models or programming languages. This sort of scientific enquiry supports the need for people who can learn languages far better than 25 years programming in Fortran G. > On the purist academic side, Computer Science / Computer Systems Engineering > degrees are not simply vocational courses, so that should not be a strong > consideration. On the empathy-with-student-applying-for-jobs side, I can see > how a student would find it very useful to have some popular technologies to > put on their CV. On the practical side, this then presents questions of how > the market changes with supply and demand in new technologies -- eg, in > Brisbane, it seemed [again, no empirical data, though] a lot easier to find > work in C or Delphi than Java, not because there was less demand for Java, but > because there were so many Java programmers around. > > Of course, here I've been straying well away from the question of Java's > empirical usefulness for teaching particular computer science concepts! Java's main benefit as a teaching language is that it is popular. It has some warts that hinder initial teaching but because it is interpreted with dynamic binding lots of interesting things can be done quite quickly in a course. The library is extensive (perhaps too much so in some ways) and supports a high level of abstraction. It is generally founded on modern architectures and idioms and so supports the curriculum. C++ handled properly could do as well but after the in initial phases Java and C++ should both be used. I should note that whilst there are many people around who can program in a given language there are only few who are good. I would not use numbers to determine policy without putting some qualifiers on the numbers. -- Russel. ==================================================================== Dr Russel Winder Chief Technology Officer OneEighty Software Ltd Tel: +44 20 8680 8712 Cygnet House Fax: +44 20 8680 8453 12-14 Sydenham Road [EMAIL PROTECTED] Croydon, Surrey CR9 2ET, UK http://www.180sw.com ==================================================================== Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act One Eighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act
signature.asc
Description: This is a digitally signed message part
