Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Education

Java as a CS Introductory Language? 913

A couple of questions concerning Java have ended up in the bin over the past few weeks, and rather than handle them separately, I've decided to lump them together as they deal with Java's use as a learning language, as opposed it's traditional use as an application language, and in many cases, which looks to be replacing C/C++ in this role. Personally, I feel that teaching Java in college is fine, however I'm a little concerned in it's replacing C/C++ in that role. This, of course, begs the question is C/C++ any better. How about this: if you were going to structure a curriculum to teach Object Oriented concepts, would you teach it using Java, C/C++, or something else?

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:

  1. Java is a fine development language, and it will help me as a programmer to learn it.
  2. 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.
  3. There's a little truth in both the above statements."
And we have this one from Banjonardo: "The AP Computers course, the strongest computers-oriented course in a high school, is changing its core curriculum. The language taught, which has progressed from Pascal to (currently) C++ is changing once more. Next year will be the last for C++. The new language will become Java. My question is, realistically, which is the best language for an AP Comp class to learn? I will use my school as an example: Our 386s were given away to students on Friday, to make way for the brand spanking new 900Mhzs provided by the "Digital High School" program. What language would be the most appropriate to send our students forth with?"

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.

This discussion has been archived. No new comments can be posted.

Java as a CS Introductory Language?

