The Worst Anti-Java Rant Ever Written

Well, okay. I exaggerate, since this is the Internet there is always something worse. But I'm calling it the worst ever since I'm a jerk. Still; this is the dumbest anti-Java rant I have ever read. Frankly it's so bad it makes me question my position of being a Java hater myself. But then I think about AWT, Swing and GregorianCalendar and I get better

Since I've already made it clear than I'm a jerk I'm going to look at the guy's points and take them apart. Java, or at least Sun/Oracle's Java, is bad. There's no question about that. But if you're going to tear Java a new one try to find points that can't be validly taken apart or dismissed out of hand by a true-believer... or a hater that's pissed off at being potentially associated with such dreck. Without further ado, let's get this trainwreck a-rollin'

1) Java has a compiler

Ruby does not. That's great! Fuck compilers and their false sense of security. Too often is bad code checked in or even deployed to production, simply because it compiled. No such luxury in the Ruby world.

Seriously. That is your starting point. You know, most people tend to lead off with something big and obviously wrong with the language. How about the stereotypical FactoryPatternStrategyVisitorDesignPatternFactory classes that give haters so much ammo yet every Java-head is supposedly head-over-heals in love with. Or how generics suck in Java and took way too fucking long to get implemented. Or at least mention how compilers slow down your code-test-commit cycle by inserting an extra step. Fuck no, that would require something resembling deductive reasoning.

Oh, and believe me. I have seen more than my fair share of terrible Python, PHP, Ruby and Perl code in my few years of coding professionally. Not having a compiler does nothing to make a bozo's code magically better. All it means is that they'll produce shit code that is a nightmare to read that by sheer luck passes your unit tests. If they exist in the first place and if they even bothered running them. They certainly don't bother compiling before committing often enough! Guess what? Having a compiler vs not having a compiler will make no difference if the problem exists between keyboard and chair.

You shouldn't be making your code harder to check for stupid errors. Especially if it's to an attempt make fools less foolish. There lies madness. Remember the maxim "Nothing is foolproof to a sufficiently talented fool." A better solution is to keep fools away from your project or rely on the human element of training your fools to be less foolish. Nothing is stopping you from having a quarantine branch in your project; Or having a list of restricted contributers.

Oh! Just for a bit of icing on the cake. Ruby can be compiled and often is (except in the default Ruby implementation.) Why can it be compiled? For the main reason compilers existed in the first fucking place. To convert human readable, but sub-optimal code into high-performance machine readable code. And what is one of the most popular things to compile ruby to? Fucking. Java. Bytecode.

2) Java framework authors are not application developers

Prime example: the JBoss guys, who are paid handsomely to work on framework code all day. Sure, they're exposed to real application development, but they don't do it themselves. As a result, none of their handiwork is extracted from actual working codebases. Which is a shame, because if it were extracted from actual working codebases then it might actually not suck. All Rails core and plugin contributors of significance are fulltime application developers, starting at the top with DHH himself and the Rails core team. Day in and day out we write applications in Ruby and extract the useful bits out for other Rails developers to make use of via gems and plugins.

This is about the closest our wonderful author gets to a potentially valid point. I can't make any comments on JBoss since I avoid Java like the plague but given this guy's track record I'm disinclined to give him the benefit of the doubt. But since I relish the opportunity to bash Java: let's look at WORA, a pillar of Java's language philosophy. Sounds wonderful on paper. Collapses like a house of cards as soon as you try to apply it to real hardware. Joel on Software can explain the cause. (article not related to WORA directly but I'm assuming you're smart enough to see the connection!)

Contrived example time! Let's go back in time to the heady days of the mid-late nineties when Java was all the rage. Let's imagine we're making a wonderful new GUI application with Java. So you get it working on your awesome top-of-the-line dev machine. Now it's time to test... and your user tells you that it dies. Why? Your user heard of this awesome thing called J2ME, Java on a cellphone. It's Java and Java is WORA so it should work. Right? Guess what, a shitty nineties era cellphone isn't going to handle a GUI application that is made for desktop.

