Reminds me of a rant I read recently, on why Apple killed HyperCard.

> The reason for this is that HyperCard is an echo of a different world. One where the distinction between the “use” and “programming” of a computer has been weakened and awaits near-total erasure. A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone. A world in which Apple’s walled garden aesthetic has no place.

> (...)

> The Apple of Steve Jobs needed HyperCard-like products like the Monsanto Company needs a $100 home genetic-engineering set.

http://www.loper-os.org/?p=568

Personally, I've lost my faith in Google, Apple and other "hip" IT companies long time ago. They feed us toys, instead of tools. Not sure if they do that on purpose or because they think Moloch/Market demands it, but they do so nonetheless.

Serious question: Why would Apple then create Swift and Swift Playgrounds for iPad in order to get more people to program? Seems like they are giving us some tools.

My current theory: they need more programmers making stuff they can sell for iOS. Popularizing Swift is beneficial to them because it still technically keeps people locked in the Apple ecosystem (a kind of soft lock-in - they've opened the language, but it's still primarily supported by Apple).

Increasing the pool of hirable developers does not otherwise exclude selling computing toys to the general population.

I haven't heard of Swift Playgrounds for iPad before. I've just finished watching its demo - I must say, it looks nice and has some cute solutions for entering code via touch interfaces (like that for-loop dragging thing) that I hope will spread around to other applications. That said, it's an educational app - I can learn some Swift with it. But what can I actually program with it? Can I use it to make my calendar talk with my SMS app? Or with my Bluetooth headset?

That's the thing I complain about when I say that mobile devices are developed as toys, not tools. You're always limited to some functionality provided by the vendor and third party apps. Apps that don't talk to each other, that restrict your choices to few operations their authors thought about. Not to mention apps that increasingly want to suck out and monetize all your data, but that's beside the point. On Android we have Tasker, which is something that I believe should be a default component of Android (albeit it could use some ideas from Swift Playground to make UX better). But it isn't, and the current trends in mobile, web and desktop suggests it'll never be - the end user is forbidden from using the computer, they must only ask their apps for services.

Yes you can.

Swift Playground has full access to the iOS APIs.

https://developer.apple.com/videos/play/wwdc2016/408/

I applaud Apple for this, as it makes the developer experience closer to the Xerox PARC ideas.

EDIT: typo have => has.

I think rather than assuming malice, assume either incompetence or different goals.

The saying I've heard is that most people want elevators, but we've been selling them helicopters and blaming them when they crash.

Someone who is largely computer illiterate can download and run apps without any fear of messing things up. There is essentially no malware for iOS. They can always exit the app. They can always delete the app. If the app wants to get the user's location, or email, or documents, or pictures, it has to ask for permission from the user. The app will not mess with things that the user can't figure out - there are easy ways to check (and in some cases limit) space usage, bandwidth usage, and battery usage. Apps are now safe.

This is an amazing achievement!

However, apple has not yet figured out how to safely enable development at the same time. They're getting closer, but they're not there yet. It is obvious that that was not their top goal. There are already lots of general purpose computing devices, and if you want development access to your device, you can get it as a developer.

Think of tools as apis to use and integrate existing services in their ecosystem into your own. A programming language is not that.

I'm not an iPad user, but hasn't Apple had a long-running policy of forbidding any app which includes an interpreter?

I've seen this being mentioned for years by various programming communities (e.g. Squeak Smalltalk), where the only work around is to buy a Mac, buy OSX, buy the Apple developer tools ("Xcode"?) and pay a $99 subscription fee in order to transfer your own app to your own iPad.

> I'm not an iPad user, but hasn't Apple had a long-running policy of forbidding any app which includes an interpreter?

That policy was rescinded almost 6 years ago: http://daringfireball.net/2010/09/app_store_guidelines and had been instituted only a few months earlier: http://daringfireball.net/2010/04/why_apple_changed_section_...

IIRC there's a policy against running downloaded code (at least automatically downloaded code) in anything but the bundled JS runtime, but bundling an interpreter in an application and running user-provided code is not an issue. You can run a Python app on iOS (e.g. via Kivy) and there are Python interpreters in the appstore.

> buy the Apple developer tools ("Xcode"?)

