Reaching the Limits of Adobe Stupidity(whitequark.org) |
Reaching the Limits of Adobe Stupidity(whitequark.org) |
There was next to no automated testing, there was some theoretical best practice, but at least in the windows world nobody cared. Heck, back in the days there weren't even multiple accounts on a machine, nor were there file system permissions for example.
Of course, those old days are long gone by now, but software surviving from back then (like Flash Player) still has this legacy.
As an aside: when it initially came out, Flash Player was called ShockWave Flash (.swf - ring a bell?). Flash was this lighter, simpler (and cheaper) version of the Shockwave authoring system.
At some point it superseded it in features though.
Some of this old Software can be rewritten, but most of it is still being depended on by independent third parties which require the mess to be bug for bug compatible.
Combine that with binary file formats, the need for backwards compatibility, the need for newer software to read older file formats and in the case of Flash, the need for newer plugins to execute old, buggy bytecode because so many compiled swf files are out there of which the source (also in binary .fla form btw.) is long lost.
It's so easy to look at Flash player today and laugh at Adobe, but remember: this piece of Software comes from a different age where nobody but the Unix guys knew better (and they knew better than to touch Windows).
It's a good thing that it's slowly dying I guess.
By the way: I'm as guilty as anybody else.
Thankfully though, the age of dial-up is over so nobody is going to use that Windows dialer I wrote back in those days (despite its bugs, it was deemed good enough to win awards even in dead-tree publications).
Where this does bite me personally though is in the Windows frontend of our product. I've written that abomination right after finishing high-school back in 2001.
Unfortunately it is still in wide use and I have to maintain it which is ever so painful.
In theory it really needs a rewrite, but by this time all new users are - of course - using the web frontend, so only people who don't care at all about technology are still using the windows clients (still 25% Windows 98 of all things)
So rewriting the client and then pushing an auto update would be incredibly painful for them unless it's pixel-by-pixel identical.
And to make this rewrite run on Windows 98. I don't even want to think about this.
It's no wonder the thing is so jammed full of fossilized code. Legacy platform support. Legacy plugin support. The whole thing is a museum of bad ideas and shoddy implementations done by people who no longer work for companies that don't even exist.
It was wildly successful, beating out even its brother Director slash ShockWave, which is an admirable achievement, yet did not come without a cost. Like Windows its success has saddled it with an enormous base of users and developers to keep content.
A big problem with all things Flash-related is that Adobe was rather half-hearted in its commitment to making Flash open so the documentation was never quite as polished as it could be. Another problem which probably the source of the frustration in the original post is that functionality was added rather than existing code upgraded. That probably meant that the existing code along with all the warts was left untouched rather than run the risk of making breaking changes.
The "interesting stuff like jumps past the end of function" were I think attempts at obfuscation since decompiling flash files and actipnscript is not very difficult. Another example was to append actionscript byte-codes at the end of a table used for strings and amend the length of the table to hide the code. The following actionscript byte-codes could then add jump into this hidden code which would hopefully but not successfully confuse the decompilers.
One example of the tail wagging the dog: http://forums.adobe.com/message/3311504
(TLDR: NTFS itself is Case sensitive even though the Win32 API isn't because NT was/is designed for POSIX compliance)
It ain't much better on the artist side. The UI revision after the Adobe/Macromedia suit was so bad it was one of the major reasons I left the animation industry. My friends who stayed have AMAZING piles of helper scripts to patch it up and make it halfway usable.
What are the amazing piles of helper scripts intended to patch up an UI revision consisting of?
And you HAVE to update to this new tool because the files saved by it are incompatible with the old versions; if you're gonna interoperate with other folks you have to somehow deal with this maddening new behavior.
I was already coming to feel that I would never have the joy of working on my own stories and creations because I didn't have the burning drive and social skills to claw my way to running a show. All that was left of animation to me was the joy of making things come to life. And this UI change made that a death of a thousand cuts instead.
The helper scripts are a lot of macros to automate common usage patterns, and a few plugins to create new palettes. I can't remember the exact details; this was a whirlwind tour of Cartoon Network's working methods when I was staying at their head Flash director's place for a funeral.
http://adobegripes.tumblr.com/
yet :)
You couldn't say the same about the Photoshop team, IMO.
http://code.google.com/p/xee/source/browse/XeePhotoshopLoade...
(ternary (false) (integer 15) (integer 15))
Think of the output of the flash compiler as being like the output of the C processor. Then it makes more sense.
There's nothing stopping someone from writing, for example, an AS3 compiler for the JVM that interacts with Java libraries in the same way JRuby does.
(I remember wasting a lot of time once on a rookie mistake where I had a Perl script with "use Strict;" in it instead of "use strict;", it worked fine on Mac OS (OS9, in this case), but failed in at-the-time-inexplicable ways when deployed on unix. I suspect my habig of insisting on choosing case-sensitive filesystem stems largely from that… And yeah, doing perl/cgi webdev on Mac OS9 was a really bad idea, I discovered.)
It might only seem like a little turd on the sideway that you can easily step over, but quite evidently in the case of flash little things like these have added up and its performance is now -- in the metaphorical sense -- up to its neck in shit.
After compression, what do you figure the cost is? I mean, that looks like a lot of text, but as opcodes it's a few bytes at most before compression. Improving video codecs provides way larger gains than fixing things like this.
> forces the JIT to sift through it and optimize it away
That code is already going to be there, isn't going to burn up a measurable amount of CPU, and only imposes a cost once per load. There are better places to work on improving the product.
> It might only seem like a little turd on the sideway that you can easily step over, but quite evidently in the case of flash little things like these have added up and its performance is now -- in the metaphorical sense -- up to its neck in shit.
That's actually far from clear. I think another way to look at it is that Flash has so many other problems that focusing on this BS clearly isn't worth their (or anyone else's) time. Heck, for all we know some of this has been caused by fixes to other performance problems they've been working on.