Lambda the Ultimate

I wish I could believe that this will hurt their developer mindshare.

Paul Graham has some interesting things to say about Apple's Mistake.

Bracha in Closing the Frontier:

Q: How is a programming language interpreter like pornography?

A: They’re both banned at the iPhone App store.

Easy to enforce in lots of cases, though. Speculation (in the link above) is that Adobe's soon to be released Flash->iPhone compiler is a primary target.

I guess one (interesting) way to think about it is to consider compilation that maintains human readability (whatever that amounts to...)

As written, the clause rules out all use of other languages. But Apple probably means the primary source language, which is much more clear cut.

Modern software development uses little languages all over the place:

- Build languages, such as ant, Maven, or jam

- Expression languages, such as "SUM(A1:A5)" and "find:cell phones -iphone"

- AI decision-making languages, such as "price LT threshold ==> SELL"

- UI-layout languages, such as (pane (label "Okay?") (button "Yes") (button "No"))

This is before getting into tools that aren't strictly source code. Things like bug trackers and configuration management. They all have their own little languages.

I daresay you can't be a productive programmer, by today's standards, without a small army of little languages.

I experience the realization not too long ago, that every program we write implements a language. Some are quite simple some are more 'complete', some are graphic, some are 'mouse click' languages, some might even be audio languages. But every user interface amounts to a set of linguistic rules and expressions.

I think this awareness has informed and perhaps improved my own application programming. It is a useful way to look at user interfaces - what sort of language are we forcing a user to learn? How different is it than other languages the user is familiar with? Ideas such as the 'principal of least surprise' fit into this model.

For an obvious example, the C program that implements GHC; for a less obvious example, the program that implements a music player like Amarok. Both have in common a set of expression rules and syntax that they allow.

You might want to review the work of Clarisse de Souza. Her writings on Semiotic Engineering of human-computer interaction share your insight that user interfaces are a form of language.

The semiotic approach (study of signs and communication) explores the relations between the strict program language and the natural language used by the humans creating and using the application. Mismatches between the operations available in the formal code (which supports a limited set of allowed meanings) and the informal users (which can generate unlimited interpretations of the program) are a major source of user errors.

In particular, the author's intent when creating the tool must be somehow transmitted to the user through the application interface. Users will infer their own meanings, and if the intent is not well expressed, those meanings will be faulty.

Extremely relevant to LtU as "The Programming Languages Weblog." PL diversity is important for us PL researchers you know...

The business angle, and Apple's feud with Adobe, are not relevant for LtU, of course. PL diversity, as Sean said, is not only relevant for LtU, it underlies what LtU is all about!

One cannot meaningfully discuss a company's technical decisions without reference to the business angle. The business angle in isolation, of course, would be just be off-topic chatter.

Not really, since I am not concerned with the rationale for the decision, but with its implications.

Understanding the rationale can help you anticipate the long-term implications. For example, one speculation is that Apple is primarily concerned with abstraction layers which let you create portable apps. If that's correct, then it might be possible to get them to tailor the developer agreement more narrowly, so that any PL you use has to expose all the UI APIs directly, and not offer any of its own.

On the other hand, if Apple's goal is monopoly for its own sake, then they're never going to open up even that much. If you want to discuss the implications, then it'll be useful to know which scenario we're looking at.

Or you might rule that it's too early to talk about it, since none of us know what Apple wants.

I think the rationale is more simple than that. It's just battery life, since you mostly pay for abstraction in terms of clock cycles.

There are more reasonable ways of doing this, which they can already do in their approval process - examine the power usage during a representative use of the app.

Adobe has asked Apple to expose certain APIs that would reduce power consumption. Apple has refused, probably on the basis that these APIs are unstable and will not exist in future releases - but also because Apple views their own APIs as all the user should need to use the platform. Things like QuickTime are differentiators.