Okay that's extreme to the point of silliness but the philosophy is Write Once Run Anywhere not Write Once Per Platform /trollface. Let's go with a more likely case. You're using some nice portable library but not every feature you're using in some library is supported on your users' hardware like it is on yours. Obviously you want to take advantage of the features when available. So what now? Hello special cases and hello code bloat. Or the alternative you're using the lowest common denominator in your code so your lunch is being eaten on high end hardware by people who didn't drink the WORA koolaid. Then your product dies because high end systems become low end systems within a year or less. But I digress. I'm here to bash someone else's anti-Java rant. Not write my own.

3) Most Java Programmers are Morons

And there goes any possible validity point 2 might have had. Oops.

So how does this detract from point 2? Well, let's imagine a world where most people are stupid. One solution is to have an omniscient council of vagueness dictate the process which uses the framework built from the lofty heights of their ivory tower. Obviously the whole thing fails horribly on encountering the nuances of real work. Exactly what point 2 says. So instead we have the masses build a framework of useful tools based on practical lessons learned in the trenches. Well look what point 3 says. The masses are idiots. So that won't work either. You just end up with a mess of unusable broken garbage. At least according to our buddy's assertions. So let's get the smart people together to make a framework from their ivory tower...

The obvious rebuttal is that the circular logic above actually bolsters point 2. Guess what, if you go that way you've got Argumentum ad Hominem It's the classic "You're stupid therefore your argument is false." Don't try that rebuttal. This whole point is also an argument by assertion Yes, most Java programmers are stupid. Guess what most programmers are stupid full stop. In fact most people are stupid.

That especially includes the author of this tripe for making the wonderful non-argument I've spent the last two paragraphs deconstructing.

Oh, and I spared you the meat of his argument since it amounts to "all the cool programmers are using stuff that isn't Java therefore Java programmers are stupid." I'll be attacking that one further down since it rapidly becomes a theme in our buddy's later points... And you wonder why I'm insulted this idiot is a representative of Java haters online.

4) Java is too Fragmented

Java has a gazillion open-source frameworks and they all suck ass. So what do Java teams do to cope? Cobble those suck-ass frameworks together into custom layered homebrews that are nothing more than exponential explosions of sheer, despicable suck-assiness.

In stark contrast, in the Ruby world, we only have Rails. All Rails projects are structured the same way and follow the same conventions. That's a good thing, since it means that Rails developers can move across projects with relative ease.

And the Rails fanboy reveals himself. What if I don't want to make a web application clever writer? What then? What the holy fuck then asshole? Java does have a lot of frameworks. Guess what? All open source languages have piles upon piles of frameworks, tools and random shit out there produced by the community. Good ones, like Rails, will be picked up by the community and become de facto standards. Let's see, how many authentication methods exist for Rails again? RESTful Authentication, AuthLogic, mod_auth_sspi, OpenID authentication and on and on. Fragmentation is a fact of life for Open Source. Don't like it? Join the thousands of developers working with Microsoft and Apple's tools instead. You might like it.

Oh, and let's not forget. Almost every single open source framework out there exists because some developer got annoyed with existing frameworks and made their own letting their experience guide them. Your precious Rails is yet another framework in the great morass that is the world of open source web application development frameworks. DHH saw a problem, wasn't happy with existing solutions, and made his own. And it's a damn good solution but he isn't exactly a dictator forcing the Ruby and Rails communities into the One True Methodology. The community embraced Rails of its own collective volition. It wasn't forced to do so.

5) Java is Too Slow

Ha. This is one of my favorite reasons, for the bloody irony of it. You see, Java isn't actually slow. Everyone reading this knows that it got plenty fast over the last five years or so. Nevertheless, 90% of the world that knows of Java thinks that it is slow, because of its association with crappy slow Java applets and crappy slow Java loading screens on mobile devices.

Ruby *is* slow, compared to Java, and yet it is fast enough. Amazing, isn't it.

Let's translate. "People think Java is slow even though it isn't; at least for well designed applications. So let's avoid using it because people will be prejudiced against applications listed as using Java." Guess what? You don't have to shove it in people's faces that you're using Java. Next!

6) Java doesn't have blocks and closures

It's a miracle. We finally have something that isn't a bare assertion and is a valid point. Functions as first class objects, anonymous functions and closures are extremely powerful tools for building useful algorithms with a minimal amount of code. Java isn't as expressive as alternatives such as C#, Ruby, Lisp and Python. This can lead to the stereotypical bloat of the pathologically bad Java application. However being less expressive than other languages doesn't automatically make a language bad. C for example is as good as it ever was for its purpose.

