While this works as far as it goes, it restricts your library boundaries to POD types with no templates and no overloading. This doesn't completely defeat the point of using C++, but it does mean, for example, that you have to fall back to C-style memory management (no std::shared_ptr / std::unique_ptr, which modern C++ libraries should be using for pretty much anything that crosses an API boundary).

It usually does, because the intended function changes over time. This is particularly true for business software (COBOL's niche), where regulatory requirements change over time and as companies grow to cover more jurisdictions, where accounting best practices change, where the company structure changes, and so on. Eventually you get to the point where the software was originally designed to do something so totally different to what it's doing now that it may make more sense to rewrite it than to keep adding hacks.

I had a housemate who had a P4 laptop. That machine was an absolute triumph of optimism over engineering. Fortunately, the thermal throttling in the P4 worked pretty well, so it didn't get too warm, it just got really, really slow...

I'm not sure how they're aggregating the data, but some of their source data is very surprising. Apparently Objective-C is the most popular language on GitHub projects, yet way down the list for projects tracked by Ohloh (which, as I recall, has been called OpenHub for a while now, so I don't know how old their data is). I'd have expected GitHub to be fairly representative of open source projects in general, though I wonder how good both the GitHub and Ohloh results are at deduplication - I have several copies of exactly the same code on GitHub...

40% is a difference that's usually easy to make up with some algorithmic tuning. It's less than the difference between -O0 and -O2 typically, and it's also less than the difference a recent C compiler will give you over an older one. You can easily lose 40% via various abstraction layers that people build on top of C to make it useable.

In the end, the browser sets the policy, though most browsers make this mostly under user control (typically allowing a small amount without prompting and then asking the user for each increase), as the browser is the program enforcing the policy. I don't have an iOS device, so I can't tell you how it implements this.

Depends. With WebGL / WebCL, I can imagine preview effects there quite easily. I can also imagine that it would be nice to be able to do the real rendering runs on a rack somewhere else. The more difficult thing is imagining the multiple GBs of data between the two. Possibly uploading the raw source data to the server and keeping the local copy and just syncing the non-destructive editing instructions would work.

Note that HTML5 does allow effectively unlimited (policy set by the user) local data to be storage and applications that run completely disconnected. It's possible to write a web app that uses the browser for the UI, but only uses the network for software updates.

You're conflating JavaScript and DOM. With FTL, JavaScriptCore can run C code compiled via Emscriptem to JavaScript at around 60% of the speed of the same C code compiled directly. That's not a huge overhead (40% is a generation old CPU, or a C compiler from 5 years earlier). Transitions from JavaScript (or PNaCl compiled code) to the DOM, however, are very expensive. This is why a lot of web apps just grab a canvas or WebGL context and do all of their rendering inside that, rather than manipulating the DOM. Optimising the DOM interactions without sacrificing security is quite a difficult problem.

Web app doesn't necessarily imply web app hosted by someone else. For companies, there's a lot of advantage in being able to roll out cheap client machines that just run a web browser and have all of the apps in a single rack somewhere. To upgrade everyone in the company, just upgrade a single install. Don't worry about employees that can't remember to always save data on the fileserver where it's backed up, because you've configured the web apps to only be able to save there (or to always save a copy there).

Itanium compiler development has also been centred in Moscow for a while, so they likely have a pool of engineers experienced with targeting weird VLIW architectures.

No, they are again. During the Pentium 4 era, they were behind on pretty much every metric. They only survived because of name recognition and AMD not having the production capacity to take more than about 20% of the market share. At the mid to low end, an Athlon system with the same performance was cheaper than anything Intel sold. At the high end, Opterons were roundly trouncing Xeons in absolute performance and performance per dollar.

The Pentium M was when it started to turn around for Intel - the laptop market started to grow rapidly and AMD was only just competitive on performance per Watt, but didn't have the laptop motherboard makers onboard. With the Core 2, Intel retook the performance crown.

Depends a lot on the ticket type. I just checked and advance singles (specific train, booked in advance) start at £39.70 each way. That works out at about $61 each way. Off-peak singles (any train, not at peak commuter times at each end) are £60 ($90) each way.

Except that, just before the invasion, they had announced that they would switch from selling the oil in US Dollars and use Euros as the currency for defining the price. This provided a strong economic incentive for the US to change the regime.

Data loss in flash cells is probabilisitic, but the standard for wear levelling software is to mark a cell as dead if it can't guarantee holding its contents for a year. There have been some interesting proposals to expose this to the OS - there's a lot of data where even holding it for one day would be fine (e.g. browser caches, swap, other temporary files), so the more worn cells could be productively used for this data.