There are no reasonable ways of achieving power consumption without a better instruction set to target (e.g., the Apple's hardware acceleration API). Jan Ozer, who consults for Adobe, has written about this in the past. This power consumption problem with Flash applies to MAC OS X laptops, too.

I guess testing goes far, but formally you run into halting problems and stuff.

It's not a bad decision on their part. They keep APIs and libraries light as not to clutter the OS with all kinds of bits, and -I assume- give reasonable performance with low battery consumption. Can't say I am that against it. What it doesn't take into account is that you can abstract all you want in an application, like embedding LUA. But that still makes sense from Apple's point of view. It just means that maintenance on their part remains low, and people can expect reasonable performance without too many software issues from the device they bought.

I find it pretty fair, albeit that it hints that there should be better ways of doing so.

Apples allows JavaScript. This negates any argument about the performance. Also note that things like GWT seems to be banned as well.

There are actually two somethings potentially relevant that have been bugging me about their policy.

First, Apple is attempting a quality control move based on language difficulty: their high-level languages (those in the browser) have horrendous performance, making them suitable pretty much only for static content, so their policy limits interactive applications to their low-level languages. This, in turn, turns away much of the developer community. Those already invested in the platform benefit from this (and I generally perceive an undertone of this when they discuss non-inherent issues like consistency). So: are there software quality benefits from *enforcing* usability barriers? Forcing the use of Objective-C by those unaccustomed to it would make me think not. However, obviously taking a bit of a jab, maybe Haskell code is beautiful because the audience has been screened.

Second, the sociolinguistic implications of this move are fascinating, which I previously brought up.

It's nebulous and overly broad precisely so that it can be selectively enforceable. Legal documents are not programs which Apple's lawyers are obligated to blindly execute. A better reading of something like this is "you're probably doing something wrong, but as long as you stay on our good side and don't flagrantly violate the agreement, we won't say anything".

Which isn't all that unusual. If even a tenth of what's written in contracts, licenses, and laws was actually enforced fully, literally, and universally, society would probably collapse. This often seems bizarre to many programmers, being the precise opposite of a computer's tendency to do only, exactly, and all of what you tell it to.

Strained justification of LtU relevance for this comment: Legalese is a terrible programming language, I wonder if it could be improved?

Legalese is a terrible programming language, I wonder if it could be improved?

Nick Szabo and Mark Miller seem to think so, among others.

The general purpose computer will exist so long as there are general purposes.

Not necessarily. Computers just have to be general enough for almost everybody. If locked-down machines like the iPad become the norm (which has got to be Apple's long-term goal), truly general machines will be pushed into smaller and smaller niches. Eventually, if you want to do PL research, you'll need a machine 10 or 100 times as expensive as what you can get at Best Buy.

I was surprised by this as well, especially since MacRuby development seems to be headed up inside Apple, and sits on the Objective-C runtime.

Regardless, you still can embed Lua (or any other interpreted language) in your C code, and write much of your app in it. But you need to keep the iPhone library interfacing in C, and not write a full bridge that's accessible via a custom language.

Actually, embedded interpreters, compilers, or virtual machines were already banned on the iPhone, even before the latest rev of the dev license. This new version limits freedom even more, by even prohibiting you from using source-to-source translation.

Actually, not quite. The ban was on interpreters running "downloaded code", not interpreters in general. I have it on pretty good authority that interpreters that didn't run downloaded code were acceptable.

Now, note the use of past tense; I'm not sure what this new agreement means for the "embedded interpreter" scenario, but I'm guessing it's not good. My only thought is that a number of App Store games must be using some sort of interpretation of scripts, and I doubt they'd be banned given Apple's attempt at courting the casual games sector.

That used to be true. Here is the clause from the original iPhone SDK agreement:

No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

but more recently (sometime in 2009, I think?) Apple changed the terms. Here is the same clause in the iPhone OS 3.2 SDK agreement, with the relevant change highlighted:

No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).

If you are finishing up your Masters in Computer Science, have determined that a Ph.D. in Comp Sci. is not for you, but you also dread going into the real world to become a "software engineer" or project manager, then apply to Law School and see if you can get an internship at the Software Freedom Law Center with Dan and the gang! ;-)