This is the kind of point you should tack on after all your hard-hitting points. The blub programmer isn't going to care about things they haven't experienced like closures. What they would care about are actual annoyances like how AWT/Swing applications are ugly crap in comparison to Qt, native or web-based alternatives. Or how the built in date/time libraries are a pain in the ass to use. In fact that's an ongoing theme of this essay so far. It's bare assertions followed by smug self-satisfaction at not using Java.

7) Java has Integrated Development Environments (IDEs)

Closely related to Reason #3 Most Java Programmers are morons. Everyone knows that the best programmers use Vim and Emacs. Then come the TextMate users. If you need to use an IDE then you suck, period.

I sincerely hope this point is a joke. This is something that massively pisses me off about certain Open Source advocates. Because tools might make life easier for a moron and lower the barrier to entry for programming newbs everyone must use the worst, most obsolete, tools possible. Not everyone does this. Our author's precious DHH (all disrespect aimed at the blog author, not DHH, nothing but mad props for him :) wasn't satisfied with the tools that existed and made something that makes web development easy and fun. I don't see the author bashing Rails despite the fact it makes development easier just like any other good tool.

No, a good developer doesn't need tools to make their life easier. But a good developer is also a lazy, easily annoyed, impatient, stubborn asshole. Guess what? I'd rather be solving interesting problems with my programs than dealing with breaks due to typos and other silly mistakes. An IDE with autocomplete and syntax checking built in lets me avoid that menial bullshit and move on with my life. Let's throw in a line debugger with watches and stack monitoring, code folding for faster reading, and shortcuts for kicking off your build tools, unit tests, program binaries etc. all accessible within your text editor and you've pretty much got an IDE.

How about another comparison? Would you say I Wanna Be The Guy is a better game than Super Mario Bros 3? It's certainly a harder game. But it crashes, the artwork is crappy and about half the deaths are bullshit surprise deaths that are unavoidable until you memorize the game. And it fucking crashes. Last I checked the consensus is that SMB3 is the main contender for best platformer evar and IWBTG is something that's for laughing at hapless Let's Players. Confession: I love playing through I Wanna Be The Guy. The game is a parody of the bullshit difficulty of many NES era games and modern romhacks. And it is glorious. Without the parody context it's not so great however. YMMV

8) Java has good debugging support

Java has great and powerful debugging (which is very necessary since most Java code sucks so much ass). Ruby has ridiculously pitiful debugging support, which means our code actually needs to be well-tested and readable.

See above. Unit tests, system tests, integration tests, static analysis *cough*includingcompilers*cough* and every other non-debugger tool under the fucking sun won't catch everything. You will have bugs. It's nice to have a useful tool for finding those obscure corner cases that the tests didn't catch. I have more important things to do with my time than tediously inserting trace code into my programs in some vain attempt to emulate what a proper debugger provides out of the fucking box. Next.

9) Java Makes a Lot of Money for Vendors

This is potentially the most subtle of all of the reasons on the list. Basically, the integrity of most anything having to do with Java is corrupted by the way that it is inextricably linked to a web of intrigue involving money, big vendors and bullshit enterprise politics and pandering. Ruby doesn't make major money for anyone except Pragmatic Dave.

Hoo boy; it's another random assertion pretending to be an argument.

This reminds me of an anti-Rails rant I read today. It's more interesting due to DHH's rebuttal than its own content but a relevant point went like this: something something shitty documentation something something selling books something.

Anything that gains popularity will make money for someone. Often many someones. Books, consulting, evangelizing, training and, of course, the resulting products all inject money into a language's or framework's ecosystem. I'm pretty sure O'Reilly, Twitter, Hulu, Yellow Pages, 37signals et al didn't use (or create, or write about) Rails for the purpose of losing money. Either way, anyone who has a stake in a particular framework, regardless of the reason, will want to influence it.

Peoples' desire to influence other people will mean politics. Last I checked most open source frameworks have some level of politics and politicking to deal with. Politics that relates to programmers' egos and personal beliefs in The Right Thing. Look at the flamewar over Javascript's implicit semicolons. And how many forks of various major projects were made specifically because someone didn't like some particular nuance? Funpidgin ring any bells? Last I checked none of the people involved were faceless corporate entities. Just stubborn egotistical asshole programmers. Hell, look at the most infamous anti-rails rant on the Internet. Most of the anger is directed specifically at the politics of the community. This sort of shit happens. Especially in open source. Get over it.

