Slashdot Mirror
Java as a CS Introductory Language?
First, tulare queries: "I'm currently a student at a small university whose CS students are required to attend two terms of Java programming courses before moving on to other OOP languages. My personal feeling is that Java is clunky, ugly, and runs much too slow on most platforms. The official CS department position is that Java is pure OOP (as opposed to C, for example), and furthermore, Java is extremely widely used at this time. Now, I may be stirring things up a little here, but just because everyone does something one way does not neccessarily mean that something is being done the best way. What I'm asking is to hear reasoned opinions on the following statements:
- Java is a fine development language, and it will help me as a programmer to learn it.
- I'm right. Java is a fad, not worth much more than the Windows OS in terms of quality, and my CS faculty is doing me a disservice by cramming it down my throat.
- There's a little truth in both the above statements."
While on IRC, I was discussing this issue a bit with other editors and Chris DiBona happened to have some thoughts on the matter, his words follow:
When Cliff mentioned that a Java in education story was going to be posted, I asked to weigh in on the topic. I will not talk about the suitablity of using a non-free language, as I'm certain that will be discussed in the comments and is not a trivial issue.I don't think that Java, or any Object Oriented language, would be suitable for an AP Computer science class. I don't think it serves the needs of students looking to fully understand the internal workings of a computer, which is in my mind what an AP computer science course should be directed towards.
C is a language that has been designed to be very close to the hardware, and its ideosyncracies and power reflect that. Through this relationship, C reflects the realities of the hardware your programs run on. Memory management, low level process and I/O control are all things that a computer scientist should understand at a very low level, to better aid in future programming and debugging no matter which language is chosen or inflicted upon said scientist.
In contrast, Java has been designed to take such concerns away from the programmer. Memory management? Low level IO? These are not the droids you were looking for.. (at least not without an RMI written in another language) That's okay too, that isn't what people want from Java and it isn't what it was designed to do.
And that is exactly my problem with it being applied in a computer science course designed to teach CS fundamentals. In short, since I believe that AP CS courses should focus on the low level architecture of computing, Java is an inappropriate language for that course.
When is Java appropriate? In your college sophomore comparative languages course, or, alternatively, in an OO course or two, but it shouldn't be used as the keystone language for any CS program. Please don't take this as me saying that Java is neither useful or important in it's own (non-free) way, as it clearly is. However, in my opinion, It should be considered an adjunct subject to a serious program in Computer Science.
C and C++ more intuitive?
You have to be kidding.
Steve Michael
Really, what language you use in those first few programming classes is a secondary concern. You don't take those classes to learn the language (although that is a side effect), you take those classes to learn the fundimentals of programming, which apply to almost all computer languages (BASIC not withstanding). Once you learn the fundimentals, learning whatever language you need, be it C, C++, Python, Perl, Java, Lisp (not as much, functional programming languages are generally different enough from procedural languages that they require another class to use correctly).
I say, use whatever they are teaching, and if you don't like it then pick up another language. It's a lot easier to learn a programming language than it is to learn how to program.
My only concern is trying to shove too much syntax down the throat of first year students. Full blown OO languages tend to require a bit more typing than something like C for the trivial projects that students do, which may turn off some people (I know in my high school, the Pascal class lost 3/4 of it's slow typers on the second day. Worse, in high school almost everybody types slow.)
I guess you might want to avoid "bad habit" languages as well, like BASIC and possibly Perl. I'd also shy away from anything that the average windows user hasn't heard of like Scheme, Python, Modula II, Ada, or APL. You probabally want to chose something with good free or cheap compilers as well. Ada95 may be a nice language, but your school won't be able to afford the licenses for the compilers under Windows.
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
I read the internet for the articles.
Today's students will probably do thir best work in a language similar to Java, but with better support for the things that Java is bad at. This language does not yet exist at all.
It will use many of the same language features that languages that currently exist have, though, and this is what it is worth learning. Of course, its features which are currently available are available in different languages, so it's important to learn multiple languages.
For OOP, I think that Java is a good tool. Possibly Scheme would be better if you wanted to present the full range of possibilities, since there are theoretically significant features that Java lacks (e.g., singleton instances). Of course, in order to be particularly good programmers, people need to know more than just OO concepts, and that means they'll need to learn a language that's good for teaching those concepts.
In practice, currently I would suggest C for actual programming, including OOP, unless you need platform-independence or you need libraries that exist only in another language. But I wouldn't want to try *teaching* OOP with C; you really want to have a language where the OO syntax is obvious and explicit.
I'd argue that unless you understand assembly, you don't fully know how registers work. I haven't had to write any assembly for over 10 years, yet with every single line of code that I write, I'm thankful that I could if I needed to. I'm sure you're a very competent programmer, but empirical evidence from 20 years of coding shows me that without fail, coders that don't know assembly are unable to progress beyond competence into true greatness. Not that greatness is actually needed for 90% of coding tasks, but nonetheless, those with a background in assembly are without fail better coders.
As for when it should be learned, I disagree that it should be a first language, but it should be mandatory in any CS course at some point. but
"The invisible and the non-existent look very much alike." -- Delos B. McKown
"I've had some conversations w/ friends of mine about this very idea. I think that assembly should be the first language taught in CS. To be a skilled programmer, you MUST know how a computer works at the fundamental level. Teaching java to beginning programmers only encourages sloppy programming, despite any admonitions from profs"
And if tomorrow a new CPU is released that doesn't have a von Neumann architecture? How does the person whose fundamental thinking processes w.r.t. application developement were structured by assembly adapt to that?
Personally, I would go a step farther. One of the reasons that ordinary human beings have so much trouble using software is that the programmers are far too close to the details of the machine architecture.
sPh
I've had some conversations w/ friends of mine about this very idea. I think that assembly should be the first language taught in CS. To be a skilled programmer, you MUST know how a computer works at the fundamental level. Teaching java to beginning programmers only encourages sloppy programming, despite any admonitions from profs.
Nice sentiment, but regardless of the "ideals" of education, when one gets out of college, one expects (screw that -- NEEDS) to get a job, and given two straight-A students, one with a lot of theoretical-application languages under his belt, and the other with not so many of those, but having known Java since his freshman year, the recruiter will pick the Java programmer, 'cause it means his company can save money having to train the programmer.
And any University with a reputation for letting the education get in the way of future employment for their students is gonna start losing students quickly.
Its nice to "learn", but the truth is that since the 1960s and the G.I. bill, one goes to university because the degree is a requirement for getting a job, not to "learn". And that isn't gonna change anytime in the near future.
The theoretical and the practical-for-today's-world should be considered hand-in-hand. I value the theory I know from my C.S. degree very highly...but I wouldn't have gotten the good job I wanted without having had C++ in college.
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
As someone who uses many languages in the course of the day, Java included, I might be able to offer some information.
This is dead on. I wish that I learned OOP properly in college. Learning C and other procedural languages actually hurts you in the early stages, because you have to unlearn tactics.If I were teaching someone OOP in college, I would start with a "pure OOP" language, such as Python or Java, and a book similar to Design Patterns. I sure wish I learned this way.. Design Patterns came out after I graduated and it pretty much changed the way I thought about OOP overnight.
That's not to say that C++ doesn't have its place. It can be fast, and it can be very flexible. However, in an academic environment other priorities are simply more important. Garbage collection is key. Trust me, you don't want to be up all night tracking down a memory leak when all you need to do is implement a certain algorithm. Also extemely important is a free, cross platform development environment. (No, C++ isn't as strong here as java or python due to library implementation differences). I consider C++ a very dangerous language to start learning with because it's so easy to slide back into C. Until you get to the point where you can understand what the consequences of that are for your project, it's a giant boobytrap waiting to snare the unwary.
This is a very popular but shortsited viewpoint. Java is stronger than it has every been in the past. It's still in heavy growth mode, with more libraries and extensions being developed for it than I can keep pace with these days. It's going to continue to evolve for quite some time. As the JVMs continue to improve in performance, and CPUs continue to double in speed, the performance difference between Java and C++ is going to become less and less. It's already at the point where I run large java applications like Jext (thank you very much Roman Guy!) on my pentium-III 600 without any noticable slowness.Java is a very good investment. It's not the best OOP language in every area but it may be the most well rounded. It's certainly not going away, and you can get a lot of useful work done with it.
Java seems to enjoy better support for the corporate world than from the open source community. This is largely because Java is so useful to corporations and they're ready and willing to develop and pay for enterprise class extensions that most lone hackers would consider boring or overkill. Java isn't a zero sum game, however, and there is plenty of room for free software to thrive. I'm glad the the Apache crew recognize this- their Xerces XML parser and their Servlet engine are excellent, excellent examples of free java software. www.gnu.org also lists a large number of useful java libraries and applications. The time is ripe for someone to bring Kaffe or similar free JVM / library up to speed.
If you do decide to get into Java, I would recommend you learn python as well, and then use the embedded scripting language jython (www.jython.org) from within your java apps. It's a killer combination.
What does widely used have to do with good teaching :-)
C++ is probably the most widely used OO language, but it sucks as a teaching language.
C is the worst teaching language one could think of and not even appropriate in the context of OO programming.
VB is extremely well used but it's debatable if it is an OO language (or even a programming language
Smalltalk enforces the parts of OO that it supports so it is an OK teaching language.
Eiffel supports and enforces all parts of the OO paradigm and is an excellent teaching language despite the fact that it is not videly used.
The University of Illinois at Urbana/Champaign has been using Java in the introductory CS class since the spring term of '98 (when I first took it... before that they had been using scheme). The first portion of the class (at least back then) dealt with basic programming syntax and how to do loops, etc. Then it moved on to the OOP philosophy and started dealing with classes.
The course homepage for CS125 is: http://www-courses.cs.uiuc.edu/~cs125/
The next class required of CS majors is CS225, which is a data structures class taught in C++. The first couple of days of the class are spent going over the difference between C++ and Java (most especially stuff on pointers), and then later they move in to data structures and algorithms.
The course homepage for CS225 is:
http://www-courses.cs.uiuc.edu/~cs225/
He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.
Doug Lea (well known C++ programmer and writer; teaches at SUNY/Oswego)
Kevin Sullivan (U. of Virginia)
A couple of less positive articles from Australia.
An article at O'Reilly.
Stupid job ads, weird spam, occasional insight at
I have had several students here who started to experiment with all sorts of arcane features like inner classes and operator overloading without learning how to write good programs first.
Funny...Java doesn't have operator overloading (just method overloading and overriding). If your students are doing that, then they are skilled indeed (as they have probably modified the compiler to do what they want)Again, you're trying to blame the language for bad teaching approaches. I've seen courses taught with buggy C compilers. Does that make C an inherently bad language? Of course not.
There is no requirement to teach applets as part of a programming course that incorporates Java, and IME courses which do concentrate on applets are normally outdated: applets don't play as large a role in Java today as they did back in the days of 1.0.x - most of the roles Java was expected to fulfil through applets are now using other technologies, from simple animated GIFs to Shockwave applications.
The last good Java course I saw didn't cover applets at all, except in passing. It did, however, cover enough to make it possible for students to learn how to write applets if they needed to.
Fair enough. Quibble over granularity rather than answering that issue. The overall question is whether Java is a better language to teach beginner programmers (or more accurately whether it's a good language to teach them) - the issue that you misunderstood was the question of whether Java is 'cleaner' than C++. This has nothing to do with buggy VMs, and everything to do with a clean and simple object model.
public class Globals {public static int GLOBAL_INT;
public static String GLOBAL_STRING;
}
Ugly, yes, but I believe you'll find it does the trick. It's actually one of those recurring features you see in bad Java code where people are trying to write C++ in Java.
And if we step back a little from your argument, what you're actually saying is that it's easier to learn to code in Java than it is to code in C++ (something that I'd personally agree with). And that's a good argument for using Java over C++ in my book: there's much less time getting to grips with (and struggling with) the language, with the result that more time can be dedicated to learning what you can actually do with it. Which is presumably what people are there to learn anyway.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
This is a great idea, and it's exactly what my CS program did in college. We learned C, C++, Lisp, SPARC Assembly, and Prolog at least in the core cirriculum. Java, SQL, several flavors of Lisp, and perhaps some other programming-type languages were taught in elective courses. VB was available in the business department.
The major problem is that after all this time spent on DIFFERENT languages, I'm a jack of all trades and a master of none... I don't even feel comfortable coding C++ anymore just because I haven't done it for at least 2 1/2 years: it wasn't asked of me toward the end of my program. The only above language that I did NOT get to take is Java, because of scheduling difficulties, and now I sorely regret that... because now I'm looking for a part time job to make ends meet as a recent BS-CS grad with an MIS minor and two completed internships. Yea, life sucks sometimes, but whatever.
Point is, I may have a diverse background in languages, but that doesn't help me professionally. I still wonder why I spent all that time learning all those languages and no one made sure that I would be able to apply my skills in the real world.
I mean, if you're gonna teach a course on a subject, maybe you shouldn't design it around trying to make money off the concept. But if you're going to assemble a department and an educational program that people will be paying in excess of $20,000 a year to enroll in, then perhaps more than FOR loops and system calls should be included in the bunch.
This is the problem with Java though. Teaching Java instead of C++ is a cheap way out... it's not supplementing a good program with job skills, it's replacing a good program with the language of the year. It's the dumb way of answering the question of "How are we ever going to use this stuff?" Instead of teaching them what they should know, they'll teach them what they want to know. That's not always good. In this case, it's flat out horrible. But I suppose it'll make many people happy as long as no one figures out that a Java-based CS program is perhaps as bad as all the Visual Basic courses they teach over in the business school...
Not to be nitpicky, but you mention providing marketable skills & performance isn't the issue. If Java is a slow performer, wouldn't it tend to hurt students more learning a language that is slow, and klunky? Last I checked, there were plenty of jobs available for C & C++ programmers. I have a feeling that Java may be a fad, and C/C++ will be around and fall back in favor unless Java really takes off.
Java lets you do some cool stuff, and it lets you do some really klunky stuff, but it isn't designed for performance. Any industry that is CPU bound (Simulation, number crunching, gaming, local applications, etc.) needs to be coded to run fast. Industries that are network bound (ISP's, ASP's, Portals, etc.) don't really care about how much the CPU is choking because the network is the bottleneck. I have a feeling, once the network is no longer the bottleneck, Java either better get fast quick, or it's going to be going back to C/C++ for speed.
Obligatory flamebait disclaimer: I don't think C and C++ are going away, or that Java is the One True Language. However, it is ridiculous to assert that Java is slow, poorly adopted, or unsuited to real-world applications in the face of overwhelming evidence to the contrary. Very serious companies like Oracle, Sybase, IBM, Macromedia/Allaire, Borland and of course Sun, are banking lots of money on Java's success, recognizing that it's a mature, robust, stable, fast language for very serious development.
Right...
Every time there is a discussion on Java, the same complaints come up:
Guess what, folks - most of that hasn't been true for the past couple of years, and it's getting better all the time. The stuff that you're not and won't be allowed to do is prohibited for the most part because it's dangerous and counter-productive. Java, like any widely-adopted language, does not simply cater to the 31337 hax0r.
I've helped teach a class for the AP and IB CS exams, and I'll tell you what they're about more than anything else - algorithms. That certainly doesn't benefit more from C/C++ than it does from Java. Hell, if that were the concern, we'd use Haskell! The point is, the class's focus isn't on pointer arithmetic, code optimization, or any other topic that makes C++ a more natural choice than Java. As a matter of fact, having to consider those things make C++ an obstacle to understanding, rather than an aid. I'm glad the College Board is changing the language to Java - it's the right thing to do for the level of understanding they're trying to teach.
Right...
Let's face it, most tutorial languages are picked for being high level, and having a fairly shallow learning curve. When I started learning programming, Pascal was used, which was fine in the days of purely procedural programming. Now that OO is more or less the defacto way of thinking about things (NOT to say that we should only be programming in OO languages), it makes sense to go with Java. Java was designed from the very very beginning with the explicit goal of making it harder to make mistakes - errors are caught up-front as much as possible.
Java has:
1) strict typing
2) dynamic linking
3) built-in memory management
4) a consistent implementation and rich libraries from a single vendor (for better or for worse)
5) works *identically* on many platforms ("identically" is the key here...we don't need to be spending half our time teaching build environments for various systems)
For all these reasons, it makes sense to use Java as a beginning language. The basic programming concepts are all there (yes, even resource management). The problem with C and C++ is that it is very easy to obscure larger concepts with intimate technical details, the learning curve is steep. I remember when I was learning Pascal, it was as if the class hit a brick wall when pointers were introduced. Imagine if learning pointers and intimate machine-dependent ("words"??) memory management was the prerequisite to larger programming concepts such as conditional statements, iteration, recursion, etc. The whole learning process would be stymied.
And I used to be one of the oh-so-cool C++ programmers who thought that Java was just a kindergarten-level "fad", and scoffed at it when it was used to teach programming in CS courses. Now enterprise Java programming is my day job, and I can attest to the fact that it is NOT a fad, is very powerful, and is used to do some really serious, and really cool stuff. I'm sure assembly programmers said "C?? You don't even need to know what REGISTERS are to use that!!".
It's 10 PM. Do you know if you're un-American?
Hear, hear. I'm sick of seeing freshly-minted Java programmers grunt out mounds of steaming O(n!) code, believing that "this is good cuz it's Java."
Knuth continues to use MIX (and the new MMIX) and MIXAL in TAOCP for this reason; once you know how the computer works, and which algorithms are the proper ones to use, your choice of high-level language often becomes irrelevent. Just a choice of style.
Wake up, people: you can write FORTRAN in any language.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
There's a really great book out called _Accelerated C++_, by Koenig and Moo. (Yes folks, that Koenig and that Moo, the C++ gods.) It's a very new approach to teaching C++ as a first language, and everybody who's used it or even just reviewed it has loved it.
It doesn't even introduce pointers for several chapters. Students learn how to write simple loops, manage collections of things using std::vector, do the common 90% of string-related tasks using std::string, write some useful and practical programs, all before ever seeing a pointer.
Side note: the book is part of the C++ In-Depth series, being edited by Stroustrup. One of the rules for the series is that the main body text of the book must be no more than 300 pages. No filler crap, no 1500-page tomes to raise revenue; make your point simple and clear and then shut up.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I suppose VB would be good for teaching what people have to do in the real world when their language isn't up to the task at hand, and vendors have to invent new and strange things to give programmers the features they want. VB feels so hacked-together it's not even funny.
Besides, if we went by "widely-used" to decide what to teach new programmers, we'd all still be using COBOL. :-)
Software engineering will come of age when programming languages no longer exist. All programming languages (Java, Lisp, C++, etc...) share a common charateistic. They are all based on a programming technique which was first pioneered by Lady Ada Lovelace more than a century ago: the algorithm. I am convinced that the algorithmic nature of software is the primary reason that computer applications are so unreliable and that software development is so time consuming and expensive.
It is a known fact that hardware is orders of magnitude more reliable than software. The most obvious difference between software systems and hardware is that the former is algorithmic whereas the latter is based on parallel streams of signals.
A signal-based system is ideal for the implementation of work-once, work-always components that can snap together at the click of a mouse. This is because their temporal signatures remain constant. By contrast, one can never be sure when an algorithm will be done and this is detrimental to stability. Algorithms should thefore be implemented on top of a signal based system. They should not be the basis of automation. In the future we will have technologies that allow computer memories to instantly reconfigure themselves into parallel logic circuits. In the meantime, even though the Von Neuman paradigm forces sequentiality on us, signal flow parallelism can be easily emulated in software so as to hide the serial nature of processors from the application developper.
Unless computer scientists wake up from their algorithmic stupor, computer science will continue to limp along, badly. More multi-million dollar space probes will malfunction, airplanes will crash, electronic stock exchanges will suffer from glitches and airports will shut down. Half a century, thousands of lives and trillions of dollars later, we'll kick ourselves in the rear and ask ourselves "why have we been so damn stupid for so long?"
Java is, I would say, more platform dependent than C or C++. Furthermore C and C++ are actual real international (ISO) standards which means that you're protected against changes to the language that will make your old code incompatible with the new language every three years. Java is something that Sun does whatever they want with (and Microsoft has it extensions to it making it incompatible with the rest of the world as usual).
/have/ had troubles when people have been using extensions to the language, or as you call it "Borland C++ programs". The point is: Those programs are not C++. They are "Borland C++ programs". Those two things are not the same.
Why is Java more platform dependent than C or C++? First of all, if your platform hasn't got a JVM, you are done for. You can't run Java programs. If anyone tells you you don't need to have a JVM, then WHAT THE HECK IS THIS DISCUSSION ABOUT?
There's absolutely nothing in the C or C++ language standards that says anything about the platform, that's why those languages are so great for writing embedded applications and operating systems. They don't even assume the existance of a monitor or a keyboard.
I have never in my life had a problem with running C++ code written using the Borland C++ tools on my GNU/Linux or NetBSD machine. I
Now, I need some coffee...
It's 11pm, do you know what your deamons are up to?
I also think that Python is better suited as a introductory teaching language than Java. OOP is important, but it is not something you can grok as a beginning programmer, IMHO. Python is a multiparadigm language, you can start with imperative programming (modules and functions), later you can introduce the OOP style with classes.
;-)
With Java, you no choice but to start the OOP way from day one. And Java's OOP isn't that hot, either (there are still primitive types that aren't objects). If you want imperative programming in Java, you have to fake it with static methods.
There is a difference between what is a good first programming language and what is a good language to learn software engineering principles. For software engineering, Java would be a reasonable good choice.
Gerhard
PS: I study c. s. and I had Java (and Haskell) as introductory languages. Yes, I do follow the cult of the snake
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Seriously. It has the pure OO-approach and lambdas of Smalltalk, simplicity of Python, flexibility of Perl, even borrows mix-ins (advanced OO concept sort of like multiple inheritance) from eiffel and is fun, with easy to understand syntax! If you're going to teach OO language approaches in an imperative language, this is a serious language that contains just what you need and no extra fluff. It is easily extendable, both in C and within the language itself. I bought the "bible", got productive after a few hours and learned almost everything but C-extensions in just 3-4 days. Very easy and fun read, plus the entire book is also available online.
;-) Java is NOT a well-designed language. It's not always best to follow the pack either, those who make a difference don't. Ruby is perfect for bringing up new ideas. Let students experiment with extending OO-concepts in the language!
Here are some additional links:
The official Ruby page
Dr. Dobbs article about Ruby
Documentation
HotLinks
If this weren't MUCH better than Java, I wouldn't pull this shameless plug. Please check it out, don't stay in the dark ages..
Btw, PLEASE don't make the students create Object Oriented ZOOs and the like. We were forced to such meaningless assignments when we had OO-classes in school, and such stupid problems are for OO-morons. Additionally, you don't need a "fast" language for teaching OO-concepts. On the contrary, since ruby is a glue language (like perl), it can be used to glue the right tools for the job when you need it to. It's definately fast enough if you just express your ideas in it correctly (avoiding many nested loops). Some people even use Ruby as a specification language, because of it's easy-to-understand syntax and lambdas. Ruby code is usually shorter and more readable than the same code expressed in other languages.
- Steeltoe
http://www.debunkingskeptics.com/
How long do you think java is going to be "free" for? My guess -- another 5 years -- by then it will be everywhere -- and SUN will pull a Unisys and start charging fees for it. (this is just my oponion, not fact)
I think schools shouldn't teach their students langauges that aren't free (as in speach). Theres 100 C/C++ compilers you can buy/download, but just a couple java compilers.
\editorial : For begining students I expect Python would be a good choice -- its simple, very consistent, and is very explicit about variable cohercion, and is still "powerfull".
Free Techno/Jazz/DNB/MI Music by guys obsessed with monkeys!
It is widely and freely available. Not as much as C or C++. Almost every machine on the planet is capable of running C code. That's not true of Java. And you're never going to write device drivers in Java.
It is being used widely in the industry - again, not as widely as C / C++. Not even close.
I think educational institutions have a responsibility to release students with marketable skills. I agree with this statement, whole-heartedly. Unfortunately, you seem to think that Java programming is a marketable skill. Or at least, you seem to think it's MORE marketable than C/C++. Which is insane. Any reasonably competent C/C++ coder can pick up Java in a heartbeat. The converse is not true. I've seen Java coders who STILL can't figure out how to dispose of memory, basically don't understand the difference between stack and heap, and don't understand pointers well enough to dispose of an element of a linked list.
And Java offers all the needed constructs and is good to teach the OOAD methodology. No, it doesn't. By virtue of using Garbage Collection, it is taking memory management out of the hands of the developer, teaching people to be lazy when it comes to object instantiation and use. Not having pass-by-reference gives people the idea that having class-level variables is a viable option. But the problem is that most simple projects are written in one class, which essentially teaches them to use global variables - which is not good. Lacking pointers is the critical flaw...
It's possible to learn C/C++, with an understanding of Java. But it's far easier to learn Java with an understanding of C/C++.
Most people will end up coding C/C++ for most of their work. Teach them to use the language that they'll end up using. Specifically because it's easy for them to then learn Java. Whereas if you taught them Java, it's not as easy for them to then learn C/C++.
Education is the silver bullet.
My school now uses Java for its introductory classes. Since I TA'd these classes in both the C++ and Java versions, I think I can speak with a little authority. Java is a good language to use for introductory programming/algorithms.
The class particularly in question is called "Data Structures and Algorithms". In my experience, the students who took this course in Java had a much smoother experience than those who took it in C++ the year earlier. Programs crashed mysteriously less often, they didn't have to deal with memory leaks, they had less compatibility problems, and were able to write more sophisticated and interesting programs in the same amount of time. Since Java is simpler, we were actually able to teach almost everything in the language to them, where for C++ we had to leave out a significant amount of its core (such as templates, which meant that they couldn't really understand the string class, for instance).
All of the CS majors took "Systems programming" the next semester, which is a hard-core C programming class; most go on to take Operating Systems, in which they learn anything you'd hope they'd learn by struggling with C or C++ in the intro class. I agree totally that systems programming should be a significant part of any CS program. But systems programming is just *a part* of computer science (in the Slashdot/Linux crowd, perhaps it is the most popular). And in truth, things like manual memory management and hardware access are not important in most of the other parts of CS. For teaching algorithms and data structures, these things are a hindrance.
Personally, I'm waiting patiently for the day when only the most low-level software (a microkernel and hardware drivers) are written in C or assembly, with all of my applications written in a safe, GC language (perhaps Java, though there are better alternatives). It sure will be nice to be free from buffer overflows and memory leaks, finally! So while my recommendation of Java here is partially influenced by that goal, I think it is also quite justified for pragmatic reasons.
Here are some reasons why you are bad (I have TA'd 7 CS classes at my university, so I am not just pulling this out of my ass):
- Many people who will not be getting a degree in Computer Science (but who might interact with programmers or write some MS Access scripts) take introductory programming classes. It is important to have these people learn the fundamentals of programming rather than their actual implementation -- assembly will be practically useless to them unless they take the time to take compilers, operating systems, etc...
- Assemblers (and I might even stick C in this category, if I was feeling snappy) do not support the abstraction and generic programming features important for writing interesting programs. (Except systems stuff.) Introductory programming classes typically focus on data structures and algorithms; if you make the students program these in assembly, you are limiting the amount of material you can cover (and therefore, how much they can learn).
- Assembly as an introductory language is going to scare people away from computer science. Systems programming is pretty fun, but it's not for everyone. Many computer scientists hardly ever program (let alone in assembler), and I would wager that most professional programmers do not need to write in assembly language. Assembly is a great enhancement to a programmer's (or scientist's) knowledge of computers, but understanding it is not a requirement for programming in high-level languages.
- The world will be a better place (fewer buffer overflows (thus security holes) and memory leaks, more portable software and code reuse, and shorter development cycles) if we encourage new students to move towards high-level, abstract languages. I'm not saying Java is the best choice for this (though it may be the most practical), but assembly certainly isn't.
WOW!! I wish that I could have seen one of those. A 25 millihertz processor! My analog watch can calculate 1+1 faster than that thing.
A goof like that really is just asking for some snide remark...
C++ has two big problems. One is cruft, and the other is memory management.
C++ has a long legacy. Too long. Not only is there the legacy of C, there's the legacy of early C++. Templates, exceptions, and references came in late. It shows. There are too many things that are done the way they are only for historical reasons.
C++ and C program design obsesses on memory management, because what you take, you must give back. The language provides little assistance with this. That's not what beginning programmers need to focus on.
C++ needs a major cleanup. I've been toying with a design for "strict mode" for C++, comparable to "use strict" in Perl, which would get rid of much of the cruft. C++ comes out of the 5-year ISO standardization freeze soon, so it's time to be thinking about this. But that's for the future.
If you *must know how a computer works at a fundamental level*, then assembler isn't it. I had a microcode class that really helped me to understand about assembler optimization. You can make the argument that you can't really understand level N unless you understand level N-1, recursively all the way to quantum physics.
Or why not start at the other end of the abstraction stack? Start with cognitive pyschology, perception, human-computer interaction, and the identification of human needs -- then you figure out an approach that best meets people's needs, which would lead to how to choose the right software tools and approach for any particular case.
For a CS class, I wouldn't start at either extreme. Choosing the right level of abstraction is important, and the answer isn't just automatically one below what the other guy suggests.
I think CS classes should start by making it clear that the point of it all is to create useful stuff for real people. Teach them what they need to know to get started ASAP doing so, and fill in the details with later classes.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Of all of the languages I have ever had the pleasure of using, none had such a beautiful object-oriented design philosophy as LPC (nor was as fun!).
;) ). For example, strings are basic types. You can do a switch statement on a string, and have string cases. You can do a switch statement on an object. You can use a 'mixed' variable type. A mixed could look like this:
;) And, with the power of the language, you could have incredibly adept functional elements at the same time as the interactive visual elements.
;) ). Then, I'd clone an object into their inventory which would prevent them from acting at all (or, perhaps, leave them the ability to scream or something, perhaps even changing their words ;) ) (ahhh, word filters were fun ;) ). I had my Star Wars dest, dests that were parodies of other people's dests... I always liked Blizzard's "Pulp Fiction" dest, though ;) Oy, that place was fun. Sometimes when I was bored, I'd destroy the main posting board, set myself to look like it ("7th Sign Wizard's Main Board says: What are you looking at?"). heheheeee..
For those unfamiliar with LPC, it was initially designed for use in MUDs - as such, it is missing many of the non-text interface and output features needed for a full featured modern language. However, what it had was so beautiful. There was one type of object variable - object. All objects can talk to each other, call whatever functions they want on each other, etc, just by obname->do_something(). You can even call functions on not-yet-loaded objects, by doing things like ("path/filename")->do_something(). You can call functions like FindObject to get the objects of a certain type. You can run through a list of all objects. Etc.
LPC is based on the principle of letting the programmer do whatever they want (I know, some people don't like this
mixed blee = { some_int, some_string, { some object, {some_object, some_bool }, some_float pointer, some_object }, some_object pointer };
It basicly acts as a struct you don't have to declare in advance (of course, you can still use structs to your heart's content). So, for example, if you just wanted to store a complex value, you could use a mixed of { some_double, some_other_double }, at any time.
Then, there's mappings. Mappings are a built in, arbitrary-formatted hash table that is an internal datatype. For example, you could have (and I may not be remembering the format exactly):
mapping blee = [ "foo" : 1.5, "bar" : 8.2 ];
Etc. (naturally, you can use mixeds, objects, whatever, as your indexes and values.
Most LPC libraries are designed to give objects a (text-based) visual representation. You give them a name, a description, a short description, etc. Objects are created in a virtual environment, and you can see them - hold them, place them inside other objects, etc. An object can talk to its environment (what it is inside), or anything in its inventory. A coder can manually call functions on various objects, or set up interface elements for them to be called at any time, not nessisarily by a coder. This visual environment, and "existance" within the code, leads for incredibly fun code wars, like you wouldn't believe
For example, I was the loki-type character coding on a mud once. At one point, I had fun by calling functions that would change the name of people's character-objects around, so that they'd be confused when talking to each other. Naturally, they'd seek retribution and fire off a dest, once they found out it was me (a 'dest' is a piece of code that artfully kicks someone off the mud). But, once I got to know other people's dests, I set up protective objects which would fire off counter-dests when I saw their dests start to go off. So, instant dests started becoming popular. So, I set up objects which propogated themselves into other coders's inventories and would filter out their commands. Instead of instant dests, to maintain artfullness while still preventing them from counter-desting, my dests first cleaned out their inventory and the inventory of the object (room) they were in, to wipe out all local protective objects (sometimes they'd mess with global commands, but well, if they did that they deserved to win
Ok, sorry, I got sidetracked. But... LPC is a fun language, and has the best object-oriented design I've ever dealt with. Its a good language "for love of the code".
- Rei
You know when it's okay to shout fire in a crowded theatre? When it's on fire.
I think the question here is this: Should we start by teaching an easier, higher level language (ie Java) to get programming concepts down, then move to lower level "closer to the machine" language for advanced topics, or should we start with the lower level language and then treat additional languages as extras?
Personally I think the first option is the more viable. Java is a fairly easy, very portable language on which students can create fairly elaborate programs somewhat quickly. With the Swing classes, one can create GUI based programs that will run almost anywhere after probably less that a semester of learning. Java has all the necesary pieces of a fully functional OO language, and it spells them out in a very easy to understand way. It also enforces compartmentalization. I remeber as a freshman, one of the most frustratin things about the way CS was taught was that none of the programs we wrote seemed "real". The assignments were written to develop skills in algorithm analysis and to point out uses of specific structures, but they always looked like a home work assignment, not a useful piece of software. With Java (or hell, even an interpruted language, like Perl or Python) I think the same skills could have been taught while allowing for more... err.. Satisfying .. assignments.
Once the basics of programmiing and software development were learned (and I don't know about anyone else, but my Uni spent most of the first year, and a chunck of the second on these skills. learning "how the computer works at the lowest level" was Sophmore and above classes) C would certainly be appropriate to tech as a lower level "how the machine thinks" langauge. Our low level systems classes were taught in Vax assembler (I never actually learned C in collage, we used Pascal as the teaching langauge, them SmallTalk and assembler in later classes), and I'd have found C both easier and more useful in "real life".
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
We have had the same question discussed. Normally in the first year of the course, we teach students about OO programming concepts using The Oberon language, a wirthian language much like Pascal and Modula-2. The benefit of starting with this language, is that practically no one knows about this one when they start. This levels the field for everybody starting the course. The second benefit is tthat it is fairly similar to Pascal and Modula-2 syntaxes, but allows for concepts like pointers and garbage collection to be explained. Basicly, it as good as any other OO language, but we have satisfactory results in teaching OO with this language. The incredible downside to this language, is that students will never ever use it again. That's the first year, in the second they are taught C++ in a strict Stroustrup way.
Our question has been whether Java would be better. Certainly, as an assistant, I would have said Java all the way 2 years ago, because I just like Java much more than Oberon (and incidently the students do too), but Java really misses out on a lot of key concepts that C++ do have. If Java would ever be taught on our university in C.S., it would replace Oberon, not C++. We consider C++ a difficult but necessary level of experience students should have endured, simply because when they will work in a company 3 years later, the majority will be either in Java or C++. BUT. In the Mathematics and Physics classes, we HAVE switched to Java. To these people, a language is more a tool than a subject on it's own. In fact, we didn't just teach them Java, we gave them a Java environment that allows for allmost functional linear programming, an interpreter which simply translates their code (which looks just like Java code, only everything is purely functional) into 'real' Java. So far, the results are promising. They actually get the concepts of recursion, which, for a mathematics and physics 1s't year class may be easy to get down on paper but harder to get done in reality. This is the first year we're doing this, so we have to consider the end results in a few weeks when exams are over. We have also taught Java to Physics PhD students, with very good results. Most of the programming in Physics labs is now in Java because it delivers faster than C++ and is simply easier to maintain and update.
From personal experience, I think C++ has a few benefits on it's own. First it is a valuable leach that leads into the UNIX world, something most people have never had the chance to experience before. You will simply have to get the UNIX concepts and commands and syntax and phylosophy right before you can say you're able to pull a C++ thing off on a server compiler. Second, I think C++ is obviously valuable once you are done studying. This should not be the major issue here, and we dislike the idea of studying C.S. because it makes good money, but it's a reality nonetheless. Thirdly, C++ has influenced more languages in the 10+ years it exists, and thus makes transition to these languages, including the Java language, easy. Fourth, c++ allmost offers every concept that an OO language should offer, so in the world of paradigma's it's a fantastic example of OO programming. Fifth, the syntax and semantics makes people think mechanically, and the ancient C subset allows for making the distinction between lowlevel and high level programming. Learning how to debug is one of the key elements that C++ offers and needs, and students will benefit from that knowledge. And finally, transitions form C++ to Java are easy, but the opposit transition is incredibly tough, even if you DO know C++. I've made the transitions about 4 times in the last few years, and I can tell you every time I had to switch back to C++ all hell breaks loose again. You simply forget the hard parts because that's what Java is, the 'nice' version without the pitfalls that C++ experienced in it's more or less uncertain growth.
I hope this has some valuable insights for you.
With great power comes great electricity bills.
I think c# would be a very good introductory language for a computer science course, ignoring the Microsoft stigmata and the fact that since it is a new language there are few books/compilers/debugers/teachers out there.
.net language for server side stuff. So you could go get a job after your first semester at college.
1) It has support for many Object oriented Mechanisims.
2) It looks like c/c++/java/javascript so you could move onto them after you completed the c# class.
3) It has automatic garbage collection, but you can work in unsafe mode and have access to pointer arithemetic. So it is nicer than both c++ and java in that respect.
4) It is the Microsoft
Personally, I don't believe that Java is the right way to go in that respect (although there are worse languages: my old comp sci dept started to teach Ada as a first language after I left...). Two main reasons:
My personal choice for a first language to teach would be Limbo, a beautiful language, designed by some of the original designers of C (who've come a long way since then!). Amongst other things, it:
- encourages simple, understandable code. Reuse is through encapsulation rather than inheritance.
- has a powerful set of primitive data-types with natural and useful semantics.
- runs on many platforms under the Inferno OS, e.g. Windows and Linux.
- is completely type-safe (unlike Java)
- has a simple but powerful set of libraries which can be understood, and are useful, in isolation from each other.
The language primitives make it quite feasible to teach different aspects of programming without moving to different languages:- Lisp-style lists are nice for teaching recursion ("car" and "cdr" become the more natural "hd" and "tl")
- Proper by-value strings (unlike Java's) make string handling sinple and natural.
- Interprocess communication is supported in Limbo by first-class channels, enabling threading and concurrency to be explored without constantly struggling against thread primitives and associated pitfalls which belong to the 1970s.
Overall, the syntax is extremely clean, but very expressive (although still recognisably derived from C). It has hardly any "gotchas", and is generally programmed in a simple, direct style, ideal for beginners (and advanced programmers who want to write maintainable code, for that matter). Moreover, it's very sparse on resources.I'd love to teach it as a first language. No more "ahh yes, that array just turned into a pointer because you looked at it funny"... oh happy memories...
I've noticed a disturbing trend in the replies; That is, most of them focus on language features.
For example, they say, "Oh, they should use this, because it has good OO," or, "Oh, use [C/ASM], because it's low level, and good programmers know how low level stuff works", or, "Use [C++/Java], because that's what the industry uses", or "Use XYZ because it's got a good set of libraries," etc., etc.,.
These folks have obviously never taught people who haven't programmed before.
These are people who are going to struggle with variables. These are people who can't write a for loop to save their lives. They can't use a function, much less a method.
OOP, pointers, bits&bytes, libraries; None of that matters for at least 3-6 months.
This is why I highly recommend either LOGO or Python as a first language. These are interactive interpreters. You need to be able to say, "X=4", and then say, "what is X?", and then reassign X. You need these basic things.
Once the concepts of variables, loops, and functions are in place, then you can easily map to other languages. I know this because I've taught it. I also know this because I've consoled students crying over their Java homework (quite literally) at the end of the semester, incapable of using a for loop. These are good students.
As programmers, we take a lot for granted.
So forget all this "X features OOP, Y has a good lib, Z is low level," and think: Variables, Flow Control, Functions. The rest will follow naturally after these are ingrained and easily used.
I teach free programming classes in Seattle. Since I teach classes for free, I don't have the economic pressure to teach JAVA or C++. I could write whole articles about the damage that certification programs do to people. Another problem is that people look at the Jobs page, discover that most industry programmers are doing something called "JAVA" or "C++". They open up the university catalog and see, "Learn JAVA in 3 months!!!" ($1500), right next to the A+ certification houses. Since the ads are all over the place, they figure that it must be the way. They take a class, and drop out halfway through. The experienced programmers with CS degrees taking JAVA to learn a new language make the newcomers feel pathetic, and they decide programming isn't for them. If only I could copy the experiences in my mind for y'all... It's really bleak.
College is a different situation. I think the reason the profs teach JAVA is because they actually bought (and contributed to!) the hoop-lah about OOP, in a theoretical rather than economic way.
I teach my students in the following order:
It is with great sadness that I teach my students OOP, as it is over-hyped, and people believe in it religiously and without question. I teach it in order to prepare them for the world that will hire them.
The primary value in OOP, as far as I can tell, is thinking about the data first, and language features supporting polymorphism. Also, the book "Design Patterns" is the most (and quite possibly only) valuable piece of literature from the OOP community. I stress that it doesn't require a particular language or ideology to implement polymorphic behavior, or to think about the data first, or to implement a common pattern. (Device drivers and web servers are great examples of objects exhibiting polymorphism and encapsulation. In Non-OO speak, that's the product of paying attention to coupling and cohesion, which takes us right back to... The Unix Philosophy.)
I teach C so that they see low level stuff, and Python, for reasons to numerous to list. I teach C++ so that they can get hired.
One of the reasons for listing Python: They can start writing programs from day 1, second 1. No fussing with heavy class notations, like Java forces you to. (Just look at Java's hello world.) To believe that new students learn about OOP by using Java is hopelessly naive. Most students I've seen working with Java as a first language struggle with making for loops, while loops, and using variables. (Of course, several students will defend their teacher and difficult learning by give you the rhetoric that OOP is the way, and that Java is great because it's... OOP! You can feel the difference!)
True, esp. for gui's. (We all know about listener leaks, right?) For other uses, however, such as web-enabled db apps, it can actually make more efficient use of resources -- and Java can remove most of the pain from tasks like session management.
the teaching language be C/C++ - once you know that, you can learn Java, Perl, PHP, etc. with little effort
The problem of using C/C++ for teaching is, a student can get distracted from learning how to program well by the idiomatic syntactical complexities that make C/C++ such a powerful language in the first place. I say, learn Java first, so you understand the classic algorhythms, simple OO, and things like threads. Then, find out what else you can do with C/C++, and others.
True, Java's cross-platform... :*)
Do not forget, Java is not the only cross-platform language -- emacs-lisp is available for many many platforms, and uses such nicities as "byte-compiling", just like Java.
Also, in Java, there's no way to pass variables by reference. So, in order to have a method change a value that you pass to it, you have to encapsulate it in a class. Either a custom one, or something like Vector - which is not cleaner. Also, teaching someone to rely on Garbage Collection is insane, it teaches someone to write sloppy code. Java is not a cleaner environment, and it doesn't teach people to write cleaner code.
Obviously you don't understand the language, because your "pass variables by reference" comment is completely inaccurate as shown by this response.
I've seen Java coders who STILL can't figure out how to dispose of memory, basically don't understand the difference between stack and heap, and don't understand pointers well enough to dispose of an element of a linked list.
Secondly, this is exactly the point of high(er) level languages: To eliminate details that are better solved by the machine, or previously by someone else. I've seen C/C++ coders who still can't produce binary output by hand from their source files. They're so stupid they have to use a compiler.
No, it doesn't. By virtue of using Garbage Collection, it is taking memory management out of the hands of the developer, teaching people to be lazy when it comes to object instantiation and use
Garbage Collection is completely unrelated to the concepts of Object Oriented Analysis and Design. Automatic Garbage Collection allows one to focus on solving a problem. Forcing manual garbage collection is a step backwards in any modern language. It's a detail that the machine is better able to deal with, as it should be. Automatic Garbage Collection is a concept that can be applied to many differing programming languages and it is a detriment in none of them.
So, in order to have a method change a value that you pass to it, you have to encapsulate it in a class
Or behavior more commonly known as a side-effect. And also best to be avoided when dealing with Object Oriented Programming. A common mistake of many C/C++ programmers is to get caught in the procedural traps introduced and taught by C and adapt those same concepts, wrongly, into their OO work when using C++. This is probably the reason why you think encapsulating your value in a custom class is a poor decision. Maybe you should study the term encapsulation.
And as for your comments about ease of learning. It may be easier to learn C/C++ (which is the biggest source of problems: C is a procedural language, C++ is not, but the grouping of these two together produces disastrous results), but that ease is because people learn the wrong way to write OO code. Java teaches, or forces, the correct way. After learning the proper way in Java, you'll find that you actually write better OO C++.
Java allows you to solve problems, C++ allows you to solve details. As an employer, I know which one I'd want you to deal with.
I agree with you in that Java is fine for an education language but it definitely shouldn't be limited to that. For example, one of the new recruits in my company has just graduated from a university where they were only taught Java. Consequently, he doesn't know what a pointer is, he doesn't know what linking object files means and he doesn't know anything about memory allocation.
As I see it, University (College) is about education not about industrial training. You shouldn't be taught specific tools at university rather you should be taught theory. That way, when you leave university you will be able to apply your theory to different languages or applications. For example, one of the Universities here in the UK teaches all the programming in Visual Basic. I mean what is that all about? How can you possibly claim you know how to program when all you know is Visual Basic! A good programmer should pick a language to use like a carpenter picks a tool for a job. Different languages are good for different jobs and university should give you the theory so that you can easily understand new languages.
A university should really teach you a mixture, pure object-oriented (like Smalltalk), imperative (like modula-2 or C), functional (like Miranda) etc. The student will then have firm foundations for being a good programmer.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
I think Java is a fine education language for the following reasons.
It is cleaner than C++.
It is widely and freely avalaible. (though so are many other languages.
It is being used widely in the industry, and I think educational institutions have a responsibility to realease students with marketable skills.
As for performance, it is slower than some languages closer to the heart of a computer, but speed is not the point of an educational language, constructs and methodology are. And Java offers all the needed constructs and is good to teach the OOAD methodology.
As x approaches total apathy I couldn't care less.
Smalltalk is much cleaner OO than Java which is much cleaner than C++. I think the main reason Java is chosen over Smalltalk is Java is more widely used in the industry. It is a tradeoff purity versus use, Smalltalk wins in purity and c++ wins in use, but Java is a good middle ground
As x approaches total apathy I couldn't care less.
I took the grade 11 computer course last year, basically they started us in C/C++ until Christmas and then switched to Java. Needless to say most of the people in this class would not have gone onto do computer nor did they have any experience but I noticed a distinct lack of interest when we swithed to Java. I think it had something to do with re-learning everything but it also had something to do with them finding C/C++ more intuitive. The point remains, whatever you go with, especially at the highschool level, stick with it all year or you will loose half the class right then and there.
More imporantly if you want to keep as many people interested in computers, especially their first introduction to programming, keep the language simple, worry about whether or not a high level or low level expericne is better later.
Agreed. While C\C++ is a good language and lies at the root of Perl and Java it and the imperative paradigm is not the center of the programming Universe. Without exploring languages from other paradimgs such as prolog, Haskell, etc one cannot get a good feel for the different ways to approache a problem. This tends to lead people into such dogamtic fun as the belif that recursion in all forms is "just plain wrong" as my C\C++ teacher put it.
In terms of which language to start with Java has the advantage over c in that it's syntax is cleaner and has less of the fun archaic elements such as the need for heavy pointer arithmetic. This makes the into learning curve too damn steep. Unfortunately it too is limiting to the iterative world. I'd recommend something like Pascal which was written to be a teaching language (if you must stick with imperative).
IMHO the best language to start with would be Lisp. It is more mature than python. It is quite tolerant allowing the students to play with less pain. It includes higher level elements such as lists that allows people to get into real programming in shorter order. Rather than forcing them to put off any real programming until after they have mastered the arcane nature of c's memory allocation. Lastly and most importantly as a teaching language it can be used for purely functional, purely iterative, and for object-oriented programming. Thus you can introduce your students to three of the major paradigms (you can do some Psudo-logic programming in it but it just isn't the same as prolog) under one roof. As a result the excess learning time is lessened.
Irvu
Remember that most software development is bespoke (i.e. it will never get out of the company that wrote, for whatever reason).
.NET...), thanks to Enterprise Java Beans and XML.
And I can tell you that whenever number crunching is not required, Java takes over. Java on the server is really gone rule the business world for the next 10 years (unless
As a learning language, I would say that Java being easier to learn, it's easier to teach OO concepts with Java because you don't have to make sense of this huge thing call C++ first.
Nobox: Only simple products.
For the express purpose of teaching OOP, why not use Smalltalk, which makes it difficult to fall into other methodologies and easy to use OO techniques?
But as a greater question, why restrict the field to one or a few languages? I'd think that in a CS curriculum (I insert the disclaimer that I came from mathematics and not from such a curriculum) one would want students to explore as many languages and paradigms as possible, ranging all the way from assembler to Prolog. This would presumably encourage a student both to develop many different ways of thinking about any given problem and to be able and willing to select an appropriate tool for any problem encountered. Far too often we see (as evidenced by responses on Slashdot to articles like this one) that many people are rather narrow-minded about language selection and unwilling to deviate from using their one pet language. Why not start to discourage that immediately in the course of formal CS training?
I figured this deserved more than the one line it got. A friend of mine from college said the same thing for his exit interview for the CS major. It's a great introductory language for people. It's complex enough to be worth an entire semester, allows for the teaching of OO techniques, and also doesn't make students feel utterly worthless (as C has been known to do. Do I malloc (amount + 1), or just (amount)? Argh!).
;)
Python is the perfect way for people to get their feet wet. Especially as it doesn't "break" a person's perspective on what to expect from languages, as perl might.
I agree that you need to know how a computer works at the low level. But this does extremely little to help you design software with typical real-world requirements - you need to also have experience thinking at a high-level, where the design of software systems takes place. I know many programmers (usually with electronic engineering background, where software development isn't emphasized) who know assembly etc very well, but don't know even the most basic things about object oriented programming, and it really shows through in the software they produce (e.g. having the base class know about ALL types of derived classes and using a "type" variable combined with lots of switch statements in functions to call derived-class-specific code - exactly what virtual functions are there for!). Likewise, I've seen people who have only learned about programming at a high-level, and their coding shows problems, because they don't understand whats going on when their code gets compiled (e.g. not understanding the difference between heap allocation and stack allocation - try "char array[10000000];" inside a function!)
You absolutely need both, no question. My 1st year CS course at university included introductory assembly as well as object-oriented programming. Personally I think Java is quite a good introductory language, C++ is too complex for beginners, you want to teach the design principles without all the pointer problems etc getting in the way.
I don't see how you can claim that "teaching java to beginning programmers only encourages sloppy programming". If anything, only teaching assembly would encourage some seriously sloppy programming. You cannot learn good high-level design from only doing low-level programming, thats like saying that you can learn good social skills by studying how neurons in the brain function.
Looks like Smalltalk enforces every OO paradigm I can think of.
Getting back to the topic of Java as a teaching tool, I don't see the problem with it. You can teach OO with it, you don't have to worry about pointers, and it makes you marketable (OT - I still get quite a few Smalltalk job offers, so it's still useful in the workforce).
Help find a cure for cancer!
The real problem is: how far do you peel back the onion? Why stop with assembler?
Thirty years ago, I learned machine code to program the PDP-8. Why not teach that today? Or why not go further down and teach VLSI processor design, or semiconductor physics?
Semiconductor physics has nothing to do with computer science. VLSI processor design is not fundamental anything, but an engineering discipline based on a particular fabrication technology (more-or-less 2D semiconductor electronics).
Learning the machine code is part of learning assembler. A small part. There's no need to memorize it, just to be able to assemble by hand to understand what's going on (with references, of course). A few hours doing such exercises should suffice.
Once this is learned, assembler is a simple convenience giving full control over the machine code with fewer headaches.
A CS student certainly should learn about logic gates and how they build up into addition, multiplication, RAM, etc. This is also fundamental CS. How to build these gates from transistors (or vacuum tubes, or tinker toys) is not, and should be left to the engineers.
If you don't understand how a functioning computer is built out of logic components, you have no theoretical basis for why one operation should be slower than another, or why there is limited memory. Without this base, all programs that work are equally good, and if one works slower than another in practice, or can't run because it needs too much memory, it is merely a quirk of the hardware design. A machine could be built which always sorts any billion entries in the same amount of time as it takes for it to add two 32-bit numbers, machines are built which take the same amount of time to multiply as to add, but addition is fundamentally simpler and faster than multiplication, and adding two 32-bit numbers is certainly fundamentally faster than sorting a billion entries. The supersorter is a quirky machine, but without knowing about the gates from which all digital computers are built, you have no valid mathematical basis for saying so.
Similarly, if you don't know anything about machine language, you have no reason for saying why one HLL program should run faster than another, or which will consume more memory.
The heart of CS is the interaction between the gate logic and the data fed into the gates. Anyone who doesn't understand the fundamentals of this interaction is not remotely a computer scientist. Learning a machine language is making one case study.
--
The main advantage of Java over C and C++ (and the reason why C and derivations are discontinued as teaching tools in my university) is it's relative platform-independence. When you want to test the programs that people have written at home, it's a real pain in the ass to get their Borland C++ programs running under Linux, you know. This disappears with Java.
On the other hand, Java is not the most highly structured language, especially in recent versions. That greatly lessens its didactic qualities; I have had several students here who started to experiment with all sorts of arcane features like inner classes and operator overloading without learning how to write good programs first. It's a bit like comparing Niklaus Wirth's original Pascal to Borland Delphi. Deplhi is more powerful, but you need a thorough knowledge of the class hierarchy and in order to deliver good OO programs, you have to be a good OO programmer beforehand.
Therefore, I now prefer either more systematic languages like Eiffel, or script-like languages like Python - the first for their higher level of abstraction and cleaner design, the latter for their greater ease of use and wider field of applications. Both are, in my opinion, better suited as didactic tools for learning OO programming.
And BTW, over here in Germany the high dependence on symbols such as {} or [] or /**/ is a didactic problem in itself because these aren't so easily reached on a German keyboard. This may sound harmless, but we get endless complaints from people who hate to perform strange Alt+Key acrobatics to get a simple thing like a curly brace.
There is absolutely no reason to panic.