Log in

No account? Create an account

t3knomanser's Fustian Deposits

Java Needs an Overhaul

How Random Babbling Becomes Corporate Policy

run the fuck away

Mad science gone horribly, horribly wrong(or right).

Java Needs an Overhaul

Previous Entry Share Next Entry
run the fuck away
This guy claims that Java is a dying language.

I think that's an optimistic assesment. I wish Java were a dying language. Instead, I predict that Java will be the COBOL of the 21st century- this arcane, but widely used language that will keep cropping up, again and again, in enterprise applications for the next fifty years. Someplace around the turn of the next century, there will be a renaissance of people needing to relearn it to replace/repair these applications.

Java is far harder to use than it needs to be. When the class library was designed, it was the first time a large-scale object oriented API was built into a language. There was a lot of backlash against that, believe it or not. People like me, coming from a C/C++ background were mistrustful of this (in retrospect, I can only wonder why!). We were used to managing our libraries as external links, and didn't want that stuff built into our languages.

So, Java's evolutionary response was to keep the class library at a low level. This made it so that huge amounts of code were needed to do simple tasks- but you could do those tasks in a million different ways. While we lost simplicity, we gained a good amount of flexibility.

Then came server side Java- J2EE. The class library strategy had proved a success, and now a bunch of very smart people set about using the same logic, coupled with strong OO decoupling principles, to design an enterprise application platform.

The result is a horrible mess. In a J2EE application, very little of what you write is Java code. Mostly, you rely on stubbed classes and JSPs to provide the framework, and gobs of XML configuration files to string it together. J2EE invented the role of the "Enterprise Architect"- someone whose sole job was to take all of these chunks of code and configuration and string them together.

Once again, there's a great deal of flexibility here- an extreme amount. But being flexible isn't always good. Let me give you an example:

Joebob writes an "Enterprise Java Bean"(EJB). This is a bunch of Java code that represents a piece of data. This EJB gets published with a "JNDI name"- basically, it goes into a folder path, something like: "ejb/data/MyBean". That information gets put into an XML config file that goes with the EJB library.

Then, Susiebob writes a JSP/Servlet application that's going to talk to that EJB, so in Susiebob's config file, she asks for (in her web config file) an EJB with this JNDI name: "ejb/beans/data/JoebobBean".

Wait a second! That's not the name Joebob gave it! That's okay though, because in the server configuration, we can set up a mapping that says: "when the web app wants 'ejb/beans/data/JoebobBean', give it the bean going by 'ejb/data/MyBean'".

This strong decoupling makes it trivial to swap out components in the future. So that's good. But it's a beast to maintain- three config file entries to simply load a class and use it?

A very common mistake in application design is being too flexible. The more flexible you try and make your application, the more work it is to use the application. Java is full of these mistakes in spades.

I have another beef with Java. Mainly in that colleges are turning to it as their defacto language for Computer Science programs. This is idiocy, and it does a disservice to the students.

Don't get me wrong, Java is great (although .NET is better) for teaching good Object Oriented design concepts. But Java isn't good (and .NET is worse) for teaching people how to think like a computer. It's impossible to truly understand the value of references and garbage collection if you don't understand pointers- and you learn pointers from C/C++ languages. You don't understand the value of OO if you haven't struggled through a moderately complex structured program.

The other problem- and I think this is a big one- is that we're teaching our CompSci students to be slaves of a single vendor. Sun makes Java. Microsoft makes .NET (oh, sure- there's open source .NET variants, and they see use. There are some open source JVMs as well. These projects are still exposed to sudden changes in the vendor's attitude.).

Imagine a musician that knows nothing about any instrument but the one they play. They might be an expert on the violin, but if they don't know at least something about the piano, they're going to have a hard time understanding music theory. If they don't know something about the violas and cellos, they aren't going to understand their role in the orchestra.

But let's go back to the piano. Anyone even moderately serious about music learns at least a little but about the piano keyboard. Why? Because it's this common standby instrument. It has a range from the low end to the high end of the orchestra. Composers use it to write out parts for every instrument. It's the least common denominator- all music theory grows from it.

Is there an analog in programming? There are several, actually. In the same way that the piano may be the base of Western music, there are other instruments that are tuned to different scales that form the base of other cultural music. Programming is the same way.

