« Shirky FTW | Main | Nice Company. We'll Take It. »

Dec 13, 2006

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c022953ef00d83504470c69e2

Listed below are links to weblogs that reference A Java parable:

Comments

1.

I think the most pointed parallel of this is the comment that Java should have gone open source two years ago. The comment applies just as well to virtual worlds, in my opinion.

2.

Um.

J2EE rules the financial world. J2ME is important in mobile, at least until handsets that run native OSes are widespread. J2SE? Since MS's decision not to support Java out of the box, most users are faced with a scary "you must download something else" message before they run Java apps.

Don't misunderstand; I heart Java as a language. But desktop Java has been essentially abandoned by everyone except those who can enforce what goes onto a user's machine (read: corporate PCs).

But I think there's a lot to be said for J2EE on the backend and Flash or AJAX on the front-end... without any necessary user exposure to Java at all.

As for games--screw interpreted language. You want access to the machine level, as low as you can go, for performance reasons.

3.

Provocative, but definitely misleading. The only reason Sun is (finally) open source-ing Java is because the GNU CLASSPATH and gcj projects have caught up. Sun has no choice.

Java did *NOT* "bring to the table" virtual machine technology. The portability improvement resulting from a clean layer of abstraction over machine code -- bytecode -- is at least as old as 1966 and Pascal-P.

There are many other cracks in the facade of Java's greatness, so I believe the metaphorical use with MMORPG's is stretched. Java was a fantastic marketing success, and very little else. (Albeit JIT compilation is kinda neat.) I'll naively believe that a MMORPG's success is driven more be quality, than the size of its shelf in the Borders computer section.

4.

Greg, um.

ONLY when you're throwing graphics on the table as a performance issue. There are plenty of games - there are some really quite popular java board games (Megamek being the first example which pops into to my mind), for example - where graphics simply are not an issue.

5.

Like virtual worlds - Java started with a big vision. More than a programming language.

Java was intended to be an OS within an OS.

In 1995 there was a tight vision about a streamlined language that could write once and run anywhere. At the end of 2006 I am salivating Jaskell.

As Ben Gimpert says, Pascal had this idea long before Java.

Though perhaps its success did not translate into the profits that Sun hoped for, nor certainly the technical home-run many of the early visionaries believed in.

The purpose of Java was to make Windows irrelevent, the theory being, that if an application could run on any OS, then the OS would be valueless. This would hurt Windows and (hopefully) prevent Microsoft from producing a server OS (aka: future versions of Windows NT) that could compete against Sun's unix. Java didn't work as planned. Sun has basically been finished off by a combination of Windows NT and, more importantly, Linux. (IBM and others pushed Linux because they wanted BOTH Sun and Microsoft to lose.)


But there is excitement (for me) in the exotic mashups. Consider Jaskell.

In the grand scheme of MMORPGs, a scripting language is an easy thing to write. I wrote my own, with IDE, in a few months. I agree that a domain-specific language is potentially useful, but whether it has its origins is Java is moot.

Most MMORPGs seem to use Python or Lua, which are small and free. They're not ideal for simulating worlds, but then again, most of what's in a MMORPG is eye candy and database; relatively little scripting code. If you want to see a well-designed domain-specific language, look at the latest Inform, designed for producing interactive fiction... and only interactive fiction (as defined by Inform/Infocom).


Greg wrote: As for games--screw interpreted language. You want access to the machine level, as low as you can go, for performance reasons.

For eye candy, yes (kind of), but not for server world simulation. When you do the financial math, code that runs 1/10th the speed of C++ takes 10x as much hardware, but hardware is (relatively) cheap. Hiring coders to write C++ (which is more difficult than python/lua), and testers to debug C++ (which has pesky memory overrun problems and crashability), and the inability to modify code on the fly, and the extra time-to-market for all of this, far outweighs the cost of extra hardware.

6.

Check out Bruce Tate's _Beyond Java_ from O'Reilly Books. His argument is that Java has had its ten year run and something new and better is inevitable.

7.

To tie the subjects of Java and VWs even closer together, Multiverse's server plugins (the bits where you write the elements that really define the way the world and its occupants behave, as opposed to the scripted elements of individual mobs, spawns and the like) is coded in Java. I've been having some fun with that myself recently (written up here and in later posts).

8.

As an aside, Simon Phipps at Sun is looking into opening Java3D for more than research use. With a nice all-in-one plugin installer and some serious 3D hacking at Java3D's core we might have a usable, cross platform, in-browser, 3D platform.

9.

Ben Gimpert: "Albeit JIT compilation is kinda neat."

