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?"

Comments

Beards and suspenders.

[Kenja]

Difference is the "real" ones have beards and wear suspenders.

Re:Beards and suspenders.

[lgw]

Java schools are a menace, but since it's nearly impossible to find grads with a "real" programming curriculum any more, I think we've just sort of given up and accepted our fate as needing to teach new college hires everything.

If you can code - really write code beyond simple toy assignments - in any language, you're already doing above average. But if you want to be top tier, you really need to understand the crufty details of what compilers do and how they do it. While there are no lack of Java jobs, you're really missing something if you don't have a good mental model of computers at the machine language level, and if you've never done any "bit bashing" (working with unsigned ints as arrays of bits, not as numbers).

My suggestion for getting a rounded education is to go write some C code. Write code to count the '1' bits in an unsigned int -- no googling the answer! -- and then keep brainstorming for ways to optimize that (when you can snatch the bitcount with "n%63", you will be ready to leave the temple). Write code to do other bit-bashing - reverse the bits in a word, find the base-2 log of an int, and so on. Write your own "bignum" implantation from scratch, to have a larger problem to solve with lots of corner cases and ugly cruft.

These are toy problems, and they won't teach you all the stuff you can learn in Java about "software engineering", but they'll cover and important gap. Most importantly of all - debug through all your solutions and get comfortable with debugging. Debug through the generated object code, stepping through one instruction at a time until you understand what's happening. Debug through the object of non-optimized vs highly optimized code.

Don't stop until you're totally comfortable with bit-bashing, with pointers and pointer-array equivalency, and so on. Once you start debugging through C code, especially the object, natural geek curiosity will serve you well to cover the gaps in a Java-only background.

Re:Beards and suspenders.

[Anonymous Coward]

Write code to count the '1' bits in an unsigned int -- no googling the answer!

Meh. That's easy...

public static void main(String[] a)
{
        int x = 0;

        for(char c : Integer.toBinaryString(847389).toCharArray())
                if (c == '1')
                        x++;

        System.out.println(x);
}

-- and then keep brainstorming for ways to optimize that

I'm sure there's already a framework for that somewhere.

Not this again.

[HornWumpus]

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.

Re:Not this again.

[Anonymous Coward]

This. Memory management isn't difficult in the brain power sense, it's difficult in the pain in the ass sense. We've decided years ago that there are much better things to be thinking about than releasing objects and reference counting and that sort of garbage, especially since it can be automated.

What you are reading is people who are trying to elevate themselves by referencing a new obscure technique. Hey, I know AT commands for a modem. Does anyone give a shit? I certainly hope not.

If the only thing that differentiates a great CS grad from a crappy one is memory management, that's a pretty shallow argument. Google it, read it, manage memory for a few hours and poof you're an expert.

Re:Not this again.

[roman_mir]

Nonsense, real CS people should have a year studying butterflies.

As to Java or Assembler, neither are computer science. CS is about algorithms, run time, data models, paradigms, approaches. BTW, without understanding memory management, you will have memory management problems regardless of the language used. It is just the degree of how bad the problems are, whether they cause program to terminate only or also may become attack vectors.

ASM

[just_another_sean]

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.

Yes, but no

[Unordained]

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. =)

Re:Why do CS grads become lowly programmers?

[passionplay]

You study ENGINEERING (a discipline) to become a LICENSED PROFESSIONAL ENGINEER.
You study MEDICINE (a discipline) to become a LICENSED MEDICAL DOCTOR.
You would have to agree an automotive engineer is not the same as a mechanic which is not the same as a scientist in combustible fuels.

Software development is an art form. Software engineering is a discipline. Computer Science is a science.

Studying computer science by itself enables you to become:
1. A computer scientist
2. A computer programmer
3. A computer technician

Even becoming a computer science teacher would require you to study EDUCATION as a discipline.

There are no shortcuts. While life experience may teach you SOME things to become an engineer, there is no substitute for a Computer Science degree that focuses on software engineering. You could become an engineer after years of experience. or you could simply learn the discipline and stand on the shoulders of giants and open yourself up to learning from and teaching others in the discipline for a lifetime.

The next time you ask yourself, "Where on God's green earth would I use this knowledge", stop yourself. And think: "Why on earth would I want to work harder and solve problems already solved by others."

An engineer solves problems a new way because the outcomes of all the known methods are not satisfactory. An engineer can predict reliably how long something should take from his body of knowledge.
A developer solves problems a new way because it's fun, it's cool and it's artistic. A developer, like an artist, works until he's done.

There is nothing wrong with being a developer or an artist. But just as we should never confuse industrial art with fine art, we should never confuse software development with software engineering.

If you can only solve the problem at hand, you will not have fun doing engineering. If you are happier solving higher order problems of how things are put together and how to do things efficiently or discovering how to things MORE efficiently by building on the knowledge of others or collaborating, you will have fun doing engineering.