That's free (with a mac and OSX obviously): https://itunes.apple.com/app/xcode/id497799835

> and pay a $99 subscription fee in order to transfer your own app to your own iPad.

The developer account is only necessary to publish in the store, since Xcode7 and iOS9 you can sideload applications with a regular appleid: http://www.howtogeek.com/230225/how-to-sideload-apps-onto-an...

To be clear, you can sideload to a device without paying, but you still can't use all the features. If you want to make an app that uses App Groups, for example, you have to have a paid account. There's no way to even test it without paying your annual Software Development Tax.

I don't understand why this has been downvoted so aggressively. I didn't say anything inaccurate. You can't develop an app that uses App Groups without a paid developer program account. You can't even test such an app locally on a simulator without a paid account.

I think your info is a bit outdated (and some incorrect). Buy a mac (or ignore the Eula and run OS X in a VM), install the dev tools (free), install the app on your iPad (free). If you want to publish, there's a fee (per year).

They don't forbid interpreters. But they forbid downloading code into these interpreters.

Ie running what the user types is OK.

(At least as far as I remember.)

Your free to down load code now, many of the interrperters come with build in support for version control now.

This is the downside of free services. They can be easy to get started. But will bite back when they go out. It has been hard to trust Google after they took reader down.

Sounds kind of like Yahoo Pipes. Is that still around?

Pipes was shut down in fall of 2015.

relevant HN article [1]

[1] https://news.ycombinator.com/item?id=9660682

Is that all it does? I'm sure there are other services out there that do exactly this. Does anyone know of any?

Check out riko [1]. It was developed to programmatically replicate Yahoo Pipes (without the UI). But as it stands, I'm pretty sure it can do most of what google feeds does.

[1] https://github.com/nerevu/riko

(full disclosure: I'm the lead dev.)

Writing a system that (correctly) interprets the zillion flavors of "RSS" out there and presents them with a common API is non-trivial. An 80% solution is pretty easy, and a 90% solution isn't that hard, but a near-100% solution will take you into some very dark and ugly places.

I don't know of any service that does this as well as the Google Feed API did. If someone else does, please share.

Well, start the service, state you use RSS library X and that you will keep it updated and send people over to it for bug reports and contributions.

Ah but RSS is a standard, so where's the problem? One method to recode them all surely?

I jest, I'm the author of http://www.weegeeks.com - I know only TOO well, how there is no such thing as a 'standard' RSS feed... (sigh)

So yeah, I get your point.

Superfeedr https://blog.superfeedr.com/google-feeds-api-welcome/

That theory is nonsense. This API is a tiny thing compared to YouTube and Android app store, two services that provide publishing opportunities to millions.

Publishing on third-party platform, with content limited to what those platforms allow, with monetization limited to what those platforms allow, with constant exposure to random nonsense DMCA takedowns.

But I guess the primary culprits of limiting people's ability to be publishers are NATs.

Even crappy home routers can port-fwd, the real barrier here is the ubiquitous (in America at least) prohibition on "hosting a server" on a residential internet connection.

You think everyone serving their own services from their residential networks is the solution? Have you thought through the security implications of that?

I can just imagine the technical support hours I'd have to log when my dad calls me up because his email server is down or his home storage is encrypted by ransomware.

Of course I have, that's why I run pfSense, a separate host for my DMZ, a reverse proxy, an IPS, and don't have DNS pointing to it (marginal benefit, but I don't need it so it's off).

I'm not arguing that people should do this, I'm arguing that the "NAT is a barrier" position espoused by the "evil ISPs are trying to keep us down, man" camp is incorrect.

NAT being necessary because of IPv4 has lead to this really useful low barrier to self-hosting. People who grok security and want to do it can, but it's just arcane enough that lots of people who shouldn't self-host are scared off and go to AWS.

How does that work with WebRTC, e.g. as used in messaging apps?

You've lost me, what's the connection between "people's ability to be publishers" and WebRTC messaging apps?

If you want to publish a WebRTC service, port forwarding will work fine and then you'll be bitten by the no servers restriction.

A messaging app doesn't have to require port forwarding, it can use a central server to broker the connection between endpoints. In that scenario, the "server" is on the internet, not the residential connection, but data comes from the endpoints.