Yes it is, but it too predates Java. VisualWorks Smalltalk had it before Java came out, which is where I first saw it (according to Wikipedia this is where it was pioneered).

The whole "write once, run anywhere there's a VM" worked perfectly in VisualWorks, for reasons that actually made VisualWorks not acceptable to many customers - the buttons, check boxes, etc were all implemented on top of the VM, not using the operating system versions, so they didn't work or look identical to the ones that were native.

Early Java applets had this problem also.

You could perhaps draw parallels to how UO had a lot of features that later virtual worlds didn't, because of the drawbacks they brought along. But I can't ;)

10.

The only reason Sun is (finally) open source-ing Java is because the GNU CLASSPATH and gcj projects have caught up. Sun has no choice.

You must be joking. Show me a single mission critical application that runs on Gnu Classpath and gcj. Please.

Java was a fantastic marketing success, and very little else.

The rest of the world disagrees. Most businesses are utilizing Java today in one way or another in their server room. There is no serious contender in the middleware space today.

11.

juha: "Show me a single mission critical application that runs on Gnu Classpath and gcj. Please."

This is totally irrelevant. Every single hip, new thing is considered bizarre and risky for the first few companies that adopt. That's where Sun's incredible marketing comes in; it eases the effort in recruiting developers with the right skill set ("where will we ever find coders who know WhizBang?"), the marketing also nudges uni's into using the language in CS programmes, etc.

And the "rest of the world" (umm, you) does not disagree. VBA is still the most popular programming language. Frameworks like ZOPE and Rails are good server-side soluations, while C# is a decent rip-off technology for Windows-only server environments. Having been a professional -- self-loating, apparently -- Java developer for ten years, Tate and I are very ready for something new.

You must dig through the marketing to unlearn what you have learned...

12.

This is totally irrelevant.

It is very relevant to your bogus claim that Sun needs to react because of increased adoption of GNU Classpath and GCJ. These projects have been around for years and they have zero penetration in the enterprise. Therefore Sun's actions have nothing to do with them.

VBA is still the most popular programming language.

I never made a claim that Java is the most popular programming language in the world. I'm pretty sure it is in the top three though ;-) However, VB is used for desktop applications (when not replaced by C#). Java today is the market leader on enterprise middleware.

Frameworks like ZOPE and Rails are good server-side soluations

They may work for you but that doesn't change the fact that they have a tiny fraction of the market share compared to Java. Zope and RoR make hardly a blip on the radar. And there are very good reasons why that is but it undoubtedly will turn to a long conversion that doesn't belong to this forum.

Having been a professional -- self-loating, apparently -- Java developer for ten years, Tate and I are very ready for something new.

Good for you. Go have a blast. However, the reality still remains the same. Java has been incredibly successful on the server side, and today has no serious contenders as the middleware platform of choice for large enterprises.

You must dig through the marketing to unlearn what you have learned...

I don't need to dig through any marketing. I see the reality of Java adoption on a daily basis in my job. The world's largest companies are using Java middleware -- and given the amount of investments they have made this is not going to change any time soon. You clearly have no experience in what goes on inside the IT departments of the world's largest companies today, or you are willingly closing your eyes and ignoring it. It's Java -- not VB, Zope or RoR.

13.

These projects [GNU CLASSPATH and gcj] have been around for years and they have zero penetration in the enterprise.

The default installations of the Debian and Fedora Linux distros include the GNU Java projects. This has been the case for some time. So even without trying, these projects have far more than "zero penetration."

During a previous project, our infrastructure folks forgot to install a Sun-blessed Java run-time on one of our Linux servers. The only reason we noticed -- days later! -- was because the performance was a bit poor. (Again, JIT is kinda neat but not new to Java.) Here I admit to confusing the availability of binaries with their actual use in "enterprise" software, but I hope this is somewhat forgivable given Java app's notoriously complicated deployments. (Can anyone here configure a J2EE container in less than twenty-three thousand man weeks? If so, please send me your CV. ;-) )

Yes this is anecdotal, but you are vastly underestimating the penetration of GNU projects in the enterprise. This is especially pointed given that grid systems ("100 cheap Linux blades") are the next hip thing (i.e. not just Google). Do you find Sun's timing -- not their marketing, but their actual decision making -- a bit suspicious? It's not like their marketing has ever been misleading before...

Besides, I am not asserting that the current adoption of GNU Java has sparked Sun's (finally!) Open Source-ing Java. It has nothing to do with current adoption, but everything to do with the hundreds of eyes now staring at an open, decent implementation of the Java API and a JVM-ish system. It is just a numbers game; there is no way GNU Java will not (at least) catch up with closed Java, just as gcc has (at least) caught up with closed C/C++ compilers. Sun knows their Java community is very Open Source friendly (thank you, Jakarta), and could very well jump ship given the real option. (See "jikes and Eclipse.")

