So, you're chugging along but don't see the light at the end of the tunnel. Are you supposed to keep chugging (don't quit!) or "be very quick to change"? Hm.
I think the one I've heard goes, the artist is imagining the sculpture beneath that lump of marble, and they explain the actual creation of it as just removing everything else that's not the sculpture.
I saw David in Florence, and I was amazed to see that they also had on display the prototypes for David. There were 3 or 4 or so. From memory, they were all massive blocks of marble, though some just had an arm or leg sticking out. I guess these are called "studies" or drafts. A bit more heavy-weight than a study for a painting.
If he could permit himself to start over several times, I can too.
If you read about small-scale game development, this is a common practice. Danc (http://www.lostgarden.com/) talks a lot about rapid prototyping. Since games have a clear but poorly-defined goal (they have to be "fun"), it's easy to make a limited product around a proposed method of finding that fun, and then either going along with it or throwing it out if it doesn't seem promising. Thus, you can (and probably will) start over several times before making a complete, polished game.
I agree with your points, though I keep coming across variants of rapid prototyping in different fields; and as Fred Brooks told us "build one to throw away".
Is it possible to have a "clear but poorly-defined goal", or are you having a joke? "Fun" is an emergent property - recognizable, measurable but the creation isn't formalizable (though BTW your link mentioned something about game grammars...)
Clear, meaning: we want our games to be fun. Startups also have pretty clear goals: make something of value and make tons of money while doing it.
Poorly-defined, meaning: one man's fun is another man's boredom, it's hard to pin down what exactly "fun" is. Thankfully, though, there are many good educated guesses, so we can't act like "fun" is impossible to define.
The interview by chromatic was quite informative. Unfortunately, they say that they're forced to repeatedly reinitialize the perl interpreter with every request. This would seem to defeat the purpose of having a persistent perl, no?
It was the safe and easy install for shared hosting providers plus the easy deployment for web devs.
Really, it's a simple recipe. I'm still wondering why Perl/Python/Ruby/$fave_lang doesn't just mix together the same ingredients and do the same thing.
The rule I try to follow is to keep things as simple as you can. So, the levels of complexity for writing an app might look like this:
Level 1: command line program. Usable for yourself and others who know their way around the shell. Great for simple tools.
Level 2: Desktop GUI. More complicated, but necessary when you have non-technical users.
Level 3: Webapp with simple browser interface. When you need a GUI and need to allow access to many users all at once (possibly access to the same instance of the app). Drawbacks are that it's slow (much slower than a regular desktop GUI app) and relatively clunky. Also, you need a webserver to run it on, and the setup time that goes along with that. Also keyboard commands probably won't work and so there will be a lot of mousing around for the user.
Level 4: Webapp with some kind of Ajaxy or Javascripty client side. So, you need this even higher level of complexity when you have non-technical users who demand a prettier interface but the app also needs to be usable by lots of people on the net at once. Drawbacks are the same as with a regular webapp but also include a much more complex design, more maintenance, and more testing with different browsers.
The rule is, you don't go up the complexity ladder if you don't have to.
Unfortunately, I don't think I have the chops, nor the time right now. (But, fortunately, it may not even be necessary... see below.)
"Other than doing your own, I think the most sensible choice is wxWidgets, which, from my point of view, only has one big problem: the API"
That's a biggie. :) In fact, I'd go so far to say that if the API in unpalatable, then you should keep looking. Otherwise you'll end up just procrastinating every time you've got to deal with GUI code.
Thanks to posts in this thread (thanks Baltar!) I'm taking a much closer look at the most recent release of Tk (8.5). Given recent developments, it doesn't seem to be as "vestigial" as I'd thought. And the fact that it's implemented in Tcl instead of C may actually be a hidden benefit. And really, app developers never even need to be aware of the Tcl'ing going on under the covers. :)
IIRC, FLTK had their 2.0 version in the works a long time ago ... and it just kept being in the works. They just never left their 1.x series. Was their redesign doomed to never replace 1.x?
