Exactly. If I had mod points, I'd mod you up.

Apple's somewhat painted themseves into a corner on this. That is, they decided that they wanted to give users the ability to run native apps, but (unlike Palm or WinCE at the time) with a consistent, predictable app experience (no crashing, memory leaks, terrible UIs, porn, writing/reading all over the filesystem, spamming users, etc.). That means that they need to review all apps to filter out the crap. But then that means that all software has to go through that process, so you have to prohibit the ability to bypass the app store approval process. Which means that you can't let people program directly on iPhones/iPads, or to distribute software through downloads that bypass the app store approval process.

The only way out of this is to use the web browser, which can download and run software, but the user is protected because it's all JavaScript running inside the browser's "sand box", limiting the damage that badly behaved software can do.

There are some descendants of HyperCard for Mac OS X (and Windows), such as http://runrev.com/. Functionally they're amazing. But they aren't positioned as tools for novices because they have to convince people to find and buy them (or at least download them, for the free ones). And while HyperCard was great because it was easy, it was also important that it was automatically provided to everyone for free, so novice users could easily find and use it, and even the barrier of having to find and buy a fairly cheap dev tool is enough to scare off novices. For example, runrev's LiveCode is great, but it's between $99 and $1,500 depending on what platforms you want to deploy on. The beauty of HyperCard was that it was easy to use, which includes not having to find or pay for it.

The only way for HyperCard to succeed in its goal of enabling non-technical people to build apps is as a free part of the OS - once it became a paid add-on, it was doomed, because novices would never know about it, much less be willing to pay for it. And professional developers donj't want novice-friendly tools, they want power tools like IB.

Thanks for posting this.

While an open souce Hyper-card like platform is very cool, that's not enough to replace the gap that hypercard filled. There are several commercial and open source tools that are "friendly like hypercard", but the other thing that HyperCard had going for it was that it was given to everyone (who bought a Mac) so it was easily available to novice computer users. While it seems easy, even the barrier of having to find out that a tool exists, and installing it, is considerable for a novice, while a pre-installed instance of HyperCard was simply there for everyone to use.

Wouldn't it be cool if some computer manufacturer could take pythoncard, or one of the others, and bundle it pre-installed as a "feature" that their PCs?

"How exactly is this consistent with a $99 per year tax to run software that you compiled on a device that you own?"

All consumer electronics platforms have restrictions around the ability to "run software that you compiled on a device that you own". Mac dev tools are free and anyone can write any app. iOS dev tools are free, but it costs $99 to be allowed to submit apps to the App Store. MSDN memberships (to get the Windows dev tools, etc.) costs $2,500 per developer. Videogame consoles, Kindle, RIM, etc., cost vastly more, and are only available to companies that are approved for access by the platform's owner. And plenty of other platforms (GPS, etc.) are completely closed, so that only the platform owner can write apps. And most platforms (Xbox, PS3, Wii, Kindle, etc.) have a much more restrictive app approval process than Apple's. Pretty much only desktop OS's and android are more open than iOS, with the tradeoff that those platforms are much less stable/predictable than iOS, and arguably for a phone consumers want a more reliable, predictable environment.

So yes, iOS isn't quite as open as Linux, so in an absolute sense the fact that there are some charges and restrictions mean that it's not "open", and you can call any fees a "tax" rehetorically if not literally, but relative to almost all other platforms it's extremely cheap and easy to be an iOS developer. If you want to complain about a "platform tax" you should look at the videogame consoles and most mobile platforms, which all have terms that are brutal to developers. Compared to that, $99 and a trivial approval process is nothing to complain about.

Exactly! Thanks for posting this!

The premise of the article, that Apple killed HC because they didn't want users to create content, only consume it, is absurd. Among other things, Apple gives away their entire (extremely good) development toolchain, docs, etc., because they want to make it as easy as possible for people to develop software.

The reason that HyperCard died is that while everyone loved it, nobody could make a business case for it. That is, while people will pay for word processors, spreadsheets, databases, etc., nobody was willing to pay for HyperCard. So when HC was moved out of Apple (where it was a free part of the OS, subsidized by hardware sales) to Claris (where it had to generate revenue) it became doomed. Because while HC was a great tool for non-technical users to build apps, it couldn't compete as a commercial tool for building apps, because professionals were better off using Director, etc., which were much harder to use but which gave them more control.

The later thing that kept it from making a comeback (when Claris basically got rolled back into Apple) is that Apple realized that the web would replace HyperCard, in that all of the nifty things that people used to do in HyperCard stacks were now being done as web apps, and it didn't make sense to try to fight that battle. So instead Apple focused in ObjC/IB for native apps, and scripting, doing things like allowing you to make apps using IB and AppleScript, which in theory is similar to HyperCard (though in reality nowhere near as non-engineer friendly).

It's a shame, since there's no way to build web apps that's accessible to non-technical users the way HyperCard was. The closest tool now is Excel, which is still where the vast majority of non-technical "app building" takes place. And Excel is a much less creative tool than HC.

Personally, I would love to have seen Apple open source HyperCard, and keep bundling it on every Mac, because that would have allowed the creativity to continue without the cost structure. And I'd love to see a HC runtime on every iPad.

It's too late for that, sadly.

"if you have time to work on automation, its probably because you don't need it ... those who really need automation don't have the time to implement it."

This is only the case if resources are absolutely fixed, the you can't prioritize your work. And in my experience, situations are never that doomed - they just feel doomed when you're in them, and you don't get "out of the box" to change the situation. If automation really saves more work than implementing it, you can find a way to defer the manual work long enough to automate it, or bring in a contractor to do the manual work (or the automation), justified by the time saved once it's automated.