...Novell, Appcelerator, Corona, Adobe, etc. will be needing you! ;-)

The iPhone/iPad OS and toolchain are so ingrained in the platform that it seems foolish to consider anything other than any of the fully supported C variants

Why? MonoTouch provides a .NET platform for running on the iPhone, and Unity started that road by providing a successful .NET game development platform for the iPhone. To my knowledge, these are the most well-supported (maybe only?), memory-safe garbage collected platforms for the iPhone.

Apple's previous terms were much more sensible, as they required only compiled code, not specific languages. This requirement is absurd.

Regardless, you still can embed Lua (or any other interpreted language) in your C code

No you can't. The agreement forbids interpreters.

I think the interesting/unfortunate part of the change is that it will almost necessarily lead to selective enforcement. After all, one of the main things we learn with implementing PLs, compilers, etc, is that, in a concrete sense, all programs are interpreters.

Quite. That was one of the points I was expecting to see mentioned.

I don't see it having a huge impact of anyone other than Adobe and Flash developers who will know have to learn Cocoa instead.

And, of course, anyone who wants to use a programming language other than C, C++, or ObjC. Imagine if you had been forbidden to use graph algorithms in your research, and you have a sense of the absurdity of this decision from my pov.

Now, of course it's true that's not the reason Apple did it, but I'm not actually obliged to adopt their point of view in preference to my own. (Maybe that will be in the next version of their developer license. :)

Lockdown is common in underpowered devices, but the iPhone represents the (by far) leading smart mobile device and the tipping point for them. When you include Kindles and the iPad, which seem to be the next wave of smart devices, we have the locked down embedded mindset being applied to systems that don't really have the same limitations yet companies are bending over backwards to put them in. When you view it as computing classes (in the sense of Bell's Law) -- mainframe, pc, laptop/netbook, cloud, and mobile, this is quite a shift. I don't think it's maintainable due to competitive pressure, but we'll see.

Actually, on SmartCards it is the JVM, demanded e.g. by Telecom providers who wanted to load their own applets, which opened the system a bit.

I wonder if we would lead the same discussion if Apple prescribed using their API but utilized LLVM more thoroughly for their own purposes instead of sticking to GCC. I remember Thomas Lord wrote something illuminating a while ago about Richard Stallmans own very different locking in intentions regarding the GCC. The bewildering and backward oriented language decision made by Apple might be a remote echo of this and isn't entirely without irony.

Dear Oliver,

I am working with Peter Van Roy's researchers on porting Mozart to Android.
We already manage to run mozart applications on Android but there are performance issues because of the Java GUI.
Mozart is running fine and some improvements should help the GUI to be more responsive.
We would like to port Mozart on iPhone/iPod/iPad but there are some problems that we need to think about before.
Mozart should be released in version 1.4.1 soon and this release will be the starting point for the mobile support.

If you want to collaborate on this work, you can send me an e-mail to Jeremie.Melchior@uclouvain.be

Trying to argue Apple's position on technical grounds seems absurd given that they use Objective-C but..

Even if that's the case, I would trust a language to generate cooperative code better than a random entrepreneur trying to write Objective-C.

In the first place it is hard to check a development tool against the ability to create badly behaved programs. Apple is declaring, up front, that it will not attempt to do so.

Red herring -- Apple can do what they've already been doing, checking programs (which I doubt is a good check to beginwith).

primary security tool for this device

That sounds like a really, really bad idea [[though might be ok in a setting like AppEngine where a high-level and instrumentable language is used]]. However, I also don't think it's true. Security comes in layers, and even how the hw is structured in phones starts to provide some.

Finally, the undocumented API stuff is more of a software engineering mistake. There are many ways to have hidden these APIs from non-Apple applications if they so desired.

I'm not sure what your point is. Linux can already be installed on 'jailbroken' iPhones and probably iPads, and of course an iPhone running Linux is not going to access the App Store. There's very little interest in it because the iPhone/iPad hardware is not cross-subsidized by App Store revenue, although I suppose that strategy could be made to work in the future. Accordingly, Apple ought to care little if you wipe out iPhoneOS from your device and replace it with Linux, whereas they would be quite justified in worrying about jailbroken iPhoneOS devices running bootleg apps.