Comments Filter:
  • by Anonymous Coward on Wednesday June 13, 2001 @10:59AM (#153744)
    C and C++ more intuitive?

    You have to be kidding.

    Steve Michael
  • by jandrese ( 485 ) <kensama@vt.edu> on Wednesday June 13, 2001 @10:18AM (#153746) Homepage Journal
    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.
  • by jandrese ( 485 ) <kensama@vt.edu> on Wednesday June 13, 2001 @11:26AM (#153747) Homepage Journal
    The only danger from teaching wierd languages is people claiming: I'm never going to use this and dropping the class on the spot. You'd be surprised how often this happens with people who are focused on Resume building, especially in college. Most of those people went on to take the business school's COBAL class, so you can't say they are better off.

    Plus there is the cool factor that comes from knowing the language you are learning is the same one your Operating system (and most of the applications you run) is written in. Beginning CS student's generally aren't concerned with the fundimentals, primarily because they don't know they are supposed to be concerned with them, so the choice of language makes a big impression on them. A teachers job is to reach beyond that, teach the students what they need and other things that they won't realize are valuble until later when they want to do real programming.

    Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
  • Out of all of the other languages I have ever studied [including C, C++, TCL, Perl, PHP, Forth, Scheme] Python is by far the easiest to pick up and use right away.

    It's something you have to experience yourself to truly appreciate how easy it is to pick up.

    If I ever had to teach someone how to program, I'd definitely introduce them to Python first. The concepts are easy to grasp without having to sweat all of the small stuff that could otherwise be extremely distracting and only dilute the main ideas.

  • I was disappointed to see that Python adopts a similar strategy to C++ in-terms of its object orientated architecture, namely that it looks like an afterthought (of course, in C++ this was the case since they were trying to remain backward compatable with C, but apparently O.O was in Python from the start). The use of clunky keywords like __init__ gives the impression of trying to hammer O.O into a syntax not designed for it. The nice thing about Java is that the syntax of the language seems designed to accomodate O.O from square one.

    --

  • 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.
    Whenever a language is released that makes life easier for the programmer, it is always assused of being too slow, I am sure the same was said of C by assembly programmers. The reality is, however, that the value of speeding up a development effort can be far greater than the value of a marginal runtime speed increase. Just think of the debugging time spent finding memory leaks in software, yet this - for the most part - is simply not a problem for java.

    Computers are getting faster all the time, but programmers won't unless they can use languages which take care of some of the housekeeping for them. It is this more pragmatic philosophy which underpins Java, not to mention most other modern languages.

    --

  • Oh, how I agree. In my university:

    We were taught procedural programming in Modula 2 -- because it enforces good practice.

    We were taught functional programming in Miranda -- because Miranda doesn't let you sneak in procedural paradigms by the back door (although Miranda only really clicked for me after a Lisp course taught by a better lecturer -- Lisp *does* let you sneak in procedural tricks).

    We were taught OO using Eiffel -- because Eiffel is a pure OO language that doesn't tempt you into non-OO constructs (as C++ might).

    --

    This was around 1995, when Java was quite new -- I recall our OO lecturer saying that maybe Java might soon become a suitable language for teaching OO but that it was too soon to tell. In my limited experience of Java, I suspect that it would make an excellent teaching language (I tried to persuade my IT-teaching girlfriend to use Java as her language for teaching programming -- school politics with regard to installing software on the system put paid to that idea).

    At university there were no end of students whingeing at the lack of real-world stuff they were learning: one student memorably complained that the word "Novell" was never mentioned in a complete networks. Likewise, many wanted to learn real-world languages such as C (which we did, later). Those people were and are wrong. If you have a good grounding in the theory, adapting to the real world is easy. The reverse is not as easy.
    --
  • ... is it vocation skills, transferrable skills based on concepts, or the inner workings of a computer.

    If it's about OO programming, I would go with Java. C++ is a complicated language, and doesn't force OO. In addition, C++ will also distract from learning OO as the student will have to fiddle around with other unrelated implementation details, such as make files, wierd linker errors, etc. If you're learning OO, spending most of your time learning a specific language is rather silly (and C++ can be a very time consuming language to learn).

    Personally I prefer learning the concepts and transferrable skills. I can apply these in many situations and they will last longer through out my career. The practical stuff I can learn on the go, and I doubt that school will ever be able to teach that sufficiently anyway.
  • by iabervon ( 1971 ) on Wednesday June 13, 2001 @11:31AM (#153766) Homepage Journal
    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'm frankly a big fan of the Georgia Tech approach (or at least what was the Georgia Tech approach when I was there, a few years ago).

    The first real language used in the CS curriculum (the first class uses a made-up language that theoretically has no compiler or interpreter) is Java. The reason is simple: Java is OOP without being obstructive about it (*cough*Smalltalk*cough*), and it's a pretty good language. The theory goes that it's easier for students to learn OOP first, then learn procedural (and functional, etc.) programming. In my experience, this seems well borne out... most people I know who learned procedural programming first really struggled (in some cases, still struggle) with OOP. Those who learned OOP first had no real problem picking up procedural.

    I think a lot of posters here are ignoring the fact that no sane human would teach an entire CS curriculum in one language or even one paradigm. It's also worth noting that we're not talking about teach a language so much as we are about using a language in the course of teaching computer science concepts. Maybe it's the GT student in me, but I find that an important distinction.

    I've mostly forgotten Java. I've also forgotten a lot of C specifics, and I can barely remember what little C++ I learned. Smalltalk is something I'm happy to have dropped from memory. I once knew BASIC, I've seen some FORTRAN and some COBOL, and at some point I even knew MOO.

    I've forgotten most of these languages because I can. When I sit down to read them (as I occasionally do) or to use one (as sometimes happens), it takes me little to no time to get back up to speed and get to work. The reason is simple: I was taught the ideas that form the basis of computer science and of computer programming. The languages were just tools, and still are.

  • I could understand this if you were actually using C or C++ in a procedural manner. This type of step by step programming is much more intuitive and conducive to learning.

    Other than that, there's absolutely nothing about C++ that is more intuitive than Java! :)
  • There are already tons of implementations of the JVM and the Java compiler, in case you hadn't noticed. Sun has a very very extensive language specification published, and anyone is free to implement it, no strings attached.

    The trick is that to make Java useful for most things, you need the very extensive libraries that are copyrighted by Sun.

    But this is just the same thing as C#, isn't it? C# is made to bind tightly to the Win32 API set and to .NET. Having the C# language standardized will mean relatively little if all of the API's that C# code depends on are not standardized. And Microsoft has *always* laughed at anyone who suggested that they should 'standardize' their API's.


    - jon
  • I think smart kids will handle the transitions to more difficult languages okay. Programming in BASIC involved 'taking too many things for granted', perhaps, but every new language you learn should have something new to teach you anyway, or else why bother?


    - jon
  • by Tet ( 2721 ) <slashdot AT astradyne DOT co DOT uk> on Wednesday June 13, 2001 @11:04AM (#153774) Homepage Journal
    I know how a computer works, as far as registers and such, yet have little desire to learn to code that myself.

    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

  • 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.
    Many people see it this way, and I can understand it to a certain degree. But you should also consider that learning a programming language to a level where you are REALLY productive and wont regret what your wrote 6 months later takes years. I think I reached this point in Java after 1-2 years (fulltime programming), C++ probably needs much longer - I cannot claim that I reached this point.
  • IMHO C++ is no language that is easy to learn, but if you are are writing software 40 hours a week you will soon appreciate its large feature set (and maybe even the compact syntax). Java's lack of features like templates/generic programming, macros or multiple inheritance has both advantages and disadvantages. The advantage is that the language is small, easy to learn and it does not have any features that an inexperienced or tasteless programmer can misuse.
    The disadvantage is the lack of expressive power resulting of this. Basically Java encourages Cut&Paste programming, which is a maintanance nightmare, a major error source and the root of all evil.

    In Java you cannot write something once and then use it for different types, so you start copying the code and modify it slightly for each type. In C++ you can write it once and use templates.

    The same problem is code that repeats itself only with slight variations that cannot be expressed with functions. This mostly occurs in regression tests, and can easily done with macros in C++. In Java you will start to copy&paste...

    When people need multiple inheritance with several non-abstract classes in Java they start to implement an interface and copy&paste the code. Sometimes this is also done using a code-preprocessor, like some CORBA implementations did. In C++ you just multiple inheritance.
  • by sphealey ( 2855 ) on Wednesday June 13, 2001 @10:27AM (#153777)
    "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 rather think the issue is do people want an introductory language for computer science or an introductory language that is going to be useful for getting jobs as programmers (software engineering, development.)

    If one is teaching the pure theory side of OO, then something like Smalltalk is going to make more sense, perhaps. (Depending on what you want to teach, theory-wise.) C/C++ would be the worst because they are closer to the machine/hardware.

    If one is teaching for the more practical/engineering side, then C/C++ and/or Java is going to make more sense, depending on your perception of where the job market is going.
  • by swingkid ( 3585 ) on Wednesday June 13, 2001 @10:07AM (#153780)
    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.
  • ...mainly because Ruby's OO model is dynamic. (Perl's is, too, but as a "first language" it is problematic.)

    Much of this "Ask Slashdot" seems a little unfocused: Some people are answering with the assumption that a "first language" is a CS major's first programming language, while others are assuming the class will be attended either primarily or partially by those in other disciplines.

    To me JAVA makes sense for the second case, but not for the first. With a good IDE, beginners can get up useful programs with a basic understanding. But it is not a language I would ever choose once I knew the others (OK, in certain cross-platform environments, maybe) for really tough projects.

    Ruby breaks through this barrier because it works for beginners who really need a glue language without limitations (Python, Perl or Ruby) as well as for people who are going to be pushing the limits of OO before they are through with their careers.

    But the Ruby book (linked in the parent) demonstrates a problem with using OO for new programmers: Which comes first, the OO chicken, or the basic programming egg? How do you teach what OO is without having some basic commands to demonstrate it with? And how do you teach basic commands in an OO language without doing it object-orientedly?

    I don't think this problem is insurmountable. But it may be more important than choosing a language. (In fact, the object-oriented ZOOs so offensive to Steeltoe may be failed attempts to do this.)

    The final question which needs to be addressed by people deciding about JAVA in first-year classes (or Ruby for that matter) is: What PRECISELY do you mean by "object oriented"?

    Perhaps because I have been around so long, I see OO as a dynamic concept. It has changed over time and really only reached its maturity with the publication of Design Patterns. I fully expect it will change still more in the future.

    Some languages (JAVA, C++ and Python) take a very accurate snapshot of the current thinking on OO and implement it very well. Other languages (Perl and Ruby) assume that OO will evolve and give you the ability to implement as much of object-orientedness as you'd like.

    An interesting question is whether aspect-oriented programming (boy, do I hate that name) will become a part of object-oriented programming or whether it will be considered a separate paradigm. Ruby is the one of the few languages that implements aspect-oriented concepts (like mix-ins) and it also allows programmers to choose where they want to work on that spectrum. (You can ignore aspect-orientedness, you can use the features offered by the language itself, or you can modify its aspect-oriented features into whatever becomes the next definition of the new paradigm.)

    All of this makes it an excellent choice for the CS majors starting a basic class which needs an OO language.

    One drawback with Ruby (which may actually prove a boon to beginning CS majors) is the lack of a large library like CPAN or the C libraries. Although it is growing, the Ruby Archive is nowhere near as comprehensive as CPAN. While this may be occasionally frustrating, it offers CS majors a good way to make a name for themselves. (There's nothing like applying for a job and finding your prospective employer uses a module you wrote. Voila! Instant reference.) All you have to do to make a name in the Ruby community is go to CPAN, find a module which has no counterpart on the Ruby Archive, and port it to the Ruby idiom. Of course, if Ruby fizzles, that still won't get you a job. But at least you can tell some Perl employer you know the module well enough to port it.

  • I found that it is much easier to teach a person procedural programming and then Object Oriented programming than just teaching OO. I found that people fresh to programming just don't have the mindset to see the beauty hidden in OO concepts.

    I'll agree with that. Procedural programming teaches the basic concepts fairly well - and makes a good starting point for learning OO stuff later on down the road.

    I started learning how to program in BASIC back when I had a brand-spanking-new TI994A. I was about 5 years old. All I really got out of it was the ability to really mess with the TRS-80s we had in grade school.

    Then I started picking up a bit of C. By the time I was gheaded to college, I had a fairly good grasp of the basics. Pointers and the like were still a bit confusing, but I was at least comfortable with if/else, for, while, and various variable types.

    I'd also started down the road of *thinking* in terms of procedural language - which i believe is the biggest stumbling block new programmers have - not being able to conceptualize and break down a problem into pieces that can be programmed.

    Intro to programming in college _was_ C, so that worked out well for me =) Learned a lot more about pointers - a _lot_ more.

    Left college when the money ran out - started dabbling in HTML and Perl. Eventually got myself mixed up in MySQL and PHP - which led to my current job as webmaster for a small but growing and suprisingly stable startup.

    Languages I use today (ranked by usage):

    Perl

    PHP

    No C, other than side-projects of my own. I'm spending a lot of spare time getting up-to-speed on C++ (mainly for the OO stuff), and have considered Java, but haven't gone there yet. I'm pretty sure my next language will be Python.

    With a background in C, I picked up PHP and Perl without too much of a problem - I'm sure the same can be said of moving from C++ to Java. I haven't quite figured out where Python fits into all this yet (that's part of what intrigues me about it ::grin:: )

  • by ian stevens ( 5465 ) on Wednesday June 13, 2001 @10:43AM (#153792) Homepage

    I wholeheartedly agree. If the language is key then you are not teaching computer science, you are just teaching people how to program. When you are learning basic computer science concepts like data structures and abstraction then the language should be one which is designed to teach. Java and C/C++ are not designed as teaching languages. In fact, C/C++ is a horrible teaching language as there are too many ways a student new to programming could shoot himself in the foot.

    Personally, I liked the way the University of Waterloo taught concepts of computer science. They started off with Pascal to teach things like abstraction and basic data structures. When it came time to teach OO concepts, they moved on to Modula-3 which was great: clean, instructive and with little opportunity to shoot yourself in the foot. Moving to other OO languages after this was easy as one already knew the concepts but only had to learn the syntax.

    Later, more advanced courses used C, LISP, Prolog and variations on C++ to teach their material. Actually, in some instances, you had a choice of the language so long as it ran on the university servers.

    I might add that at UW the language was not the subject material only its facilitator. When a new language was introduced, you were lucky to receive two weeks of introductory instruction on that language with the first assignment due the following week. Most other times, you were required to learn the bulk of the language yourself.

    Some argued that Pascal and Modula-3 weren't useful because they weren't used much in the industry. My feeling is that if that is important to you in your first and second years at university, then a technical college and programming courses might be a better way to go rather than computer science.

    ian.

  • Here in the UK most of the better Universities are the ones that teach more theory whereas the less good ones teach more practical applications.

    Well, that's been the British practice throughout most of Britain's higher education...and it cost them dearly, historically speaking. A brit (Perkin) created (by accident, he was looking for artificial quinine) one of the more important inventions in the modern world (the coloured dye, which eventually led directly to plastics (also a coal-tar derivative)), and the British culture of "higher education isn't something someone does for work" pretty much through that head start right down the drain...the winners in the new chemistry technologies were the Germans, where education WAS considered something for the practical. In particular, color plating and color photography was a German invention that the Brits might have had a lead on otherwise...(Source: James Burke's Connections)

    But as I said (and I was talking about American Universities, where the competition to get in can be harder at times, 'cause it isn't practically set-in-stone by some test one takes in the 4th grade...or do the Brits still do that?)-- the Balance is what's important. The theory languages are good for teaching good programming and design and all that, but there's no reason that the practical, business-hyped languages should be ignored -- teach BOTH of them and you've got the prime candidates for a fresh-outta-college job.
    --
    You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)

  • Oh give me a break and read between the lines (translation -- show your education).

    If a BALANCED education, in liberal studies as well as the field of industry one intends to specialize in, wasn't important, then college wouldn't be important and the american tech industry would all be based around people who are "Computer Learning Centers" graduates.

    I'm not talking about higher-education being 100% directed to getting the job, but it is almost 100% NECESSARY to get a good job, especially in the IT industry. Just having a head full of theory and languages that one will never use again (and liberal studies along the way) is NOT going to necessarilly be useful in the competition to get a decent job (competition that is increasing in today's .com-deaththrows) -- some experience (classroom is usually enough) in practical languages used in the modern world is also important.

    Companies won't take a "generic c.s. grad" without practical experience in a language that company uses -- they'll only take the "exceptional c.s. grad".

    It would be nice if we were all exceptional and all could just study the finer theory of things, but its not that way -- schools don't get 100% exceptional students (not even the ivy league), and their curriculum should reflect that and provide means by which their average students are in some ways prepared for getting jobs in a competitive market. Teaching practical programming languages like Java, C++, Python, Perl are means to that. A smalltalk-educated student will have a learning curve to learn Java that a company may decide isn't worth paying for when another candidate already has Java experience. They'll only take the smalltalk one if his overall record is exceptional as well.
    --
    You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)

  • Yes, but to reiterate, a graduate with BOTH theory and practical experience applying the theory with pragmatic, business-world languages, may be more valuable than either. The question that started this wasn't "should we teach java in place of teaching c/s theory", it was "[sh|c]ould we use java to teach c/s theory". I believe that if the teacher designs his curriculum right, he can test for and grade the students ability to use the language to demonstrate knowledge of the theory.

    Yes, Java has the ability to "bypass" good OO design (as does C++), but if the teacher makes the programming assignment conditions include not using those proceedural cheats, then the student MUST learn the theory too, and walks away with both theory and practical application.

    --
    You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)

  • If they "learned Java so they could make money fast", they DIDN'T learn it in a 4-year university bachelors of science degree program. If you want BS of CS or EE graduates with decent GPAs, you'll already have ignored the "i just learned this language in a computer training center" types already in your resume filtering, so why worry?

    Remember I wasn't talking about those who "learned Java", but those who learned Java as part of their university c/s program who will have a slight advantage over those who didn't. Read between the lines, people, I didn't say "java programmer" meaning "one who only knows java" -- i was referring to the c/s grad who knew java as well as all the rest of what normally goes into a c/s degree (as opposed to the one who only had theoretically "correct" languages that aren't used as much in the real world, like smalltalk or eiffel). sheesh.
    --
    You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)

  • You shouldn't be taught specific tools at university rather you should be taught theory.

    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)

  • IT DOESN'T MATTER IF YOUR FIRST-YEAR LANGUAGE IS NEVER USED AGAIN IN YOUR LIFE. As a CS major, you should learn many languages of several paradigms to some extent or another. C++ is an awful first-year language, and I'm very happy to see instruction move to Java. The reasons are the same as why most schools during the procedural era used Pascal or Modula-2 for the first year, then ramped up to C for third semester and beyond. The idea is that good languages emphasize extremely important design concepts early on, with a minimum of distraction. FWIW, I think that C was orders of magnitude better than C++ in this regard yet...

    Largely due to a misguided OO-fad pressure, university CS departments forgot their reasons reasons against C in the first year and adopted C++. The argument often went "but it's a relevant language, and industry wants it!" Thus academia, like many companies at the time, made an unprepared mass transition to C++ (in the mid-90's more than 67% of departments used C++ in the first year). Thus the pedagogical issues with C were compounded by the added complexities and pitfalls of C++. Worse, virtually none of the new C++ instructors had any clue about how to leverage the OO paradigm whatsoever. At best, they taught "Modula-C", and at worst you got students in senior level OS classes asking "do I need to write a class for this project?" Finally, the faculty teaching higher level classes in these departments generally didn't retrain either. What many CS students don't realize is that a good four-year program isn't just a disconncted collection of classes. The students should be gradually ramped up in their design and implementation skills throughout their program. But the faculty suddenly had a design (non-OO vs. OO language) and language (via gross misunderstanding of C++'s tools) disconnect with the students. Disaster.

    Beyond all that, there are specific reasons to choose Java over C++ as a first year language. First: C++ has no object library, Java does. Yes, now after many years, it sort of has the standard template library, but for anyone with experience with languages like Smalltalk or Java, the STL is too little, too late. If you need further convincing, take a look at Brown University's first-year program, and what the students are able to accomplish both from a pedagogical standpoint and from a look-what-I-made! standpoint. The first year is run by Andy van Dam (yes, of Computer Graphics fame) and is a fantastic model for excellent OO instruction. Also check out University of Virginia's program -- and if you can get the opportunity to hear Jane Prey (on the Board of Directors of the ACM's Computer Science Education SIG) talk about their program, take it!

    I taught a variety of CS classes over a period of several years, and was (am) very interested in the best techniques available for teaching our the mathematics and engineering of our discipline. All of this experience suggests that the introduction of C++ to the first year created a *major* problem for Computer Science -- I'm glad to finally see it phased out for a clearly better language.

  • That's all fine and well, but what if java is not a language they will ever use in the "real world". The replacement of introductory courses from C++ to java has left everyone that is not a CS geek in the dust.

    In scientific computing, speed is paramount. Most people use fortran. Many would like to get away from fortran because it's over thirty years old, and has none of the nice features of newer languages. But for non-CS people, C++ is not something you pick up on a whim. C++ is by far the most complicated language around. The world of scientific computing, I fear, will be stuck with fortran forever because of its lower learning curve, and because of the fact that The bastards have stopped teaching C++ altogether. Java, while nicer in some regards, does not easily lead to picking up C++ (mostly, I think, due to templates and STL). Taking an intro java class and using fortran works though, because the language constructs needed for fortran are few, and certainly contained as a (small) subset of java.

    So I think teaching java is a horrible turn of events for we mere mortals. It has too many variants, is not (and will not be) standardized. And most importantly, most places only have one language class. That language should be the one that is most common, and contains enough language elements to allow people to easily transition to most other languages. Going from C++ to java is easy. Going the other way is nearly impossible.

    Maybe when more compilers correctly implement the C++ standard the situation will improve. These days it's very hard to compile on different platforms because different vendors implement different subsets of the standard. That, and they have to make STL errors readable. A newbie is not going to sift through a page of horrible looking errors from a single template mistake, just to find that none of the errors tell him what (or where) he did wrong!

    --Bob

  • 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.

    I have to agree. (Though I'd add Lisp and Forth (or PostScript) to the list just to round out the programming paradigm experience.)

    For those of you old enough to remember life before OO, remember how the early OO advocates were fond of smarmily remarking that OO required an entirely different way of thinking, and was therefore a big jump from procedural/imperative code? That runs both ways. Now that the schools are producing people who never wrote a non-trivial program in a non-OO language, I'm increasingly having to work with people who have severe mental limitations when it comes to problem solving. Procedural-only programmers tend to create tight but obscure and hard-to-maintain code. OO-only programmers tend to create overcomplicated, overengineered code. The best programmers I know can handle both design methodologies, and their code tends to be efficient, modular, clear, and easy to maintain.

    There is no knowledge that is not power.

    --

  • Java is a good primary language to teach in MIS, but not as a replacement for C/C++ in CS. Most CS-type work will not be done in Java. Much of the new MIS work, traditionally done in Cobol, will be done in Java if newly implemented.
  • You can't get more object oriented than Smalltalk. The IDE is what all the CASE and developer tools want to be when they grow up.

    The only systemic failing that Smalltalk has is that contained objects only know about their containers if they are explicitely made aware and passed in a reference at instantiation time.

    Java is a wanna be. C++ is even worse. The rest of the languages and development environments are left standing on the shore.

    Use Smalltalk. You can find a free version at http://www.squeak.org/

    Go try it out. But be warned, you'll be utterly spoiled by it.
  • First you take intro to Java (if you need it, most don't)

    Then you take data structures in Java (which ultimately becomes GUI construction techniques in Java, despite how hard they try.) People who have never programmed fail since they either are A) not fast enought at GUI design or B) cannot comprehend the idea of the linked list.

    Then you take functional programming in scheme. People who can't handle recursion and functional thinking fail.

    Then you take computer architecture, in which you write MIPS assembly and design a CPU. People who at this point still can't understand what a computer _really_ does, fail.

    From thereon you advance through stuff and less people fail out. I think it's probably a decent system since there is a steady drop-out rate, as opposed to people doing computer architecture or scheme first and everyone jumping ship at once. The first two Java classes basically get you warmed up in coding and try to get you thinking about data relationships and stuff.. things which are very important when doing scheme and even when designing a CPU. The data structures class, if taught in C or any other language, would have the same purpose and would not delve into the things Java does automatically like memory management. CS classes are not about learning the language, they're about learning the theory and concepts behind using the language. You eventually do learn the things that are absent in Java like MM, but they are taught in a different context, on the hardware level.

  • So, have they bothered with a 'select'-like statement, or is it still 3000+ threads for a server with 3000 cllients?

    IMHO, Java is NOT industrial strength. It is fine for many things, but for what I want to do, C++ is still it. It will never be as fast as C++. All those nice run-time optimizations being applied to Java work for C++ too, if anybody would bother. Of course, since C++ is generally tons faster, nobody has yet.

    As for worrying about all that icky memory stuff. I want to worry about it. My programs are faster and better designed for it. I think it would be highly amusing to plop down a Java programmer in an environment where careful memory management was crucial to successful execution. They wouldn't know their heads from their arses.

    It's possible to do memory management in Java, despite the garbage collector, but it isn't as easy, and nobody feels they have to with the nice, warm, fuzzy garbage collector wrapping them up.

    I think Java is fine for many things. I've watched its development and maturation with interest. I actually made a good stab at porting JVM beta 1 to my platform (UnixWare). It's just not the wonderful be-all and end-all language you make it out to be.

    It also makes me extremely nervous that Sun still has such tight control of it.

  • Unfortunately, the number of professors who are competent to teach lisp/scheme/etc are limited by the difficulty of the language. While this is not typically a problem at a large university, it would be debilitating at a small one if this were made some kind of requirement.

    The prime example I have of this is the small midwestern private school I graduated from. I took an AI course where we were supposed to be learning lisp. After the second week of class, when the professor showed us two syntatically identical lists and said that in one the end parentheses went away and in the other they didn't but couldn't explain how the machine was smart enough to discern the difference, I dropped it. I can't think of any of the other CompSci professors in the department that I would have expected to be any better either (I knew one who was still trying to use antique print control codes on a laser printer connected to a Unix system).

    The problem with this "good weed out gimmick" is that it would have weeded out the entire faculty too. And the fact is, good quality faculty are hard to come by...

  • Personally, if you want to teach core computer operation then you need to say away from any OO language. There are many many programmers out ther that have no clue how the hardware works. (What registers are you using for that math operation? I know, we don't have to anymore! but that is no excuse) If you look at software in general over the past 12 years we have steadily went from applications that do the job to bloated monsters that do 90 billion things that 90% of the customers don't want. now add to the fact that the code is bloated as hell because we don't have to be careful anymore.. (256Meg is standard on a low end pc now... why should I actually delete that meg of unused code?) and now with processors at insane speeds we dont even have to optomize anything anymore.... A standard bubble sort can be used and noone will be the wiser because that 866mhz computer waits for the Hard drive or ram longer than it takes to sort.

    we either need to kick all the CS "professors" out of the colleges or smack them in the heads, because all they are generating is sloppy programmers that write sloppy code and use sloppy techniques. The best example I ever witnessed was a CS professor proclaiming that embedded processors would fade away because they weren't powerful enough to run a program that was compiled from an OO language.

    Whatever..... Many of my non-OO, C programs fit in less than 2K... and if I need speed I use assembly, a language you have to learn on your own now.... and was my first introduction to programming in college (assembly,fortran,basic,C/C++ was the progression bac in the olden days)

    but then I work with computers that have a maximum of 64meg ram to use as system ram and filesystem, and operate at 66-200mhz sometimes without FPU....
  • by Outland Traveller ( 12138 ) on Wednesday June 13, 2001 @11:43AM (#153826)

    As someone who uses many languages in the course of the day, Java included, I might be able to offer some information.

    1. Java is a fine development language, and it will help me as a programmer to learn it.
    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.

    2. 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.
    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.

  • Da. Stimmt. Very true. You are very right that variables, flow control, functions et al. are what are important.

    The problem is that most CS departments don't like teaching languages. Therefore they must use a real (read: very powerful/widely used) language (C/C++/Java) for the into courses, so that later on, when students are doing more real-world things, they already have the language skills to do it.

    Now, the first programming course I took (in high school) was a semester of C, then a semester of C++. Personally, I think that this is one of the best ways to go. C doesn't have any of the fancy OO stuff. It encourages you to use loops and function calls. It isn't some "pure" language (Smalltalk = pure OO, Lisp = pure functional, etc), and can therefore be used to teach a variety of styles. Porcedural-type programming is the simplest thing for a beginner to understand, but they do need to be introduced to recursion and OO too. C is a fairly solid, usable, simple language and allows such.

    OK, now for the disclaimer. I said simple. There are 2 topics in C that are not simple, and I wish that there was a version of C where they were unneeded. Pointers and memory management. A lot of people find learning C difficult for the simple reason that pointers and memory management are confusing complex topics, and very integral to effective use of C.

    Disclaimer part 2: I said usable. Another problem with C is that you can't do neat shit with it right away. Beginners want eye candy. They want to do something impresive, without too much difficulty. C is bad at that. No fancy graphics. No easy network code. None of the nifty things that other languages make fairly easy and removed from the hardware. You say that libraries aren't important for the first 3-6 months. I'd revise that to say teaching libraries isn't important for the first 3-6 months. But if you can provide some code that lets your students easily do something cool (they write maze-solving code, you write a graphical frontend for them), then they are more likely to stick with it.

    Given that, I think that Java isn't that bad of a choice. Yes, Java is OO, which is a count against it as a teaching language. But it is garbage collected. It also has no pointers. These two things are very very nice for an intro language. I know that when we started pointers/memory management in HS, we lost 1/4 the class (and they had to take a drop). At the semester (where there was no drop penalty) we lost half again. The lack of these difficulties makes Java a very tempting choice. Also, Java has all of the eye candy one could possibly want, and then some. Yes, it isn't good to teach all of those fancy libraries to beginners, but giving them code that lets them use some of the fancy stuff is good encouragement.

    Now, Java is OO. Most people teaching it as an intro language introduce the OO features. This is probably not good. But just because it has OO doesn't mean you have to use the OO. So there is some magic "public class fooclass{" stuff around all of your code. And instead of "int main(){" you have "public static int main(String []..." garbage. But you can still pretend that it is functional, or procedural, or whatever. Like C, Java is a hybrid language.

    So, you say language features are unimportant. Fancy features are unimportant, but the simple features of

    1. Garbage collection
    2. No pointers
    3. Hybridness
    make Java, IMNSHO, a decent choice of an intro language.

    Oh, and I'm not talking entirely out of my ass. My first CS course in high school was in C, but the intro college course I took was taught in Java. CS 101 [wustl.edu], while it did focus more on OO than I thought healthy, was a very good intro class nevertheless. The labs had a lot of provided code, and then ask you to fill in simple methods for it to work well. Overall, an excellent course, if a bit slow for someone who already knows how to program.

    I guess it sums up that Java isn't a bad language to teach in, but that you need to teach it correctly (no OO, no libraries) for it to be good.

  • Well, no wonder you don't feel comfortable coding C++ anymore. :)

  • Highschool and/or intro to programming classes should start with the basics of how a computer works, some theory, and into to a couple different languages. I'd suggest short stints in C, PHP/SQL/HTML, and Python to start. Then after the intro classes you can take a more in-depth approach and add things like C++, Java, and Asm.
  • Programming languages that try to make programming to easy tend to be slow to use and a lot more work in the long run than just learning to program well. Programming in human-language is painful. You'll find the human language very unspecific. You often won't get what you meant. It's at least as bad as using visual programming techniques.
  • Maybe but I disagree. For me at least I had a much better grasp of programming because I was forced not to visualize problems in a single language. I taught myself to use flowcharts and psuedocode first and then could code into several languages. These are important steps skipped over by teaching with a single language. Intro classes should concentrate on theory and steps of breaking a problem into logic flow and not on programming. :)
  • I know it's a heretical stance to take, but I'd say that to teach OOP concepts, a visual language would be best.
    It took me a while to get my head round OOP in the first place, but working in windows, when you can instantly show the subclassing of a textbox into a purple textbox (for instance), it's very easy to get the basic concepts across to people in a non-abstract manner. Having got those concepts across, it's then very easy to move onto non-visual languages and apply the concepts you've learnt.
    _____
  • 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.

    Yes, it is, but I question whether schools should make programming too much like driving. Consider this: drivers who understand the workings of their cars are always better drivers than drivers who understand "wheel turn, gas go." Drivers who understand how the car works understand why you don't accelerate the car by flooring the gas pedal. They know why you change your oil periodically. Their cars last longer and work better.

    So it is with programmers. Those who know how the machine works know why memory allocation is slow, and reusing blocks of memory is faster than allocating new ones. Those who understand the preprocessor know why defining a frequenly used value or code block will produce faster code than those who only know object fields and functions. People who understand low level operations recognise good programming practice better than those with experience only in high level language because they've had to. Their code is more reusable, more readable, faster, and less prone to bugs.
  • by MSG ( 12810 ) on Wednesday June 13, 2001 @05:08PM (#153836)
    You have your analogy all backwards. The parent post was absolutely not advocating any course of action based on it's relative simplicity.

    Assembly programming is like adding single digits. It's very low level. You're learning exactly what happens at the very foundation of all of the things you will go on to learn.

    High level programming languages are like Calculus. It's high level. The purpose of high level operations is not to iterate through the low level operations ad nauseum. Calculus is really just a bunch of addition and subtraction expressed in a very consice manner.

    Teaching calculus or high level languages to people who don't have any background with lower level operations will always produce inferior skills than the oposite.
  • The best introductory language depends a lot on who the course is aimed towards. For some student populations Java might be best, but for other C, C++, Cobol, or even Fortran might be best.

    Back when I was an undergrad, different sections of Intro Programming were taught in a variety of languages. Different engineering departments allowed their students to take different languages, but the only section that all of the engineers could take was 2/3 Pascal and 1/3 Fortran. It was definitely a weird combination, but I thinked it worked out pretty well. Learning 2 languages right away makes it easier to pick up other languages on your own later. Plus, Fortran was still (and probably is still though C/C++ are making some headway) the dominant language for engineering/hard sciences.

    So anyway, Java might work OK, in some of the situations above, but I'm not sure that having a particular language that is the dominant one taught in introductory classes is the best option

    --

  • When I was going to school we were taught basic. It is a hig enough level language but you can learn alot from it. Pascal was also good in that reguard. You can learn what funcitons are, variables, types, bits and bytes, etc. You learn structured programming as well as event driven programming. Personally I'd think that learning OOP right of the bat may be a little difficult to understand at first.

    As far what is better Java, C or C++, it really depends on your application. I would not right an OS in Java, but C or C++ would be better as both could give you far greater speed improvements. JSP is a good way to go for writing web applications, and if it ever gets standardized (hint hint sun Microsystems) then it could be even better. Certain applications Java is not well suited for, but others it is great. Anywhere where speed is a real issue, C is better.

    I don't want a lot, I just want it all!
    Flame away, I have a hose!

  • by Hammer ( 14284 ) on Wednesday June 13, 2001 @10:33AM (#153842) Journal
    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.
  • by zealot ( 14660 ) <xzealot54x@y a h oo.com> on Wednesday June 13, 2001 @10:09AM (#153843)
    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/

  • The very things that make Java so useful for getting work done, are the things that make it a bad choice for learning fundamentals. Use a lower-level language that has pointers, doesn't have garbage collection, etc. C, Pascal, or even assembly would be good.


    ---
  • I started out with C and then moved to C++. I never was able to master C++ to an elite level. I was always blown off by its complexity.

    I was just about ready to give up until I came accross perl. Perl was simple and easy to learn. I quickly got good at it and started going into more advanced OO perl programming. Now, I have a great perl job.

    I believe I do better starting out with a simpler language and with limited tools than with a more complex language like C++.

    But this is just me and I know I'm not the only one out there. It's not that were too stupid to learn it's the way we are being taught is wrong.

    I know Perl is slow like Java so I focus on my algorithms to improve speed and I make it modular to work with others and to reuse code.

    I'm a better programmer because the language is simpler for me to learn and grasp.

    So I'm sorry for the C++ guys here but I agree with the Java crowd here. It's better to start with a simpler language than with a complex one.
  • by Lumpish Scholar ( 17107 ) on Wednesday June 13, 2001 @11:04AM (#153849) Homepage Journal
    Doug Lea [oswego.edu] (well known C++ programmer and writer; teaches at SUNY/Oswego)

    Kevin Sullivan [virginia.edu] (U. of Virginia)

    A [uwa.edu.au] couple [elj.com] of less positive articles from Australia.

    An article at O'Reilly. [oreilly.com]
  • by IsleOfView ( 23825 ) <jason&mugfu,com> on Wednesday June 13, 2001 @10:49AM (#153872) Homepage

    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)
  • by iapetus ( 24050 ) on Wednesday June 13, 2001 @04:56PM (#153880) Homepage
    Oh, Java APPLETS crash all of the time. And any college that'll try to teach computer programming is going to try to do it with applets, at least partially.

    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.

    The claim here is that Java is a better language to teach beginning computer programmers.

    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.

    By the way, you CAN'T write global variables in Java - everything is inside of a class!
    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.

    it's (in my opinion) FAR easier to code Java, from an understanding of C++, than it is to code C++ from an initial understanding of 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.

  • by brianvan ( 42539 ) on Wednesday June 13, 2001 @11:09AM (#153927)
    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...
  • by Dr.Evil ( 47264 ) on Wednesday June 13, 2001 @12:38PM (#153936) Homepage

    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.

    1. Java's not slow and klunky. I don't know when the last time you looked at Java was (it must have been years ago), but it is fast and getting faster. There are some optimization tricks you can do to code at runtime that can't work with a static compiler.
    2. C++ lets you do some really klunky stuff, too - more, I would argue. There's no cure for incompetent programming.
    3. Java isn't just taking off, it's already taken off. The base of Java developers and companies using Java for enterprise-critical applications is growing in direct proportion to C++'s falloff rate. Java isn't a fad, it's the language of the future. You can bury your head in the sand all you want, but that's the way it is. I'm sure lots of COBOL programmers thought C was just a fad, too.
    4. Java's making huge inroads in graphics performance and I/O speed, which is where it's always been slowest, especially in the upcoming Merlin release (J2SE 1.4). I won't pretend that you could write Quake III in Java yet, but you could probably write Quake I. Computation speed has never really been the problem. After all, even Fortran has great number-crunching capability, but nobody would use it for serious enterprise-type applications.
    5. Java's great strengths are binary portability, syntactic simplicity, and standard, supported APIs for everything under the sun. C++ doesn't even have an ABI standard that everyone plays with yet, let alone standard networking, graphics, and GUI libraries. Any industry that doesn't want portable, maintainable, extensible code is better off out of business.

    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 [oracle.com], Sybase [sybase.com], IBM [ibm.com], Macromedia/Allaire [allaire.com], Borland [borland.com] and of course Sun [sun.com], are banking lots of money on Java's success, recognizing that it's a mature, robust, stable, fast language for very serious development.

  • by Dr.Evil ( 47264 ) on Wednesday June 13, 2001 @11:31AM (#153937) Homepage

    Every time there is a discussion on Java, the same complaints come up:

    • Java is slow.
    • Java doesn't allow me direct memory access, pointer manipulation, templated classes, overloaded operators (insert favorite C++ feature here).
    • The syntax is not rich enough.

    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.

    • Java is approaching C++ speeds for execution time. Java benefits from some runtime compilation techniques that a static compiler can't accomplish, such as finalizing and inlining methods that aren't being overridden by an inheriting class and dynamically re-compiling "hot" methods. Many of the optimization tricks for static compilers, such as loop unrolling, are being brought into the HotSpot server compiler. Changes in the I/O libraries and the 2D libraries are providing a speed boost of 40-100% in J2SE 1.4 (now in Beta) Swing-based GUI applications over v1.2. The 2D layer in v1.4 uses native hardware acceleration for local apps and remote X calls for apps on remote terminals.
    • The litany of things Java abstracts away - direct memory manipulation, pointers, overloaded operators, multiple inheritance - all can be very dangerous for the naive programmer. The fact that C++ not only allows, but often makes you think about these things, is what I consider the bad thing.
    • Templates are coming to Java, probably in 1.5. Generics, as they're being called in JavaSpeak, however, have one important difference - they are 100% type-safe. You will only be able to template Objects, not primitives.
    • Java's syntax provides one blessed thing that C, C++, and especially Perl and some other newer languages don't - readability. There's none of this C++ -> nonsense, or Perl's $/@ crap. Thank god there is no such thing as preprocessor directives. Syntactic simplicity is as much a reason for Java's rapid adoption as anything else. The cleanest-written code is the most maintable code. Considering the commenting habits of most programmers, being able to tell what the code's doing from the code itself is a godsend. Sometimes there should be only one way to do something, because it reinforces the right way of doing it.

    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.

  • by Hard_Code ( 49548 ) on Wednesday June 13, 2001 @10:16AM (#153941)
    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!!".
  • by devphil ( 51341 ) on Wednesday June 13, 2001 @10:31AM (#153947) Homepage
    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.

    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.

  • by devphil ( 51341 ) on Wednesday June 13, 2001 @10:23AM (#153948) Homepage


    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.

  • by J.Random Hacker ( 51634 ) on Wednesday June 13, 2001 @11:15AM (#153949)
    I must humbly disagree. If we suddenly had acess to some non- von Neumann architecture machine, everyone who worked on it would have much rethinking to do, especially since our notions of complexity -- and therefore our notions of what makes a good algorithm -- are all rooted in the idea of serial execution of a stored program, threading notwithstanding. Even fine-grain parallel machines are just collections of serial execution machines.

    I have worked with people in the past who insisted that particular machine details are unimportant. For instance, they would say "There is no need to worry about the cost of paging due to a large resident memory set -- just buy more memory!" And then it would occur that we'd maxed out physical memory on that generation of machine -- response was -- "wait -- memories will be bigger next year." Memory did get bigger, but by the time memory was large enough, we were out of business.

    Ignoring the machine does not solve a problem here. Ignoring people will definately cause a problem, though, as you observe. Therefore the solution (it seems to me) is to teach more -- not less. Teach good user interface practices in addition to teaching how the machine works.
  • by babbage ( 61057 ) <cdeversNO@SPAMcis.usouthal.edu> on Wednesday June 13, 2001 @11:14AM (#153970) Homepage Journal
    What a shatteringly bad idea. The single biggest problem for the average CS department isn't that the students don't understand what they're doing, but that the attrition rate is so high. Students take a couple of semesters using a commercially viable language, get the idea, and quit to get one of thise glamorous high paying stock option drenched dotcom jobs that they keep hearing about. Admittedly, that siren isn't singing quite so seductively these days, but that doesn't change the underlying problem there.

    In order to cut down the attrition rate, you cannot scare off the incoming students. No way. If the first thing they get in Programming 101 is a solid smack upside the brain, a lot of them are going to just walk away. The dotcoms may not be hiring as much as they were before, but braving the job market is still going to be more appealing for the average student than having to put up with assembly language.

    They're gonna get the low level stuff before long; at this point they need to get a grasp of the big picture. As interesting as your suggestion is -- and I would agree that it's a very unusual way to approach the subject -- my advice would be to do almost completely the opposite. Use a language that shields the students from a lot of the underlying complexity, so they can focus on broader concepts that would usually come later in a software engineering class.

    Use Python.

    It's still a bit exotic, so the incentive to ditch school for a job using it is less pressing (though that would change fast if a lot of people started learning it, of course). It enforces clean syntax & frees coders up to focus on higher level problems through the use of -- get out your buzzword bingo cards -- object oriented libraries. It's scripted, so the students won't have as much arcana to deal with right away, and better still it comes with a command line interpreter, so students can test expressions to see what happens when various language constructs are executed, with instant feedback if anything is going wrong.

    As the students move through the curriculum, they can revisit earlier projects by rewriting libraries in a low level language like C (or assembler, if your sadistic impulse can't be denied any longer... :). This can be a bridge to understanding how a big project develops, especially among multiple programmers: the obvious thing to do would be for the first classes to use object libraries written by the second classes, which in turn are writing to specs prepared by the later software engineering classes. Etc.

    I really think it could be the foundation (with the later addition of C, C++, &/or Java) to a good, comprehensive CS curriculum.

  • by jjo ( 62046 ) on Wednesday June 13, 2001 @10:49AM (#153972) Homepage
    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?

    The answer is, of course, a tradeoff. Learning any of these things is potentially of value, but one must compare that potential value to the time and energy investment required. I submit that for most CS students today, the effort in learning assembler is not worth the benefit. It is therefore more appropriate for an elective rather than a core course, and has been for some years.

    A more interesting question is the current value of studying C after learning an object-oriented language. The tradeoff there is much more difficult, and I don't have a strong opinion one way or another.

    7402
  • by Zigg ( 64962 ) on Wednesday June 13, 2001 @10:09AM (#153981)

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

  • by Zigg ( 64962 ) on Wednesday June 13, 2001 @10:15AM (#153982)

    Actually, that is a pretty interesting philosophy... I like it, and not just because of sadistic tendencies. :-)

    Think about it:

    1. People learn first-hand what happens under the hood.

    2. The lack of any kind of visually impressive positive feedback will guarantee that the really bad programmers with a serious lack of dedication never come back.

    3. The apparently inexplicable things the machine does when you do something wrong will guarantee that those with some dedication but poor understanding will never come back.

    4. You are left with those who are really good programmers at heart, understand what they do, and are strongly dedicated to doing it. Ergo, fewer programmers, better programmers, more money to go around to less people, six figure salaries to all and real productivity. Oh, and Windows eventually goes away too. :-)

    Sigh, what a world that would be...

  • by Louis Savain ( 65843 ) on Wednesday June 13, 2001 @11:06AM (#153987) Homepage
    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?"
  • by andkaha ( 79865 ) on Wednesday June 13, 2001 @01:30PM (#154027) Homepage
    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).

    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 /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.

    Now, I need some coffee...

  • by err666 ( 91660 ) on Wednesday June 13, 2001 @11:07AM (#154070) Homepage
    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 ;-)
  • by Steeltoe ( 98226 ) on Wednesday June 13, 2001 @11:47AM (#154080) Homepage
    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" [amazon.com], 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 [rubycentral.com].

    Here are some additional links:
    The official Ruby page [ruby-lang.org]
    Dr. Dobbs article about Ruby [ddj.com]
    Documentation [ruby-lang.org]
    HotLinks [ruby-lang.org]

    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.. ;-) 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!

    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
  • by OmegaDan ( 101255 ) on Wednesday June 13, 2001 @10:58AM (#154089) Homepage
    The problem with java always has been and always will be - SUN. If you wanna use java you have to play SUNs game because they've got the only halfway useable compilers / interpreters / JIT compilers.

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

  • by Viking Coder ( 102287 ) on Wednesday June 13, 2001 @11:22AM (#154107)
    It is cleaner than C++. No it's not. Java crashes more often than C++, with provably correct code. The Java environment is inherently more unstable, and prone to crashes. Assuming of course that you're talking about Applets. 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.

    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++.

  • by Tom7 ( 102298 ) on Wednesday June 13, 2001 @10:50AM (#154111) Homepage Journal
    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.
  • by Tom7 ( 102298 ) on Wednesday June 13, 2001 @11:10AM (#154112) Homepage Journal
    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.
  • by paulywog ( 114255 ) on Wednesday June 13, 2001 @11:11AM (#154133)
    "My AP compsci classes used the old 25mHz Macs"

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

  • by Animats ( 122034 ) on Wednesday June 13, 2001 @10:43AM (#154152) Homepage
    I agree with teaching Java as a first language. It's clean, not too complicated, and you get useful error messages. Performance is mediocre, but for a teaching language, that's not a big issue.

    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.

  • by GCP ( 122438 ) on Wednesday June 13, 2001 @11:23AM (#154153)
    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.

  • by Rei ( 128717 ) on Wednesday June 13, 2001 @10:48AM (#154177) Homepage
    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 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 ;) ). 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:

    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 ;) And, with the power of the language, you could have incredibly adept functional elements at the same time as the interactive visual elements.

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

    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

  • by DrgnDancer ( 137700 ) on Wednesday June 13, 2001 @10:40AM (#154201) Homepage

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

  • by andr0meda ( 167375 ) on Thursday June 14, 2001 @01:18AM (#154260) Journal

    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.
  • by shim0070 ( 180059 ) on Wednesday June 13, 2001 @04:44PM (#154284)
    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.
    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 .net language for server side stuff. So you could go get a job after your first semester at college.
  • by rpeppe ( 198035 ) on Wednesday June 13, 2001 @11:20AM (#154314)
    I taught electronics undergrads C as their first language for some years. When I left, they were moving to Java. I was glad I had left! Like some others here, I'm not convinced that the actual language itself matters, just that it allows you to demonstrate, in a clear way, the programming concepts you're trying to get across.

    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:

    • Inheritance-based OO programming is a naturally obfuscated way of writing code, and is hard even for experts to get right. This page [lh.com] holds, amongst other things, a couple of paragraphs I wrote giving some of the reasons why.
    • The Java class libraries, partly for the above reasons, are a huge, tangled mess, and extremely hard for a beginner to come to terms with.

    My personal choice for a first language to teach would be Limbo [vitanuova.com], 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 [vitanuova.com], 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 [ibm.com] 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...

  • by LionKimbro ( 200000 ) on Wednesday June 13, 2001 @11:15AM (#154324) Homepage

    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 [taoriver.net]. 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.

  • by LionKimbro ( 200000 ) on Wednesday June 13, 2001 @10:32AM (#154325) Homepage

    I teach my students [taoriver.net] in the following order:

    1. Python. They learn to use variables, flow control, and functions in Python. Lists, Strings, Tuples, Dictionaries, Integers, and Files.
    2. C. They learn what bits and bytes are, binary logic, pointers, and some OS details.
    3. Python. They learn what classes and objects are. More importantly, we go over Design Patterns book, full of designs that extend in scope well beyond OOP.
    4. C++. They use classes and objects in C++.
    5. Python. Functional notations such as filter and map.
    6. Python. How to interface between C and Python.

    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!)

  • by wheel ( 204735 ) on Wednesday June 13, 2001 @10:21AM (#154333)
    ...java ...sucks resources like none other.
    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. :*)

  • by CoreyG ( 208821 ) on Wednesday June 13, 2001 @01:08PM (#154354)
    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. [javaworld.com]

    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. [elj.com]

    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.
  • by abdulwahid ( 214915 ) on Wednesday June 13, 2001 @01:01PM (#154374) Homepage

    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.

    I can't say that I agree with you. Here in the UK most of the better Universities are the ones that teach more theory whereas the less good ones teach more practical applications. For example, the University that teaches Visual Basic, that I referred to in my comment, is City University. Hardly a University renown for its computer science. Consequently, the computer graduates from there that I have come across know next to nothing. They didn't need a 3-4 year degree to learn Visual Basic programming! Down the road at UCL and Imperial they teach a lot more theory, several languages and guess what, the students that graduate are generally clued up.

    As for employers I think they understand the difference too. I definitely do when I look for people. I know the difference between someone who has done some training and knows particular applications and someone who has studied computing and knows a lot of theory. I usually find a simple set of problems to solve at a job interview weeds out the difference. And I for sure would prefer to employ someone who has a grasp of theory because then they will easily be able to pick up the many different programming languages that we use in our company.

  • by abdulwahid ( 214915 ) on Wednesday June 13, 2001 @11:08AM (#154375) Homepage

    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.

  • by ralphbecket ( 225429 ) on Thursday June 14, 2001 @01:40AM (#154397)
    Good grief. Where does one start?

    Modern programming languages are not based on Ada Lovelace's ideas. They cluster around notions of change of state (imperative languages), function composition (functional programming), or logical deduction (unification based logic languages).

    Hardware is more reliable than software because (a) it's far less complicated, (b) H/W designs start off with a very precise spec., (c) H/W is sufficiently simple that modern formal methods are applicable, (d) most software programmers out there are monkeys.

    Quite how you get from "based on parallel streams of signals" to non-algorithmic (whatever that means) is beyond me. I refer you to the Church-Turing thesis ("all Turing-powerful computational models are equivalent") for which a counterexample has yet to be presented.

    Among the main reasons why many languages are strongly biased towards sequential execution are that (a) it's easy to understand, (b) it has a clear computational cost model, (c) it's easier to design H/W for this model, (d) data dependencies often demand that you work sequentially.

    There are plenty of languages which do focus on concurrency (e.g. Occam) and plenty of schemes for supporting cheap concurrent programming (e.g. the Transputer, data-flow architectures, parallel functional language compilers, lazy functional languages, etc.) although they all have their drawbacks - mainly that the bookkeeping cost tends to seriously water down the naive intuitive expectation that it'll "all just work really fast."

    In my opinion, we have such buggy software because programmers are rarely given a rigorous spec. to start with and are rarely capable of following it properly when they are, and that the most common languages in use today (C, C++, Java, VB, Perl) are unbelievably poor: they have weak type systems, if any, they have weak abstraction mechanisms, and they have absolutely no mathematical underpinnings, and they are very bad at preventing mistakes (I would spend time debunking the "Java's not like that" arguments, but ...)

    This sort of "you're all fools - why can't you just see?" kind of rant really gets up my nose, especially when it's just backed up with an ill-informed wish list.
  • by bmongar ( 230600 ) on Wednesday June 13, 2001 @10:12AM (#154406)

    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.

  • by bmongar ( 230600 ) on Wednesday June 13, 2001 @10:19AM (#154407)

    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

  • by trolebus ( 234192 ) on Wednesday June 13, 2001 @10:09AM (#154412) Homepage
    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.
  • by Irvu ( 248207 ) on Wednesday June 13, 2001 @11:10AM (#154438)

    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

  • by AdamInParadise ( 257888 ) on Wednesday June 13, 2001 @10:09AM (#154456) Homepage
    Remember that most software development is bespoke (i.e. it will never get out of the company that wrote, for whatever reason).

    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 .NET...), thanks to Enterprise Java Beans and XML.

    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.
  • by IanA ( 260196 ) on Wednesday June 13, 2001 @10:28AM (#154460)
    pure genius!

    get a newbie, teach them the hardest concepts!

    calculus should be the first math taught!
    12th grade will be addition of single digits!

    how about you make it so that you learn assembly, then low level c, then basic?! i think the AP class should be MicrosoftBasic!

    stop trying to be karma whore and THINK.
  • by hding ( 309275 ) on Wednesday June 13, 2001 @10:14AM (#154510)

    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?

  • by njug ( 314066 ) on Wednesday June 13, 2001 @10:51AM (#154518)
    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. ;)
  • by SpeelingChekka ( 314128 ) on Wednesday June 13, 2001 @11:47AM (#154520) Homepage

    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.

  • by bark76 ( 410275 ) on Wednesday June 13, 2001 @07:18PM (#154550)
    What part of the OO paradigm does Smalltalk not support?

    • Polymorphism? Nope, Smalltalk does that. C++ and Java do this too (C++ use to cheat at this, but not anymore)
    • Encapsultation? Every version of Smalltalk I've used enforces this, there's no way around it. C++ and Java don't enforce encapsulation
    • Inheritance? How many OO languages don't support this :) Multiple Inheritance is an ugly thing that never should have been thought of. Any program that has to use it wasn't designed right, using this is as bad as using friends in C++.
    • Interpretted? C++ isn't true OO because of this (if you talk to an OO purist at least, I consider C++ to support OO, not be an OO language), Java cheats at this, Smalltalk doesn't

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

  • 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.
    --
  • by absurd_spork ( 454513 ) on Wednesday June 13, 2001 @10:13AM (#154597) Homepage
    I have been using Java for CS teaching for some time. It is not the funniest language for people to learn, mainly because you have to get yourself a thorough knowledge of Sun's standard libraries and their class hierarchy.

    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.

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...