FlashDevelop is a donationware IDE for Adobe's now-open source Flex framework--basically Flash for programmers instead of animators. Between the two, you can make Flash-based software for free now, which is kind of a big deal. Maybe everyone already knew this, but I was surprised by it. Pleased, granted, but still surprised.
At this point Flash seems to have achieved what Java wanted to be: a slick, machine-portable, Internet-aware programming language with an unbelievable level of market penetration. It also has the advantage of a runtime that's very small compared to a JRE. Java has managed to achieve a valid niche as a server-side technology, but it's not much of a force on the consumer side any more.
But the weakness of Flash has been cost for the development tools, as far as I have been concerned, and I'm sure lots of other people feel the same way. You can develop Java for free, and you don't have to use a command line any more. You can get a limited copy of Visual Studio (pick your variant) for the price of a download. But Flash is what, $600 nowadays? Even Flex Builder is at least a couple hundred bucks. Moreover, Flash (the app, not the API) is truly terrible for programming, what with that weird floating psuedo-window and its continued dependence on the timeline.
Which leads me inescapably, knowing people as I do, to the conclusion that a great deal of Flash's popularity has been built on pirated copies of the software. So it was probably only a matter of time before Adobe decided to open the software up with a free/cheap version, simply reserving some of the goodies (bonus UI components, for example) for paying customers. Which is, as far as I can tell, exactly what they've done.
Anyway, the politics of it aside, you can make Flash for free now. This is a very good thing. I'm guessing they'll screw it up any day now.
My Internet claim to fame, before I started plastering my name all over this mountain of wandering ASCII, was as a coder in a very small corner of the PocketPC gaming market. Quake had just been ported to Microsoft's first usable mobile operating system, which was a big win, but I couldn't run it. At the time, PocketPCs were much more powerful than the Palm device where I'd started, but they were also much more expensive. To save money, some OEMs were making using cheap greyscale screens instead of the color versions that were more common. Greyscale was actually an advantage for some users, because the battery life was longer, but it used a 4-bit screen depth (like the original Gameboy) instead of 16-bit color. As a result, applications that weren't written to handle the lower scale would overwrite video memory with four times as much information, all incorrectly formatted, and the device would crash.
I was just a student, so I had to dip my toes into the WinCE market with one of the lower-end devices from an eBay auction. And while I was content to grin and bear it when the best commercial games would only run on color devices, Quake was open source. So I got a copy of the compiler and started mangling the video code until I created a version that would run on both devices. The conversion was tricker than I had initially figured (the buffer was actually addressed in landscape mode, so I had to write non-adjacent pixels to each byte when in portrait), but I managed to blunder through. It wasn't perfect (I had a bug in my lookup tables, and very bright colors would turn black), but it was a hit in the small community of users who used the same devices. I followed up with a replacement for the PocketPCs game .dll (which told software where to locate video memory and directly access the buttons) that would automatically convert color games to greyscale, even if the author hadn't done any work, by creating a virtual color screen and converting from there.
I could do all of this, even though I didn't (and still don't, really) know anything about the Windows API, because Windows CE would give considerable leeway to programmers. If you wanted something onscreen fast, you didn't waste your time trying to get the OS to draw it for you. You grabbed the screen memory and wrote the bytes yourself. This was a low-level hackability that the PocketPC shared with Palm, although the latter was even more primitive (and therefore even more fun to code on). PocketPC does, after all, have several great modern features--multitasking, protected memory, error collection--that always felt like they were in my way. On a Palm, the OS was laid open. You could ignore the proper way to code, disrespect the other programs, and have your game largely take over the machine. As a user, it was an often unsatisfying platform, but as a programmer it was a blast.
The reason I started to think about this was because there's word that the Apple iPhone won't be able to run third-party software. Well, that's not entirely true. I expect that a few months after it's out on the open market, or as open as a $500-with-expensive-contract phone can be, someone will have hacked it open. Eventually, you will be able to play Quake on it--everything plays Quake or Doom, given time, even if no-one could ever imagine such a thing being useful or enjoyable. At this point I think the port just spawns on its own, no coders required, after a set gestation period. But what you probably won't be able to do is break into the system guts like I did. Maybe that's a good thing, from a modern perspective--should kids really be learning about addressable video memory at this point, instead of real APIs like Core and DirectX (which will eventually come to Windows Mobile, mark my words). No doubt those kinds of programming environments are more powerful. I guess I just wonder if they're any fun.
I read a theory once that British programmers became dominant during early days of computer gaming because they learned on terrible little machines (the BBC Micro, I think) that were nevertheless easy to hack. For the last ten years or so, coding on a portable computer has been like a time machine back to a simpler era. For a certain kind of person, like me or maybe the guy who wrote a GTA game for NES, there's a powerful appeal in that simplicity. But it looks like PDAs and cell phones are no longer a destination for that kind of ground-level coding. We're either going to have to go to even simpler devices (wristwatches? digital cameras?) or to emulation for a retrocomputing fix. As our present moves into the future, our past keeps pace with it.