10) Java does not have DHH

In the words of my inimitable friend Zed Shaw, "If DHH ain't doing it, you don't fucking do it. (Seems every time some clever fellow gets into trouble it's because of that.)"

Who does Java have? Jimmy Gosling? Hahahahahahahaha...

Sigh. You just had to go there. You just had to go with the "my visionary is cooler than your visionary" argument. You just had to go with the most childish, insolent, smug, short-sighted, juvenile, peabrained, puerile, putrid, pointless, pissy, motherfucking worthless shitstain of an argument possible. Do you hear people advocating Python solely on the basis that it has Guido van Rossum (aka BDFL) at the helm? Not too often. People advocate it because of his vision, stupid. Why don't you speak of what DHH contributes to the community? How he is actually able to create a useful tool and eloquently defend his decisions for Rails against complaints. Like he does here. That is how you get people behind you. That is how you make sure everything created in your ecosystem closely follows your vision.

But noooooo. You just had to resort to the fucking mocking. Your point is presented stupidly. How about this? How about you try attacking Sun or Jimmy Gosling for specific missteps in how they've managed their community and caused Java to suffer versus how DHH succeeded? Maybe then I wouldn't have to call you a fucking douche. You fucking douche!

Closing Words

Well. Fuck. That was exhausting. And writing this bitchfest took a bit of effort too.

I appreciate the sentiment of the article in discouraging the use of Java. The sooner Java dies, the better. The poor quality of the article I've ranted about does nothing to diminish the shortcomings of Java or the superiority of any alternatives. I wish the article did more to highlight hard facts about what makes Java bad instead of sucking up to DHH and poorly advocating Rails.

In the words of Jon Stewart

A Mini-rant on Documentation

If you're releasing a non-trivial API... for example a YAML parser for .NET. Please remember to document the most commonly used functions so it's easy to understand how they relate. Whatever you do, don't write undocumentation.

What is undocumentation? Well, if you didn't follow the link, it's something that looks like documentation but is devoid of anything that makes it useful documentation. Like this:

// Default constructor for the Node object
Node::Node()
{
   // do stuff
}

This documentation says nothing that the code doesn't already say. Writing documentation sucks. I know. But in this case not writing documentation is an equally meaningful alternative. And it saves everyone time. Particularly me since I now know I have to search for code samples or troll message boards and Stack Overflow to get the information I want.

Rant over.

If you insist on taking the time writing documentation make sure whatever you write isn't stuff made obvious in your method signatures. To mangle DC Comics for a second; a constructor is. You don't need to tell me it's a constructor. Tell me what isn't shown in the code. Tell me when I might use it. Tell me how I can cause it to fail. Tell me why I'd need it in the first place. Every piece of your documentation should provide a hint about how you intend your functions to work together. Preferably, these hints should be about as subtle as a pile driver.

Ruby on Rails and the Standard Python Library are both generally good examples of documentation. The parts of Ruby itself that I have used were also generally well documented. For all its faults the parts of the Java library I have used were well documented. The issue there was more the godawful design of what I had to work with.

Programmers are lazy and have a low tolerance for unnecessary work. You know best how your API should be used. You should let your users know what you know. A nice side-effect is, usually, more, and happier, users.

As an aside. The YAML parser I mentioned above otherwise looks good. I might make another, less harsh, post about it earlier. I want to use it. But it's taking longer to grok than I'd like. The result was this rant.

Another Gem

Posting this from work since I'm doing some boring data uploading crud.

If you ever find yourself doing this as a programmer/software engineer, please reconsider (your career choice)

From: http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96624/03_types.htm#29460
Note: Currently, VARCHAR is synonymous with VARCHAR2. However, in future releases of PL/SQL, to accommodate emerging SQL standards, VARCHAR might become a separate datatype with different comparison semantics. So, it is a good idea to use VARCHAR2 rather than VARCHAR.

Brilliant! Create a new type because maybe at some point you might want to change the behavior of an existing type at some unspecified time in a vaguely defined future. Apparently the guys at Oracle decided it made less sense to introduce a new type when the need arises (what sane people do) instead of adding a redundant type right away... just in case. Oh! And make the new type have the old behavior just to conveniently screw up backward compatibility if the original type does change. That's like making "Toy Story" the sequel to "Toy Story 2"... WTF