Thomas, you summed this up beautifully. I had wanted to write something similar, but was struggling immensely with the big picture - you nailed it.

Some comments:

This raises the questions: should programming language designers more explicitly aim to compete not only with other programming languages, but with traditional operating systems? Should programming language theorists begin to regard OS theory as an important sub-specialty of the field?

Competing with operating systems requires better support for resources. Languages should start with a TCP/IP networking stack that is more modular than Linux, but equal to its performance that comes from its monolithic structure. Ian Piumarta has started in this direction, Walid Taha has done some interesting stuff with resource-aware programming, and the Austin Compiler Project has done interesting research in transforming a clear protocol specification into efficient executable code.

~ We are entering an age of commodity computing, in which typical users have less and less say over what software can run on their systems. The theoretical significance of "legally banning new abstractions" is of growing, real significance because the day to day computing that people and businesses do is migrating towards (a) centralized computing utilities owned by third parties, leased under contract, and accessed under contract; (b) end-nodes (handheld devices up through "workstations" and "servers") which come with built-in DRM and strong contract terms that limit not only what music files you can play or what movies you can watch, but what software you can run.

This is one of the things the EFF and FSF have been fighting, and losing against. Linus Torvalds and Richard M. Stallman simply delayed the inevitable. More broadly, net neutrality is already a myth - what you access through the iPhone is a reflection of what you access through the App Store. The recent appellate court ruling against the FCC is irrelevant. It's also irrelevant whether Congress decides to pass net neutrality legislation or not. You cannot defeat the market, and the market is controlled by mega-corporations.

The upshot of this is that I think services with contracts based on capabilities will become more widely endorsed, out of necessity.

As an example of one implication, suppose that other platform vendors and commodity computing providers continue to follow Apple's lead. Academic programming language research and development can and will certainly continue but on what terms, and with what relevance?

Researchers will go to China, and Sean McDirmid will teach them mandarin, cantonese, and altanese. Half serious. American cryptography researchers did go to Europe in reaction to DMCA. So did *BSD developers. Researchers go where the laws won't apply to them. Do not underestimate labors of love.

The "unwashed masses" (sorry) of computer users have more or less used their magical machines first to type, then create small spread sheets, charts, contact databases, and now to communicate with other people and read lots of Web published stuff.

So what? Today's users gobbling up pre-installed software is no different to me than Word Perfect users circa 1990 who had no concept of DOS directory structures and kept hundreds of docs in one directory that they *only* accessed from within Word Perfect, completely ignorant of the operating system at all.

A potential saving grace (has been in the past) is all the small to medium industry applications. Awkward and ugly stuff, like software to manage a textile printing shop - everything from contact management to Pantone colors to book keeping. Not exciting stuff, but stuff like that is ubiquitous in small business (that's most business) and it still drives lots of hardware, system, software and training sales. Outside the relatively mainstream hype, this (useful) crap kind of makes a big (boring) part of the small computing world go round and round.

Many/most of these folks won't every learn anything like C++ or Objective C or try to stuff their (Pascal and Basic, mostly) apps into a browser using Java Script. Just won't happen. Apple will come around or limit their market strictly to "consumers" - which will cost them serious change.

My current neurologist has the most automated office I've ever seen. Every Dr. and nurse has a pad-type device and all past records are at their finger tips, future appointments are scheduled on the spot, and prescriptions just spit out of a big fancy Xerox printer thingy. I image a whole bunch of companies are making a VERY PRETTY PENNY configuring systems like that for the health care industry.

Etc. blah blah blah. I wouldn't worry. A more open platform simply *WILL* exist sooner rather than later - because there's filthy lucre to be made :-)

As for Apple? I've never really assigned them any special status in my picture of the computer platform world. WHO CARES?

