The languages used in various parts of a CS curriculum are one component to the whole. Holding up that component as the reason that the sky is falling is, at best, disingenuous. I can construct terrible CS curriculums that start with C, and terrific ones that start with Java.

If those who construct the curriculum want the beginning courses to focus on algorithmic thinking, I think it's fair to use a language that abstracts away much of the physical machine. The abstractions can be peeled away in later courses.

If, instead, they want the beginning courses to focus on the realities and difficulties of dealing with computer systems, it makes sense to start with something like C. They can then introduce the abstractions that let people manage those difficulties in later courses.

I think both approaches are valid, as long as a student gets a view of the important points of the field. I can even see arguments why one approach might be better than the other. But claiming that one approach represents the failure of our CS academic system is zealotry.

Now, that doesn't imply that Java shouldn't ever be taught. But the reasons for choosing any language should be academic reasons. Particularly, it is bizarre to see academia trailing industry in language adoption.

Also, I doubt your claim about C is true. C was used because it was close to the machine without actually being assembly. I suspect C was then taught because it was used everywhere.

Kids these days don't understand that computer science and software development are distinct disciplines.

A cs degree is universal, it should be language agnostic.

One computer language or another, it doesn't matter one bit, they're all functionally equivalent. Just like a chef cook has 30 knives to choose from you have a palette of languages that you could choose from to solve a given problem.

If you really understand computers then the languages are just a means to an end.

See PG's essay where he talks about the Blub Paradox: http://www.paulgraham.com/avg.html

Note that I think this point is different than how this thread started, which was about teaching.

The right tool for the right task.

To address your question, Java abstracts away memory management - not just dynamic memory allocation, but common off-by-one mistakes will result in a runtime exception. It's possible, but unlikely, that you'll get a segfault in C. You probably own the memory just past your array, and you're more likely to get strange errors because you're invisibly overwriting values.

If you want to focus on algorithmic thinking, and not the realities of a computer, this is a win. As another posted pointed out above, I think other languages are better suited for this, but Java is still valid.

I don't know that Java does this all the much better than C. The problem with C for a beginning student isn't so much that you have to manage memory manually--it generally takes a few weeks to even get to malloc() in a C-based introductory course--but that C gets in your way with explicit typing, #includes, etc. Java does away with some of that but introduces its own OO scaffolding to get in your way too. Instead of having to write main()s and #include's, the Java student has to enclose their functions in a class and so forth. Let's compare Hello World in C, Java, and C#.

C:

  #include <stdio.h>

  int main(void)
  {
    printf("Hello, World!\n");
    return 0;
  }

  class HelloWorldApp
  {
    public static void main(String[] args)
    {
      System.out.println("Hello World!"); // Display the string
    }
  }

  class Hello 
  {
     static void Main() 
     {
        System.Console.WriteLine("Hello World!");
     }
  }

If you really want an abstract language to enforce algorithmic thinking, pick one that doesn't have all that extra mental burden when you first approach it.

Perl 5.8

  print "Hello World!\n"

  say "Hello World!"

  print "Hello World!"

  print "Hello World!"

Java has advantages over C. These advantages don't include "letting beginning programmers focus on algorithmic thinking by using high level abstractions". Java's higher level than C in that it protects you from naked pointers and lets you do OOP, but that's not the type of high-level abstraction that helps a beginning programmer, especially not when it comes at the cost of forcing them to put everything in classes and methods.

If those who construct the curriculum want the beginning courses to focus on algorithmic thinking, I think it's fair to use a language that abstracts away as much as possible. We have no shortage of good interpreted languages to accomplish this.

For example, unless you're concerned with specific performance issues, you're not likely to care how a string is implemented in Java. It's difficult to use strings in C without understanding memory. Without understanding when strings are mutable and when they aren't, what null-terminated means, how "%s" works, and such you will quickly run into some unexpected behavior and will likely just trial and error until you get something that seems to work. When you understand that C is a syntax for allocating and manipulating memory, it tends to make a lot more sense.