It's the same short-sighted logic that junior people make, where they're "too busy to interview/hire/train" so they never add capacity to improve their situation, so they have in effect created a trap, walked in, then complained about being trapped.

The answer is to be smart, and to invest a little time automating because that's a much more efficient way to work than doing everything manually.

As an example, at my last startup we built and deployed everything as debian packages, generated straight from the build boxes, so we could do a software build, automated regression test, and deploy of a complex distributed system to hundreds of servers, by one person in an hour. Sure, it took some time to get all of that completely automated, but we had no alternative - as a startup, we couldn't afford NOT to automate, because the work required to do every software build, QA, and release manually, forever, was vastly more than the one-time cost of scripting builds, regression testing, and deployment.

The trick, in my experience, is to hire very smart, lazy, cranky sysadmins. The kind that get pissed off the second time they do something manually, then script it so they can get their work done more easily.

"For the sake of efficiency, drive API's will lie about data having been being persisted."

No. The ability to control write-through cache has been quite explicit for decades. If applications need performance most, which is the case 99% of the time, they use a normal write, which is written to the drive's controller buffer and considered "written" even though it's actually written to disk later. Applications that need to ensure that data is written to disk (e.g. databases) explicitly force the write not to be confirmed until the data is safely on disk. This can be explicitly controlled by the application, the RAID controller, the drive's controller, etc., so that systems can be tuned (by the owner and/or OS vendor) for the tradeoff between performance and data integrity.

If a drive manufacturer's drives violated the API spec and claimed that data was written to disk while it was still just in the buffer, without being configurable to disable this for critical applications, nobody would ever buy the drives.

So how do hybrid drives decide what's stored in the SSD vs the disk? From working in the hard drive business, I can think of several ways to tackle this - which is it?

1. Drive observes usage patterns and stores data on SSD vs disk based on that. This would be cool since it's transparent to the OS, etc., so it can work by "magic" (e.g. like bad block remapping), but it feels like it might be less effective than the other strategies depending on how good a job it does guessing how data is used. Also, there are some cases that are 'rare' (such as boot time) but which are important to optimize, even if statistically it wouldn't appear so.

2. Driver/OS controls what's stored where. This could be great, since they can have much more knowledge of what's going on than the drive.

3. SSD and disk are distinct 'drives'. This would allow the user to optimize (e.g. put boot OS and swap on SSD, big files on disk, etc.). But it requires users to understand and manage tradeoffs explicitly, which most people probably don't want to deal with.

So which is it? Does anyone know?

I'll second that about the lack of marketing. I'm a HUGE Lego fan (I have my VIP card, went to Lego Florida on opening day, bought the T-Shirt, etc.) and I only saw Lego Universe promoted once - at CES a year before it launched! And then the next time I saw it, it was a random, abandoned-looking box in a Game Stop's PC software section. No posters, no online marketing (other than it being discussed on fan sites), nothing. And if they can't sell ME a copy of Lego Universe, a lego-loving geek with disposable income, they can't sell it to anyone.

I pretty much use Mac (client) and Linux (server) for everything.

But I still use Windows because there are some specific, very useful apps, that are Windows native, so I run them on a PC or on Parallels. Yes, there are web-based alternatives, but, to be honest, they suck to use - the web app UIs are clunky and slow compared to a native app. In the long run, I hope that web based alternatives surpass the native Windows apps, but right now it's more important that I be able to work efficiently than be cross-platform. Parallels is cheap and works fine, so I can run Windows apps on my Mac and they nearly feel like native apps.

Of course, the problem wasn't the battery, but a software bug that causes the phone to draw more power than it absolutely needed to. So the fix is a software update (already released to developers), not a replacement battery.

The point of 3D printers, of course, is that they can make unique items. It'd be fun to algorithmically generate unique shells to see what the hermit crabs like.

The thing that people here seem to be forgetting is that this is just a weird art project, like all of the "contests" that Makerbot runs. They're not seriously trying to save hermit crabs, any more than they were trying to get people to wear plastic printed bow-ties, or collect things based on a model of Stephen Colbert, or any of their other contests. They're just trying to come up with fun things for people with 3D printers to do.

There are models that include human activity as inputs and models that ignore human activity. The former are much more accurate predictors of the actual climate.

If you think that the models are "highly simplified" then you haven't seen any of the models. That is, unles you think that models with hundreds of variables and millions of data points are simple.

When new data comes out, it's only right to adapt the models to take that data into account. Remember, in science you start with observed facts and you try to work out how things work. It's not science when you decide on how things work first and ignore new facts.

The models predict global climate destabilization, so while the overall temperature goes up, the destabilized weather patterns lead to more extreme storms and snows as well as droughts and record high temperatures. Some people simplied this complex interaction into "global warming", which is in a simple sense what is going on, but in reality the models were ALWAYS more complex than that simple phrase.

If anything, the changes in the models have been that the changes are coming faster and are more extreme than the early predictions.

You've got cause and effect backwards. Gore has been trying to get people to do something about global climate change for decades, at the start of which nobody cared about the issue and it probably hurt him politically to keep pushing it, and has invested his personal money in companies that are working to do what he advocates.

If you think that people trying to do something about the global climate change are using deception, tricking people, etc., please provide some examples that are supported by evidence. "We don't like it" and "we don't want to pay for it" aren't arguments of fact. :-)