I've seen what Jecel Assumpcao, Jr. did with Merlin programming language/operating system and building his own laptops using FPGAs and bitblt for graphics, all by himself. I know creating a counter-culture will not be a serious issue (following up on naasking's point about a new Apple counter-culture revolting). However, pragmatically speaking, counter-culture movements have always resulted in consumers being denied access to fun leisurely enjoyments like modern 3d games.

If the market is indeed dominated by large corporations, then it is not a free market but a corrupt one, and it can and, historically, will be beaten. Corruption cannot be destroyed, but particular corruptive tools can be broken, as Thomas Covenant says.

"Dominance" and "empire", those militarist categories, hardly ever apply to markets, although they are very seductive metaphors. Market share must be conquered like territory. On the backside of success, being a "monopolist" has a negative appeal and is almost immoral and calls for resistance. The modern day liberal, worker-consumer still loves warfare, in particular when no one gets hurt.

if many economically significant platforms are subjected to measures similar to what Apple is doing, the programming language theorists and many other sorts of software theorists and engineers ought to just pack up and go home: the society will be legally barred from developing more sophisticated approaches to programming.

I'm not particularly concerned. Like Microsoft, only a counter-culture will compel more openness from Apple, or relegate them to a niche where they might be happy. Anti-trust convictions did very little to curb MS, but the open source counter-culture to MS's lock-in is very effectively dismantling its stranglehold.

Fortunately, while Apple got a significant first-mover advantage here, Google preempted Apple's draconian measures and already started the counter-culture with Android and the Dalvik VM. It seems to be going pretty strong so far.

As a first-gen iPhone user, I'm fairly certain I'll be getting an Android phone next, because iPhone development has just lost all the exciting PLT potential in my eyes.

It is becoming an unquestioned habit of upcoming generations of individuals and businesses to, as much as possible, give up control of their own computing needs and perform computing and communications subjecting themselves to relatively unconstrained contractual restrictions.

I'll just note that most "owners" are generally not themselves technically savvy, and thus they had already surrendered control of their computing infrastructure to IT staff. I'm not sure handling staffing is any less of a headache than dealing with a third-party service. I suspect it just shuffles the headaches around a little.

This raises the questions: should programming language designers more explicitly aim to compete not only with other programming languages, but with traditional operating systems? Should programming language theorists begin to regard OS theory as an important sub-specialty of the field?

The idea that Operating Systems are Languages is probably pretty uncontroversial and unsurprising. But the converse is also true: Languages are Operating Systems, it's just that most are pretty bad ones.

Of course, none of this is in any way novel. I was still crapping my diapers when Dan Ingalls wrote this in the Design Principles Behind Smalltalk paper:

Operating System

An operating system is a collection of things that don't fit into a language. There shouldn't be one.

That quote reminds me of Forth, where the language kernel is traditionally used as its own OS. Chuck Moore has the "guts" of his IDE driver posted here.

Not all meta-platforms are Tcl/Tk. Tcl/Tk, I will agree, tends to make applications that are quirky and unpolished, and that do not mesh well with the OS. However, what about Java, .NET, and web software?

As a sniff test, anyone who has used an Apple desktop or laptop is invited to consider how much of the software they use was developed specifically for Macs. Personally, I tried the experiment, and it went heavily in favor of the meta-platforms. I started out trying to live the Apple dream and using all of the software that is optimized for Apple. Over time, I grudgingly dropped mail, contacts, and calendar for Google equivalents. I never even tried XCode; as a primarily Java developer I use Eclipse, which is based on Java. I have used a variety of web browsers, but all of the big ones are multi-platform, including Safari. At this point, practically everything I use, except the core OS, is cross-platform.

The case against meta-platforms in general is interesting but does not look especially strong in practice. There is certainly a lot of crummy cross-platform software written. At the same time, the very best software is usually cross-platform!

