Slashdot Mirror
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?"
Difference is the "real" ones have beards and wear suspenders.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
"Real Programmers don't use GC" is a mantra that is responsible for 90% at least of production bugs, together with "=" being typed instead of "==".
This is not a signature.
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'
There are different tracts in CS degrees, with some focusing on C++ and low level coding (embedded systems, OS, robotics, etc.) and others focusing on Java and other more abstract languages (automated reasoning, AI, NLP, web programming)...so I think it really depends on what the student choose to focus on.
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
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
Well, in MY opinion, CS students who learned in C or C++ or Pascal or PL/1 are inferior because they use the stack as a crutch, instead of manually keeping track of callback history. If you don't have to write explicit code to keep track of every call, or allocate every local variable, your code will... well, actually, it'll likely be easier to read, easier to maintain, and easier to optimize. But it won't be as good as the code we had to write back in my day.
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.
In my totally completely unbiased opinion, I think that everyone should have a basic understanding of how computers actually work, from the ground up. A little bit of basic logic (and how that is implemented in hardware), introduction to low level programming (assembler) and using C to make hardware DO something. From there just keep moving on up until you get to Java. Learning operating system functions and why they are important (handling I/O devices, memory management, process and thread management, etc.). All that stuff helps you understand what you are doing, and potentially give you insight into how to debug it.
Nothing is more frustrating than arguing with someone about some computer bug/problem when their argument/explanation is provably impossible, based on how things actually WORK.
Computer Scientists understand the theory of computing. Software Engineers understand how to build software. Information Managmentstudent know how to apply computers to business problems. IMHO CS students are not prepared for real world coding applications. If you're going to program you don't need a CS degree, you just need a background in the programming language du jour. If you're going to solve difficult problems with a computer, you need a CS degree (theory, algorithms, heuristics). But to build a web site, ECPI is good enough. I don't think current CS curricula creates a solid programmer. However, many enterprising young CS students are already involved in external activities (open source projects, web site construction) and are learning the key skills on their own.
Feh. C. "Memory Management".
CS students taught in high-order language are completely deficient in their education. They haven't learned about opcode timing and instruction placement and hardware stack management.
If you aren't working exclusively in machine code, you're just a poser.
Welcome to the Panopticon. Used to be a prison, now it's your home.
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. =)
I remember learning a couple of assembly languages, 3 procedural languages, sql, lisp, and prolog during my undergrad CS degree, while learning three more languages including Forth, Basic, and SmallTalk in summer jobs around that time.
But in my recollection, particular programming language (details of) was not the main point of the majority of my CS (or EE elective) courses, especially not after first year. Quickly learning any programming language was just the price of admission to learning and practicing other CS knowledge. Computing general concepts, algorithm and database general concepts, intro to and practice with different styles of programming such as functional, declarative, procedural, particular types of applications as examples, cool AI'ish stuff, and a few things about software engineering practice, were much of the point.
So if your degree program is "about Java" and "experience with Java and an N-tier JEE stack", then RUN and take some MIT or Stanford online courses in more interesting and useful stuff!
Where are we going and why are we in a handbasket?
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....
Yes, the concern is real and common. The antidote is building stuff. A bunch of stuff. The more stuff you build, the more likely it is you'll have to get "dirty" with the underlying guts of it, the more you'll know, and the more valuable you'll be.
For instance:
Of the many garbage collectors Java offers, have you ever used anything but the default? Do you have any idea what the trade-offs are and when you might want to use another one?
Have you ever profiled any Java code?
What do you know about Java byte code?
Ever SWIG wrap anything into Java?
Ever used Java serialization? Do you know what's wrong with it and why you wouldn't want to use it?
Custom class loaders?
My adivce: go learn everything there is to know about "something", it doesn't really matter what (maybe you want be the worlds foremost expert on malloc). In the process of gaining a very, very deep understanding of that 1 specific sliver; you're going to also learn about a ton of other stuff on the way.
C does offer the ability for explicit memory management and if thats what you want to learn I suggest picking up C. In programming the lessons are transferable and always useful when looking at another language. What you learn in C can be applied to what you do in Java.
That being said, Java does a lot of the heavy lifting in memory management, but it isn't fool proof. If its java you want to learn about, try running your jvm with less and less memory. This will make you conscious of the size of large objects and ways of getting around memory barriers. In java this really starts to apply when you are using huge data sets and repetitive tasks. Poorly written code will start to see oom and stack overflow errors. There are plenty of tools out there that will analyze memory usage of your code. I'd suggest getting some and trying to decrease your programs memory footprint without a loss in speed.
This, of course is all computer science, and has little to do with most software engineering done today. Knowing these things, though, will definitely put you leaps and bounds in front of other software engineers.
Brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants.
Web development? Keep learning Java. You will rarely ever have to worry about memory management. Learning C won't make you a better Java programmer, and there are plenty of jobs for people with Java backgrounds. Of course, you should also know HTML/CSS etc. if you're going this route.
Video games? Learn C and C++, probably in that order. Java isn't going to cut it, you'll need to learn things like memory management and graphics programming. However, the object-oriented programming stuff you learn in a Java-centric curriculum will still be very helpful in C++ (or C# if you go in that direction), so you have a solid base to work with.
Embedded systems? You're in either the wrong school or the wrong major for that, you need to focus on C and Assembler for that. Completely different world from Java.
You get the idea. Figure out what you plan to do with your career if you don't already know (in a broad sense, you don't have to nail down a specific job), and steer your studies that way. If you want to keep your options open, teach yourself some basic C or C++ and see if it's right for you. If you can't figure out how to manage pointers, then you know what type of programming not to get into.
and the Godheads sling opcodes. THIS is memory management, making all of your 1K count.
if this is supposed to be a new economy, how come they still want my old fashioned money?
I agree with the parent (@HornWumpus -- good name), but I'd like to elaborate.
First, I agree that "There have always been a subset of CS students that didn't get anywhere close to the metal. They suck.", and I agree that "C isn't good enough." No language is good enough by itself. If you haven't played with Functional, Procedural, Object-Oriented, and hardware-level (Assembler) languages by the time you've graduated, you've missed something.
You can figure it out no matter what they teach you, you just have to be inquisitive and ask good questions. You should take compiler, operating systems, and a numeric computing class which will each teach you about overflow and precision and memory allocation, in different ways, regardless of programming language used. You should have a basic understanding of how to do everything from scratch, with bare hardware, short of soldering the chip to a board (unless that's your thing, then go learn that too).
But then you should also learn that many "higher" languages make this easier... they have garbage collection built-in and you should learn why and when that's a good thing and why and when it's a bad thing. Java is good for some things, bad for others. If you go through a CS degree and all that you come out with is knowing one language, get your money back. Ask "why" early and often.
You should learn concepts and hands-on. You should learn the ideas so that, when a new language comes up next year, you can understand the literature about the pros and cons. But you should also be able to sit down with a couple of languages and pound out some simple algorithms and I/O with no references.
I liked my CS degree, but there were things missing. I had to learn network programming (TCP/IP, etc.) on my own. We didn't do embedded systems, so I didn't have much experience with small hardware and the nuances that come with them. But the advice I'd give is to avoid too many classes that are "just" programming, and focus on the fundamentals. Use as many languages as possible. Take Artificial Intelligence, Compiler design, Operating systems, data structures, numerical computing. Take a comparative languages class if one is offered. Take a database class. And take these all realizing that they're teaching you exactly the same thing -- how to solve problems using computers.
It's all ones and zeroes in the end. Once you've mastered pushing them around for one thing, you should be able to push them around for another, it just takes practice. Practice as many things as possible.
egads. i know a few gods. none of them write assembly or opcodes. they may write their own microcode compiler for the processor they're designing to solve what ails them, though :)
seriously, these are a few things i know most grad-student CS guys have never been exposed to but which should be taught:
. source code revision control systems
. debugging techniques (vs. broken hardware, not software)
. platform integration (e.g. where do i store preferences!?!?, etc)
. multi-programming in event-loop schemes
. techniques for gaining understanding of a large body of code, relatively quickly
. Makefiles/code build environs
. packaging
. testing, with large systems/moving parts.
i do device drivers so i don't often come across people who'd rather code in java. but the rest are widely applicable, i think.
Wow could you please not downvote me please thanks? That's really rude.
Why don't you impose a $500 fine?
The problem I've seen in CS grads over the last 10-15 years is they have little to no engineering background (even when their degree is "Computer Engineering"). Most applications are complex systems. And most CS grads don't understand systems. I've been able to teach EEs, a chem E, a civil E, an MD and a CPA (among others) how to program. And they've had no trouble implementing solid class hierarchies and robust applications. It's much harder to teach a CS grad about structural integrity, analyzing a design for weaknesses, and root cause analysis. In some cases they won't accept those are even an issue since "software is so different from physical structures". So they keep building things that pass all the tests but repeatedly fall down once they get to production.
Those who can write in Java, and those who can write Java.
Or those who can write in C#, and those who can write the .NET runtime.
Or those who can write in PHP, and those who can create PHP. Wait, those are the same.
You get what I'm saying. The programmers who whine about requirements to understand low-level memory management are in the first category, and their knowledge and skills are laughable compared to the kind of programmers who get hired by the likes of Google, Apple, and Microsoft.
Stop trying to pretend you're as good. If you were as good you'd be doing something interesting instead of slapping together enterprise bloatware.
I just went on a rant at work because one of our programmers decided, at some point in the past, to write blocks of code in inline hexadecimal. With little to no comments. It had a bug... five bugs actually. I spent two days in the code, finding and fixing problems which should have taken at most a couple of hours, all because someone decided to be a "Real Programmer", aka elite ass. I don't care what the esteemed Mr. Raymond and Mr. Nather (the author of the article in catb.org) believe; we created higher level languages, like C, to make it easier to write and maintain code. I can write code directly using machine instructions too; but, I have too much work to do. As the parent said, don't be like Mel, we all have real work that we have to get done and someone will hate you later.
but gawddamn, if I meet ONE more unshaven skinny ratty-haired white dev/programmer in his late twenties/early thirties with an aversion to water, soap, matching colors and food (what is it with devs and eating disorders???) here in Seattle, I might just have to defenestrate the fucker to save my sanity. Preferably out an upper window at the downtown Macy's, so that said dev/programmer might actually observe cleanliness and fashion through visual osmosis prior to becoming one with pavement. I don't care if said beautiful mind is autistic, aspie, or what-not--Hygiene is source code!!!!!! Execute it on a daily basis! And if the sensory stimulus is THAT much of an overload then spend some of your six figure salary to get therapy and coaching on how to minimize input while maximizing the ability to incorporate the close proximity of other people!!! I much prefer the Indian and Chinese devs and programmers, not least because they don't have eating disorders and they both understand and practice a minimal standard of hygiene.
Here's to hot beer, cold women, and Glaswegian kisses for all.
Not Babbage or Lovelace I wouldn't think... too practical :-)
Church and Turing, perhaps; the functional programmers can follow the former and the procedural ones the latter. I'd probably also include Claude Shannon.