Do not use Java. Ever.

While browsing The Daily WTF I was led to this gem of a bug in Java. As if being bought out by Oracle wasn't enough.

I doubt the issue will ever be fixed since nobody in the OSS community seems to bother reading documentation for any APIs regardless of who produced them (based on rants from Linus and the above bug). Perhaps if they gave a shit about reading docs they'd give a shit about writing docs eh? But I digress...

Strike that... generalizations like that aren't fair since the OSS community is large and subject to Sturgeon's Law like any other. And subject to GIFT like any online community.

JAVA RANT TIME!


My experience with Java as an application development tool has been, frankly, appalling. AWT and Swing, when combined with NetBeans' visual editor tool, are easily the worst APIs I've ever had to work with.

A theme I've seen in my mercifully brief experience with Java is that it arbitrarily chooses to do things differently. Not necessarily because it's less verbose (Java code tends to be anything but verbose) or more flexible (where LISP supposedly cornered the market). Just different... in a manner that's pointless and stupid.

Imagine if you will that you're designing a data type to store dates. Some methods that might spring to mind would be GetDayOfMonth, GetDayOfWeek, GetMonth, GetYear, GetLengthOfMonth and so on. All fit common use cases for the printing of dates in various fashions used by humans. Using the functions wouldn't require consulting any documentation. So what does Java do? Mash all of that into one function! You say that description isn't all that helpful since it doesn't link to relevant information. Fuck you! Find it yourself! (it's here) Oh and let's not call the type for storing dates Date or anything like that. Let's call it GregorianCalendar, so that the most obvious common use cases are buttfucked right away.



Most software engineering programs include at least one course on how to make quality code. The fundamental rules of quality can be summed up as follows.

Make your program's actions and purpose blindingly obvious to the next idiot to see them.

Java's standard library fails even that relatively simple test. Ruby, Python, C#, C, Perl and who knows how many other languages manage to achieve this feat. This is stupid! The only other language which consistently pisses me off like Java is Perl. At least Perl is honest in being a pile of random hacks stacked haphazardly together to scratch some developer itches. Perl is a lazy tool for lazy developers. It fills its niche nicely though arguably Ruby and Python are better languages for the same niche and more besides.  
  

Don't use Java. Ever. If your environment is a JVM then try to use a better language that compiles to bytecode. You can find them, JRuby, Groovy, Jython, etc. If you can't do that then at least avoid using Sun's ass-tastic libraries... if Sun has a good library somewhere feel free to use that but my experience makes me doubt the existence of such a beast.

What's a better language? C#, Python, Ruby, C++ (despite its many flaws), Visual Basic (again despite its many flaws, I think this reflects nicely on how utterly godawful I think Java is) 

Bad Demo, Good Demo

So, here's the final update about Space Combat Sim as a school project. I'll follow up with a postmortem and a bit about what I'm doing in the future.

Bad Demo
The first presentation was to faculty and some industry representatives (fortunately their thing seemed to be anything but games.) It was originally going to be in a classroom setting but moved to the lounge in the student life center due to the number of people attending. The lounge, which happened to have one, maybe two, network ports. Both which were in use by other equipment... sigh. Without being able to play with someone all I could do was crash into scenery. Not much of a demo.

I was able to re-show the project in a lab, with a proper network, but the damage was done. My kingdom for Fraps... and the time (and people) to use it effectively. The fact I didn't have a fallback in case of network failure was a pretty major oversight on my part. Still that last minute venue change was really frustrating.

The most frustrating issue though was the fact the most vocal representative was most interested in how a project was supposed to make money. The fact he seemed more impressed about a group wearing suits than their actual project (which was quite slick) was particularly rankling. Why in the fuck are superficial details such as what the presenter is wearing even considered relevant? Caring more about clothing than the product demonstrated is not something to be proud of!

The impression he left me is that I could have run a pre-rendered video (not a recording of the game) and made up some bullshit about online gaming being worth billions and not been called on the fact I didn't even present a product. That would have saved a couple months of effort... At least the other members of the panel were willing to ask some technical questions during all the presentations.

Good Demo
The second demonstration was at the technology program showcase for the college. This was a 3 hour affair where a large number of people in the various technology programs at the school got to show off their projects. This time a lot more time was given to setup, last time there was a token effort in setting up a router which didn't work at all when used for wired networking. The project was set up on two PCs and running with proper Live accounts. There was some pain as some old bugs managed to magically un-fix themselves, and I didn't actually have the passwords for the Live accounts that were set up for the demo, but that got worked out early on.

The big lifesaver was having Heather (from Slime Cat Blog) and her sister to demo playing the game while I could talk about what it was and how it worked. They would fly around, shoot at each other, be silly, laugh and generally have fun. This attracted a lot of attention from the various people attending the showcase. It also nicely showed what the project was without me having to go into crazy amounts of detail describing how it worked. I'm glad they were there because a lot of the people coming to see the project weren't gamers.

By the way, if you're wondering how those photo****d textures turned out; here's a rendering of the three fighter types.


Not great but still decent for about 2-3 hours per ship I think.

Slightly late. Slightly different.

So I show up to school on Friday, slightly bleary from a late night, ready to get cracking on the testing the game and... pretty much nobody shows up. In fact, those who did show up were far too busy to help out with testing. The screenshots I promised on Thursday were supposed to be from some multiplayer testing but that didn't work out.

Today I added point lights to the game. These are nice for lights which come from a location and affect a specific, limited area. Great for more dramatic explosions, shooting and so on. Here's a pic


Lighting in Space Combat Sim is done using some fairly simple math. One topic covered in high-school geometry was the dot product. The dot product is a scalar product of two vectors. One property of a dot product is that, when it's produced from two unit vectors, its value is equal to the cosine of the angle between the vectors.

Why is that useful? Try shining a flashlight on a marble, or ball bearing, or basketball (anything round will do.) Notice that the brightest parts are those that face the light. As the surface of the ball faces away from the light it darkens. If you remember that old high-school math cosine is one for an angle of zero and zero for an angle of ninety degrees.

Cool. But this still doesn't say how light or dark a surface is... We need one more piece of data. The surface normal. This is a unit vector points straight off of the surface being lit. Let's express the direction of some infinitely far away light source with another vector. Remember what I said in the previous paragraph? The dot product of the two vectors is one if the surface is facing the light perfectly and zero if it isn't facing the light at all. Cool, eh?

This is the shader code for a directional light. It's a nice stand-in for some sunlight. Notice there's a little bit of extra work here so that it can render eight lights at a time.

float4 outputColor = float4(0, 0, 0, 0);
for(int i = 0; i < GlobalLightCount; i++)
{
    float LightFactor = dot( GlobalLights[i].Vector, input.WorldNormal );
    float4 color = GlobalLights[i].Color * LightFactor;
    outputColor += color;
}
outputColor.a = 1;
return saturate( outputColor ) * tex2D( DiffuseSampler, input.TextureCoord );

Now to extend this to point lights.

Point lights are a little different in that they have a definate location and a limited range. Both of these are fairly easy to deal with. Instead of specifying the direction of the light explicitly we calculate it by finding a unit vector that points from the light source to the object being lit. Cake.

The range limitation can also be made quite simple if we don't care about being 100% realistic.
Get distance between the light and the object being lit.
Divide that distance by the radius of the light.
Clamp the value to a range between zero and one
Subtract the value from one

This gives an additional value that we use to adjust the light's intensity based on distance. Here's the resulting HLSL shader code

float3 lightVector = GlobalLights[7].Vector - input.WorldPosition;
float lightDist = length( GlobalLights[7].Vector - input.WorldPosition );
float3 directionToLight = lightVector / lightDist;

// falloff light intensity linearly between alpha*radius and radius
float baseIntensity = 1 - saturate( lightDist / GlobalLights[0].Radius );
float diffuseIntensity = saturate( dot( directionToLight, input.WorldNormal ) );
outputColor += GlobalLights[7].Color * baseIntensity * diffuseIntensity;

outputColor.a = 1;
return saturate( outputColor ) * tex2D( DiffuseSampler, input.TextureCoord );

Networking Remark

Preview of my next entry:
Debugging network code in XNA Game Studio 3.1 sucks. I spent way more time than I care to think about restarting my game due to stupidity that has nothing to do with actual bugs in the game.