jfmiller call to our attention two professors emeritus of computer science at New York University who have penned an article titled Computer Science Education: Where Are the Software Engineers of Tomorrow? in which they berate their university, and others, for not teaching solid languages like C, C++, Lisp, and ADA. The submitter wonders whether any CS students or professors would care to respond. Quoting the article: "The resulting set of skills [from today's educational practices] is insufficient for today's software industry (in particular for safety and security purposes) and, unfortunately, matches well what the outsourcing industry can offer. We are training easily replaceable professionals... Java programming courses did not prepare our students for the first course in systems, much less for more advanced ones. Students found it hard to write programs that did not have a graphic interface, had no feeling for the relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging."
I have to agree with the article. At Uni I was taught java much to my detriment and annoyance (I had taught myself VB6 prior to going to uni so wasnt a newbie to programming).
I find I am now having to teach myself C++, and am struggling in a lot of areas that had I been taught in Uni I would be a lot more confident in.
My biggest gripe with my college experience (graduated 1994 - BS in CS) was that even though they were teaching the "solid" languages, they still didn't really teach me what I needed to know in order to do the job I do today (DB App development). Sure, things like Algorithms and Data Structures had some low level fundamental use, but they didn't teach me how to develop a SYSTEM.....most of my "projects" were simple "take some input - produce some output" programs.
Most of my professors had no real world experience, either. So, teaching things like team dynamics and working within a project schedule were really beyond their expertise. Granted, I've been quite successful, but I attribute most of that to my abilities, not what I learned in college. College just got me a piece of paper that opened the door.
I don't think the problem is with the languages being taught, but in the lack of true engineering being taught. This is true of any of the programming related fields (CS, MIS, SE). All of them need these skills.
I think there needs to be a distinction between learning concepts and the tools you use to learn them. I graduated from uni within the past 5 years, and they taught first year CS students in Java. They used these languages to teach data structure (ie stacks, dictionaries, etc) and some simple algorithms like sorting. At the same time, they taught us proper object oriented skills since that is what the industry is demanding.
During the second year we took a class that taught C/C++ which basically taught pointers and memory management. In my upper level courses like operating systems and graphics, it was all C and C++ from then on. I think this gave me a pretty well rounded education.
When I was done, I had used a number of tools (languages) to learn a variety of CS topics, and felt that I was well prepared for the industry.
by Anonymous Coward
on Tuesday January 08 2008, @08:32AM (#21952880)
I've been alternating between C++ and Python
Do more. Try doing your homework in haskell or lisp or hell, write in forth or postscript. It's a billion times easier to learn a language when you have someone else telling you what to do in it, and a billionth of the stress when your paycheck doesn't depend on it working.
I've wanted to learn ruby and rails for a while now, but I've got nothing to do with it at home, and like hell I'm going to show up at work and replace a production app with ruby for the hell of it, even though we've got a number of internal web apps that are basically exactly the kind of CRUD RoR was designed for.
I think a lot of employers advertise Java /.NET as a lot of employees believe that is the new thing and the way forward. i.e. C programming is on the decline, and (young to middle aged) employees don't want to get too far behind the times. Older employees might instead make a selling point of their skills.
I'm mainly a C programmer these days, but I took the job basically understanding that I would be working significantly with Java. That was the only language I had experience with on leaving Uni, and I was promptly put to work on a Pascal / OpenVMS system! Friends from Uni have had similar experiences.
I have been a bit worried about an outdated skillset as lots of employers ask for lots of object oriented programming experience and I only occasionally use this. I think this would be my primary problem if I started looking for a new job. I also think it's a bit unfair as the skills are pretty transferrable - there's only a little new theory to learn and after that, good programming practices aren't hugely dependant on language used.
In dealings with many (perhaps even most) other companies whose software I write interfaces with, it's pretty clear that they are also using C or C++, and often even older systems (in one interface we have to convert our messages from ASCII to EBCDIC). You can frequently tell what language the other system is from the sort of errors that crop up, and sometimes from the design of the interface. I'm forced to believe that my area of the industry is still primarily C based.
There are many jobs in.net and java yes. I hated Ada in school, and particularly difficult was FP. But once we got to assembler it all made sense. It was the guts of the system, and I finally saw how it all fit together. Once I saw data structures, and then had a look at how stack based code was generated from all of the other languages, I felt like I could learn any of the languages and not feel like I was using a black box. In my opinion, it's ok to learn java and C# in school after one has had a look at the internals, perhaps a primer in virtual machines. That would cover the bases of actually knowing how computing works, in addition to allowing for the preparation for job markets. One thing that's absolutely crucial to a computer science grad in the real world is being able to adapt to any language when needed, so all of this argument over which language to learn is a little off the mark. You should learn programming in general in school, and optionally focus on any language of the day for the market after you've become versed in the art in general. I realize that 'becoming versed' while in school is a little bit unrealistic as well, but if you've at least been exposed to the concepts at a lower level, it doesn't leave you scratching your head as much in practice when you can't figure out, for example, why your C# code makes a distinction between stack and heap allocated structures, and what impacts it has on performance and all that. It also means that when security holes are pointed out, or patched, you at least know what the hell is going on, and why it was a big deal to begin with.
Dijkstra did say that, and if the software world consisted of only theory then we could all get 90% for our efforts and be happy with that.
In practice systems have to work 100%, and when your graph search algorithm (by Dijkstra naturally) segfaults due to dereferencing a wrong pointer then computer science is very much about computers.
I'm just worried that too few students these days know assembly and C, which leaves us in a predicament when the current generation of kernel devs retire.
Anyone with a true gift to become a kernel dev has probably engaged in flame wars with his/her professors already, regardless of what she/he teaches.
Pointers aren't rocket science. If you never perform an operation where you haven't first met the operation's preconditions, you never get a pointer error.
If you aren't rigorously checking preconditions on *every* operation you perform, you're not going to cut it as a kernel dev anyway. Pointers are the least of your problems. Race conditions can become exceptionally hard to reason about. The prudent kernel dev architects the system such that this doesn't transpire. That requires a whole different galaxy of aptitude beyond not leaking pointers.
When I first learned C in the K&R era, I thought those greybeards were pretty clever. Then I came across strcpy() and I wondered what they were smoking that I wasn't sharing. I thought to myself, their must be some higher level idiom that protects against buffer overflow, because no sane architect would implement such a dangerous function otherwise. Man, was I ever naive.
More likely, too many of them had learned to program on paper teletypes, and just couldn't bring themselves to face having to type unsafe_strcpy() when they had reason to know it would work safely and efficiently.
The C language deserves a great deal of shame in this matter of giving many beginning programmers the false impression that any function call should dispense with formal preconditions.
Interestingly, if you sit down to implement an STL template algorithm manipulating iterators, it proves pretty much impossible to avoid careful consideration of range and validity.
OTOH, C++ makes it charmingly easy for an object copy routine, such as operator=(self& dst, const self& src) to make a complete hash of managed resources if you fail to affirm dst != src.
There are plenty of amateur mathematicians who can manipulate complex formulas in amazing ways. The difference with a professional mathematician is that the necessary conditions for each transformation is clearly spelled out.
A = B ==> A/C = B/C iff C != 0 A > B ==> C*A > C*B iff C > 0
Infinite series must converge, etc.
I'm not even getting into defining A,B,C as fields, groups, rings, monoids, etc. for maximum generality.
Yet the average programmer feels sullied to exercise the same intellectual caution manipulating pointers. I've never understood that sentiment. My attitude is this: if that's how you feel, get your lazy coding ass out of my interrupt handler; go code a dialog box in some Visual Basic application that won't work right no matter what you do.
Why did the software industry play out this way? Other professions have much harsher standards. Primarily because software was in an exponential expansion phase, any work was regarded as better than no work (perhaps falsely), and industry couldn't afford to reduce the talent pool by demanding actual talent.
Now we've allowed many people to enter the profession without comprehending the rigors of preconditions. It's as if we had taught a generation of lawyers how to practice law, but omitted liability. Oops. What to do about it? Invent Java, and tell all these programmers it wasn't their fault in the first place.
So yes, Java doesn't teach very darn much about the harsh realities of actually thinking. And since thinking is hard, it's an impediment to productivity anyway, so it hasn't much been missed. The only thing we lost in the shuffle is our professional self respect.
I thought to myself, their must be some higher level idiom that protects against buffer overflow, because no sane architect would implement such a dangerous function otherwise. Man, was I ever naive.
Naive about the purpose of C, anyway. C was never designed to prevent you from shooting yourself in the foot. Writing C requires you to think, which is sadly out of vogue these days, as you point out later. C was never designed to protect you from yourself, as explicitly pointed out by Dennis Ritchie many times. If you want a language that will protect you from yourself, program in VB.
So yes, Java doesn't teach very darn much about the harsh realities of actually thinking.
But C obviously does - like checking boundary conditions. I don't understand how you can slam C in one breath, then praise it in the next.
I don't advocate protecting the programmer from him/herself.
I do advocate designing primitives as essential to the language as the C string functions to powerfully remind the programmer using those functions of the programmer's logical obligations and support the programmer to reason correctly about those obligations, without having to digest 15 lines of preceding context to see that calloc() provided the implied terminating NUL.
There are several problems encountered when strncpy() and strncat() are used as safe versions of strcpy() and strcat(). Both functions deal with NUL-termination and the length parameter in different and non-intuitive ways that confuse even experienced programmers. They also provide no easy way to detect when truncation occurs. Finally, strncpy() zero-fills the remainder of the destination string, incurring a performance penalty. Of all these issues, the confusion caused by the length parameters and the related issue of NUL-termination are most important. When we audited the OpenBSD source tree for potential security holes we found rampant misuse of strncpy() and strncat(). While not all of these resulted in exploitable security holes, they made it clear that the rules for using strncpy() and strncat() in safe string operations are widely misunderstood.
We have had a lot of success explaining the issues and getting a lot of people to switch from strcpy/strcat to strlcpy/strlcat.
Weirdly enough, the Linux people are about the only major group of people that has constantly stayed deaf to these arguments. The chief opponent to strlcpy in glibc is most certainly Ulrich Drepper, who argues that good programmers don't need strlcpy, since they don't make mistakes while copying strings. This is a very mystifying point of view, since bugtraq daily proves that a lot of Linux and free software programmers are not that bright, and need all the help they can get.
The original C strcpy() could just as easily have had the semantics of strlcpy(), with insane_strcpy() provided to copy strings/trash core without a cycle wasted.
One must recognize that in a solid code base, thinking occurs more often while reading code than writing code. Correctness is not a write-only proposition in any living code base.
We came to the conclusion that a foolproof alternative to strncpy() and strncat() was needed, primarily to simplify the job of the programmer, but also to make code auditing easier.
The original C string functions were (and remain) a pedagodic disaster. Most beginning programmers failed to realized how much thinking had been folded into the surrounding context. If they were reading K&R, that thinking existed. If they were reading any code they had at hand, it likely hadn't, by any survey of average C code quality ten years later. With the original string functions, whether this careful thinking existed is not obvious without doing a lot of mental work, and that work has to be repeated *every time* the code is seriously reviewed.
Worst of all, the strcpy() function seemed to imply "buffer overflow is no great concern, we're not even going to give you a single argument on this very dangerous function to help you avert it". It was a false parsimony to save that extra argument in the default case.
This isn't at the level of whether the handgun has a safety or not. It's at the level of whether it is possible to chamber a round too large for the barrel. I can point the gun successfully, but I'd greatly prefer it not to detonate in any other direction.
A more thoughtful C string API would have averted mistakes on the magnitude of chambering bad ammunition, without encumbering the pointy end in the slightest, or failing to endanger the programmer's foot.
Exactly. C is best thought of as a very powerful assembly preprocessor. I know that sounds harsh but when I look at a chunk of C code I have a pretty good idea of the assembly language the compiler is going to emit. Even with C++ that works to a certain extent.
With Java and most other 'friendly' languages you have literally no way of knowing what is going on under the hood unless you are prepared to invest a lot more time and effort than is available to the average comp-sci student.
With C that's as close as a single flag on your compile line and you can study the generated code until you're tired of it.
Anyone with a true gift to become a kernel dev has probably engaged in flame wars with his/her professors already, regardless of what she/he teaches.
Piffle. You are equating software engineering talent with a propensity to participate in shouting (or its equivalent) matches. Those things are, to say the least, incommensurate.
If you aren't rigorously checking preconditions on *every* operation you perform, you're not going to cut it as a kernel dev anyway.
I disagree. Once a precondition has been checked once (on entry to whatever subsystem we're talking about) there is no need to re-check it all the time. Especially if it's an invariant of the algorithm. Sometimes such precondition re-checking gives rise to bugs anyway, since the negative arm of the conditional may contain code with a bug in it (though obviously using an assert macro will prevent that) - error cases get poor test coverage so such bugs may persist for a long time, too.
They aren't as valid once you've realized that abstraction is the key to tackeling complexity, that how hard somethings is does not equal it worthiness, that a language where even K&R wrote unsafe code is probably not for everyone and that not every architect needs to be a Michelangelo.
Different languages have different purposes, C has gravitated to a 'niche', system level stuff, situations where performance is more important than security (not everything is connected to the internet, impressions to the contrary). And - surprise - 30 years ago we were living in a different world security wise. The biggest problem with strcpy is not that it is 'inherently unsafe', it is that if you do not do proper input sanitation you can not rely on it.
This goes for most of the so called 'insecure' functions in C, they only become insecure if you have already messed up in an earlier stage of your code. If you are aware of the limitations of the standard library routines (even the unsafe ones) and you are operating in a 'hostile' environment (and todays internet certainly qualifies as such) then you'll need to take great care to accept only input that matches your assumptions in the code further down, if not you are in trouble. But good programmers will work like that anyway.
It's perfectly possible to write crappy code in *any* language, not just in C (though, in the words of one old timer programmer 'C is like a racecar, you can cut corners but if you do that too often you'll end on your side).
To come back to a fairly well thought out piece with an answer like what was written several levels above here is not in any way helping the discussion, it is simply insulting.
Yes, abstraction is key to tackling complexity. But equally, having no clue what happens behind that pretty Java code is the key to writing bad code and spending time debugging what you shouldn't even worry about.
Guess what? Even in Java, pointers still come to bite you in the arse when you least expect them. I see people every day who have trouble understanding the difference between "==" and "equals()" in Java, because they never learned the pointers behind them. They're essentially one abstraction level too far from understanding what their own code is doing.
Or even in Java learning why you can't modify an "int" parameter, but you can modify the contents of an "int[]" parameter, guess what? Requires pointers. People end up doing all sorts of unnatural metal contortions to remember when passing by value isn't really passing by value, when "it's a pointer" would sum it up perfectly.
And it shows. I've had people come to me half a dozen times with basically the same idiotic "auugh! Java's Hashtable is broken! I added a new value, and when I look into its array with a debugger it replaced my old one!" When in fact, it was only added a node to the front of the linked list. But they don't know what a linked list is, nor what a hash table really is, nor how a Node can contain another Node, without a concept of pointers. Worse yet, not only I see them spending a week debugging Hashtable, I see piss-poor workarounds done to prevent it from doing its job.
Or I see burger-flippers-turned-programmers occasionally get the real programmers fired for doing the right thing. Like using a "==" where it's correct to use it. But the burger flipper doesn't understand that. He learned some "for String use equals()" mantra, and he'll apply it and preach it, cargo-cult style, without even understanding what he's _doing_.
Or I see people think that optimization means replacing two lines with a one line call, because they have no fucking clue what the machine does with that code. They think that speed is measured in lines of code, because noone explained to them otherwise. So they wonder why their replacing two ifs with a catch is actually slower. (And I'm not getting into the many ways such a catch can make the code less secure, for example, by assuming that a real exception is just their loop reaching the end of the array.) Exactly what throwing an exception does, is a mystery to them.
Etc.
No, noone said you must keep programming in "a language where even K&R wrote unsafe code, nor that difficulty equals worthiness. But it helps to be at least exposed to those concepts once, even if thereafter you go on to program in Java or VB for the rest of your days. The fact that you worked with pointers once in C and managed to get them right, _will_ show in your Java code too.
Probably the best thing that helped my coding was doing assembly on my parents' old home computer, back in high school. In fact, in hex, because that ZX-81 with 1k RAM didn't even have enough RAM for an assembler. Wrap your mind around _that_, if you think C is too hard.
Would I advise anyone to write a production program in assembly nowadays? Nope, God forbid. I wouldn't have advised writing a whole program in assembly even back then. But understanding the machine behind that high level stuff will show even in your Java code.
And, yes, not every architect needs to be a Michelangelo. But it helps if they're not a clueless moron who can't even build a doghouse right. You can see plenty of architects nowadays who can't even get a basic house right. They know how to draw an artsy sketch of a house, but they have no clue how to calculate it to actually stand upright or what materials to use so it doesn't get damaged by rain within a year or two. And/or need a civil engineer to fix their elementary mistakes. Maybe it wouldn't hurt that much if they knew a bit more, ya know?
Just as an extra anecdote and illustration of what happens when such people finally get told about pointers (but still don't quite "get it"): one team's architect actually told everyone to use "Integer" instead of "int" in method definitions everywhere, because it's faster! See, it copies only a pointer instead of the whole int!
Yeah, that guy was quite a bit less than a Michelangelo.
Ok, I'm not a programmer, but a mechanical engineer, and I know precious little about programing, but I find articles like this very interesting. I was reading your post, and I stopped dead in my tracks here:
I think the authors are WRONG in saying that a university should be focussed on the academic
People don't go to the university to get real world skills, people go to the university to understand the foundations of their field, so that they can adapt their fundamental understanding to solving the problem at hand. People get certificates to learn routine use of employment friendly tools.
As I said, I'm not a programmer. I could (if I had to) model the frequency response of a simple mechanical system to a range of perturbations by hand. The chance that I'd have to do that in the course of my professional employment is so slim as to be laughable. Yet, the fact that I could do this (if I really had to) tells me that I don't want to put an eccentric load on a rotating shaft with out a lot of careful consideration. Now if I sort of knew this was a bad thing, but didn't really understand why I might to something silly like put only a single U-joint in a shaft. After all, it provides flexibility, and as long as the shaft is straight there is no eccentricity. The problem occurs when there is a deflection, then your single U-joint translates a nasty sinusoid down-stream. If you do that things tend to break.
Now, I agree that the university should have some courses focused things that practicing professionals in the field use. I could draw a part by hand (if I really had to), but if I've never seen CAD before, I'd be at a serious disadvantage if I ever wanted to be a machine designer. However, fundamentally, a university is an academic institution. The suggestion that it should be an employment mill would severely compromise our education system.
Last year I was in the decidedly odd position of having to teach third year CS students (who had primarily used Java), what pointers were, how memory allocation worked, and how to use C.
That they didn't know C wasn't too surprising. That they didn't have more than a basic grasp of memory management was shocking. They were also completely baffled when it came to not using an IDE to develop software. Makefiles had to be explained several times.
I've grumbled many times about this concentration on Java, and the resultant lack of detailed understanding about programing, but each time I did so at my university I was disregarded, and someone always trotted out that age old nonsense "not re-inventing the wheel".
I mean, sure, I see the point, but surely you should have a basic idea of how wheels are made?
True. Besides, the idea that Java is damaging to students is pure bullshit anyway. If the students are learning the Java way to do things, and nothing else, then they have horrible professors. I learned CS from good profs (well... one good and one bad), and surprise, even though I got my start in Java, I am perfectly capable of doing things in other ways.
When I took data structures, and we used C++, I didn't have mental convulsions because Java had wrecked up my thinking so much (although I did have mental convulsions cause C++ is incredibly messy to read at a glance), I learned different ways of doing things. So, maybe these professors should look at whoever's teaching these kids so sloppily, not the language.
unfortunately he doesn't go far enough into the core of the problem, which is today's universities are mass producing what employers want, rather then the thinkers of tomorrow.
employers want nothing more then easily replacable drones who come with an easily definable skill set which they can replace when a new buzzword comes along. this is NOT what universities should be pandering to.
In Australia, universities are spewing out people who can pass a test but cant think in programming terms to save their life.
I was rolling on the ground laughing when I saw the problems people were having making a simple Sudoku program in C#. Once they were done drag/dropping all the UI elements, they all got stuck.
Mind you your right about they are teaching what they think employers want. We didnt get to see a *nix system let alone use one. Although that may be because of that rather large donation Microsoft gave.......
It's just the usual senseless Java bashing. It has ZERO to do with Java. If the students are taught VB or C# and nothing else, like it happens in my country today, the problem is the same.
And because it's like that, you have heap allocations for every non-atomic data type, which is really the opposite of performance. Need a simple int[2] for the pipe(2) syscall? (let's just assume it, even if Java does not have)?
try {
int fds[2] = new int[2];
pipe(fd);/* still check return value */ } catch (memoryAllocationErrorOrSo) {... }
Why does this need to be so complicated [...]
It doesn't. You've made it more complicated than it needs to be, by putting in an exception handler. What are you going to do in the unlikely event that there is an exception, anyway - fix it somehow? Free up another 8 bytes of memory to make room? Just remove that try statement, and let the exception be caught by your top level handler.
And then there is this garbage collector that professors swarm about. Does it handle circles?
Yes, it does. It's not a reference counter, it's a garbage collector. It collects garbage, i.e. any heap object that can't be reached by following a chain of references from a root reference (like a local variable, a static field, or an instance field of any non-garbage object). A modern GC won't be fooled by two garbage objects holding references to each other.
Java programming courses did not prepare our students for the first course in systems, much less for more advanced ones. Students found it hard to write programs that did not have a graphic interface, had no feeling for the relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging.
Yeah, I just read a press release from the FAA blasting driver training courses. Apparently, flight students who just got their drivers licenses were not able to navigate in the air, execute banks, take-off, or land properly.
Students have to start somewhere. It's easier to start with simple stuff than to try to cram their heads full of everything all at once.
Don't be silly. Flying an aircraft requires a whole new set of skills, that are outside the normal experience of most people. Driving is not just flying with a number of 'security enhancements', whereas programming in Java is like programming in C, but without the need to learn about pointers or good programming discipline. So if C is like a manual car, Java is an automatic.
It is reasonable to expect that a CS student has both the ability and the interest it takes to learn all the details of programming well in C.
I started programming in Pascal, and then moved to C/C++. Structured programming, language syntax, variable typing, functions, parameters, recursion, etc I could ALL learn in Pascal.
When I came through Java was still pretty new, but I did take a java course, and found it reminded me a more of Pascal than C/C++; I'd say its a good starter language.
Also you can easily write command line apps in java, so i don't know why they blamed gui dependancy on java.
And as for 'systems programming' well DUH. Your first language is where you learn the basics of programming, before you start taking systems programming you should also have a lower level course ideally in something like assembly language (even if its just on emulated hardware) or C.
C->C++->assembly (any ISA)->some functional language->some other language (Java, python, ruby, etc).
Assembly is necessary, to understand how a computer really works. Functional languages are good, just to know a completely different style. Some other language for breadth. Then the student can realise that everythin after asm was a waste of time, and return to C.
C->C++->assembly (any ISA)->some functional language->some other language (Java, python, ruby, etc).
Assembly is necessary, to understand how a computer really works. Functional languages are good, just to know a completely different style. Some other language for breadth. Then the student can realise that everythin after asm was a waste of time, and return to C.
This is kind-of bollocks.
When I was a young programmer - which is about twenty-five years ago - the team I was on got a new ink-jet printer. It printed its own character set, we needed it to print bitmaps. The processor it used was one none of us had ever worked with before. One of the older members of the team - a guy called Chris Burton - took the spec sheet for the processor and the spec sheet for the printer home with him on the train, and came back the next day with the code for the new printer driver written in long hand, not in assembler mnemonics but in actual op-codes, in pencil on a pad of paper. It was burned on an EEPROM that day and drove the printers until that model became obsolete five years later - there were no bugs, it never needed fixing.
It should be said in passing that Chris had worked in his youth on the Manchester Mark One [wikipedia.org], and after he retired was part of the team that rebuilt Baby and got it running again.
I've always thought that was epic programming, a standard I'll never reach. But it's one particular layer on the stack. My job on that team was writing inference engines, and Chris was always really impressed by that. It's nearly thirty years since I touched any assembler and fifteen since I wrote anything serious in C. A modern computer system is way too complex for any single person to really understand, in depth, all the layers. I take what the silicon designers do as given, and likewise the microcode programmers. Right back in the early days of Linux I did fix issues in kernel code a couple of times but I wouldn't even try these days - the guys who do that are much more expert at it than I am. Likewise, I don't expect them to understand the compiler compilers that I write. It's a different layer on the stack.
I agree that you need to have a rough idea about how the whole stack works. But we no longer expect all computer science students to be able to wire up NAND gates from discrete valves or transistors. And although a computer scientist needs to know that there are primitive logic operations carried out on the metal, and that on top of that there are a stack of different software layers with real machine code on the bottom and a whole slew of intermediate code representations above that, I don't believe that it is any longer necessary for all students to be able to write a serious program in assembler.
If they teach you only one programming language, yes, they damage you.
In the course of my CS education (early 90s), they started with Pascal when they explained algorithmical basics. Later courses were in C for OS and networking, while other courses used about everything from PROLOG to ADA.
You learn that some paradigms map to certain types of problems better (or worse) than others. So don't open sockets in Prolog (I have seen'em do it man) , and don't do AI in C.
a quote: "if the only tool you have is a hammer, every problem looks like a nail".
Robert B.K. Dewar, Ph.D., is president of AdaCore and a professor emeritus of computer science at New York University. He has been involved in the design and implementation of Ada since 1980 as a distinguished reviewer, a member of the Ada Rapporteur group, and the chief architect of Gnu Ada Translator.
Edmond Schonberg, Ph.D., is vice-president of AdaCore and a professor emeritus of computer science at New York University. He has been involved in the implementation of Ada since 1981. With Robert Dewar and other collaborators, he created the first validated implementation of Ada83, the first prototype compiler for Ada9X, and the first full implementation of Ada2005.
Maybe Ada is helpful for learning concurrent programming and safe typing, but I'll wait for the opinion of a slightly less partial party.
I'm a slightly less partial party. I've taught Ada to first year students, and our school replaced Ada with Java. Some observations are...
Students found Ada a relatively simple language to start with (if you choose an appropriate subset)
Java can have more overhead for a beginning student
Lecturers are often tempted to push a lot of "stuff" in intro subjects
Java GUI motivates some students to get more involved
Many of my students regretted that Ada would no longer be taught in first year (having quite enjoyed it)
No matter what you start with, teaching students to be better programmers takes more than just a language. Each language allows you to teach a specific set of skills, and Ada is not bad for teaching some important SE skills (IMHO).
I think pointers are overrated as a first year concept, and can wait for later years.
As someone who programs mainly in java, I have to say they have a point. Surely a degree in CS should get someone familiar with all forms of higher order programing (both OO and functional). They should also have a reasonably solid understanding of basic hardware architecture and how that affects programs.
Unfortunately this does not seem to be the case at least in NZ. Some don't even know about basic complexity ideas and often have little to zero mathematics under there belt.
I did not do CS but physics. I was required to do Assembly,basic,C,matlab,R,Lisp,Java,C++,Haskell and a bunch of others I don't care to mention (Like PLC's and FPGA stuff).
Where I go to school [rose-hulman.edu], just this year we switched from teaching the introductory classes in Java to a combination of Python, then C, then Java. I think that this is much better than using any particular one of those languages the whole time. It gives the student experience with more different concepts and from that I think they can begin to see how everything works together. Also, starting with something simpler than Java/Eclipse seems to make it a lot easier the first few weeks of the course.
One thing I have noticed though, is a complete lack of security related training. Something about calling eval() on every input just to parse integers makes me cringe. I guess the idea is that worrying to much standard practices keeps people from thinking creatively or something. Unfortunately, it also seems like a good way to get into a lot of bad habits.
OK, this hit one of my hot buttons. Before I continue, though, let me preface my statement by saying that I don't disagree with the article (which is right on the button). But I disagree with the way the summary characterizes the situation.
I totally agree that universities shouldn't be teaching Java exclusively. They need to teach the basics of modular, functional, declarative and oo languages. Why? Certainly *not* to fill "software engineering" positions!!! A university's role is to do research, not to act as some technical college. OK, I can see having a programming course aimed at creating programmers for industry if it's going to pay the bills at the uni. But *don't* make that your "Computer Science" course!!
Computer Science should be science (well, math anyway). Universities should be getting the 5 or 10 graduates they need that will move on to academia (or industry research) later in their careers. Because right now, *nobody* is getting taught Computer Science! Lately I've been reading papers posted on http://lambda-the-ultimate.org/ [lambda-the-ultimate.org] Regularly I have to go back to the basics and learn extremely fundamental theory because nobody *ever* taught them to me in the first place. Half the time I think, "OMG, I never even knew this existed -- and it was done in 1969!!????"
More and more lately, I've been wanting to phone my University up and ask for my tuition back.
If you want to learn how to program in a professional setting, there's nothing better to do than just start writing code. Get your chops up. Then find some big free software projects and start fixing bugs. Learn how to use the tools (configuration management, etc). Learn how to interact with the other programmers. That's all you really need (well, that and a quick automata and grammar course so that I don't have to look at yet another context free grammar being "parsed" by regular expressions).
But right now, where do you go if you want to actually learn theory? I guess the library... And getting back to the point, this is essentially what the paper is suggesting. Students need to learn all these things because they are relevant to the field. A university supports industry by doing basic research. If you don't understand the concepts that they point out, you just can't do that. Paraphrasing from the article, having a university course that's meant to pad out a student's resume is shoddy indeed.
I am a headhunter for high end roles at investment banks, and we are close to classifying CompSci as a "non degree", along with media studies, languages, etc.
Java is fine for teaching design patterns, and classical algorithms like Quicksort, or binary search. But you can't do operating systems, and the success of Java in isolating you from any notion of the hardware is actually the problem. We have already blacklisted courses like the one at Kings College, because they teach operating systems in Java. Yes, really. Their reason apparently is that it is "easier". I have zero interest in kids who have studied "easy" subjects.
The world is a bigger, more competitive place, how many jobs do you think there are for people who have an easy time at college ?
Java is part of the dumbing down of CS. A computer "expert" is not someone who knows template metaprogramming in C++, or compiler archaeology in BCPL, or the vagaries of the Windows scheduler. It is someone who understands computers at multiple levels, allowing them to choose which one illuminates the problem at hand. To be wise in computers you choose whether to think of something as a block of bytes, quadwords, a bitmap, a picture, or a buffer overflow pretending to be porn. If also have the option of understanding flash vs static RAM, virtual memory, or networked storage, all the better. I doubt if even 1% of CS grads could write code to turn this BMP into a JPG, or even explain the ideas behind this. In my experience, 50% could not work out how to develop a data structure for a bitmap that used palettes. I have interviewed CS grads with apparently good grades who could not explain any data structure beyond arrays.
Any CS grad who sends us their CV with bullshit like "computers and society" or "web design" has their CV consigned to trash with no further reading. A CS should be able to write a web server, not be an arts graduate who didn't get laid.
C++ makes you think at multiple levels, unlike Java, you simply cannot avoid thinking about your system from patterns to bytes. This may be good or bad for productivity, and I'm sure we risk a flame war here. But I am entirely convinced you need to hack your way through a "real" system.
How can someone understand the Linux kernel without C & C++ ? Is someone really fit to be called a computer scientist if like >50% of the Computer "Scientists" we interview for very highly paid jobs, show actual fear of working at that level. They have the same "way above my head" attitude that a mediocre biologist might have to applying quantum theory to skin disease.
Partly, as in the Kings College debacle it is lazy mediocre lecturers, but also CompSci grads frankly are not that smart, so they need their hands held. Although the seats get filled, they quality is in monotonic decline.
Java is the new COBOL. And we will regret it in 20 years for much the same reasons.
It actually gives me hope that you have recognized this in hiring practices. That a CV with a list of Sun's Java buzzwords is not an indication of a useful programmer.
I was disturbed in college (1997-2001) that things were changing towards Java and other idiocy. Too many people didn't get pointers and other basic concepts, and Java was hiding them even more. I believe it was the one class we had in assembly programming that really pointed it out - when confronted with having to deal with real hardware, most of the students didn't know what to do. Concepts like "two's complement" vs "one's complement" caused a strange brain-lock for them, as they were so sheltered from the actual binary math and hardware of the computer.
It was only a handful of us that had been programming for years already (yay for the Atari 800XL) that had any idea of what was going on. The college (UC Davis) skipped entirely over very basic concepts like Von Newmann Architecture. I ended up having to spend most of my time trying to help my fellow students, there was so many fundamentals missing.
I think the most frightening part was having to yell at one of the professors one day, because the basic data structures he was teaching were being done incorrectly. He was teaching people to leak memory. ("Let's allocate a huge linked list, and then just set the head pointer to NULL and consider it freed!")
Sigh. It was frightening then, and apparently all my fears were justified, as now the entire discipline is getting a bad reputation. Unfortunately, I can't exactly disagree with that reputation from some of the CVs I've seen recently. My degree is destined fscked, apparently.
I'm kind of a proponent of having a student's evolution mirror the industry's, to an extent. Start them with C and then gradually introduce problems that were more and more difficult to solve in C. That way, when you show them C++ or Java, they can appreciate why these languages were needed and what classes of problems they're appropriate for and more importantly, what they're not appropriate for. But to really appreciate these things, you have to have students implement their own little OO runtime in C or whatever other procedural language. You can bet that after that, by the time you show them a true OO language, they'll know plenty about OOP, and things will just come more naturally.
These students are being trained as engineers. They shouldn't be afraid of a little grease.
The better CS undergrad programs don't really teach languages per se. The main focus of the curriculum should be the theoretical underpinnings of computer science, combined with the practical aspects of software development. Since languages themselves are part of the practical aspect of software development, in addition to also being the focus of some computer science theory, it is unavoidable that languages should themselves be studied to some degree, and also used to a large degree to practice the theory that is being taught. Most theoretical CS only really needs 'pseudocode' to illustrate the concepts being discussed. But since students are often asked to write programs to demonstrate their understanding of the subject matter, a real language is unavoidable. But the language itself is secondary to the real meat of the subject, which should all be mathematical and theoretical in nature.
At CMU the very first CS class (that losers like me who didn't AP out of the first CS course, mostly because my high school didn't even have computer classes let alone AP computer classes!) really did focus on teaching a language - Pascal - and a significant part of the class was the learning of the language. It was the least useful CS class I took in the long run (not surprising, as an introductory course in any subject is likely to be the same). Subsequent courses would spend 1 - 2 weeks going over the fundamentals of the language to be used in coursework for the remainder of the class (which in some classes was C, in some was C++, some used ML, others Scheme, etc), to get everyone started, and after that, you had to figure it out on your own in conjunction with actually learning the theory that was being taught. It really isn't that hard to pick up a new language once you know a couple, although I did have a hard time with ML, mostly because I was completely unmotivated to learn it, feeling that it was absolutely useless to know (I was right).
No really good CS program has any classes with names like "Java 101" or "Advanced C++". To use a carpentry analogy, I would expect a really good carpentry school to teach the fundamental rules and "theory" of carpentry, so that the student upon graduation really understood what carpentry was all about and could apply their knowledge to aspects of the subject that they hadn't even encountered in school. I wouldn't expect a good carpentry school to have classes like "Advanced Hammering" and "Bandsaw 101". The courses would instead be "Introduction to House Frames" and "How to Construct Joints". You'd be expected to learn the use of the tools in the natural course of studying these subjects.
It's the same for CS. Good programs don't teach the tools, they teach the *subject*; learning the tools is intrinsic in the study of the theory.
I you make everyone special, nobody is really special.
Every time someone tells me that there are no pointers in Java I laugh a little. EVERYTHING in java that isn't a scalar is actually referenced through pointers. That is, you declare the pointer variable and then "new" the object into place.
They are just incredibly _boring_ pointers. You cannot math on them. There is no sense of location to those pointers. But the absence of interesting pointer operations, and the absence of the _semantic_ _copy_ operation is what all this alleged pointerlessness is all about.
I have only two _Real_ problems with java... (okay three if you count the complete requirement that you constantly have to deal with exceptions even when you know they cannot really happen, and if they did, you would want the thing to abort all over the place... but I digress)
(1) Java has no useful destructors because no object has predictable scope. If you think finalize methods are the same as destructors then don't bother responding, you don't know what destructors are...
(2) Since everything is a pointer in Java, you have to bend over backwards to pass-by-value. The fact that the language doesn't even begin to provide copy-construction semantics. What a miserable PITA.
Now the _dumbest_ thing about java is that they were so set against multiple inheritance that they never bothered to ask themselves why _every_ OO language starts out life without multiple inheritance only to have to add it later. By making everything a proper linear subclass of Object, they left themselves with having to graft on "interfaces" which is just multiple inheritance with the "bonus" of completely preventing default implementations. (Which lead to delegation etc.)
The way the language keeps sprouting things it claims to never have and never need, well it's very like watching a clown car endlessly explode with ridiculous archetypes. After a while it just isn't funny any more.
So yea, teaching people Java as an introductory language is something of a disservice if you ever want to make them truly think about programming and what makes some things machine smart, while others are machine stupid.
--- BUT ---
I worked in education for years. The fundamental problem with computer science education is that it is being taught by computer scientists instead of educators. We are stuck learning from the people who learned from the people who made it up. None of these people ever learned to EFFECTIVELY IMPART INFORMATION.
Consequently, the students are largely unemployable on the day of graduation.
The classic computer curricula seems to consist of throwing three or four languages at a kid in the hopes that they will "just kind of figure out this programming stuff."
The field of computer science has not yet come up with a "basic theory"... a starting place... The list of things a student simply must know before you start filling their head with syntax.
And so we are a bunch of prelates training our acolytes in our special, individualized deeper mysteries.
And that's what everybody is doing worldwide, so our graduates are just as lame as everyone else's...
99% of what you learn as a programmer you don't learn at college anyways (at least the people who don't totally suck at programming). Furthermore, unless you have one-on-one mentoring from a senior programmer or professor who has at least 10 years of solid professional coding experience under their belt, not much else is going to help you other than you and yourself in maturing as a programmer.
Most CompSci college graduates are totally unproductive on their first job. They can be put to work on trivial things, but no matter what school they came from, they are just going to need a lot of hand-holding to make it through the first year. That is just how it is. Doing coursework at school is no substitute for coding on a meaningful project, whether it be work related, something open-source related, or just something for fun. That is the honest to god's truth as a software developer for over 12 years now and I don't even consider myself even that wisened in the field (maybe after 20 years I will feel differently).
Now, with respect to Java as an introductory programming language, it is not bad but not great either, however the purpose of any introductory course to anything should be to capture the interest of the people who are curious enough to take the course in the first place. Back in college, we started with C (most of my peers had already been programming since they were teething but this was CMU) and if not for my persistent no quit attitude in life, I probably would of given up programming right then and there because spending your entire night trying to debug a trivial program not because you didn't understand the material but because of one stupid uninitialized pointer turns a lot of people off right then and there who may have had the potential to be great programmers, but because their first impression of programming was so bad, they gave it up before they got to learn more about how great programming really is.
Oh yeah, and the not relevant at all math courses didn't really help much either. Whenever in your career you need to use some advanced calculus or discrete math, you will have likely forgotten about 99% of it and need to look it all up in a book anyways. Besides, 99% of programming projects in the real world basically involve high school level algebra and not much else. What separates the productive programmers from the unproductive ones is not who got a better grade on their math course back in college, but those who innately understand systems and are willing to make the extra effort to learn all about the gazillion design patterns available to programmers so that when they are faced with a difficult project, they will not waste inordinate amounts of time reinventing the wheel.
As for understanding computing at a rather low-level, as is the case with a class in operating systems, then yah Java might not be such a great choice, but then again learning C is easy because C is made up of very simple constructs (C++ is another story). However, using C productively just requires a crapload of practice/experience to be good with, not necessarily a whole lot of computing expertise. In addition, the mastery of whatever API's you happen to be basing your career on is paramount as well. In the real world, employers don't want to hear "but I can learn anything quickly" because mastering some API's can take 6 months or more so if you come out of university with no specific skill sets, it is going to be really hard to get that first job because unless you can be productive soon (or even on day one), you are useless as far as employers are concerned. Also, though I don't program in Win32 professionally myself, from my understanding it takes at least 3 years of non-stop work with those API's just to be semi-proficient in them. Professionally, most of my work over the years has been in Java, and Java is probably scary to a lot of neophyte programmers these days because since 1.5, it has unfortunately turned into the bastard child of complexity like its twisted sister C++.
As a CS Professor, here are some of my thoughts on this article:
(1) Java is what the market wants. Yes, we can teach any other language under the sun. But the reality is, that the software industry values individuals who are Java-literate. By this I mean an individual who has a basic understanding of the OO principles that the language is founded upon, can write Java code using common tools, and has at least some insight into some of the more common Java APIs. Any learning institution that doesn't take this into account when designing their curriculum is doing a serious disservice to their student body. While some do go to University for the sheer joy of learning a subject - most are there to ultimately get a job.
(2) In my opinion there is something seriously wrong with a Java course that emphasizes Swing or Web development, rather than the fundamentals. Yes, its important to get things in and out of a program, but, at least initially these should be incidental to the main event. Learning the language, and applying it effectively. Thinking in an object-oriented way, which many of you know is not necessarily an intuitive way to look at the world - especially if you already have a procedural background. GUI and web application development should be separate, advanced courses.
(3) I sometimes lament the lack of insight into pointers, but any professor worth their salary will spend some time discussing the Java object reference architecture, and relate that to pointer-based languages. Regardless of how abstract your language is "opening up the hood" and demonstrating how things work, and why things have been designed the way they are, is often worth knowing.
(4) I laughed when I read the article about Praxis, especially the part about formal methods. Are they serious? Yes I was taught formal methods in school, and could understand *why* I'd want to use them... If I had all the time in the world... a huge budget to burn and customers not screaming for something that the business needed yesterday. Praxis offers software development based on formal methods and as a consequence occupies an important (and probably expensive) specialized niche of the software ecosystem. To suggest that this approach should be the norm and lament its absence really betrays that the authors have spent too much time in academia and not enough in the real world.
(5) Ada is a great language - in fact I learned Ada 83 as a first language along with C. It just isn't relevant to most software development companies or IT departments - if indeed it ever was. I worked on a research project that was part of the Ada 9X Real-Time initiative - the main users were aerospace and military vendors - particularly embedded systems. There you do need to know about concurrency and distribution - along with hard performance deadlines and often a slew of safety and mission-critical issues you need to consider to do a good job. However, I fail to see the general relevance of Ada to a commercial market that is primarily interested in "simple" information systems, getting information out of a database and/or putting it in - with some processing on route. Why should I use Ada when the market in general doesn't use it?
(6) We teach concurrency - its useful stuff to know. I think that using formalisms to describe concurrent programs is going a wee bit too far (see (4)) above.
Well, the problem is that you want to a collage. That's a bunch of stuff pasted together by art majors. If you had gone to a college, or perhaps a university, you would have learned stuff beyond programming such as data structures, compiler theory, etc. Programming, especially in any particular language, is a skill, like plumbing or electrical wiring. Knowing the theory behind it is education. I was a decent programmer when I started college. All the theory and stuff that I learned in college didn't seem that useful at the time but as I've gone along in my career it's definitely the difference between being a code monkey and being someone who can design systems.
by Anonymous Coward
on Tuesday January 08 2008, @04:10AM (#21951300)
I'll answer as a computer scientist.
I view school as bootstrapping a person to learn how to learn, and for teaching them the things that are timeless. The only reason that a popular programming language like Java is used in the first place is because something has to be used, so it may as well be that. However, many schools offer Scheme, ML, or Common Lisp as the programming language of choice when the job market is comparatively low. This is because it's seen to help the learning process. The goal isn't a marketable skill, but a vehicle to teach the timeless things like algorithms, data structures, and all those courses that have he word "theory" tacked on to the end of the titles.
If you want someone to be a lackey and build you a GUI, you'd be better off looking for someone who has an ITT certificate. If you're looking for something more on the math side of computing (again, algorithms, analysis), then you talk to a computer scientist.
"I have to read *3* *books* *a* *week* on average. Not picture
books either I assue you. It is a lot of work, but the upshot is
improved grammer and spelling skills that are lacking in the
technical."
It does not work for you. In your post mispelled: narrowm, lets, aggreed, trun collage, auctually, focuesed, assue, grammer, socialolgy, beeing, couyld, cynsical
tasty (Score:5, Funny)
I dunno about you, but java was nothing but helpful to me as a student. the drinkable kind, at least.
Re:tasty (Score:5, Interesting)
I find I am now having to teach myself C++, and am struggling in a lot of areas that had I been taught in Uni I would be a lot more confident in.
Parent
Re:tasty (Score:5, Insightful)
Most of my professors had no real world experience, either. So, teaching things like team dynamics and working within a project schedule were really beyond their expertise. Granted, I've been quite successful, but I attribute most of that to my abilities, not what I learned in college. College just got me a piece of paper that opened the door.
I don't think the problem is with the languages being taught, but in the lack of true engineering being taught. This is true of any of the programming related fields (CS, MIS, SE). All of them need these skills.
Layne
Parent
Re:tasty (Score:5, Informative)
During the second year we took a class that taught C/C++ which basically taught pointers and memory management. In my upper level courses like operating systems and graphics, it was all C and C++ from then on. I think this gave me a pretty well rounded education.
When I was done, I had used a number of tools (languages) to learn a variety of CS topics, and felt that I was well prepared for the industry.
Parent
Re:tasty (Score:5, Insightful)
Do more. Try doing your homework in haskell or lisp or hell, write in forth or postscript. It's a billion times easier to learn a language when you have someone else telling you what to do in it, and a billionth of the stress when your paycheck doesn't depend on it working.
I've wanted to learn ruby and rails for a while now, but I've got nothing to do with it at home, and like hell I'm going to show up at work and replace a production app with ruby for the hell of it, even though we've got a number of internal web apps that are basically exactly the kind of CRUD RoR was designed for.
Parent
Re:tasty (Score:5, Funny)
Hell? Maybe you meant Perl?
Parent
Re:Java == Jobs (Score:5, Insightful)
I'm mainly a C programmer these days, but I took the job basically understanding that I would be working significantly with Java. That was the only language I had experience with on leaving Uni, and I was promptly put to work on a Pascal / OpenVMS system! Friends from Uni have had similar experiences.
I have been a bit worried about an outdated skillset as lots of employers ask for lots of object oriented programming experience and I only occasionally use this. I think this would be my primary problem if I started looking for a new job. I also think it's a bit unfair as the skills are pretty transferrable - there's only a little new theory to learn and after that, good programming practices aren't hugely dependant on language used.
In dealings with many (perhaps even most) other companies whose software I write interfaces with, it's pretty clear that they are also using C or C++, and often even older systems (in one interface we have to convert our messages from ASCII to EBCDIC). You can frequently tell what language the other system is from the sort of errors that crop up, and sometimes from the design of the interface. I'm forced to believe that my area of the industry is still primarily C based.
Parent
Re:Java == Jobs (Score:5, Insightful)
Parent
software engineering != computer science (Score:5, Insightful)
that's true, but again soft engineering/programming is a subset of computer science (maybe, i suppose you could argue they aren't)
"Computer science is no more about computers than astronomy is about telescopes."
- Edsger Dijkstra
Re:software engineering != computer science (Score:5, Insightful)
In practice systems have to work 100%, and when your graph search algorithm (by Dijkstra naturally) segfaults due to dereferencing a wrong pointer then computer science is very much about computers.
I'm just worried that too few students these days know assembly and C, which leaves us in a predicament when the current generation of kernel devs retire.
Parent
Re:software engineering != computer science (Score:5, Insightful)
Pointers aren't rocket science. If you never perform an operation where you haven't first met the operation's preconditions, you never get a pointer error.
If you aren't rigorously checking preconditions on *every* operation you perform, you're not going to cut it as a kernel dev anyway. Pointers are the least of your problems. Race conditions can become exceptionally hard to reason about. The prudent kernel dev architects the system such that this doesn't transpire. That requires a whole different galaxy of aptitude beyond not leaking pointers.
When I first learned C in the K&R era, I thought those greybeards were pretty clever. Then I came across strcpy() and I wondered what they were smoking that I wasn't sharing. I thought to myself, their must be some higher level idiom that protects against buffer overflow, because no sane architect would implement such a dangerous function otherwise. Man, was I ever naive.
More likely, too many of them had learned to program on paper teletypes, and just couldn't bring themselves to face having to type unsafe_strcpy() when they had reason to know it would work safely and efficiently.
The C language deserves a great deal of shame in this matter of giving many beginning programmers the false impression that any function call should dispense with formal preconditions.
Interestingly, if you sit down to implement an STL template algorithm manipulating iterators, it proves pretty much impossible to avoid careful consideration of range and validity.
OTOH, C++ makes it charmingly easy for an object copy routine, such as operator=(self& dst, const self& src) to make a complete hash of managed resources if you fail to affirm dst != src.
There are plenty of amateur mathematicians who can manipulate complex formulas in amazing ways. The difference with a professional mathematician is that the necessary conditions for each transformation is clearly spelled out.
A = B ==> A/C = B/C iff C != 0
A > B ==> C*A > C*B iff C > 0
Infinite series must converge, etc.
I'm not even getting into defining A,B,C as fields, groups, rings, monoids, etc. for maximum generality.
Yet the average programmer feels sullied to exercise the same intellectual caution manipulating pointers. I've never understood that sentiment. My attitude is this: if that's how you feel, get your lazy coding ass out of my interrupt handler; go code a dialog box in some Visual Basic application that won't work right no matter what you do.
Why did the software industry play out this way? Other professions have much harsher standards. Primarily because software was in an exponential expansion phase, any work was regarded as better than no work (perhaps falsely), and industry couldn't afford to reduce the talent pool by demanding actual talent.
Now we've allowed many people to enter the profession without comprehending the rigors of preconditions. It's as if we had taught a generation of lawyers how to practice law, but omitted liability. Oops. What to do about it? Invent Java, and tell all these programmers it wasn't their fault in the first place.
So yes, Java doesn't teach very darn much about the harsh realities of actually thinking. And since thinking is hard, it's an impediment to productivity anyway, so it hasn't much been missed. The only thing we lost in the shuffle is our professional self respect.
Parent
Re:software engineering != computer science (Score:5, Insightful)
Naive about the purpose of C, anyway. C was never designed to prevent you from shooting yourself in the foot. Writing C requires you to think, which is sadly out of vogue these days, as you point out later. C was never designed to protect you from yourself, as explicitly pointed out by Dennis Ritchie many times. If you want a language that will protect you from yourself, program in VB.
So yes, Java doesn't teach very darn much about the harsh realities of actually thinking.
But C obviously does - like checking boundary conditions. I don't understand how you can slam C in one breath, then praise it in the next.
Parent
Re:software engineering != computer science (Score:5, Insightful)
I do advocate designing primitives as essential to the language as the C string functions to powerfully remind the programmer using those functions of the programmer's logical obligations and support the programmer to reason correctly about those obligations, without having to digest 15 lines of preceding context to see that calloc() provided the implied terminating NUL.
strlcpy and strlcat - consistent, safe, string copy and concatenation [gratisoft.us] by Todd C. Miller and Theo de Raadt, OpenBSD project
Weirdly enough, the Linux people are about the only major group of people that has constantly stayed deaf to these arguments. The chief opponent to strlcpy in glibc is most certainly Ulrich Drepper, who argues that good programmers don't need strlcpy, since they don't make mistakes while copying strings. This is a very mystifying point of view, since bugtraq daily proves that a lot of Linux and free software programmers are not that bright, and need all the help they can get.
One must recognize that in a solid code base, thinking occurs more often while reading code than writing code. Correctness is not a write-only proposition in any living code base.
The original C string functions were (and remain) a pedagodic disaster. Most beginning programmers failed to realized how much thinking had been folded into the surrounding context. If they were reading K&R, that thinking existed. If they were reading any code they had at hand, it likely hadn't, by any survey of average C code quality ten years later. With the original string functions, whether this careful thinking existed is not obvious without doing a lot of mental work, and that work has to be repeated *every time* the code is seriously reviewed.
Worst of all, the strcpy() function seemed to imply "buffer overflow is no great concern, we're not even going to give you a single argument on this very dangerous function to help you avert it". It was a false parsimony to save that extra argument in the default case.
This isn't at the level of whether the handgun has a safety or not. It's at the level of whether it is possible to chamber a round too large for the barrel. I can point the gun successfully, but I'd greatly prefer it not to detonate in any other direction.
A more thoughtful C string API would have averted mistakes on the magnitude of chambering bad ammunition, without encumbering the pointy end in the slightest, or failing to endanger the programmer's foot.
Parent
Re:software engineering != computer science (Score:5, Interesting)
With Java and most other 'friendly' languages you have literally no way of knowing what is going on under the hood unless you are prepared to invest a lot more time and effort than is available to the average comp-sci student.
With C that's as close as a single flag on your compile line and you can study the generated code until you're tired of it.
Parent
Re:software engineering != computer science (Score:5, Insightful)
Parent
Re:software engineering != computer science (Score:5, Insightful)
Parent
Re:software engineering != computer science (Score:5, Insightful)
This goes for most of the so called 'insecure' functions in C, they only become insecure if you have already messed up in an earlier stage of your code. If you are aware of the limitations of the standard library routines (even the unsafe ones) and you are operating in a 'hostile' environment (and todays internet certainly qualifies as such) then you'll need to take great care to accept only input that matches your assumptions in the code further down, if not you are in trouble. But good programmers will work like that anyway.
It's perfectly possible to write crappy code in *any* language, not just in C (though, in the words of one old timer programmer 'C is like a racecar, you can cut corners but if you do that too often you'll end on your side).
To come back to a fairly well thought out piece with an answer like what was written several levels above here is not in any way helping the discussion, it is simply insulting.
Parent
And ignorance is key to bad habits (Score:5, Insightful)
Guess what? Even in Java, pointers still come to bite you in the arse when you least expect them. I see people every day who have trouble understanding the difference between "==" and "equals()" in Java, because they never learned the pointers behind them. They're essentially one abstraction level too far from understanding what their own code is doing.
Or even in Java learning why you can't modify an "int" parameter, but you can modify the contents of an "int[]" parameter, guess what? Requires pointers. People end up doing all sorts of unnatural metal contortions to remember when passing by value isn't really passing by value, when "it's a pointer" would sum it up perfectly.
And it shows. I've had people come to me half a dozen times with basically the same idiotic "auugh! Java's Hashtable is broken! I added a new value, and when I look into its array with a debugger it replaced my old one!" When in fact, it was only added a node to the front of the linked list. But they don't know what a linked list is, nor what a hash table really is, nor how a Node can contain another Node, without a concept of pointers. Worse yet, not only I see them spending a week debugging Hashtable, I see piss-poor workarounds done to prevent it from doing its job.
Or I see burger-flippers-turned-programmers occasionally get the real programmers fired for doing the right thing. Like using a "==" where it's correct to use it. But the burger flipper doesn't understand that. He learned some "for String use equals()" mantra, and he'll apply it and preach it, cargo-cult style, without even understanding what he's _doing_.
Or I see people think that optimization means replacing two lines with a one line call, because they have no fucking clue what the machine does with that code. They think that speed is measured in lines of code, because noone explained to them otherwise. So they wonder why their replacing two ifs with a catch is actually slower. (And I'm not getting into the many ways such a catch can make the code less secure, for example, by assuming that a real exception is just their loop reaching the end of the array.) Exactly what throwing an exception does, is a mystery to them.
Etc.
No, noone said you must keep programming in "a language where even K&R wrote unsafe code, nor that difficulty equals worthiness. But it helps to be at least exposed to those concepts once, even if thereafter you go on to program in Java or VB for the rest of your days. The fact that you worked with pointers once in C and managed to get them right, _will_ show in your Java code too.
Probably the best thing that helped my coding was doing assembly on my parents' old home computer, back in high school. In fact, in hex, because that ZX-81 with 1k RAM didn't even have enough RAM for an assembler. Wrap your mind around _that_, if you think C is too hard.
Would I advise anyone to write a production program in assembly nowadays? Nope, God forbid. I wouldn't have advised writing a whole program in assembly even back then. But understanding the machine behind that high level stuff will show even in your Java code.
And, yes, not every architect needs to be a Michelangelo. But it helps if they're not a clueless moron who can't even build a doghouse right. You can see plenty of architects nowadays who can't even get a basic house right. They know how to draw an artsy sketch of a house, but they have no clue how to calculate it to actually stand upright or what materials to use so it doesn't get damaged by rain within a year or two. And/or need a civil engineer to fix their elementary mistakes. Maybe it wouldn't hurt that much if they knew a bit more, ya know?
Parent
Just as an extra anecdote (Score:5, Funny)
Yeah, that guy was quite a bit less than a Michelangelo.
Parent
Re:software engineering != computer science (Score:5, Insightful)
As I said, I'm not a programmer. I could (if I had to) model the frequency response of a simple mechanical system to a range of perturbations by hand. The chance that I'd have to do that in the course of my professional employment is so slim as to be laughable. Yet, the fact that I could do this (if I really had to) tells me that I don't want to put an eccentric load on a rotating shaft with out a lot of careful consideration. Now if I sort of knew this was a bad thing, but didn't really understand why I might to something silly like put only a single U-joint in a shaft. After all, it provides flexibility, and as long as the shaft is straight there is no eccentricity. The problem occurs when there is a deflection, then your single U-joint translates a nasty sinusoid down-stream. If you do that things tend to break.
Now, I agree that the university should have some courses focused things that practicing professionals in the field use. I could draw a part by hand (if I really had to), but if I've never seen CAD before, I'd be at a serious disadvantage if I ever wanted to be a machine designer. However, fundamentally, a university is an academic institution. The suggestion that it should be an employment mill would severely compromise our education system.
Parent
Re:software engineering != computer science (Score:5, Interesting)
That they didn't know C wasn't too surprising. That they didn't have more than a basic grasp of memory management was shocking. They were also completely baffled when it came to not using an IDE to develop software. Makefiles had to be explained several times.
I've grumbled many times about this concentration on Java, and the resultant lack of detailed understanding about programing, but each time I did so at my university I was disregarded, and someone always trotted out that age old nonsense "not re-inventing the wheel".
I mean, sure, I see the point, but surely you should have a basic idea of how wheels are made?
Parent
Re:software engineering != computer science (Score:5, Insightful)
When I took data structures, and we used C++, I didn't have mental convulsions because Java had wrecked up my thinking so much (although I did have mental convulsions cause C++ is incredibly messy to read at a glance), I learned different ways of doing things. So, maybe these professors should look at whoever's teaching these kids so sloppily, not the language.
Parent
Re:software engineering != computer science (Score:5, Insightful)
employers want nothing more then easily replacable drones who come with an easily definable skill set which they can replace when a new buzzword comes along. this is NOT what universities should be pandering to.
Parent
Re:software engineering != computer science (Score:5, Interesting)
I was rolling on the ground laughing when I saw the problems people were having making a simple Sudoku program in C#.
Once they were done drag/dropping all the UI elements, they all got stuck.
Mind you your right about they are teaching what they think employers want.
We didnt get to see a *nix system let alone use one.
Although that may be because of that rather large donation Microsoft gave.......
Parent
Re:software engineering != computer science (Score:5, Insightful)
Parent
Re:Pointers, References and Performance (Score:5, Informative)
try {
int fds[2] = new int[2];
pipe(fd);
} catch (memoryAllocationErrorOrSo) {
}
Why does this need to be so complicated [...]
Parent
You have to start somewhere... (Score:5, Interesting)
Yeah, I just read a press release from the FAA blasting driver training courses. Apparently, flight students who just got their drivers licenses were not able to navigate in the air, execute banks, take-off, or land properly.
Students have to start somewhere. It's easier to start with simple stuff than to try to cram their heads full of everything all at once.
Re:You have to start somewhere... (Score:5, Insightful)
It is reasonable to expect that a CS student has both the ability and the interest it takes to learn all the details of programming well in C.
Parent
Re:You have to start somewhere... (Score:5, Interesting)
I started programming in Pascal, and then moved to C/C++. Structured programming, language syntax, variable typing, functions, parameters, recursion, etc I could ALL learn in Pascal.
When I came through Java was still pretty new, but I did take a java course, and found it reminded me a more of Pascal than C/C++; I'd say its a good starter language.
Also you can easily write command line apps in java, so i don't know why they blamed gui dependancy on java.
And as for 'systems programming' well DUH. Your first language is where you learn the basics of programming, before you start taking systems programming you should also have a lower level course ideally in something like assembly language (even if its just on emulated hardware) or C.
Parent
Re:You have to start somewhere... (Score:5, Interesting)
Assembly is necessary, to understand how a computer really works. Functional languages are good, just to know a completely different style. Some other language for breadth. Then the student can realise that everythin after asm was a waste of time, and return to C.
Parent
Re:You have to start somewhere... (Score:5, Insightful)
Assembly is necessary, to understand how a computer really works. Functional languages are good, just to know a completely different style. Some other language for breadth. Then the student can realise that everythin after asm was a waste of time, and return to C.
This is kind-of bollocks.
When I was a young programmer - which is about twenty-five years ago - the team I was on got a new ink-jet printer. It printed its own character set, we needed it to print bitmaps. The processor it used was one none of us had ever worked with before. One of the older members of the team - a guy called Chris Burton - took the spec sheet for the processor and the spec sheet for the printer home with him on the train, and came back the next day with the code for the new printer driver written in long hand, not in assembler mnemonics but in actual op-codes, in pencil on a pad of paper. It was burned on an EEPROM that day and drove the printers until that model became obsolete five years later - there were no bugs, it never needed fixing.
It should be said in passing that Chris had worked in his youth on the Manchester Mark One [wikipedia.org], and after he retired was part of the team that rebuilt Baby and got it running again.
I've always thought that was epic programming, a standard I'll never reach. But it's one particular layer on the stack. My job on that team was writing inference engines, and Chris was always really impressed by that. It's nearly thirty years since I touched any assembler and fifteen since I wrote anything serious in C. A modern computer system is way too complex for any single person to really understand, in depth, all the layers. I take what the silicon designers do as given, and likewise the microcode programmers. Right back in the early days of Linux I did fix issues in kernel code a couple of times but I wouldn't even try these days - the guys who do that are much more expert at it than I am. Likewise, I don't expect them to understand the compiler compilers that I write. It's a different layer on the stack.
I agree that you need to have a rough idea about how the whole stack works. But we no longer expect all computer science students to be able to wire up NAND gates from discrete valves or transistors. And although a computer scientist needs to know that there are primitive logic operations carried out on the metal, and that on top of that there are a stack of different software layers with real machine code on the bottom and a whole slew of intermediate code representations above that, I don't believe that it is any longer necessary for all students to be able to write a serious program in assembler.
Parent
1 language is damaging. (Score:5, Interesting)
In the course of my CS education (early 90s), they started with Pascal when they explained algorithmical basics.
Later courses were in C for OS and networking, while other courses used about everything from PROLOG to ADA.
You learn that some paradigms map to certain types of problems better (or worse) than others. So don't open sockets in
Prolog (I have seen'em do it man) , and don't do AI in C.
a quote: "if the only tool you have is a hammer, every problem looks like a nail".
About the Authors (Score:5, Informative)
Edmond Schonberg, Ph.D., is vice-president of AdaCore and a professor emeritus of computer science at New York University. He has been involved in the implementation of Ada since 1981. With Robert Dewar and other collaborators, he created the first validated implementation of Ada83, the first prototype compiler for Ada9X, and the first full implementation of Ada2005.
Re:About the Authors (Score:5, Informative)
Students found Ada a relatively simple language to start with (if you choose an appropriate subset)
Java can have more overhead for a beginning student
Lecturers are often tempted to push a lot of "stuff" in intro subjects
Java GUI motivates some students to get more involved
Many of my students regretted that Ada would no longer be taught in first year (having quite enjoyed it)
No matter what you start with, teaching students to be better programmers takes more than just a language. Each language allows you to teach a specific set of skills, and Ada is not bad for teaching some important SE skills (IMHO).
I think pointers are overrated as a first year concept, and can wait for later years.
Parent
Programming languages are tools, not religions. (Score:5, Interesting)
As someone who programs mainly in java, I have to say they have a point. Surely a degree in CS should get someone familiar with all forms of higher order programing (both OO and functional). They should also have a reasonably solid understanding of basic hardware architecture and how that affects programs.
Unfortunately this does not seem to be the case at least in NZ. Some don't even know about basic complexity ideas and often have little to zero mathematics under there belt.
I did not do CS but physics. I was required to do Assembly,basic,C,matlab,R,Lisp,Java,C++,Haskell and a bunch of others I don't care to mention (Like PLC's and FPGA stuff).
Biased? (Score:5, Informative)
Dr. Robert B.K. Dewar, AdaCore Inc. (President)
Dr. Edmond Schonberg, AdaCore Inc. (Vice President).
The article by some weird coincidence slams Java and praises Ada.
Salt, please...
PS, Ada is mainly alive in the Military/Aerospace industries where projects can last 20+ years.
Variety (Score:5, Interesting)
One thing I have noticed though, is a complete lack of security related training. Something about calling eval() on every input just to parse integers makes me cringe. I guess the idea is that worrying to much standard practices keeps people from thinking creatively or something. Unfortunately, it also seems like a good way to get into a lot of bad habits.
Why is "Computer Science" Staffing S/W companies? (Score:5, Interesting)
I totally agree that universities shouldn't be teaching Java exclusively. They need to teach the basics of modular, functional, declarative and oo languages. Why? Certainly *not* to fill "software engineering" positions!!! A university's role is to do research, not to act as some technical college. OK, I can see having a programming course aimed at creating programmers for industry if it's going to pay the bills at the uni. But *don't* make that your "Computer Science" course!!
Computer Science should be science (well, math anyway). Universities should be getting the 5 or 10 graduates they need that will move on to academia (or industry research) later in their careers. Because right now, *nobody* is getting taught Computer Science! Lately I've been reading papers posted on http://lambda-the-ultimate.org/ [lambda-the-ultimate.org] Regularly I have to go back to the basics and learn extremely fundamental theory because nobody *ever* taught them to me in the first place. Half the time I think, "OMG, I never even knew this existed -- and it was done in 1969!!????"
More and more lately, I've been wanting to phone my University up and ask for my tuition back.
If you want to learn how to program in a professional setting, there's nothing better to do than just start writing code. Get your chops up. Then find some big free software projects and start fixing bugs. Learn how to use the tools (configuration management, etc). Learn how to interact with the other programmers. That's all you really need (well, that and a quick automata and grammar course so that I don't have to look at yet another context free grammar being "parsed" by regular expressions).
But right now, where do you go if you want to actually learn theory? I guess the library... And getting back to the point, this is essentially what the paper is suggesting. Students need to learn all these things because they are relevant to the field. A university supports industry by doing basic research. If you don't understand the concepts that they point out, you just can't do that. Paraphrasing from the article, having a university course that's meant to pad out a student's resume is shoddy indeed.
Java for Dummies (Score:5, Interesting)
Java is fine for teaching design patterns, and classical algorithms like Quicksort, or binary search.
But you can't do operating systems, and the success of Java in isolating you from any notion of the hardware is actually the problem.
We have already blacklisted courses like the one at Kings College, because they teach operating systems in Java.
Yes, really.
Their reason apparently is that it is "easier".
I have zero interest in kids who have studied "easy" subjects.
The world is a bigger, more competitive place, how many jobs do you think there are for people who have an easy time at college ?
Java is part of the dumbing down of CS.
A computer "expert" is not someone who knows template metaprogramming in C++, or compiler archaeology in BCPL, or the vagaries of the Windows scheduler.
It is someone who understands computers at multiple levels, allowing them to choose which one illuminates the problem at hand.
To be wise in computers you choose whether to think of something as a block of bytes, quadwords, a bitmap, a picture, or a buffer overflow pretending to be porn. If also have the option of understanding flash vs static RAM, virtual memory, or networked storage, all the better. I doubt if even 1% of CS grads could write code to turn this BMP into a JPG, or even explain the ideas behind this. In my experience, 50% could not work out how to develop a data structure for a bitmap that used palettes.
I have interviewed CS grads with apparently good grades who could not explain any data structure beyond arrays.
Any CS grad who sends us their CV with bullshit like "computers and society" or "web design" has their CV consigned to trash with no further reading.
A CS should be able to write a web server, not be an arts graduate who didn't get laid.
C++ makes you think at multiple levels, unlike Java, you simply cannot avoid thinking about your system from patterns to bytes. This may be good or bad for productivity, and I'm sure we risk a flame war here.
But I am entirely convinced you need to hack your way through a "real" system.
How can someone understand the Linux kernel without C & C++ ?
Is someone really fit to be called a computer scientist if like >50% of the Computer "Scientists" we interview for very highly paid jobs, show actual fear of working at that level.
They have the same "way above my head" attitude that a mediocre biologist might have to applying quantum theory to skin disease.
Partly, as in the Kings College debacle it is lazy mediocre lecturers, but also CompSci grads frankly are not that smart, so they need their hands held.
Although the seats get filled, they quality is in monotonic decline.
Re:Java for Dummies (Score:5, Insightful)
Java is the new COBOL. And we will regret it in 20 years for much the same reasons.
It actually gives me hope that you have recognized this in hiring practices. That a CV with a list of Sun's Java buzzwords is not an indication of a useful programmer.
I was disturbed in college (1997-2001) that things were changing towards Java and other idiocy. Too many people didn't get pointers and other basic concepts, and Java was hiding them even more. I believe it was the one class we had in assembly programming that really pointed it out - when confronted with having to deal with real hardware, most of the students didn't know what to do. Concepts like "two's complement" vs "one's complement" caused a strange brain-lock for them, as they were so sheltered from the actual binary math and hardware of the computer.
It was only a handful of us that had been programming for years already (yay for the Atari 800XL) that had any idea of what was going on. The college (UC Davis) skipped entirely over very basic concepts like Von Newmann Architecture. I ended up having to spend most of my time trying to help my fellow students, there was so many fundamentals missing.
I think the most frightening part was having to yell at one of the professors one day, because the basic data structures he was teaching were being done incorrectly. He was teaching people to leak memory. ("Let's allocate a huge linked list, and then just set the head pointer to NULL and consider it freed!")
Sigh. It was frightening then, and apparently all my fears were justified, as now the entire discipline is getting a bad reputation. Unfortunately, I can't exactly disagree with that reputation from some of the CVs I've seen recently. My degree is destined fscked, apparently.
You hiring? ^_^
Parent
"Sure I know C!" (Score:5, Insightful)
These students are being trained as engineers. They shouldn't be afraid of a little grease.
Better CS programs don't teach languages anyway (Score:5, Insightful)
At CMU the very first CS class (that losers like me who didn't AP out of the first CS course, mostly because my high school didn't even have computer classes let alone AP computer classes!) really did focus on teaching a language - Pascal - and a significant part of the class was the learning of the language. It was the least useful CS class I took in the long run (not surprising, as an introductory course in any subject is likely to be the same). Subsequent courses would spend 1 - 2 weeks going over the fundamentals of the language to be used in coursework for the remainder of the class (which in some classes was C, in some was C++, some used ML, others Scheme, etc), to get everyone started, and after that, you had to figure it out on your own in conjunction with actually learning the theory that was being taught. It really isn't that hard to pick up a new language once you know a couple, although I did have a hard time with ML, mostly because I was completely unmotivated to learn it, feeling that it was absolutely useless to know (I was right).
No really good CS program has any classes with names like "Java 101" or "Advanced C++". To use a carpentry analogy, I would expect a really good carpentry school to teach the fundamental rules and "theory" of carpentry, so that the student upon graduation really understood what carpentry was all about and could apply their knowledge to aspects of the subject that they hadn't even encountered in school. I wouldn't expect a good carpentry school to have classes like "Advanced Hammering" and "Bandsaw 101". The courses would instead be "Introduction to House Frames" and "How to Construct Joints". You'd be expected to learn the use of the tools in the natural course of studying these subjects.
It's the same for CS. Good programs don't teach the tools, they teach the *subject*; learning the tools is intrinsic in the study of the theory.
Java is like "The Incredibles", or a circus (Score:5, Interesting)
Every time someone tells me that there are no pointers in Java I laugh a little. EVERYTHING in java that isn't a scalar is actually referenced through pointers. That is, you declare the pointer variable and then "new" the object into place.
They are just incredibly _boring_ pointers. You cannot math on them. There is no sense of location to those pointers. But the absence of interesting pointer operations, and the absence of the _semantic_ _copy_ operation is what all this alleged pointerlessness is all about.
I have only two _Real_ problems with java... (okay three if you count the complete requirement that you constantly have to deal with exceptions even when you know they cannot really happen, and if they did, you would want the thing to abort all over the place... but I digress)
(1) Java has no useful destructors because no object has predictable scope. If you think finalize methods are the same as destructors then don't bother responding, you don't know what destructors are...
(2) Since everything is a pointer in Java, you have to bend over backwards to pass-by-value. The fact that the language doesn't even begin to provide copy-construction semantics. What a miserable PITA.
Now the _dumbest_ thing about java is that they were so set against multiple inheritance that they never bothered to ask themselves why _every_ OO language starts out life without multiple inheritance only to have to add it later. By making everything a proper linear subclass of Object, they left themselves with having to graft on "interfaces" which is just multiple inheritance with the "bonus" of completely preventing default implementations. (Which lead to delegation etc.)
The way the language keeps sprouting things it claims to never have and never need, well it's very like watching a clown car endlessly explode with ridiculous archetypes. After a while it just isn't funny any more.
So yea, teaching people Java as an introductory language is something of a disservice if you ever want to make them truly think about programming and what makes some things machine smart, while others are machine stupid.
--- BUT ---
I worked in education for years. The fundamental problem with computer science education is that it is being taught by computer scientists instead of educators. We are stuck learning from the people who learned from the people who made it up. None of these people ever learned to EFFECTIVELY IMPART INFORMATION.
Consequently, the students are largely unemployable on the day of graduation.
The classic computer curricula seems to consist of throwing three or four languages at a kid in the hopes that they will "just kind of figure out this programming stuff."
The field of computer science has not yet come up with a "basic theory"... a starting place... The list of things a student simply must know before you start filling their head with syntax.
And so we are a bunch of prelates training our acolytes in our special, individualized deeper mysteries.
And that's what everybody is doing worldwide, so our graduates are just as lame as everyone else's...
Cue "Enter the Gladiators"...
Beginner language? (Score:5, Interesting)
This guy is about as unbiased as Stroustrup! (Score:5, Interesting)
Most CompSci college graduates are totally unproductive on their first job. They can be put to work on trivial things, but no matter what school they came from, they are just going to need a lot of hand-holding to make it through the first year. That is just how it is. Doing coursework at school is no substitute for coding on a meaningful project, whether it be work related, something open-source related, or just something for fun. That is the honest to god's truth as a software developer for over 12 years now and I don't even consider myself even that wisened in the field (maybe after 20 years I will feel differently).
Now, with respect to Java as an introductory programming language, it is not bad but not great either, however the purpose of any introductory course to anything should be to capture the interest of the people who are curious enough to take the course in the first place. Back in college, we started with C (most of my peers had already been programming since they were teething but this was CMU) and if not for my persistent no quit attitude in life, I probably would of given up programming right then and there because spending your entire night trying to debug a trivial program not because you didn't understand the material but because of one stupid uninitialized pointer turns a lot of people off right then and there who may have had the potential to be great programmers, but because their first impression of programming was so bad, they gave it up before they got to learn more about how great programming really is.
Oh yeah, and the not relevant at all math courses didn't really help much either. Whenever in your career you need to use some advanced calculus or discrete math, you will have likely forgotten about 99% of it and need to look it all up in a book anyways. Besides, 99% of programming projects in the real world basically involve high school level algebra and not much else. What separates the productive programmers from the unproductive ones is not who got a better grade on their math course back in college, but those who innately understand systems and are willing to make the extra effort to learn all about the gazillion design patterns available to programmers so that when they are faced with a difficult project, they will not waste inordinate amounts of time reinventing the wheel.
As for understanding computing at a rather low-level, as is the case with a class in operating systems, then yah Java might not be such a great choice, but then again learning C is easy because C is made up of very simple constructs (C++ is another story). However, using C productively just requires a crapload of practice/experience to be good with, not necessarily a whole lot of computing expertise. In addition, the mastery of whatever API's you happen to be basing your career on is paramount as well. In the real world, employers don't want to hear "but I can learn anything quickly" because mastering some API's can take 6 months or more so if you come out of university with no specific skill sets, it is going to be really hard to get that first job because unless you can be productive soon (or even on day one), you are useless as far as employers are concerned. Also, though I don't program in Win32 professionally myself, from my understanding it takes at least 3 years of non-stop work with those API's just to be semi-proficient in them. Professionally, most of my work over the years has been in Java, and Java is probably scary to a lot of neophyte programmers these days because since 1.5, it has unfortunately turned into the bastard child of complexity like its twisted sister C++.
Last but not
Why We Teach Java (Score:5, Insightful)
(1) Java is what the market wants. Yes, we can teach any other language under the sun. But the reality is, that the software industry values individuals who are Java-literate. By this I mean an individual who has a basic understanding of the OO principles that the language is founded upon, can write Java code using common tools, and has at least some insight into some of the more common Java APIs. Any learning institution that doesn't take this into account when designing their curriculum is doing a serious disservice to their student body. While some do go to University for the sheer joy of learning a subject - most are there to ultimately get a job.
(2) In my opinion there is something seriously wrong with a Java course that emphasizes Swing or Web development, rather than the fundamentals. Yes, its important to get things in and out of a program, but, at least initially these should be incidental to the main event. Learning the language, and applying it effectively. Thinking in an object-oriented way, which many of you know is not necessarily an intuitive way to look at the world - especially if you already have a procedural background. GUI and web application development should be separate, advanced courses.
(3) I sometimes lament the lack of insight into pointers, but any professor worth their salary will spend some time discussing the Java object reference architecture, and relate that to pointer-based languages. Regardless of how abstract your language is "opening up the hood" and demonstrating how things work, and why things have been designed the way they are, is often worth knowing.
(4) I laughed when I read the article about Praxis, especially the part about formal methods. Are they serious? Yes I was taught formal methods in school, and could understand *why* I'd want to use them... If I had all the time in the world... a huge budget to burn and customers not screaming for something that the business needed yesterday. Praxis offers software development based on formal methods and as a consequence occupies an important (and probably expensive) specialized niche of the software ecosystem. To suggest that this approach should be the norm and lament its absence really betrays that the authors have spent too much time in academia and not enough in the real world.
(5) Ada is a great language - in fact I learned Ada 83 as a first language along with C. It just isn't relevant to most software development companies or IT departments - if indeed it ever was. I worked on a research project that was part of the Ada 9X Real-Time initiative - the main users were aerospace and military vendors - particularly embedded systems. There you do need to know about concurrency and distribution - along with hard performance deadlines and often a slew of safety and mission-critical issues you need to consider to do a good job. However, I fail to see the general relevance of Ada to a commercial market that is primarily interested in "simple" information systems, getting information out of a database and/or putting it in - with some processing on route. Why should I use Ada when the market in general doesn't use it?
(6) We teach concurrency - its useful stuff to know. I think that using formalisms to describe concurrent programs is going a wee bit too far (see (4)) above.
Re:Right on! (Score:5, Insightful)
Parent
Re:I've noticed that... (Score:5, Insightful)
I view school as bootstrapping a person to learn how to learn, and for teaching them the things that are timeless. The only reason that a popular programming language like Java is used in the first place is because something has to be used, so it may as well be that. However, many schools offer Scheme, ML, or Common Lisp as the programming language of choice when the job market is comparatively low. This is because it's seen to help the learning process. The goal isn't a marketable skill, but a vehicle to teach the timeless things like algorithms, data structures, and all those courses that have he word "theory" tacked on to the end of the titles.
If you want someone to be a lackey and build you a GUI, you'd be better off looking for someone who has an ITT certificate. If you're looking for something more on the math side of computing (again, algorithms, analysis), then you talk to a computer scientist.
Parent
Re:CS Newbie here. (Score:5, Funny)
http://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html [duke.edu]
Parent
Re:University should be about people (Score:5, Funny)
It does not work for you. In your post mispelled:
narrowm, lets, aggreed, trun collage, auctually, focuesed, assue, grammer, socialolgy, beeing, couyld, cynsical
Read more...
Parent