for (int x = 1; x <= 100; x++){ System.out.println("Hello World! " + x); }

vs

for (int x = 1; x <= 100; x++){ printf("Hello World! %d! \n", x);

PS: How do you include readable code snippets on HN?

    Prefix four spaces to a line to format code.  

  for (1 .. 100) print "Hello World! $_\n";

  100.times { |i| puts "Hello World #{i}" }

I've taught intro to Java labs to undergrads, and I did get questions on the scaffolding required. I answered their question, but also told them they don't need to understand that now. I'd rather not have to do that.

It would be fairly easy for someone to learn Java once they've been taught C. Professors should not have to spend time going over pointers and memory management in an OS class, however.

Granted in our OS theory class we spent most of our time using / talking about ASM, but C could also work fairly well.

http://www.cs.northwestern.edu/~bmd/cs213-f03/docs/syllabus....

I do teach programming, and most of the time I see both the concept of pointers, and syntax is pretty understandable.

The real trouble begins when you expect students to use them to their advantage - but it really is beyond syntax.

As a newb, you get bogged down in the details and knowing the cases for when to use &,* seems like an added complication.

If you have a pointer (that is, the address), then you need to prefix it with a * in order to get the value in order to do useful things. If you have a value, you need to prefix it with & in order to get the value's address in order to pass it around more efficient (at least it will be more efficient if it is some large data blob).

Did anyone ever mention addresses and values and their difference when looking at Java from a users point? Not to me, to be honest.

Pointers are simply the first thing that forces most coders to consider that split. But, a reasonably competent JAVA developer moving to C can pick them up in little time. The problem is reading other peoples C code that looks more like line noise than structure. But, pointers are a tiny step along that path.

Low-level memory issues should be avoided whenever possible by using a higher level language. There's a reason why garbage collection was invented.

I'd much rather have spent that time learning the more-useful mundanities of memory management in C.

Software engineering, on the other hand is too important a subject to be left to the schools. Let them learn Scheme on their own. They'll appreciate it more that way.

Language details are all academic, pointless debates to be had by people who like one over another where the differences are often trivial (C++/Java). If you have a great mind and can understand what languages are doing then either will do you just fine.

I'd rather not teach the next generation of CS under-graduates the same old stuff that I did (and yes that included how the VAX-11/750 - one of the first to do so if I recall correctly - didn't have to have all a programs data or code in memory...)

Teach them things that will take CS forward...

Among the higher-level problems you mentioned, how many of them are interrelated? I'd rather see professors cover material that is useful in 80% of cases, even if they are well-trodden topics - students can specialise in the rest. In my CS course (UK) we studied parallel systems, including MapReduce; distributed databases and NLP can be studied optionally along with several other topics of much higher level than mere page faults. That said, not all CS courses are created equal.

you do not need to understand how your compiler works, or how De Morgans law is responsible for all those NOT gates in your CPU to produce useful and meaningful CS.

"Programmers who don't understand the memory hierarchy write slow code" is just nonsense.

Most programmers today use languages where they aren't even aware of, or able to manipulate in any way how and when memory is managed. And this trend will continue as the hardware their programs run on are increasingly virtualized.

Let's face it, virtual memory is a done deal, its now fundamental until we find computer hardware architectures that don't ever have address spaces that exceed the physically addressable memory. With virtualized kernels, possibly its a better solution to boot operating systems that have no concept of constained memory resources, and let the virtualizer do the paging.

The problem with Java (and C, to a lesser extent) in basic problem solving is that you can almost brute-force-code and get a working solution that will get full credit, but after writing it a more elegant (and efficient) solution isn't always obvious. In functional languages, that "more correct" solution almost always seems to stand out more, at least to me.

If a functional language was taught in beginner CS classes I think it would be easier for students to see how it works. It certainly "clicked" for me once I'd learned a bit of Scheme in my first AI class.