If Java's system of references and the way that strings are assigned and passed as parameters wasn't a horrible mess, then this forum would not be filled with people asking questions about these topics. Thread titles like "Java question about references (I think)". Having not put a lot of study into it, I bet immutable strings (this was something I was initially confused by, not knowing much Java) significantly reduce the number of string copies made in most programs, compared to the number of copies that wind up being made in most other languages. But that's not something any beginning programmer should worry about. It's unintuitive. It makes them think about the language rather than about their programs. When I was in high school the AP CS test was in C++, so of course the advanced programming courses were taught in C++... and C++ has that same problem as Java... I spent so much of my time overcoming the language that I never wrote anything cool in it. On the other hand, I wrote lots of really cool stuff in toy languages like TrueBASIC and for my graphing calculator.
Furthermore, the whole idea of object-oriented programming, to me, has no business in introductory programming courses. Save it for college. People think that if kids get non-OO thinking in their squishy brains they'll be doomed to write code like this their whole lives:
Code: Select all
In reality, the only reason I truly understand why writing code like that is usually undesirable (usually = unless you're coding for the lulz) is because I've done it. Abstraction and encapsulation are good things to keep in mind when writing medium-to-large programs that you'll want to reuse, and OOP is a good tool to enforce abstraction and encapsulation (that's all it is... well, it also helps you model reality sometimes... and there may be other practical things it's good for... the point is that OOP is not a means unto itself). But when you're a beginner writing small programs you should use a language that lets you get at the code, and get at the data. A language where it's easy to explore, easy to think of and design your own cool programs. Even if your design totally sucks; it's important to write badly-designed programs... how else will you ever find out why bad design is bad?!?! Java requires you to think about objects -- you can't write "Hello, World!" without writing a class. You already have to learn how to program, which is one problem... someone says, "use classes!" Now you have two problems. Frankly, the culture surrounding Java doesn't help. There's no Joie de Java, no, "and this is how you hack around with port IO and simple graphics" (QBASIC on DOS) or "smashing the stack for fun and profit" (C/asm) , but a lot of, "YOUR DESIGN PATTERNS ARE ALL WRONG". In one of the Java threads on this board a beginning programmer was advised to use inheritance to factor out code duplication, and to FUCKING CAPITALIZE THE NAMES OF HIS CLASSES! A programmer will learn inheritance from teachers, and about the perils of code duplication from co-workers. A programmer will absorb naming conventions just like people absorb social conventions. A young programmer should explore. Should Do Cool Stuff. Shouldn't be abstracted from the hardware. Shouldn't have code and data encapsulated away where they can't be seen.
QBASIC on 386s running DOS is a *great* first platform. I knew a guy in high school that wrote stuff in QBASIC to interface with electronics projects and model train systems that he built; I'd have to look through lots of manpages to do that in a "real language", even with my advanced education. I knew a guy in college that still prototyped everything he wrote in QBASIC; he knew no language that got in his way less, that made simple programs as absolutely trivial as QBASIC. It's truly a classic. Graduate them to C on Linux or something. Commit gross, dirty hacks. Maybe learn some assembler. Learn how those confounded boxes actually work. Or, alternately, start with something that's clean and high-level but actually abstracted *well* (some might say lisp? I'm not really knowledgeable about any languages that fall in this category), something that makes beautiful algorithms look and feel beautiful... and then let them fall down to languages burdened by pragmatic considerations, the ones that have won the marketplace (C++, Java, .NET, etc.) when they've already grown old and lost their will to live.