4 ms·

I'd disagree. I've come to realize that crashing is usually either the developer's fault (e.g. trying to do something that doesn't make sense) or the browser's

I'd disagree. I've come to realize that crashing is usually either the developer's fault (e.g. trying to do something that doesn't make sense) or the browser's (with Firefox I'd get crashes constantly, since their sandboxing actually breaks the plugin more often than it protects from it; with Chrome, using the same version of the plugin, I get none). Still, if you look at what they've done in the past couple of years you'd see a lot in trying to revert that situation. Forcing a maximum tick rate of 60hz (was 120), dropping memory use and performance (tick rate goes to 2hz when hidden on a separate tab, or out of the screen); coming up with new browser APIs so the browse can control the plugin performance; and on and on. They do deprecate a lot over the years. However, is "eliminated" something people really want? The platform prides itself in the fact that SWFs that worked for Flash 2 still work today, despite the changes in the language and virtual machine. So unless it's a change of security policy, nothing breaks or is "eliminated"; as a developer, I find this to be a good thing as I don't have to have a client coming to me after 6 months complaining about something not working anymore. Flash is a platform that allows people to do a lot. Including shitty binaries. And there's not much defense against it. And personally I still have my browsers crash more because of shitty HTML/JS than Flash. YMMV.

lootabooga 15y ago
" Forcing a maximum tick rate of 60hz (was 120), dropping memory use and performance (tick rate goes to 2hz when hidden on a separate tab, or out of the screen);" Wow! Those are SERIOUS feats of engineering! Color me impressed. And they must have took Adobe the best part of a couple of hours work by some intern...
ed 15y ago
Crashing in a managed environment like Flash is never the developer's fault. These issues are either introduced by the browser vendor or Adobe. It's worth noting that Adobe is very reluctant to deprecate API's. They've historically preferred (with AVM1/AVM2) bundling new VM's into the player over deprecating features. And any deprecation must be version-specific, and tends to be more for API consistency than anything else. What really disappoints me is Adobe's reluctance to support really neat Labs projects like Alchemy. Want to run C (or any language which compiles to C, like haskell!) in the browser? It's been possible since Flash 9, way before NaCl. Official support is coming soon but it's a bit too bad it took so long.
- Peaker 15y ago
  Haskell doesn't really compile to C, unfortunately. The (deprecated) via-c backend of GHC compiled to something that looked like C, but depended on a horrible Perl script to post-process the object output. It does have an LLVM backend these days, though, maybe that can work?
- MetaMan 15y ago
  "Crashing in a managed environment is never the developer's fault" !!! WHAT? Are you serious? Please educate us as to how that is done.
  - ed 15y ago
    How can you fault a managed system? Addresses are a few abstractions below the developer.
    - MetaMan 15y ago
      For me there are many real world cases which can't be handled without showing the user a fatal error. E.g. - the developer asks for an runtime created asset that doesn't exist anymore or there's a condition under which a block of code runs forever (actually in this case the flash runtime stops after 15 seconds of activity and allows the user to kill it but it's still a "crash" insofar as the user is concerned.
      - beagle3 15y ago
        But Flash often crashes way worse than that; it segfaults, or raises a structured exception. It used to take browser processes with it, before Chrome made it popular to have plugins in their own process. I suspect Flash's (lack of) stability was one of the reasons for considering this design decision in Chrome.
  - georgemcbay 15y ago
    He's right though it depends what you mean by a "crash". An unhandled exception due to referencing a null object that caused the Flash app to crash? Developer's fault, not Adobe's. A crash that brings down the entire Flash runtime (and possibly the browser hosting it)? Adobe(or the browser vendor)'s fault, not the developers. Even if the developer does something horribly stupid in ActionScript, the runtime should never die due to developer error.

lootabooga 15y ago

" Forcing a maximum tick rate of 60hz (was 120), dropping memory use and performance (tick rate goes to 2hz when hidden on a separate tab, or out of the screen);" Wow! Those are SERIOUS feats of engineering! Color me impressed. And they must have took Adobe the best part of a couple of hours work by some intern...

ed 15y ago

Crashing in a managed environment like Flash is never the developer's fault. These issues are either introduced by the browser vendor or Adobe. It's worth noting that Adobe is very reluctant to deprecate API's. They've historically preferred (with AVM1/AVM2) bundling new VM's into the player over deprecating features. And any deprecation must be version-specific, and tends to be more for API consistency than anything else. What really disappoints me is Adobe's reluctance to support really neat Labs projects like Alchemy. Want to run C (or any language which compiles to C, like haskell!) in the browser? It's been possible since Flash 9, way before NaCl. Official support is coming soon but it's a bit too bad it took so long.

Peaker 15y ago
Haskell doesn't really compile to C, unfortunately. The (deprecated) via-c backend of GHC compiled to something that looked like C, but depended on a horrible Perl script to post-process the object output. It does have an LLVM backend these days, though, maybe that can work?
MetaMan 15y ago
"Crashing in a managed environment is never the developer's fault" !!! WHAT? Are you serious? Please educate us as to how that is done.
- ed 15y ago
  How can you fault a managed system? Addresses are a few abstractions below the developer.
  - MetaMan 15y ago
    For me there are many real world cases which can't be handled without showing the user a fatal error. E.g. - the developer asks for an runtime created asset that doesn't exist anymore or there's a condition under which a block of code runs forever (actually in this case the flash runtime stops after 15 seconds of activity and allows the user to kill it but it's still a "crash" insofar as the user is concerned.
    - beagle3 15y ago
      But Flash often crashes way worse than that; it segfaults, or raises a structured exception. It used to take browser processes with it, before Chrome made it popular to have plugins in their own process. I suspect Flash's (lack of) stability was one of the reasons for considering this design decision in Chrome.
- georgemcbay 15y ago
  He's right though it depends what you mean by a "crash". An unhandled exception due to referencing a null object that caused the Flash app to crash? Developer's fault, not Adobe's. A crash that brings down the entire Flash runtime (and possibly the browser hosting it)? Adobe(or the browser vendor)'s fault, not the developers. Even if the developer does something horribly stupid in ActionScript, the runtime should never die due to developer error.