I think we're conflating two issues; one is the reality of how Java is used in the "enterprise" now-a-days, versus the promises and marketing of the Java platform extolled by Sun through the 90's. This distinction is worth making, because Nate's original post talks about the idealisms of Java, and asks us to consider these ideals as a metaphor for the development of some MMORPG's. This could still be applicable, but it ain't for technical reasons.

I agree that we needn't dig up the stale and ancient debate of Algol-ish languages like Java versus more Lisp-y languages like VB, Python and Ruby. This argument will never go away, and doesn't really matter anyway.

You clearly have no experience in what goes on inside the IT departments of the world's largest companies today, or you are willingly closing your eyes and ignoring it.

Well that's a bit harsh. Obviously you don't know me, and might be utterly baffled by the skepticism with which Java "marketing speak" is met with in my industries (City of London finance and consultancy). At least a few of the world's biggest trading firms and banks -- and thus some of the world's largest IT shops -- talk about simplifying over-architected 90's systems with (Java) tools like Spring & Hibernate, and talk about using more "scripting" languages like Ruby and Python for the client and server side glue.

Yes, just as we still write C++ and maitain COBOL code, the world's investment in Java means it's not going away. However, I predict (there's that word) Java development becomming a lot more competitive, pragmatic and Open Source. In other words, less Sun-centric. At least we'll get JDK bugs fixed a helluva lot quicker.

But again, we're not really progressing this topic. Nate's post seems to talk about metaphor -- a comparison between the development of one technology (Java) with the development of another, completely different technology (MMORPG's). As an overall metaphor, I think it's totally misleading and hence my de-lurking.

Anyone coding on the server-side of MMORPG's care to talk about their experience with Java, or with more modern platforms like C#, Rails or Zope?

(PS -- I don't work for Microsoft, or for Sun, or for any of the Rails zealot consultancies. Any more.)

14.

I'm using Java on the server side. C# is probably a better language than Java, but if you're looking for cross-platform support, it seems Java is more mature on the Unix side of things than Mono is. For instance, Mono has only recently added generics support.

JIT compilers have come a long way. Since this happens at runtime, it can theoretically be faster than precompiled code.

The constant factor runtime performance of you code doesn't always matter that much. Most CS undergrads are supposed to learn that it's the "Big-O" that really matters. If you write your bubble sort algorithm in assembly, and I write my merge-sort/quicksort in Ada (or insert whatever language you think sucks the most), mine will beat yours with a large enough problem set. The thing with MMOGs is that we have really large problem sets, with several N-squared, or worse, problems which needs to be addressed. What this means is that how your system 'scales' matters more than how fast it runs. This largely depends on your design and algorithms.

An area this is usually apparent is when you scale your platform to multiple machines. Some platforms dont allow you to this at all. In this scenario, if Ironforge, for example, gets too crowded, then you just have to buy a bigger machine to run it. In other geographically scalable solutions, you have inefficiencies introduced with each extra machine you add. Probably because there are communications overhead in managing the servers or overlapping geographical areas between servers (so that you dont have obvious server transition borders). It doesn't matter why, it comes down to how efficiently the system scales. A system that runs on C++ but has a 50% effieciency is going to lose over a Prolog based server with 90% efficiency pretty fast. My feeling is that current platforms have radically differing efficiencies and scaling capabilities.

If youre dealing with a small world with a few hundred people, it just doesnt matter much. But if youre dealing with a few hundred thousand, then how the platform scales will matter a lot more.

I don't quite understand the comment about Pascal being like Java. C# and Java allow you to write your code that can interact with the OS in a platform neutral way. A few years back we used to use NSPR to do the same thing (a runtime library developed by Netscape for C). Try writing some Pascal code that can send and receive UDP packets, create threads, and do thread-level locking and signaling. Let me know how that goes.

15.

I heartedly agree with Rafhael that BigO analysis (should) pervade our thinking about scalability, but I think there is a class of algorithms ("solutions") that may not be as efficient but are easier to parallelize. In other words, more SMP and grid-ish hardware architectures might mean I'd choose a "n(log(n))" algorithm over just "n" if (and only if) the n(log(n)) is easier to split across a bunch of CPU's.

Actually, I brought up Pascal because a certain flavor of that language had a portable bytecode and API long before Java and C# were on the scene. (See "http://en.wikipedia.org/wiki/UCSD_Pascal".) I'm not sure about thread-level locking, but the whole TCP/IP stack and signals were definitely there. Just another of my "there's nothing new in Java" slants. ;)

The comments to this entry are closed.