The core language you need as a programmer is C++. C++ is the piano of most mainstream programming languages. If you understand C++, Java and .NET follow naturally from it. C, its ancestor, also follows naturally from it. There's a whole family of languages that just drop off from C++.

Any serious programmer must know C++. But that isn't enough.

There are several families of programming language: Structured, Functional, Object Oriented and Logical. The boundaries aren't clean and clear between them, but there are rough areas.

C++ is so important because it touches on three of those four- it is Structured (procedures represent tasks), Functional (a function represents some calculation to be performed) and Object Oriented (there are objects, they are models real-world things and concepts). If you know C++, other Structured languages are easy to learn, as are other Object Oriented ones.

But there's an entire family of languages that are truly Functional languages. LISP is the big one- the "piano" of Functional languages. LISP is great for mathematical programs- it is the language closest to pure math (and hence, gets a lot of use in those circles). But for a programmer, knowing a little LISP makes it easier to work with a lot of more modern languages- JavaScript and Ruby, for example, are heavily influenced by functional languages. .NET's delegates are an attempt to bring the most powerful features of functional languages back into strong OO languages (C/C++ used "function pointers"). The article I linked above mentions adding closures to Java- closures come from LISP.

Logical languages are high-order languages- generally very abstract. PROLOG is the classic example. They're good for designing expert systems and AI research, and I haven't worked with any of them very much. I've learned to play classical music, blues and rock, but not so much jazz.

So, my ideal CS program would teach: LISP (or a derivative) and C++ for the intro and core classes. Then one of: Ruby, Perl, Python. Then, in senior year, it would get into vendor specific technologies- .NET, Java. Web application design, etc.
  • I think part of the problem is that colleges accept boatloads of money from Sun. I know this was a big part of the impetus for Pitt to switch to Java-only CS courses. (Thank goodness I was at Pitt during the transitional period, and could ride the C++ rainbow through all the core classes...)

    I want to get back into Ruby eventually, but I'll keep my Java know-how in my back pocket. If it actually does become like COBOL development someday, I could start earning some serious cash. If only I earned gobs of money for all the obscure crap I know...
    • Quote:
      is that colleges accept boatloads of money from Sun

      Corporations should sponsor sports teams, not CS programs.
  • If you know C++, other Structured languages are easy to learn, as are other Object Oriented ones.

    If you know any modern procedural/object-oriented language reasonably well, any other is easy to learn if you have a good reference book and a project to work on. There's no reason to bother learning C/C++ unless you're actually going to use it for something. If you're a serious programmer, you don't have time to waste on picking up extraneous knowledge.
    • Quote:
      If you're a serious programmer, you don't have time to waste on picking up extraneous knowledge.

      There's no such thing as extraneous knowledge. My ability to learn JavaScript (useful) was enhanced by a basic familiarity with LISP. The same is true of ActionScript. My knowledge of design patterns informs my daily life, let alone what I do at work. My knowledge of C++ allows me to spot ways to use VB6 that my coworkers never imagine.

      Of course, I may be a programmer now, but my goal is to be a computer scientist. My values are different, perhaps.
      • There is definitely such a thing as extraneous knowledge. In high school, I studied FORTRAN, among other things. In a CS class in college that I TA'ed for, I used Scheme. At one of my first programming jobs, I used Rexx. Each of these languages had their place at the time, whether for getting a grade, helping other students, or paying the bills, but they all had little long-term utility, and if you were to ask me to write some code in any of them now, I'd probably just give you a blank stare. Did my study of these languages help me with any other aspect of my personal or professional life? Can't say that it did.

        Then again, I don't consider myself a programmer or a computer scientist; for me, the computer is just a tool to use to solve more interesting problems in other disciplines. The majority of "computer science" - as thought of as an academic field of study - just doesn't do much for me.
        • Scheme is the particular derivative of LISP I learned. While I couldn't write anything complex in it, I'm really glad I learned it. Without knowing LISP, I couldn't have gotten as good at JavaScript as quickly as I had without having learned it.

          Honestly, I'd rather have learned pure LISP. I've dabbled in it, and it's "purer" than Scheme. I would have learned more that way.
Powered by LiveJournal.com