I don't know why this is, but to speculate: cross-platform software has a larger user base, which through a mysterious step two leads to more resources to further develop the app. There are a variety of ways to fill in step two. Pay-per-copy software has more profit if it's cross-platform, which will partially be redirected back into further development. Open-source software will attract more developers, because it can scratch more people's itches. Popular software has more critics and commentators, which lead to a better pool of ideas existing for the developers to draw from. Popular software causes other software to interface with it, making the original software more valuable with no work from the developers. It's good to be popular, and cross-platform software has more room to be popular.

Software Factories and Software Product Lines are fundamentally meta-platforms.

So are 4GL code generators. The essence of these code generators is to generate 3GL code that optimizes for nonfunctional requirements given your functional requirements. This equates to 100% reuse of nonfunctional requirements code across all applications. -- Some software factories and software product lines are basically code generators/compilers in this respect.

If you actually look at the quality of code by many modeling tools these days like Eclipse's modeling framework, especially for managed languages, they are often superior to the quality of code output by developers. Modeling tools can also mask away performance optimization differences across versions of a managed runtime environment. e.g. javac transforming pure string concatentation into StringBuilder calls.

The same logic applies to GWT, and also for that matter mapping OCaml code to C or JavaScript, or even the published uses of Haskell for real-time systems in IEEE journals, through the use of FRP.

I've also seen a lot of "all languages are Turing-complete anyway, so what does it matter?" comments ...

If you bar the mythical sufficiently smart optimzer, and constrain the extent of white box composition, and impose a particular process and IO model from the outside, at least (a) and (b) have a reasonable basis. Both languages definitions and the environment inherently constrain language implementation.

For point (d), consider an intermediate possibility: executables are distributed, but only after static analysis, certification, and compilation by a trusted third party. Would it be reasonable to limit the language in this case? i.e. to Joe-E? Or perhaps a language that supports analysis of memory and CPU and power requirements? or process accounting? I think so.

That said, this isn't an argument capable of justifying the "originally written in" constraint. A high-level language can be an intermediate compilation target.

I am a bit curious as to whether Apple's judgement will lead us to develop "code translation" tools that attempt to preserve style and comments and such to beat the system. The floundering 'language oriented programming' movement might see a little more interest.

So there's at least one area of research that will benefit from all this...

Ironically, after the Android Native Development Kit, Windows is now the only safe phone OS.

They support JavaScript, so perhaps you mean "fine-grained security" or "security with reasonable performance." Oddly, at least for multiprincipal systems, I view JS as safer than most mainstream languages.

I seriously refuse to take seriously someone that call C, C++ and Object-C "not safe".

It's the same line of someone saying that the world should ban airplanes 'cause they can be used for war.

Here on LtU, we take a lot of PL terminology for granted, such as the concept of a "safe language", which has a particular technical meaning that excludes C, C++, and Objective-C.

If you're new to LtU, I recommend the links under "Getting Started" on the left-hand side to get acquainted with how things are discussed here.

from cap-talk.

They have a been funding a Ruby implementation called MacRuby. It is still only at version 0.5, and it's not currently intended to work with the iPhone platform, but my guess is it'll wind up there soon after 1.0.

That pretty much defines a 'systems programming language'. Or any language suitable for developing frameworks.

The idea is to automatically resolve non-functional requirements, such as platform mapping. The idea originated (as far as I'm aware) in code generation tools such as the ones James Martin wrote about in the early '80s (but these were not very sophisticated) [edit: Although I suppose the use of microcode by Xerox to build portable platforms like the Alto is an earlier example]. In Model-Driven Architecture circles, where you have a Platform Independent Model and a Platform Specific Model, there is intended to be a clean separation of these models. The goal is to bury non-functional requirements from the purview of developers and the domain expert.

A meta-platform is not a system's programming language. It is a translation tool. The goal is actually to ignore the system as much as possible. Once you understand the system and its performance model, there is little need to keep writing directly to the system. This facilitates reuse.

edit: recently multimedia outlets like TechCrunch have latched onto meta-platform as a buzzword. Surprisingly, they are using it correctly. For example, Google's meta-platform for social networking subsumes Facebook. It commoditizes Facebook.

Somebody on Hacker News commented that this reads like satire. I can see how one can come to this conclusion :-)