Mark Damon Hughes Topic: Software [Parental Advisory: Explicit Lyrics] [about]

During the MacWorld Expo 2008, Twitter died. Too many people, hammering it with updates, too many people reading it. And in posts to their blog, MacWorld Why We Are Focused on Engineering and Operations, Twitter is pointing at high traffic as the cause.

Except, it's not, it's just something that exposed the inherent weakness in the system. The cause of the failure is that Twitter is written in Ruby on Rails. And it worked fine for a few hundred people and their friends, so they scaled it up to a few million. And it has been an unmitigated disaster, getting slower and slower no matter how hard they whip the servers. They can keep adding hardware, but that only delays the inevitable with the poor design of Rails, and the inherent slowness of Ruby. Alex Payne, one of the Twitter developers, gave an interview which explains just how bad the Rails situation is.

This is the Rails trap. Setting it up is so easy! You can roll out a basic site in a day! But when you need to add unusual (for Rails) features that aren't just database-to-web-forms scraping, or when you need more performance on the front-end boxes, or, Why forbid, change the way you interact with the database, then you're in for a world of hurt. And that hurt is an order of magnitude worse than the hurt you'll get by doing it "right" in the first place.

I certainly won't argue that building a big webapp in Java with JSP/Servlets or JavaServer Faces and maybe Hibernate is easy, because it's not. It takes a good week to have a basic site that does something, and that's if you know what you're doing (for an average Java programmer, a month of studying Marty Hall's Core Servlets books and building test applications should be enough to get up to speed). But adding more functionality that works to the JSP or JSF site is pretty easy after that, and it'll be tens to hundreds of times faster than an equivalent Rails app, and can support far more users, and won't require you to write entirely new database drivers to handle caching.

For a site that's meant to support just a small group of people with light usage, Rails can be okay, though it'll always frustrate you when you intend to expand it. A software service like Twitter is the archetypical example of something that would be vastly better off if based on a more robust platform.

← Previous: Ruby Riding the Rails as a Filthy Hobo (Software) Next: MacBook Air (Mac) →
Ruby Riding the Rails as a Filthy Hobo
Mon, 2008Jan07 08:00:00 PST
in Software by kamikaze

Tim Bray's predictions for 2008 include the rise of Ruby on Rails. I think not.

The best reality check is to search on (or other job site):

java: 15018 jobs
c++: 7363 jobs
c#: 7017 jobs
perl: 5220 jobs
php: 2176 jobs
python: 1233 jobs
ruby: 637 jobs
delphi: 139 jobs
smalltalk: 44 jobs
lisp: 22 jobs
objective-c: 16 jobs
haskell: 2 jobs

Java is the dominant language for solving problems that are worth paying money to solve. Nobody else is even close. Java is almost as popular as everything else combined.

Ruby on Rails is excruciatingly slow, and requires far more hardware to scale up than other tools. Using a tool that makes it easy to get started but costs more and causes more pain down the line is not good business sense. The disaster that has been Twitter trying to scale up is going to be repeated over and over, until people quit being penny-wise and pound-foolish, and learn to invest a little in more serious technology.

This might take a while, and certainly Ruby's going to get more popular in the next year, but in the long haul I think it's headed down again, sharply. In my experience, managers are extremely tolerant of senior engineers recommending and using whatever language or framework or technology they like--that's the point of being a senior engineer--but by the end of the development cycle, 12-18 months later, they had better have a working product, or they're out of a job.

The Rails hype machine started up nearly 2 years ago. Now we're seeing a lot of the apps built on it reach the market and creak and groan under the weight of even modest usage; they collapse utterly under Slashdot-type loads. This is going to lead to a lot of fired senior engineers who took a chance on the wrong language/framework, and Ruby will quietly sink back down to its natural place around Lisp's popularity.

And yes, I write Java and JSP code for a living. Also HTML/CSS/JavaScript, and Python tools. And in my own time I write Objective-C and some Haskell (more for educational purposes than anything practical, as I'm unconvinced Haskell can be practical).

I wrote this blog and site in PHP, and I've written tens of thousands of lines of PHP code (not counting the HTML); I can speak from hard experience now that PHP is shit. It's an awful language, with horrible syntax and semantics that must have been dreamed up by a madman. It's insecure, and the PHP team doesn't care. It is sheer folly to perpetrate new code in PHP, use something better if you value your data and time.

My experience with Ruby is more limited; I've done the tutorials and read Why's Poignant Guide to Ruby (which at least has good cartoons and chunky bacon, pity about the language), and tried building stuff in it, and got annoyed by its lack of new features and its ugly, Innsmouth-look, "dear god what abomination did you crossbreed with?!?" syntax compared to beautiful, graceful, simple Python. But I've read the project postmortems like everyone else. Ruby isn't going to fix your problems for you, it just gives you new problems.

While I love Python for quick problem-solving and for writing beautiful code, there's no way I'd ever again use it for an app that would be run by more than a half-dozen people in the world. It's faster than Ruby, but still 10-100x slower than Java. If it was half the speed, that'd be okay, but it's just not there. Even if speed was not an issue, writing big tools in Python sucks. Compilers turn out to be really handy at catching stupid mistakes, and everyone makes stupid mistakes.

There's nothing magical about what dynamic languages do. If you want dynamic web code in Java, make some JSP pages, and use JSTL with the <sql:> tags, or wrap your database code inside JSP beans. This works at least as well as PHP, maybe better, and will have several orders of magnitude better performance than an equivalent site in Ruby, because it's really compiled into pure Java servlets.

[update 2008-01-11: added Perl statistics.]

Java 6 for Mac OS X Leopard!
Wed, 2007Dec19 18:08:48 PST
in Software by kamikaze

Developers can get a developer preview now at the Apple Developer Connection.

Thanks, Apple!

Yes, it's 64-bit Intel only. No, it doesn't run Eclipse (because their SWT library is only 32-bit right now). But you can run Eclipse in Java 5, and use Java 6 for the compiler and app runtime, and it works. I'm sure some of the whiny Java dorks will be complaining about this anyway. I'm not with them.

[Update] As I predicted, the whiny Java dorks are, in fact, complaining, saying things like "What????? Only 64 bit???? You have GOT to be freaking kidding me!!!! My MacBook is a 32 bit Core Duo one. The arrogance is just dripping off left and right, I don't know HOW people put up with it. I don't."

Really, this is why we can't have nice things in Mac-Java-land. Even when we get them, most of the Java devs bitch and whine like little girls. They bitch and whine for a pony, and when they get it, they're upset that it's not the right color. YOU GOT A PONY, YOU WHINY BITCH! SHUT UP! If I was Apple, I'd have stopped supporting Java entirely, it's just not worth dealing with these whiny little bitches.

← Previous: Human Engineering (Software) Next: Rob Enderle Drinks Too Much Eggnog (Media) →
Human Engineering
Fri, 2007Dec07 09:10:11 PST
in Software by kamikaze

Closure is the aspect of communications design that causes the greatest problems. The concept is best explained with an analogy. The user is at point A and wishes to use the program to get to point B. A poorly human-engineered program is like a tightrope stretched between points A and B. The user who knows exactly what to do and performs perfectly will succeed. More likely, he or she will slip and fall. Some programs try to help by providing a manual or internal warnings that tell the user what to do and what not to do. These are analogous to signs along the tightrope advising "BE CAREFUL" and "DON'T FALL." I have seen several programs that place signs underneath the tightrope, so that the user can at least see why he failed as he plummets. A somewhat better class of programs provide masks against illegal entries. These are equivalent to guardrails alongside the tightrope. These are much nicer, but they must be very well constructed to ensure that the user does not thwart them. Some programs have nasty messages that bark at the errant user, warning against making certain entries. These are analogous to scowling monitors in the school halls, and are useful only for making an adult feel like a child. The ideal program is like a tunnel bored through solid rock. There is but one path, the path leading to success. The user has no options but to succeed.

The essence of closure is the narrowing of options, the elimination of possibilities, the placement of rock solid walls around the user. Good design is not an accumulative process of piling lots of features onto a basic architecture; good design requires the programmer to strip away minor features, petty options, and general trivia.

-Chris Crawford, De Re Atari: Appendix B: Human Engineering, 1982

← Previous: Throw More Kindling on the Fire (Toys) Next: Java 6 for Mac OS X Leopard! (Software) →
User Interface Design
Mon, 2007Nov12 20:07:15 PST
in Software by kamikaze

It has been noted that I'm... intemperate, let's say... with bad design, and an obsessive fanboy for good design. When people identify too strongly with the systems I say have bad design or no design at all, like Linux, they take it very poorly indeed, and think it's a personal attack. It is rarely personal, and even if you have mal-designed one of these programs I scorn, it's just strong encouragement for you to do better. I don't wish you ill, I just want you to learn from your mistakes. Of course, I have only good will to those who share my madness...

I'm finally starting to see a method in this madness, and to organize my thoughts about it. So, below the break, a few thoughts on user interface design.

There are three ways to write a GUI program. Because they are most commonly associated with specific platforms, I'll call them the Unix Way, the Windows Way, and the Macintosh Way, but any can appear on any platform.

The Windows Way

First, check MSDN, see if Microsoft has written a library for your task. If not, write a library. Don't bother with tests, or any interface, you just want a bunch of code. Then throw together some dialogs, maybe in Visual Basic, and push the buttons to see if they work. Don't verify any results, or rethink the design at all. Ship it.

Sure, the app is unusable trash, it's full of bugs, eats your HD, and loads viruses in place of your family photos, but it was easy to produce, huh?

Most Java apps, I would note, are written the Windows Way. Except Java doesn't really have Visual Basic, so the programmers make the most bare-minimum GUI possible, using the default unspeakably hideous "Metal" look and feel. I remember back in JDK 1.1, when Swing first got the Metal theme, and I thought it was a programmer joke that'd gone too far, and surely they'd never release it with that theme, but I was wrong. Never attribute to excessive humor what can be attributed to bad taste, I guess.

The Unix Way

Write a command-line app that takes text on standard input or a filename as an argument, with a minimum of 20 command-line options. Make sure it works perfectly on the 2 or 3 regression test cases you set up, but don't worry about anything else.

Now throw together a dialog box with a field or checkbox for every command-line option, and a big GO button. If you use Tk for this, you can make the most absolutely hideous interface possible on every desktop, and thereby drive people to the command line instead. Since the command line is superior, this is the best outcome. Ship it as a bundle of source code, a make file, and a GPL license. You don't want anyone using your program who can't compile C code.

Sure, it's unusable trash, but at least it works, right?

(Note: In my former life as a Linux-based Java/Python programmer, I was guilty of this myself. RandPod is a hack I threw together in an hour to get music onto my Treo, before I got an iPod. Nobody should use RandPod unless they're totally desperate.)

The Macintosh Way

Think about what you want the user to be able to accomplish, and what kind of screen interfaces they might interact with. Design this in Interface Builder (even if you're going to write it in some other language), but don't wire it up to any code yet. Just play with it in IB.

If you haven't already, go read Jakob Nielsen's web site and the Nielsen Norman Group books, especially Usability Engineering, which is, I would say, the best book on the science of measuring usability ever written.

When you're ready, show it to people who aren't programmers (programmers are not people, we think in a different way than humans, and are unsuitable for testing), and get their opinion, and PAY ATTENTION. You can't just take them at their literal word, because users aren't quite speaking the same language you are, but you can translate. My first pass of translation from user-ese to designer-ese is:
"I can't figure out how to X" means I need to bring feature X or the object it manipulates to the top of the interface, it's almost certainly buried too far down.
"X sucks because it's not like MyFamiliarProgram" means I should make my app even less like MyFamiliarProgram so there's no confusion.

A good app pays attention to what the users want to do, and drives them like a piledriver into the app to accomplish their task. Once you pick a path, you should have no choice but success or returning unharmed to the start, not wandering aimlessly through the app with the task half-finished. A great app does that and has one strong vision behind it, but until you develop a consistent style, the users know better than you do when an app is pleasant to use or not.

Okay, so you've tested the UI. Throw out your current NIB files, and rebuild the UI and hook it up to some prototype code, that just uses test data. Now run your usability tests again, and incorporate any changes needed.

You're getting close, now. You can start implementing real functionality. Big chunks of code. If you set up your app with proper Model-View-Controller separation, it's easy to write unit tests which are driven by a test harness and not the "real GUI", so you should do that.

When the entire app is hooked up, you can finally begin the last round of user testing, to make sure nothing slipped through. When the users have the reactions of "OMG I'm totally addicted, here, take my credit card and my first-born child", you can ship. If not, go back to work.

The Despot Sociopath Theory

Today, "miclorb" in #javaposse said "I have noticed good UI deisgns usually have some despot sociopath behind it. Someone with a single vision who just pushes and pushes." Certainly that has the ring of truth to it. We all laugh about Steve Jobs and his "Reality Distortion Field" and call him "Pope Steve" when he makes big pronouncements to the faithful, but "sociopath with impeccable taste" is probably the best description there can be of him. Jean-Louis Gassée is similarly an obsessive perfectionist, and made Newton and later BeOS have singular design visions. Every designer (or manager of designers) I've seen who was any good was that obsessed and mad.

What drove me insane, made me the annoying, obsessive design freak I am now, was using Linux. I'd had years and years of being indoctrinated by the Macintosh Human Interface Guidelines and the Atari ST design guidelines, then OS/2 and IBM's VERY focused attention to user interface flow (it didn't have to be pretty, just responsive and consistent).

Even then, it didn't really sink in until I had to use Linux day in and out, and got more angry, HULK SMASH! angry, every day at how awful it was. Edit /etc/X11R6/xf86config with some parameters you can only find by reading the source code for the video card driver, then recompile your kernel, and maybe you can get video working. Repeat for sound, but you can't get two channels of sound, even though the card supports it. Now pick one of the dozens of window managers, pick one of dozens of themes, and try to run a few apps. Oh, but this one's KDE, this one's GNOME, this one's Motif, and soon you're out of memory, and they all look and act completely different. And they're all designed the "Unix Way", so they suck.

The problem is the lack of organization to the Linux desktops. The kernel is a despotic kingdom, and while I'm no more a fan of monolithic kernels than Andrew S. Tannenbaum is, it's a consistent piece of software. But on the desktop, there is nobody saying to the Linux developers, "This is what a Linux app looks like, this is how it should act. This app is friendly, this app sucks." There are no market pressures, because it's impossible to make a living selling Linux software when people will just recompile it for free. Sometimes Linus will say "GNOME sucks, I just tell people to use KDE", but that's not really guidance.

When I switched to Mac OS X, suddenly everything worked, and worked in a consistent, user-friendly manner. I turned over a new leaf, and started making my software no longer suck to use. It's a long, slow process to learn UI design, but the end result is worth it: making insanely great software, not crappy software.

Where Do We Go Now?

Part of the solution is simply training. Learn how to make usable software. It's painful at first, especially when you start getting user feedback and it crushes your ego, but when you make usable software and people tell you they love your software, it's the best feeling in the world.

Part of the solution, though only secondary to actually learning usability design, is technological. Some platforms are not viable for making good, modern, usable software. You can fight the local idioms and do so despite them, but why not go with the good stuff in the first place?

Obviously, the first and best choice is Mac OS X native apps, written in Cocoa, in Interface Builder and Xcode. Hit the Apple Developer Connection, get a free Web membership, start reading the docs and sample code, and try it yourself. Interface Builder is worth using even if you never ship a Cocoa app.

The next best is The New Web (aka "Web 2.0™ O'Reilly"). Web applications used to be incredibly minimalist link, form, button, page reload affairs, which was unpleasant enough to start with, but most also chose horrible layouts and hid material as far away from any consistent navigation scheme as possible. More recent developments with HTML 5, CSS, JavaScript, AJAX, and now higher-level frameworks like Prototype JavaScript, Dojo Toolkit, and so on, have made the web interface more powerful and consistent across browsers. In some cases, like GMail and Google Maps, this is enabling an entirely new era in user interfaces. In others, like Microsoft's "Outlook Web Access" and Sharepoint, it produces nightmares.

Flash is a quagmire. The animation and media controls were exciting a few years ago, but now mainstream HTML is approaching its capabilities, and Flash is slow (in some recent tests I did, Flash animation runs at around 1% of the speed of JavaScript-controlled DOM objects, and was far less responsive to the user), awkward, and memory-consuming. Users reject the slow, non-native look and feel of Flash for good reason; the only popular Flash apps are extremely minimalist, or small games. Making a good, usable Flash app with Adobe's tools is nearly impossible. But Flash is, I think, a temporary aberration, and will soon be replaced with the standard language of the web: HTML and JavaScript.

Desktop Java apps and Java applets have recently staggered, zombie-like, back to life (I never quit making them, but I'm a freak), and Java cell-phone apps like the Blackberry have done extraordinarily well. Whether Sun can do anything about the ugly look-and-feel of Swing and the AWT remains to be seen. JavaFX is a neat framework for making GUIs, except that A) it's a nerdy programming language, not a graphical designer like a real UI designer would want, and B) it has no human interface guidelines. JavaFX may turn out to be worse than Flash for usability, but there are good designers who are embracing and using it, and it can be used for good instead of evil.

It's too late for Linux. It's poisoned, full of garbage apps, and the native population are almost entirely programmers without any taste or design sense, so they won't appreciate it if you do write good apps.

Windows seems to deliberately go against every principle of good user interface design more aggressively and hideously with every new version; Vista is full of shiny eye candy, but it's rotten and poisonous to actually use. It's presumably possible to make good apps for Vista, but few people ever try, and even fewer of them succeed. Microsoft's current strategy is to push desktop Windows apps into C# and .NET, but they offer no guidance or tools for making anything pleasant to use. They also push "web apps" of a sort with Silverlight, but that's just another Flash-type thing, but without even Flash's limited attention to usability.

Mozilla wants to revitalize their old XUL technology. This is not a terrible idea, and good, usable software can be built with XUL. But XUL is unpleasant to develop in, and is not as powerful as modern AJAX and web toolkits. Why tie yourself to slow, bloated Firefox?

Cocoa logging
Sat, 2007Sep01 16:06:11 PDT
in Software by kamikaze

I've finally worked out what I think is a reasonably robust logging system for my debugging code, which I can disable when I'm ready for production:

In the project's Debug build configuration, set preprocessor macro DEBUG=1

In foo_Prefix.pch:

#ifdef DEBUG
// DLOG takes a format argument and 0 or more args:
// DLOG(@"");
// DLOG(@"%d", x);
#define DLOG(fmt, ...) NSLog(@"%s: " fmt, __PRETTY_FUNCTION__, ##__VA_ARGS__)
#define DLOG(...)

Now I can use DLOG(@"foo"); instead of NSLog(@"foo"), and the console contains:

2009-02-03 04:05:06.789 AwesomeApp[6109:a0f] -[AwesomeAppDelegate someMethod]: foo

__PRETTY_FUNCTION__ inserts the current classname and method selector.

##__VA_ARGS__ removes the preceding comma if there are no arguments.

The GNUtards Must Be Crazy
Mon, 2007Aug06 02:06:29 PDT
in Software by kamikaze

Chris Stone wrote a while back:

The GPL effectively prohibits any sort of commercial use. With version 3 due out soon, it gets even more restrictive because of the Microsoft/Novell patent tax pact. The BSD and MIT licenses do not prohibit commercial use. That means that it is possible for someone to make money off of them, i.e., to eat, buy clothes, buy plasma TV’s.

This is the enlightened view. The MIT, BSD, and X11 licenses are the only true "open source" licenses. They are clear, unambiguous, and allow you to share your work in the spirit of scientific research. When others improve on your work, they are free to either continue contributing to that body of knowledge, or go make some money from their unique contribution.

I don't feel bad when someone uses my BSD-licensed code to make money, I feel happy. I intended to give it away, so I'm going to honestly give it away, without lying to you and attaching strings to the gift.

The GPL is bigoted hate speech from a bitter dork who was upset that all his Lisp buddies were leaving the AI lab and getting real jobs at Symbolics, so he first tried to destroy them with an inferior copy of their work, and when that failed, he made it his life's work to destroy the commercial software industry. The GPL is solely about jealousy: they aren't making any money, so they hate anyone else who is making money. It's the same mental disorder that makes hippies hate all corporations and businesses, because they're dirt-poor and stupid, so they resent anyone else who isn't.

The GPL is discriminatory. It is biased against anyone who wants to actually produce commercial software and make a living from it. It is difficult, bordering on impossible, to make money from GPL software. Red Hat, Novell, and a handful of others sell service, because Linux is so hard to use and maintain that most people need service to use it. But if they tried to sell licenses without support contracts for Linux, they'd be crushed by Ubuntu giving it away for free. The most successful business model Novell's found has been getting bribed by Microsoft. Neither of these companies make any new software, they just repackage someone else's software, and then try to extort money for it. The GPL has led directly to extortion.

The GPL is a bait-and-switch. It shows you functional code that might very well solve your problem, and then says, "Oh, no, you can't actually use this, because you work for a living."

It's difficult to impossible to use open source software in many interesting ways. Readline is a totally useless library for many projects, because the GPL license is poison; if it was LGPL or BSD, it would be ubiquitous. A normal, sane mind would be enthusiastic about that, about seeing their tool be used and make others happy.

And Stallman's not getting more sane with age, either. In a Groklaw interview, he says:

"Q: One final question. We're seeing more and more devices, and I'm thinking specifically of games consoles -- I know that my kids have one in the house -- where there is no --"

"Richard Stallman: I wouldn't. You have to learn how to say no to your kids."

"Q: That's true, that's true, I wouldn't deny it. Now, there is no free software at all for devices like this [correction: Yellow Dog supports some console(s)]."

"Richard Stallman: That's why there is no possible ethical way you could use one, and so you shouldn't have it."

Great. Now he's calling everyone who plays videogame consoles unethical. Is there no end to this blackguard's insults against people who just want to use some fucking software? As Thomas Becket asked, "Will nobody rid us of this turbulent homeless loser?"

But then, let's look at all the great games which were written as GPL... Oh, wait, there aren't any. If you're a totally obsessive GNUtard (or the pitiable child of such a GNUtard), you can't play any new games, only crappy ripoffs of commercial software. There are no equivalents to Nintendo or Square/Enix in the GNU world. Even id software, who always release Quake and Doom on Linux, don't do it as GPL. (Some developers, including id, do release end-of-life software years later as GPL, just as I do with BSD, but they weren't written and released under GPL initially). And why is that? Because if you release a game as GPL, someone else will give it away for free, and you'll go out of business. There will then be no more new games. At least with commercial software, you can fight the pirates with the law. But if you GPL your game, then the pirates are protected by the law.

Chris's thought that the GPL causes slow-downs in development of open source is exactly right. When have you EVER seen a truly innovative piece of GPL software? Everything in GPL is a bad copy of some other software that was developed under a commercial license or a true open source license like BSD. Worse, GPL software damages and even drives out commercial competitors; it doesn't have to be any good, it just has to consume resources, like rabbits in Australia or pigeons in any city.

  • Linux is a copy of Unix. BSD Unix is years more advanced than Linux, and MacOS X (which is based on BSD Unix) is 10-20 years ahead of Linux.
  • gcc is just another C compiler, and not a very good one. The Intel compilers compile significantly faster and produce faster and more memory-efficient code from the same source. I'm sure Borland's compilers are still faster and more efficient than gcc, too. There used to be many others, but the widespread availability of a shitty but "free" gcc has poisoned the market. There are alternative CPUs for which gcc is the only real compiler, but that's not a positive feature, that's a tragedy.
  • KDE and GNOME are hideous, difficult, and unstable desktop environments. I'm appalled that these are what pass for a desktop environment on Linux. While I have few kind words to say about Windows, at least their desktop is better than KDE. There's no comparison at all to Mac OS X. GNOME isn't even basically functional... GNOME is one of the worst pieces of software I have ever seen in my life.
  • The GIMP is... almost decent. It's not innovative in any way, it's still an inferior copy of Photoshop, but at least for once a GNU program isn't a complete piece of shit. I include it in this list because it shows the best possible result for a GPL program: not a complete piece of shit, but still a ripoff.
  • The FSF is trying to make "Gnash", a replacement for Flash 7, and it's apparently as attractive and functional as the name makes it sound. Adobe already has a free version of its Flash 9 player for Linux. Not that I understand why they bother; they get nothing but hate from the FSF and a lot of the Linux community for providing Flash and Acrobat, even though they give away free client software.
  • is scarily ugly and barely functional. Now, it's interesting that Sun's found a way to use GPL as a weapon against all other office suites, and put out this crappy free version and then charge for the slightly less terrible StarOffice version. But it's ultimately just another MS Office clone. Compare that to, say, Apple's iWork suite (Pages, Keynote); Pages is graceful and attractive and works in a very different way from Word. It's certainly not as complex, and that's a virtue. That's something that would never happen with GPL software.

Yes, there is bad closed-source software, too, every Microsoft product being the canonical example... But normally the market weeds them out, and for every bad closed-source commercial product, I can show you a dozen crappy GPL equivalents.

Because he lives in the Bizarro universe where black is white, up is down, and cats and dogs live together, Stallman doesn't even care about functionality or originality:

"Write letters to the editor whenever you see a newspaper or magazine praise non-free software, by judging it according to shallow criteria, only caring what job it would do and what's the price and not caring whether it respects your freedom."

Functionality is not shallow. Functionality is the purpose of software. To get the job done. To do it cost-effectively, efficiently, reliably, in an easy-to-use and attractive manner.

Whether or not you can modify a piece of software is meaningful only to a handful of programmers. It makes no difference at all to the users. To a working programmer, GPL software is useless, because you can't include it in your software at work. So the only ones who find GPL software's "freedom to modify" useful are bored college students and useless hippies.

Ultimately, the GPL is about restricting the rights of programmers to do as they wish with the software they write. Someone who loves liberty would allow and encourage every programmer to release their software under terms that they find acceptable for their own needs. For some people, that'll be commercial; for some, BSD. But if he had the political power, Stallman would put a gun to the head of every programmer and force them to use the GPL, and would put a gun to the head of every user and force them to only use GPL software. His motivation is to steal your software and make it part of the FSF, so that all new software development ends, all commercial software goes out of business, and finally the demon of jealousy screeching in his head can stop.

Stop giving a crazy person power over you. Don't use the GPL.

← Previous: The NetBeans Masochism Tango (Software) Next: Cocoa logging (Software) →
The NetBeans Masochism Tango
Fri, 2007Jul20 19:37:35 PDT
in Software by kamikaze

Okay, I've given up on IDEA. It's crazy piled on crazy, with just enough things working to make me not instantly reject it, but then it hurts me at every opportunity. Using Ant was such a chore, and reading my Ant output was so bad, it really wasn't viable.

It looks like I'm stuck with a not-very-nice Eclipse Europa. Maybe they'll fix the code completion focus bug someday.

As a last, masochistic exercise, I tried NetBeans. I hate Sun's constant lies and bullshit about NetBeans, and every time I've tried to use it or seen it used it was like like a boot kicking in my face, FOREVER, but I'm a desperate man, and my ideals can be bought with shiny software that works.

To forestall the usual "that's fixed in the nightlies, what, are you living in the dark ages?" responses Sun's shills give me when I bitch about stuff in NetBeans, I got NetBeans 6.0M10, the latest, best, most polished and awesometasticular version, so it should rock the house, yeah?

25MB for just Java SE, 103MB for J2EE with Glassfish and Tomcat. Okay, fine, I've got a healthy respect for Glassfish as a Sun product that doesn't suck, and I am all about the J2EE. The installer is... well, it's an installer. It works okay. I still like Eclipse's non-installer installation best, but it beats the shit out of JBuilder 2007.

As you might expect, the Swing GUI is uglier than 10 miles of ugly on a hot summer day. The file dialog is the Swing JFileDialog, which looks like Windows on every platform. Option checkbox trees show a full checkmark even if only some of the sub-elements are checked, instead of a highlighted dash as they should until every option is chosen; you have to expand the tree to see if it's really a full or partial selection. The editor pane tabs are glossy Aqua-like buttons instead of actual tabs and have a totally non-standard teeny little close x instead of brushed metal dark grey like Mac has used for some time; see Safari for how document-view tabs should look on a Mac. Aqua tabs are for control panels ONLY. As always, I come to the conclusion that nobody at Sun has the slightest trace of visual style, any comprehension of usability, or any comprehension of making a platform-specific GUI appearance. I can't tell if they're all blind, or perhaps if they only develop in BSD vi from the command line, and have never seen a GUI in their lives. There is no escape. There's no Quaqua GUI because this is a Sun app, and changing the Swing L&F won't help me any because all the others are even more hideous and just as unusable.

Also as usual, the key bindings are an unspeakable horror. Their idea of "Eclipse"-like keys is laughably wrong (binding Ctrl instead of the platform menu modifier, which is available and defined in the java.awt.Toolkit!), and things like Cmd-Y for Redo (instead of Shift-Cmd-Z)... Does anyone really use such stupid keys? Have they even heard of the Apple Human Interface Guidelines? If you're going to make an app that works on the Mac, make it work right on the Mac or don't bother.

Yeah, okay, so I'm a Condescending, Superior, Elitist Mac Bastard, and I'm proud of it. I don't like to use ugly, stupid software. Only ugly, stupid people use ugly, stupid software. I don't live in a cardboard box surrounded by rats and filth, I like to be surrounded by efficient, beautiful things, and I'm willing to pay well for it. Software that doesn't meet my "Insanely Great" standards gets my contempt, at best, and my absolute loathing at worst. You should never accept living in squalor... say, using Windows, or any of the ugly-ass Windows apps (as far as I'm concerned, the only two attractive and usable apps on Windows are iTunes and Safari), or ugly-ass Swing apps. Eclipse, for all its faults, actually looks and acts pretty nice, at least on the Mac. If not for this ONE GODDAM BUG...

Okay, so I make a new class, and of course I'm assaulted with this ugly-ass boilerplate:

 * Created on Jul 20, 2007, 6:17:30 PM
 * To change this template, choose Tools | Templates
 * and open the template in the editor.

I can't pick on just NetBeans here. Eclipse is just as awful. But here's the thing... Eclipse's templates are in the Preferences dialog. Everything configurable is in Preferences, because you pick Preferences to configure shit!!!. Where are the templates in NetBeans? Off in some other menu item, way away from Preferences. Not in the Java class template, even. It's under License | Default License. Yeah, that makes sense. The user hasn't specified license boilerplate yet, so let's fill every class with IDE spam until he does.

The code completion is beyond retarded. I start writing a paint method, hit and get completion:


Anyone see a problem there? On the bright side, the code completion worked quickly (a vast shock from NetBeans... are computers now so fast that even NetBeans is usably fast? I can't believe Sun did anything to fix it, because they hate users) and the hovertext shows the fields correctly named, but I want the IDE to help me, not create bugs for me to fix. There's no way to even turn this "feature" off and let me fill in the fields myself.

I try to go on, editing away, and NetBeans happily continues sabotaging me and writing gibberish in my code instead. So this experiment crashed and burned pretty quick. I'm sure there are thousands more horrors lurking in NetBeans, but since the primary function of an IDE--EDITING FUCKING CODE--doesn't work worth a damn, no point in even going on.


So I tell NetBeans to quit. It beachballs. It just sits there, squatting on my desktop like a sumo wrestler. DIE, NETBEANS, FUCKING DIE ALREADY! Had to Force Quit to close the damn thing. Oh, of course, it doesn't put its support files in Library/Application Support/NetBeans like any Mac app would. rm -rf ~/.netbeans ~/.nebeans-derby

Sun, you suck at writing IDEs. Please stop.

← Previous: Stuck in the IDEA Quagmire (Software) Next: The GNUtards Must Be Crazy (Software) →
Stuck in the IDEA Quagmire
Fri, 2007Jul13 10:24:21 PDT
in Software by kamikaze

My attempt to use IntelliJ IDEA is going slightly better than the war in Iraq, but perhaps not as well as peace in Palestine.

When you right-click on an object, say a filename in the project view, a user interface is supposed to act on the object you right-clicked on; hardly shocking news to anyone who's used a computer in the last 20 years. Instead, IDEA acts on whatever you last left-clicked. So now I have to learn to left-click, then right-click, in order to do anything. You could right-click anywhere in IDEA, it acts on the last thing you left-clicked. What kind of brain-damaged crack baby came up with this? Is this just Swing being retarded?

There's no equivalent to the Eclipse "Open With..." right-click option. What, IDEA never has multiple editors that could apply to a type? External tools appear way down at the bottom of a big-ass menu, and can't be associated with a file type, as far as I can see. I would never want to use an IDE's text editor for text or HTML documents instead of BBEdit, but I don't get that choice here.

Is there some law that IDE help systems have to be hideous, unusable pieces of shit? Obviously, Xcode is exempted from this; the 2.0 system was okay, but the 3.0 system is fantastic, especially with the context-aware help sidebar. Using IDEA's help system is like going back to the stone ages. It's like MS Help. And, hey, don't bother to wrap a big HTML document so it fits on a screen. It's okay to have a 2000-pixel-wide page! Fucking wankers.

Finding references takes forever. Goddamn, IDEA is slow at all sorts of stuff. I see that "Cancel" "Background" dialog way too much.

The equivalent of Eclipse's "Quick Fix" is "Show Intention Actions", Opt-Enter. Whew. For a moment there, I thought I'd actually have to USE THE MOUSE to correct errors. But if you do use the mouse, don't double-click on a "create method" fix! It'll totally screw up the placement and your code. Yet half the IDEA UI requires double-clicking instead of single-clicking, with no clear distinction.

Huh. Opt-Left/Right moves by word correctly in IDEA, not by CamelCase subword (and inconsistently between left and right) in Eclipse. That's a pleasant change!

The Structure pane keeps going blank on me, whenever I make changes that are temporarily invalid Java. Closing and reopening it refreshes it, but it's insane... I want to see the last known good code outline. That's how I navigate. Ah, "Show Members" button lets me see methods in Project pane, and that doesn't seem to have this problem.

The hover text is always on top of the thing you're looking at, not underneath it where it belongs. I think this is just the fault of Swing for being an ugly piece of shit and Sun's engineers for having less sense of style than a homeless person, nothing JetBrains did, but it's still really annoying and un-Mac-like.

You can't reorder editor tabs by dragging. I am happy to report that in IDEA 7, you can drag pane tabs around to reorganize, but you can't drag by title bar like any other MDI app.

The more I use this, the more I miss Eclipse's SWT-based GUI. Swing is an absolute piece of shit, totally unsuited to any serious task. Sun needs to quit throwing money at this garbage, get over their bruised ego, and adopt SWT. But not take it over, because they'd just fuck it up.

The Ant pane constantly hiding itself is a pain, and I don't need a giant sidebar for Ant. I NEED constant access to my Ant tasks. Ant is my life. Hitting Cmd-6, click the Run button is stupid. And the output window is terrible; it shows each task, not just the output. I like to be able to see my messages, not a bunch of noise. I've tried playing with all the little buttons on the Messages pane, and can't get it to do that. I've been forced to resize my IDE up, so it's harder to work with the browser now, but at least I can use Ant when I need it.

← Previous: Trying IDEA out of desperation (Software) Next: The NetBeans Masochism Tango (Software) →
Trying IDEA out of desperation
Wed, 2007Jul11 19:38:40 PDT
in Software by kamikaze

Next up is IntelliJ IDEA. Download is only 66MB, which is a nice change. I would note that neither CodeGear or JetBrains web sites detect your browser to show the correct download, which is somewhat incompetent.

The first quote on the front page of IDEA is... not that inspiring:

While I'm currently using Eclipse 3.3M5 at work and at home, I've used IDEA a few times and found it more intuitive than Eclipse. It came up in a conversation with a couple of other developers: From time to time, while using IDEA, it would do something, and we'd ask, "How did it know to do that?!?" We decided to call it mind reading.
-Jeff Grigg, Steering Committee for the St. Louis Java User Group

So the best customer testimonial they can get is from someone who doesn't like it enough to run it, has only used it a few times. That is sadder than a box full of abandoned basset hound puppies in the rain.

IDEA comes as a standard Mac DMG file, and inside is just the .app, like any sane Mac application. Drop it into my Applications folder, run it... and nothing happens. I check (again, I'm a Unix geek, not a normal person), and see that it's crashed:

Jul 11 17:09:33 75-92-175-249 launchd[81]: Background: Aqua: [0x0-0x41041].IntelliJ IDEA 6.0.5: posix_spawnp("/Users/mdh/Applications/IntelliJ IDEA", ...): Bad executable (or shared library)

Google leads me to this: IDEA 6.0 does not officially support macosx 10.5 Leopard (as of 25 Aug 2006!!!), still with no resolution. Fortunately, there's also a quick and dirty bugfix from Hani of the BileBlog of all people. I do that, and it runs. That's STUPID, and does not give me much confidence in these people, either.

Oh, hmn. There's a 7.0 milestone, should I try that? I'll download and compare when that's down.

But I already have 6.0.6 downloaded and fixed, let's see how that goes. The new project wizard goes on FOREVER. Great Cthulhu, people, it's okay to have more than a couple fields on a screen! Really! NEXT. NEXT. What the hell is a "module"? NEXT. NEXT. Finally I have a project up. Ugh.

The editor is weird. Clicking in whitespace past the end of a line... puts the cursor there. There's no text there. There's no whitespace there. It's just void, it shouldn't hang there like that. I want to click past a line and get cursor at end of line, like in every other editor I've ever used in my life.

IDEA has *14* application-specific menus. It covers up some of the menu bar gadgets I use, and my screen's not that small. A normal Mac app has 3-6 menus. BBEdit has 15, but 5 of them are symbols so they don't eat much space (and I wouldn't usually recommend copying BBEdit's appearance!)... Buttons and look-and-feel aren't very Mac-like. Ah, here in Appearance prefs, you can change it to "Quaqua", which looks a little better. At least the preferences window looks like someone with some visual style was involved. Oh, good: Editor | Virtual Space | Allow placement of caret after end of line, uncheck, no more insane clicking in places where text cannot exist.

Code completion works nicely. I was actually able to type what I wanted and get it completed. Woo! Huh. Cmd-D is "Duplicate line". Cmd-Y is my good friend, "Delete line". Oh, that'll be a painful muscle memory to change. Cmd-F4 is close active editor. Uh, no. That's the most moronic Windows-centric thing I've ever seen... Oh, and that's what they call their "Mac OS X" keymap. The others are far worse. The "Eclipse" keymap doesn't seem to be much like Eclipse, and doesn't have any way to close the active editor! Wow. These may be the worst key bindings I have ever seen in an IDE. Is this a joke? Do these people just not use the keyboard, and so have never realized how awful this is?

At least I can make my own keymap. Gah. I'll be screwed if I ever have to use anyone else's machine, but I guess I can put my keymap on my site somewhere. Bah, nobody's made a BBEdit clone keymap. Oh, thank fuckery, Simon Harris already asked this. Copied it into Library/Preferences/IntelliJIDEA60/keymaps/, restarted, and I have Happy Fun Cmd-W Action, just like any other Mac app.

How do I move docked panels around? In Eclipse, you can just drag where you want. Oh, huh. Right-click, Move To. How quaint. How very 20th Century user interface of them. You apparently can't get multiple widgets to share a side. I'm accustomed to having a little Ant pane under my Project pane. I have to use pop-out slider windows in IDEA.

Ah, the 7.0 download is done. Run that, same crash, same fix. STUPID.

Import from my 6.0 preferences, including the modified keymap, went fine.

I guess I can work with this for a while, see how it goes. It keeps up with my typing, and code completion isn't a pain in the ass. So far I'm not happy with it, but it sorta works.

← Previous: An Eclipse by any other name would be as dark. (Software) Next: Stuck in the IDEA Quagmire (Software) →

Well, it didn't take long to evaluate "Turbo JBuilder 2007".

First, when you unpack the behemoth 400MB download, you get a directory full of files. Somewhere, buried in there, is an install.html. So I read that, and find out I have to run a shell script. What? On the Mac? Okay, I don't care, is always running, always visible on my screen, but I'm an old Unix geek. Normal Mac developers are going to look at you funny. So I run it, it creates a jar file, which pops up a Java install/visit web site panel, which creates a Mac package-installer... which finally installs JBuilder. Let me just point out something here: the Eclipse installer? You unarchive a directory somewhere and run the binary. The JBuilder process just looks amateurish.

So I get it started. The Welcome screen doesn't work. None of the links do anything. Even the "Return to Workbench" icon does nothing. All I can do is close the Welcome tab, and see the fully glory of Turbo JBuilder 2007...

It's Eclipse 3.3 with the current crappy editor, and a ton of plugins. Now, I appreciate a good collection of plugins as much as the next guy, that's why I usually use MyEclipse, but MyEclipse is only $30/year.

I'm sure JBuilder has lots of neat visual stuff for RAD, but as an actual Java IDE, it's just Eclipse. They didn't do a damned thing to it, that I can see.

Worse, the giant collection of plugins they've put in there slows it down. Eclipse was a bit of a pig before, but with JBuilder I saw nothing but spinning beach ball.

I was hoping they'd ported the old JBuilder editor, or at least made the Eclipse editor suck less. No luck.

Sorry, CodeGear. Not interested now. Maybe you could actually work on the Java programming experience in your Java programming environment...

I've been using Eclipse's new release, Europa, for a few days now. And I'm about to punch someone in the face. The Ant editor has hung on me several times, forcing me to "Force Quit" Eclipse. The codesense dialogs now steal focus and puts it in the MOTHERFUCKING JAVADOC PANE, not the method pane, and won't let you finish typing a method name. So you have to use the mouse to select what you want. My hands should never be reaching for the mouse while typing code. There are a ton of other little things that bug me, but that's the one that's driving me insane. I'm working about half as fast with this piece of shit, and getting so frustrated I have to go take a walk, so I'm about 25% productive with it.

Screw this. If I'm going to be unproductive, I'll look at other IDEs. I don't care if it's free or commercial, it has to be good. I'm perfectly happy to pay for quality software, just as I'm happy to get paid for my software!

JBuilder 2007 is out now for Mac OS X (when I tried it, the HTTP download link was broken, but FTP worked; hopefully they'll have that fixed soon)! They have a free "Turbo" version and the Professional and Enterprise editions. I don't mind paying for a good IDE, and the old versions always used to be worth at least $500. CodeGear hasn't done a good job getting this news out, though. I only know about it because I went back to their site to check if it was on Mac yet. I hadn't heard anything on the Web. MARKETING, guys, you can't sell licenses without marketing!

I've never been too taken with IDEA in the past; while I have friends who are fanatical about it, I think it's just an okay IDE, but not particularly awesome. My brain was wired for IDEs by VisualAge for Java and JBuilder, and IDEA's just weird enough to be awkward for me. But if I'm not thrilled by JBuilder I'll give that another shot.

I'm not interested in hearing how NetBeans is 50% less shit than it used to be, it's still shit, and I ain't having any. I've seen Sun's own engineers struggling to use it to do basic tasks, and it was sad and pathetic.

I wish Xcode had better Java support. It's a fantastically good C/C++/Cocoa IDE, and the stuff I can't tell you about from WWDC07 is FANTASTIC, but really does not do Java well at all.

Are there other Java IDEs I should know about? I don't need student toys like BlueJ, and even awesome editors like BBEdit are not a substitute. I need an industrial-strength Java IDE that doesn't suck.

← Previous: Karl Fant Reconsidered (Software) Next: An Eclipse by any other name would be as dark. (Software) →
Karl Fant Reconsidered
Sun, 2007Jul08 07:21:25 PDT
in Software by kamikaze

Karl Fant has released a rather ridiculous new book, "Computer Science Reconsidered: The Invocation Model of Process Expression", apparently a 45x longer version of his 1993 paper "A critical review of the notion of algorithm in computer science" (ACM membership required to read the paper, but if you're not in the ACM, you should be).

I won't be wasting my money on the book, but the paper is presumably representative of his soi-disant logic.

His first claim is that Alan Turing and John Von Neumann "infected" computing with mathematics, just because they happened to be mathematicians with a bent for algorithms when they worked on early computers... This is equivalent to shouting "conspiracy!" because all bridges are built by civil engineers, and all maps are made by cartographers. A computer is a mathematical device. There's nothing here but numbers, being manipulated in a small number of ways in a deterministic, step-by-step process. Who else but a mathematician is going to be able to design and analyze one? Ada Lovelace, a mathematics student and the first programmer (albeit for a computer that was never built) independently came up with very similar algorithmic processes and expressions. This is an inevitable result of trying to accomplish anything with computers.

His next claim is that a mathematician's algorithm is the abstract "expression of a process"--the semantics, though he's unable to articulate that distinction--and that computer science is really about language expression--the syntax:

Mathematics is primarily concerned with the nature of the behavior of process independent of how that process is expressed.

The nature of a process is independent of its expression.

Computer science is primarily concerned with the nature of the expression of processes regardless of what particular process might be expressed.

The nature of an expression is independent of its process.

-Karl Fant

His description of Computer Science there is entirely wrong. Computers do not execute our nice high-level languages. Our syntax is only for our own benefit. We use compilers to reduce our human-readable syntax down to what we call machine language, the bytes in memory itself, but even those aren't really what gets executed, they really become microcode, which is then executed. The syntax we use has nothing to do with the final syntax of the executed code, but the process that we specified, the semantics, are carried down to the lowest levels of logic gates. Real Programmers can work down at the machine code and mechanical limits level of hardware, but the rest of us work at an entirely different syntactic level, and yet we're able to make working code. This can only be possible if the process is independent of the expression, if semantics are independent of syntax.

Fant's next blunder is deciding that only the strictest mathematical sense of "algorithm" can be used:

  1. An algorithm must be a step by step sequence of operations
  2. Each operation must be precisely defined
  3. An algorithm must terminate in a finite number of steps
  4. An algorithm must effectively yield a correct solution
  5. An algorithm must be deterministic in that given the same input it will always yield the same solution

-Karl Fant

Here he shows a gross misunderstanding of how computer science uses these terms.

  1. This is absolutely true, because computers operate in a step-by-step sequence of operations.
  2. This is absolutely true, because computers are extremely literal machines.
  3. The requirement for a finite number of steps allows for a very large, unbounded finite number of steps. A program must be stoppable, even if only by interrupts (which are a well-defined input, even though implicit). An operating system must have the ability to be shut down. We know that in reality, there are also hardware failures, the sun could go supernova, etc., but that's outside the scope of algorithmic analysis.
  4. Correctness does not mean the answer is right, only that it is logically consistent. As with any logical system, if you put garbage in, or if you have a bug in your algorithm, you get garbage out.
  5. An algorithm simulates "random" inputs by use of the Universal Turing Machine's "infinite tape". Given the same inputs, whether from "random" sources or not, it is absolutely true that a computer will always give the same outputs. Those outputs are not in a single number "solution" in most cases, but instead consist of further changes to the "infinite tape", writing to devices, etc.

So what's the purpose of an algorithm? Analysis. By refining your function definition down to an algorithm, you can determine how long it will take to complete, whether there is always a path to termination in it (whether it will take that path to termination is indeterminable, but the existence of the path must be provable). You can't do that by just proving that the syntax is correct, as Fant seems to think. You can't do that without formalizing your logic; not all expression systems are equally useful for all tasks, but it is always possible to translate from one Turing-complete expression system to another. If you can't analyze your algorithms, you will write slow, crappy code.

And at the bottom, that's what it's really all about: producing efficient, reliable code.

Hephaestus 3 Wish List
Mon, 2007Jul02 09:55:10 PDT
in Software by kamikaze

I've been getting a number of good suggestions for Hephaestus 3, but I'd still like some more feedback.

  • Containers (backpacks, etc.) and item encumbrance. Now you won't be limited to just a couple dozen items.
  • An easy command for displaying large image dialogs, maybe movies with QuickTime For Java. Yes, I know QT4J doesn't work on Linux, but it's the only high-quality media player for Java; as I did with sound, I'll have some way to launch a command-line app to play media as an alternative.
  • Skills, replacing the non-magical "magic" sometimes necessary in a game (e.g., the 0 MP spell "Map" in Umbra). I don't want to fall into the design morass of NetHack and such where there are hundreds of commands, each one equivalent to Use or Magic, but one more command won't hurt.
  • World maps and level map memory without lots of custom coding. Any tiles a player sees will be recorded and be shown when they pull up the map. This will happen without any work by the adventure author. To make the world map, every map will have an image and location to place it on a "World Map" map that should never be visited by the player. So by placing the Pit of Eternal Stench image at 1,1 and Buttercup's Castle at 5,5, and a windy road image at 3,3, it becomes clear how to get there from here.
  • The map editor could be better, but I'm not sure I know exactly what "better" is. Specific suggestions? Are there glaring defects in it I should fix first? I'm afraid it's a bit of a blind spot for me, as I mostly make randomized map generators; the few times I've really used it, it did what I needed but certainly wasn't a great experience.
  • Around 95% of my bug reports are: "I'm on Windows, and I can't get it to launch!". The few times I've tested on Windows, it worked just fine for me, but I am pretty much the definition of "Not the Average User". At this point, I either need a better launcher, or I need to just say "Windows is unsupported, I only support Mac and Linux". If anyone has a better approach than what I do now with heph.bat, let me know, but it has to be a solution I can compile from my Mac. I'm going to take another look at Java Web Start, but it's been pretty hard to get working previously. I suspect anyone who has trouble with it now, will still have trouble with Java Web Start.
  • I'd like to have customized control keys as much as anyone, but this is hard to do in Java using the AWT graphics library (which is considerably faster than Swing). If there are alternative keybindings for the existing actions you'd like, I'm willing to add more; right now, for instance, the numpad, roguelike (hjkl), and arrow keys all work for movement. If there's specific requests for rearranging the key layout, I'd like to hear them. I mostly play with the roguelike keys, so maybe they're harder to reach for people with their fingers off the home keys? Would putting various actions on PgUp/PgDn/Ins/Del be helpful?
  • When it's released, I will be hosting an adventure design competition, with real cash prizes for quality work! I haven't decided on exact amounts, but at least $100 for 3rd place, and up considerably for 2nd and 1st! If I get Hephaestus 3 released by end of this year (as seems most likely), the competition may run through summer 2008.
← Previous: Software Gallery (Software) Next: Live Earth (Media) →
Software Gallery
Mon, 2007Jul02 09:50:04 PDT
in Software by kamikaze

Items on my to-do list do get done eventually... It can just take a while. For instance, this morning I updated, my software gallery. I had been using a cruddy text index page for a couple years. Now it shows a nice organized summary of my freeware games and utilities, with screenshot "box covers", so you can figure out what they are. Fancy!

← Previous: Safari for Windows (Mac) Next: Hephaestus 3 Wish List (Software) →
Java Code Style
Wed, 2007Jun06 10:38:49 PDT
in Software by kamikaze


Adam Ring (ABCGi) writes:

I love to see code posted, its a great way for people to learn to code properly... but many programmers are afraid of the criticism they might get from better coders - which means they don't learn - and why they often won't even ask co-workers for help. Do you reckon this is more/less readable or the same? It does take up more vertical space though.

public void openFileInEditor(File file) throws MyFileOpenFailedException
	List lines = new ArrayList();
	BufferedReader in = null;
		in = new BufferedReader( new FileReader(file) );
		String line;
		while ( (line = in.readLine()) != null )
	catch (IOException e)
		LOGGER.log(file, e);
		throw new MyFileOpenFailedException(file.toString(), e);
		if (in != null)

That's how I used to indent code, too, but co-workers finally convinced me to switch. The Sun Java style guide specifies how Java code should look, so it's always consistent between developers. As soon as you work on a team with source control, consistent style becomes very important, far more important than individual preference. Merging code with whitespace changes is a pain. Reading code with randomly-varying indentation styles because 10 different programmers have used their own styles is a pain.

One nice feature of the inline braces is that if you always use braces (and you should, as it prevents errors), your eyes can just skip over them and read the code by indentation and keyword, as if it was Python. It simplifies your brain's internal Java parser.

A very contentious point from that style guide is:

4.1 Line Length

Avoid lines longer than 80 characters, since they're not handled well by many terminals and tools.

Note: Examples for use in documentation should have a shorter line length-generally no more than 70 characters.

I thoroughly agree; it's miserable merging code in a side-by-side comparison editor with more than 80 columns, you don't have room to expand out a class in the Package Brower in your IDE of choice with a wide editor, and people with decaying eyesight like me can't use a proper-sized font. But I've had long, bitter arguments with co-workers over it, some people are just absolutely devoted to using hundreds of columns in Flyspeck 3 font. Needless to say, I'm right, and they're wrong, and the standard supports me.

It sounds ridiculous to have arguments over such trivial matters as whitespace, when any IDE can reformat text on the fly, but that's what we get for having multiple syntax representations for language semantics. Python at least only has the argument over how many spaces or tabs to use per indentation level, and considers it a error to mix tabs and spaces.

I must confess, I'm doing something bad in my examples. I'm using one tab per indent level. Java standard is 4 spaces, with 8-space tabs. But Eclipse uses 4-space tabs, and it's impossible to configure it correctly, so I always indent Java code with tabs now, and it just looks ugly anyplace that handles tabs correctly. Yeah, that sucks.

The main place I send people to look for good code examples is in popular open-source projects. Tomcat's pretty good internally, though a bit too complex. The source code for all Java libraries is included in $JAVA_HOME/src.jar, and Sun does a great job of consistent style, efficiency, and thread-safety.

← Previous: Checked Exceptions in Java (Software) Next: Review: Dario Argento's Opera (Media) →
Checked Exceptions in Java
Fri, 2007Jun01 13:37:15 PDT
in Software by kamikaze

This is a long, serious, technical Java post. I promise that my drunken, hostile ravings about how much Hollywood sucks will resume soon.

Elliotte Rusty Harold is asking for people to vote for checked exceptions. +1. This is an argument I've had many times, and expect I always will, because it's about competing, incompatible philosophies.

There are two schools of thought about what a language compiler should do. The first is fully dynamic, where the language only enforces syntax and knows nothing about semantics; all error-checking is done at run-time. In Python, for instance, any object could respond to any method call, you don't know anything about the type of a variable at compile-time, you don't know anything about what exceptions it returns. This is great for rapid application development, if you're very smart, and aren't making anything huge and interconnected. But it is incredibly hard to develop and maintain a large application in Python, because there's no help from the compiler about method calls, no help about what exceptions are raised. When writing dynamic code, you spend 90% of your time reading documentation and writing unit tests to make sure you can actually call every stupid accessor function. Refactoring in a dynamic language is almost impossible; when you've renamed a method, how do you know you've found all the references to it? I love dynamic languages for making small tools, but it's insane to use them for big applications.

The other philosophy is fully static, where the compiler knows everything about the objects you're calling, and can tell you if you didn't pass enough parameters, or if they're the wrong types, or if you didn't handle an exception that's likely to happen. This means just banging out some code takes a little longer, because you have to get it right before you can run it, but it also means the code usually works the first time. You can concentrate on real functionality in your unit tests, because the compiler checks that the interface matches. Java is a static language, though it gives an escape hatch with reflection; you shouldn't use that unless you absolutely have to, though. Static compiling powers the great Java IDEs. Static compiling makes refactoring code trivially easy, because the compiler will tell you if you didn't finish renaming methods.

Checked exceptions are an important part of this process. Consider this code (hypothetically, from a text editor):

If IOException Was Unchecked:

public void openFileInEditor(File file) {
	List lines = new ArrayList();
	BufferedReader in = new BufferedReader( new FileReader(file) );
	String line;
	while ( (line = in.readLine()) != null ) {

What happens when file doesn't exist? The exception's thrown up the stack, probably crashes your app because you didn't bother to deal with it, since the compiler didn't force you to. The input stream is still open, using up resources until you kill the program. Your unit tests didn't catch it, because you only did a happy path test. If it's a desktop app, suddenly the window goes away, if it's a webapp, the container catches it and shows an ugly stack trace page (and the FileReader's file handle won't be closed for days, maybe months, until the app server is restarted).

IOException Is A Checked Exception:

public void openFileInEditor(File file) throws MyFileOpenFailedException {
	List lines = new ArrayList();
	BufferedReader in = null;
	try {
		in = new BufferedReader( new FileReader(file) );
		String line;
		while ( (line = in.readLine()) != null ) {
	} catch (IOException e) {
		LOGGER.log(file, e);
		throw new MyFileOpenFailedException(file.toString(), e);
	} finally {
		if (in != null) {

Sure, it's a bit bigger and more verbose. But now it's solid; you know what's going to happen in both the happy and unhappy paths through the code. There's not much that can go wrong. It doesn't have obscure, undocumented dependencies on other code cleaning up after it. The thrown exception is just a message back to let the calling code know it didn't work.

I thought people had learned this lesson already from the monumental security disaster that is C and C++: any error the compiler doesn't force you to resolve, most programmers will ignore. How often do C programmers really do all the error checks on every function that can error? Basically never. I've seen some Python implementation code that does, and it's insane, 10-20 levels of indentation to resolve all the possible errors and then back out of each item. C/C++'s totally optional error handling is largely responsible for how terrible most software is. Any argument of "a good programmer will..." is false, because even good programmers don't do it unless the compiler forces them to, and most programmers aren't good (90%, according to Sturgeon's Law, but I think it's more like 90% of programmers are barely literate, forget about getting the 1% who actually think about computer science).

Checked exceptions force you to acknowledge that the world is not perfect, that things can go wrong, and deal with it. They're "exceptional" only in the sense that they're not the happy path, but they should be expected to occur in the normal course of events.

Unchecked exceptions are for truly exceptional situations. NullPointerException, IndexOutOfBoundsException, and perhaps a few others are the only legitimate unchecked exceptions. IllegalArgumentException is borderline; you really should use an application-specific exception in its place, but an AssertionError is reasonable for internal methods that "can't" ever be called with wrong arguments. I'd really rather that Java didn't have RuntimeException, and instead used Error for the few cases where it's legitimate.

← Previous: Very Special Episode of Studio 60 (Media) Next: Java Code Style (Software) →
The Vicious Cycle of Game Development
Mon, 2007May28 00:49:21 PDT
in Software by kamikaze

Brandon Van Every asked on gamedesign-l how long solo game developers take to get things done.

The core of Hephaestus 1.0 was started on 2001Nov12, and I announced a first beta on 2001Nov21. Admittedly, I was reusing a scripting language I'd already written, and some app framework code from another program I'd written, but still wrote a complete and mostly functional CRPG system in 9 days. I started my Hades adventure for it in 2001Nov23, and was done on 2001Dec13. I continued working on it until 2002Apr. It was shareware (only registered users could save), and I got a thousand-odd registrations over the next year or so.

Now, that doesn't count any of the design time, scribbling into notebooks, deciding I could play through an old console RPG again just to get in the mood, drinking, etc., which took months of preparation before that. Also doesn't count the dozens of half-finished, not-quite-what-I-wanted games which I've never released... I try to release everything in beta as soon as it's even vaguely usable, to get user feedback, but some don't make that cut.

Umbra (the Python edition) took me from 2001Mar17 to 2001Jul14 before I more or less gave up on building games in Python, but again there were months of design before that.

Looking over the history of my other games, I see an obvious pattern:

10 Fuck around aimlessly for 3d6 months
30 Heads-down development for a few weeks to months at most
40 Release
50 Apathy
60 GOTO 10

If I got a regular paycheck out of it, I might be more inclined to continue the heads-down mode and produce something really awesome. As it is, I make games when the mood takes me, for my own fun and artistic expression, and if someone else likes them and maybe even tosses some money in my tip jar, that's a sweet bonus. I see very similar behavior in a lot of artists in other mediums, so I suspect it's inherent to the limited human brain.

Another part of it is the technical limitations I've been fighting. Java and Python are great languages, but they have piss-poor support for graphics and sound, which makes games hard, and eventually I get depressed and quit. I'm currently shifting into Mac programming with Cocoa (Obj-C 2.0 has garbage collection, hooray!), and it's very refreshing to not have stupid technical limitations; the only limits I have right now are how fast I can learn new tech (or old tech I've forgotten, like OpenGL).

← Previous: NULL, nil, None (Software) Next: RSS feed (Personal) →
NULL, nil, None
Sun, 2007May27 09:37:34 PDT
in Software by kamikaze

ENOUGH, already, language designers. Pick one set of words for "null", "true", and "false", I don't care which (I think Java's choices are pretty good, but anything consistent is fine with me). I frequently switch between Java, Python, and now Objective-C. The syntax changes are fine, they make each language distinctive enough that I can switch into thinking in that language. The libraries aren't that hard. But the little stuff is driving me crazy:

Language null true false
Java null true false
Python None True False
Objective-C nil, or NULL, or [NSNull null],
depending on context
C NULL anything except 0 0

Objective-C is psychotic. It's a Smalltalk dialect built on top of C (and for the most part, it got the good bits of both and left out the bad bits), so I can understand having nil and NULL. [NSNull null] is just stupid. Obj-C lets you instantiate arrays like [NSArray arrayWithObjects:@"Hello", @"World", nil], using nil as an end-of-array marker because C's shitty varargs implementation doesn't know how many args you passed. So it has this extra "null" object that's not really null. A few more moments thought when designing the Objective-C language would have solved this problem.

7 Habits Of Effective Text Editing 2.0
Fri, 2007May04 10:44:58 PDT
in Software by kamikaze

Bram Moolenaar, the world-famous creator of Vim gave a Google tech talk, 7 Habits Of Effective Text Editing 2.0.

If I was still using Vim all the time, this would be awesome. For technical people on Linux and Windows who don't yet use Vim, you MUST watch this. It will make you vastly more efficient at working with text (source code, HTML, or even just plain ASCII like blog posts).

However, I'm mostly using BBEdit these days. It only works on Mac, of course, but that's not a problem for me. I almost never touch any other OS anymore. I have a Windows box at work that I use for Outlook. This site is still run on FreeBSD, so I use Vim for some stuff there. Otherwise I only work on Mac.

The thing that strikes me about this talk is how complicated and fiddly Vim is, and how hard it is to do advanced things with it. It's a fantastic editor, compared to anything else on Linux or Windows; it blows even KATE and Notepad++ out of the water; emacs is equivalent in power, but you have to be insane to use emacs. But BBEdit is just so much simpler, and much more powerful. You can easily write Unix shell scripts as text filters, or AppleScript as text filter, or to manipulate and control the entire editor. The Clippings and Markup menus, and the Preview in BBEdit/Safari/Firefox commands make writing HTML source insanely easy. The code folding is easy to use and looks pleasant, unlike Vim's. The BBEdit documents drawer and the disk browser make it easy to work on giant sets of files, which are difficult to manage in Vim.

Vim doesn't update very often, and doesn't seem likely to get much easier to use. It's open source, so it's difficult bordering on impossible to make money from it. Bram asked for donations to live on while working on Vim 7. Now he works for Google, and gets to spend some time on Vim, but doesn't really have time to add major features. Vim is one of the most polished and professional open source programs ever made, but it's still very crude.

BBEdit is a profitable, closed-source program by a software company; sure, it's $125, but it's worth every penny if you work with text a lot. They update it regularly with new features. The documentation is more than just a command reference. It's one of the most solid pieces of software I've ever used.

This is just another chapter in my long disillusionment with open source software. Photoshop makes The GIMP look gimpy. Mac OS X makes Linux look like the random scribblings of autistic college students (oh, wait, it is). Yeah, I like free stuff. But I like good stuff even more.

Page:   0    1    2    3    4    5   Archive  
Feedback  | Key: ] =local file, * =off-site link  | Copyright © 2003-2010 by Mark Damon Hughes | Subscribe with RSS 2.0