Ask Slashdot: "Real" Computer Scientists vs. Modern Curriculum?
An anonymous reader writes At work yesterday, I overheard a programmer explaining his perception of the quality of the most recent CS grads. In his opinion, CS students who primarily learn Java are inferior because they don't have to deal with memory management as they would if they used C. As a current CS student who's pursing a degree after 10 years of experience in the IT field, I have two questions for my fellow Slashdoters: "Is this a common concern with new CS grads?" and, if so, "What can I do to supplement my Java-oriented studies?"
Shouldn't they be computer scientists? Software engineering, while related, is not the same thing as computer science. Would you ask a scientist to build a bridge, or an engineer?
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
Yes Java monkeys don't understand memory management.
But a CS student shouldn't be a simple Java monkey. C isn't good enough. They should all have at least a semester of Assembler.
There have always been a subset of CS students that didn't get anywhere close to the metal. They suck.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
1. Yes.
2. Learn some lower level languages like assembler, C, or C++. Even if you don't use the techniques, understanding them will give you a better understanding of what's going on in your Java programs.
Learn some assembly. Not because you will use it every day (or ever) but because it helps remind you that all the code we typically write is just layers of abstraction on top of a machine (which even assembly is, albeit very low level abstractions).
An old boss from years ago (a mentor for me really) watched me troubleshooting a network issue in an application. He said to me "you seem to be having trouble spotting the problem. Have you tried going lower down the stack?". So I tried ping by name, nothing, ping by number, nothing, etc. Finally after reviewing ip configurations, arp and routing tables and probably a few other things I forget I figured out I had a bad cable.
That taught me a lesson that I've applied to many areas of computers, including programming, over the years. If something seems like it should work but does not maybe something underneath it is the problem. If you want to be able to debug code at the library level or interfaces to lower level languages it helps to understand things like memory layout, registers, the call stack, etc.
My $.02.
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
You know, I wouldn't want to specifically use the word 'inferior', but you do learn a hell of a lot from having to deal with your own memory management.
When I was in school, lo these many years ago, I and a fellow student wrote the same basic assignment for a course.
He was one of the sysadmins on the VAX and could set his process to use a vast array which was mostly empty, and rely purely on virtual memory. I had a tiny little 80286, and had to implement the same thing in a sparse array which took up a fraction of the space.
We both got the expected results and got good grades, but the prof basically said since I'd done so much more thought on memory management and the other guy didn't, I'd get the A+ and he got the A.
The Prof also stole my code to use in his own project, because by the time you accounted for architecture mine was about 4x faster and 100x smaller, and he'd basically given us an assignment which overlapped with his own research.
Would I want to do bare metal memory management in C every day? Probably not. Do I think it was valuable to have had to learn how to shoehorn something into a small amount of memory and explicitly be the one to make sure my memory wasn't leaking? Absolutely.
I think more modern software would suck less if developers didn't just assume there were massive gobs of memory sitting around, and implement everything in the easiest way possible without having to factor in resources. Most modern browsers seem to grow their memory usage at a pretty linear rate, even if you're not using the browser.
Because, really, pretty much every piece of software seems to double in it resource requirements every few years.
And understanding pointer arithmetic and semantics in C is valuable, even if most people will never directly see anything resembling a pointer these days.
Lost at C:>. Found at C.
I've recently watched my wife (C++ environment) deal with a new-grad (Java-based education.) It's true that pointers are a sticking point -- in the process of being taught Java, they get taught that pointers are bad and dangerous (all hail Java for solving the problem,) and can be made only barely tolerable by using auto_ptr, but really should just be avoided. Yeah, it's a problem, sure.
But the bigger problem we have with new-grads and junior-devs, in general, is the same problem you'd have in any field: they're green. They don't test well, or at all. They don't think designs through. They don't communicate well. They ask too many questions, or maybe worse, they ask too few. They try to fix things that aren't broken. They're bad at estimating task sizes (admittedly, people rarely get much better at that even after decades.) In an attempt to not suck, they reach out for best-practices and apply them zealously and inappropriately. They can't imagine how things will fail, or be abused. They spend too much time fixing small problems, and not enough time fixing big ones. And maybe worst of all, they're under the illusion that what they learned in school ought to prepare them for the workforce, when really it just gets their foot in the door.
We, as their seniors, are the ones that should be spending the time fixing their misconceptions, fleshing our their education, filling their minds with the horrors we've seen, and setting up their work habits. When they fail, it's because we fail to do these things, usually because we brought them in too late in a project, gave them too much responsibility, and are fighting a deadline. So we "just fix it" for them, and they don't learn from the experience, while we gain nothing in terms of productivity from having them.
But if I were to nitpick their education? Databases. Recent grads have little or no understanding of relational databases. Their thinking on organizing data, in general, is fuzzy at best, which impacts more than just database code, it impacts class and API designs, often crippling whole features with incorrect cardinality. It deserves more attention in school. The rest, we can fix in production. =)
The department I go my masters in computer science from divided the discipline into three chunks:
systems
languages
theory
I think this is a good way to divide computer science.
It sounds like your Java / C question involves mostly languages, and a little bit about systems (since Java programmers do not need to have a fundamental understanding of memory works at a system's level.)
I don't think this question really addresses the underlying issue - what is computer science? To me, I tell people that my formal education is closer to applied mathematics than what I do on a day to day basis. I also like to humorously use the derogatory term "code monkey" to people that have learned everything through the "languages" chunk above. A lot of times when I've worked with these people, they haven't even really studied languages (Why did the language designers make the choice that they did? What does the formal language specification say the language should do in this case? How is this language related to earlier languages?)
Again, about 90% of what I do on a daily basis could be considered "code monkey" level. It's when a customer has a REALLY difficult math problem that my formal education comes into play, and for giving people confidence in me.
For your direct question, I'd study the book Computer Architecture, Fifth Edition: A Quantitative Approach (The Morgan Kaufmann Series in Computer Architecture and Design)
That's what I used, and it helped me understand a ton of memory management. Then again, my undergrad curriculum was based on C....
CS should be different from programming. Back in the day when I did my undergrad, the programming was something you mostly figured out on your own time. When I took Operating Systems 1, we were studying memory management, Belady's anomaly, semaphores, etc, but we were also expected to become proficient in Unix scripting by the end of the semester. The exchange on the first day of class went something like this:
Prof: Homework for this week is to write a tcsh script that will set your environment variables when you log in based on a menu.
Student: What's tcsh?
Prof: It's one of the shells in Unix, you can write scripts using it.
Student: How do I learn to use it?
Prof: The manual command is "man" in Unix.
Student: How do I use the "man" command?
Prof: Use "man man" to find out how to use "man".
(whole class looks bewildered for about 10 seconds - not sure if he's joking or if Unix is really that insane)
Prof writes across the top of the board: THIS IS A UNIVERSITY, NOT A TRADE SCHOOL. RTFM.
If you can't figure out how to learn the mechanics of Java, Python, whatnot on your own time, you really don't have the brain needed to do computer science. The problem is that everyone and their plumber is getting a 4 year degree these days, so it's become the equivalent of a high school diploma in the 80's.
Support microSD: in a post 9/11 world, it is unwise to carry your data on media that you cannot comfortably swallow.
I can't believe that you can graduate with a CS degree today without having at least one assembly language class which should show you about bit-twiddling and memory management just a bit. Not to mention an OS class that would expose you to exercises to modify a Linux kernel - written in C.
What do they actually teach in a CS degree these days? Don't tell me... Gamification, HTML, CSS, and Javascript, right? Do they actually make you take a database or an algorithms class any more?
That is all.
You do know that sort of obsessive language-lawyering is exactly what turns people off to exploring C, right?
Someone well-versed in Java won't be surprised that arrays know their own size. That's not the interesting lesson here, for someone who's never seen the difference between big- and little-endian in a debugger.
Socialism: a lie told by totalitarians and believed by fools.
And as soon as you work for Facebook or Amazon, you will never have any use for 'bit bashing' again. ... but has bottom line nothing to do with serving web pages to 100,000,000 concurrent users accessing the same DB of products and hosting all the infra structure on 4 IBM mainframes that run the web front ends on 10,000 virtualized linux boxes running slackware linux (2002) and IBM Java 1.3. ... ... but well, you already do comprehend ... so, you agree with me: it is pointless. So are you examples, that only work straight forward in assembler. Lol, reverse the bit order of a word in C? Seriously?
It is interesting as a mental exercise
Sorry, how good are you actually in classic greek? It would do wonders to your comprehension of logic
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You do know that sort of obsessive language-lawyering is exactly what turns people off to exploring C, right?
If it also turns them off from having to ask why this program
doesn't print two identical lines - or from writing code that breaks because of this - that would be for the best.
None of these or any other internal arcana of c have anything to do with designing algorithms or programming computers.
May the Maths Be with you!