Slashdot Mirror
Java as a CS Introductory Language?
First, tulare queries: "I'm currently a student at a small university whose CS students are required to attend two terms of Java programming courses before moving on to other OOP languages. My personal feeling is that Java is clunky, ugly, and runs much too slow on most platforms. The official CS department position is that Java is pure OOP (as opposed to C, for example), and furthermore, Java is extremely widely used at this time. Now, I may be stirring things up a little here, but just because everyone does something one way does not neccessarily mean that something is being done the best way. What I'm asking is to hear reasoned opinions on the following statements:
- Java is a fine development language, and it will help me as a programmer to learn it.
- I'm right. Java is a fad, not worth much more than the Windows OS in terms of quality, and my CS faculty is doing me a disservice by cramming it down my throat.
- There's a little truth in both the above statements."
While on IRC, I was discussing this issue a bit with other editors and Chris DiBona happened to have some thoughts on the matter, his words follow:
When Cliff mentioned that a Java in education story was going to be posted, I asked to weigh in on the topic. I will not talk about the suitablity of using a non-free language, as I'm certain that will be discussed in the comments and is not a trivial issue.I don't think that Java, or any Object Oriented language, would be suitable for an AP Computer science class. I don't think it serves the needs of students looking to fully understand the internal workings of a computer, which is in my mind what an AP computer science course should be directed towards.
C is a language that has been designed to be very close to the hardware, and its ideosyncracies and power reflect that. Through this relationship, C reflects the realities of the hardware your programs run on. Memory management, low level process and I/O control are all things that a computer scientist should understand at a very low level, to better aid in future programming and debugging no matter which language is chosen or inflicted upon said scientist.
In contrast, Java has been designed to take such concerns away from the programmer. Memory management? Low level IO? These are not the droids you were looking for.. (at least not without an RMI written in another language) That's okay too, that isn't what people want from Java and it isn't what it was designed to do.
And that is exactly my problem with it being applied in a computer science course designed to teach CS fundamentals. In short, since I believe that AP CS courses should focus on the low level architecture of computing, Java is an inappropriate language for that course.
When is Java appropriate? In your college sophomore comparative languages course, or, alternatively, in an OO course or two, but it shouldn't be used as the keystone language for any CS program. Please don't take this as me saying that Java is neither useful or important in it's own (non-free) way, as it clearly is. However, in my opinion, It should be considered an adjunct subject to a serious program in Computer Science.
I'd argue that unless you understand assembly, you don't fully know how registers work. I haven't had to write any assembly for over 10 years, yet with every single line of code that I write, I'm thankful that I could if I needed to. I'm sure you're a very competent programmer, but empirical evidence from 20 years of coding shows me that without fail, coders that don't know assembly are unable to progress beyond competence into true greatness. Not that greatness is actually needed for 90% of coding tasks, but nonetheless, those with a background in assembly are without fail better coders.
As for when it should be learned, I disagree that it should be a first language, but it should be mandatory in any CS course at some point. but
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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...
Every time there is a discussion on Java, the same complaints come up:
Guess what, folks - most of that hasn't been true for the past couple of years, and it's getting better all the time. The stuff that you're not and won't be allowed to do is prohibited for the most part because it's dangerous and counter-productive. Java, like any widely-adopted language, does not simply cater to the 31337 hax0r.
I've helped teach a class for the AP and IB CS exams, and I'll tell you what they're about more than anything else - algorithms. That certainly doesn't benefit more from C/C++ than it does from Java. Hell, if that were the concern, we'd use Haskell! The point is, the class's focus isn't on pointer arithmetic, code optimization, or any other topic that makes C++ a more natural choice than Java. As a matter of fact, having to consider those things make C++ an obstacle to understanding, rather than an aid. I'm glad the College Board is changing the language to Java - it's the right thing to do for the level of understanding they're trying to teach.
Right...
Let's face it, most tutorial languages are picked for being high level, and having a fairly shallow learning curve. When I started learning programming, Pascal was used, which was fine in the days of purely procedural programming. Now that OO is more or less the defacto way of thinking about things (NOT to say that we should only be programming in OO languages), it makes sense to go with Java. Java was designed from the very very beginning with the explicit goal of making it harder to make mistakes - errors are caught up-front as much as possible.
Java has:
1) strict typing
2) dynamic linking
3) built-in memory management
4) a consistent implementation and rich libraries from a single vendor (for better or for worse)
5) works *identically* on many platforms ("identically" is the key here...we don't need to be spending half our time teaching build environments for various systems)
For all these reasons, it makes sense to use Java as a beginning language. The basic programming concepts are all there (yes, even resource management). The problem with C and C++ is that it is very easy to obscure larger concepts with intimate technical details, the learning curve is steep. I remember when I was learning Pascal, it was as if the class hit a brick wall when pointers were introduced. Imagine if learning pointers and intimate machine-dependent ("words"??) memory management was the prerequisite to larger programming concepts such as conditional statements, iteration, recursion, etc. The whole learning process would be stymied.
And I used to be one of the oh-so-cool C++ programmers who thought that Java was just a kindergarten-level "fad", and scoffed at it when it was used to teach programming in CS courses. Now enterprise Java programming is my day job, and I can attest to the fact that it is NOT a fad, is very powerful, and is used to do some really serious, and really cool stuff. I'm sure assembly programmers said "C?? You don't even need to know what REGISTERS are to use that!!".
It's 10 PM. Do you know if you're un-American?
There's a really great book out called _Accelerated C++_, by Koenig and Moo. (Yes folks, that Koenig and that Moo, the C++ gods.) It's a very new approach to teaching C++ as a first language, and everybody who's used it or even just reviewed it has loved it.
It doesn't even introduce pointers for several chapters. Students learn how to write simple loops, manage collections of things using std::vector, do the common 90% of string-related tasks using std::string, write some useful and practical programs, all before ever seeing a pointer.
Side note: the book is part of the C++ In-Depth series, being edited by Stroustrup. One of the rules for the series is that the main body text of the book must be no more than 300 pages. No filler crap, no 1500-page tomes to raise revenue; make your point simple and clear and then shut up.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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
Actually, that is a pretty interesting philosophy... I like it, and not just because of sadistic tendencies. :-)
Think about it:
People learn first-hand what happens under the hood.
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.
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.
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...
If you *must know how a computer works at a fundamental level*, then assembler isn't it. I had a microcode class that really helped me to understand about assembler optimization. You can make the argument that you can't really understand level N unless you understand level N-1, recursively all the way to quantum physics.
Or why not start at the other end of the abstraction stack? Start with cognitive pyschology, perception, human-computer interaction, and the identification of human needs -- then you figure out an approach that best meets people's needs, which would lead to how to choose the right software tools and approach for any particular case.
For a CS class, I wouldn't start at either extreme. Choosing the right level of abstraction is important, and the answer isn't just automatically one below what the other guy suggests.
I think CS classes should start by making it clear that the point of it all is to create useful stuff for real people. Teach them what they need to know to get started ASAP doing so, and fill in the details with later classes.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
I think the question here is this: Should we start by teaching an easier, higher level language (ie Java) to get programming concepts down, then move to lower level "closer to the machine" language for advanced topics, or should we start with the lower level language and then treat additional languages as extras?
Personally I think the first option is the more viable. Java is a fairly easy, very portable language on which students can create fairly elaborate programs somewhat quickly. With the Swing classes, one can create GUI based programs that will run almost anywhere after probably less that a semester of learning. Java has all the necesary pieces of a fully functional OO language, and it spells them out in a very easy to understand way. It also enforces compartmentalization. I remeber as a freshman, one of the most frustratin things about the way CS was taught was that none of the programs we wrote seemed "real". The assignments were written to develop skills in algorithm analysis and to point out uses of specific structures, but they always looked like a home work assignment, not a useful piece of software. With Java (or hell, even an interpruted language, like Perl or Python) I think the same skills could have been taught while allowing for more... err.. Satisfying .. assignments.
Once the basics of programmiing and software development were learned (and I don't know about anyone else, but my Uni spent most of the first year, and a chunck of the second on these skills. learning "how the computer works at the lowest level" was Sophmore and above classes) C would certainly be appropriate to tech as a lower level "how the machine thinks" langauge. Our low level systems classes were taught in Vax assembler (I never actually learned C in collage, we used Pascal as the teaching langauge, them SmallTalk and assembler in later classes), and I'd have found C both easier and more useful in "real life".
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
I teach my students in the following order:
It is with great sadness that I teach my students OOP, as it is over-hyped, and people believe in it religiously and without question. I teach it in order to prepare them for the world that will hire them.
The primary value in OOP, as far as I can tell, is thinking about the data first, and language features supporting polymorphism. Also, the book "Design Patterns" is the most (and quite possibly only) valuable piece of literature from the OOP community. I stress that it doesn't require a particular language or ideology to implement polymorphic behavior, or to think about the data first, or to implement a common pattern. (Device drivers and web servers are great examples of objects exhibiting polymorphism and encapsulation. In Non-OO speak, that's the product of paying attention to coupling and cohesion, which takes us right back to... The Unix Philosophy.)
I teach C so that they see low level stuff, and Python, for reasons to numerous to list. I teach C++ so that they can get hired.
One of the reasons for listing Python: They can start writing programs from day 1, second 1. No fussing with heavy class notations, like Java forces you to. (Just look at Java's hello world.) To believe that new students learn about OOP by using Java is hopelessly naive. Most students I've seen working with Java as a first language struggle with making for loops, while loops, and using variables. (Of course, several students will defend their teacher and difficult learning by give you the rhetoric that OOP is the way, and that Java is great because it's... OOP! You can feel the difference!)
True, esp. for gui's. (We all know about listener leaks, right?) For other uses, however, such as web-enabled db apps, it can actually make more efficient use of resources -- and Java can remove most of the pain from tasks like session management.
the teaching language be C/C++ - once you know that, you can learn Java, Perl, PHP, etc. with little effort
The problem of using C/C++ for teaching is, a student can get distracted from learning how to program well by the idiomatic syntactical complexities that make C/C++ such a powerful language in the first place. I say, learn Java first, so you understand the classic algorhythms, simple OO, and things like threads. Then, find out what else you can do with C/C++, and others.
True, Java's cross-platform... :*)
Do not forget, Java is not the only cross-platform language -- emacs-lisp is available for many many platforms, and uses such nicities as "byte-compiling", just like Java.
I agree with you in that Java is fine for an education language but it definitely shouldn't be limited to that. For example, one of the new recruits in my company has just graduated from a university where they were only taught Java. Consequently, he doesn't know what a pointer is, he doesn't know what linking object files means and he doesn't know anything about memory allocation.
As I see it, University (College) is about education not about industrial training. You shouldn't be taught specific tools at university rather you should be taught theory. That way, when you leave university you will be able to apply your theory to different languages or applications. For example, one of the Universities here in the UK teaches all the programming in Visual Basic. I mean what is that all about? How can you possibly claim you know how to program when all you know is Visual Basic! A good programmer should pick a language to use like a carpenter picks a tool for a job. Different languages are good for different jobs and university should give you the theory so that you can easily understand new languages.
A university should really teach you a mixture, pure object-oriented (like Smalltalk), imperative (like modula-2 or C), functional (like Miranda) etc. The student will then have firm foundations for being a good programmer.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
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.
I took the grade 11 computer course last year, basically they started us in C/C++ until Christmas and then switched to Java. Needless to say most of the people in this class would not have gone onto do computer nor did they have any experience but I noticed a distinct lack of interest when we swithed to Java. I think it had something to do with re-learning everything but it also had something to do with them finding C/C++ more intuitive. The point remains, whatever you go with, especially at the highschool level, stick with it all year or you will loose half the class right then and there.
More imporantly if you want to keep as many people interested in computers, especially their first introduction to programming, keep the language simple, worry about whether or not a high level or low level expericne is better later.
Agreed. While C\C++ is a good language and lies at the root of Perl and Java it and the imperative paradigm is not the center of the programming Universe. Without exploring languages from other paradimgs such as prolog, Haskell, etc one cannot get a good feel for the different ways to approache a problem. This tends to lead people into such dogamtic fun as the belif that recursion in all forms is "just plain wrong" as my C\C++ teacher put it.
In terms of which language to start with Java has the advantage over c in that it's syntax is cleaner and has less of the fun archaic elements such as the need for heavy pointer arithmetic. This makes the into learning curve too damn steep. Unfortunately it too is limiting to the iterative world. I'd recommend something like Pascal which was written to be a teaching language (if you must stick with imperative).
IMHO the best language to start with would be Lisp. It is more mature than python. It is quite tolerant allowing the students to play with less pain. It includes higher level elements such as lists that allows people to get into real programming in shorter order. Rather than forcing them to put off any real programming until after they have mastered the arcane nature of c's memory allocation. Lastly and most importantly as a teaching language it can be used for purely functional, purely iterative, and for object-oriented programming. Thus you can introduce your students to three of the major paradigms (you can do some Psudo-logic programming in it but it just isn't the same as prolog) under one roof. As a result the excess learning time is lessened.
Irvu
Remember that most software development is bespoke (i.e. it will never get out of the company that wrote, for whatever reason).
.NET...), thanks to Enterprise Java Beans and XML.
And I can tell you that whenever number crunching is not required, Java takes over. Java on the server is really gone rule the business world for the next 10 years (unless
As a learning language, I would say that Java being easier to learn, it's easier to teach OO concepts with Java because you don't have to make sense of this huge thing call C++ first.
Nobox: Only simple products.
For the express purpose of teaching OOP, why not use Smalltalk, which makes it difficult to fall into other methodologies and easy to use OO techniques?
But as a greater question, why restrict the field to one or a few languages? I'd think that in a CS curriculum (I insert the disclaimer that I came from mathematics and not from such a curriculum) one would want students to explore as many languages and paradigms as possible, ranging all the way from assembler to Prolog. This would presumably encourage a student both to develop many different ways of thinking about any given problem and to be able and willing to select an appropriate tool for any problem encountered. Far too often we see (as evidenced by responses on Slashdot to articles like this one) that many people are rather narrow-minded about language selection and unwilling to deviate from using their one pet language. Why not start to discourage that immediately in the course of formal CS training?
I figured this deserved more than the one line it got. A friend of mine from college said the same thing for his exit interview for the CS major. It's a great introductory language for people. It's complex enough to be worth an entire semester, allows for the teaching of OO techniques, and also doesn't make students feel utterly worthless (as C has been known to do. Do I malloc (amount + 1), or just (amount)? Argh!).
;)
Python is the perfect way for people to get their feet wet. Especially as it doesn't "break" a person's perspective on what to expect from languages, as perl might.
The main advantage of Java over C and C++ (and the reason why C and derivations are discontinued as teaching tools in my university) is it's relative platform-independence. When you want to test the programs that people have written at home, it's a real pain in the ass to get their Borland C++ programs running under Linux, you know. This disappears with Java.
On the other hand, Java is not the most highly structured language, especially in recent versions. That greatly lessens its didactic qualities; I have had several students here who started to experiment with all sorts of arcane features like inner classes and operator overloading without learning how to write good programs first. It's a bit like comparing Niklaus Wirth's original Pascal to Borland Delphi. Deplhi is more powerful, but you need a thorough knowledge of the class hierarchy and in order to deliver good OO programs, you have to be a good OO programmer beforehand.
Therefore, I now prefer either more systematic languages like Eiffel, or script-like languages like Python - the first for their higher level of abstraction and cleaner design, the latter for their greater ease of use and wider field of applications. Both are, in my opinion, better suited as didactic tools for learning OO programming.
And BTW, over here in Germany the high dependence on symbols such as {} or [] or /**/ is a didactic problem in itself because these aren't so easily reached on a German keyboard. This may sound harmless, but we get endless complaints from people who hate to perform strange Alt+Key acrobatics to get a simple thing like a curly brace.
There is absolutely no reason to panic.