SEC interested in smart contracts?

According to Jayanth Varma, the SEC is considering specifying parts of contracts using programs:

We are proposing to require that most ABS issuers file a computer program that gives effect to the flow of funds, or “waterfall,” provisions of the transaction. We are proposing that the computer program be filed on EDGAR in the form of downloadable source code in Python....

It's vindication for agoric computing!

I share the same question as Prof. Varma, however. Isn't it problematic that Python is ill-specified? It is surely convenient to write and read, but a contract needs to be especially rigorously defined. Using a program to describe a contract has the potential to be very reliable, but only if the programming language is particularly well defined.

There are much better specified alternatives. Some have suggested Java as well-specified, and I'd agree, so long as the precise libraries used are also delineated. A more tempting candidate for me would be Scheme or SML. In addition to being well-defined, functional languages lack overriding and thus yield programs that are easier to analyze. Object-oriented languages, by allowing every method to be overridden, yield tremendous power and convenience but make it harder to prove definitive statements about a program. Just imagine trying to say something about E=mc^2 when all of E, m, c, squaring, multiplication, and equality can be overridden.

Some commenters in the above blog article suggest spreadsheets as being a closer match to how financial analysts would like to work. Spreadsheets, it is claimed, would allow the analysts to examine intermediate results. That's very interesting, but are there any spreadsheet-friendly languages that are particularly well specified? All the ones I've encountered are defined by their implementation.

ACTA released

Americans tend viciously debate every little detail of our own national policy. Yet, I've encountered very little interest in ACTA, an international trade negotiation that is just as potent as the much-maligned DMCA.

For any interested, there's a draft of ACTA now available to the public. Techdirt is underwhelmed:

Most of the language that critics have grown familiar with (making the bypassing of copy protection illegal even in cases of fair use, making copies of a large quality of content illegal even if no money is exchanged, mandating that ISPs become copyright nannies) remain at the heart of the ACTA. The agreement's central thrust continues to be to foist clearly dysfunctional, unreliable, and draconian U.S. DMCA-style copyright enforcement policies upon other countries.

I have admit, I'd rather see something with some more principles to it, rather than simply all the major content holders pulling up a chair to the table and divvying up the world. A good one to start with is that if a citizen buys and owns a copy of something, they can make further copies for personal use. I don't see how that kind of right could ever even be proposed at a gathering like ACTA.

Meta-platforms make bad apps?

John Gruber has a claim that Steve Jobs appears to endorse.

I can see two arguments here. On the one side, this rule should be good for quality. Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy. On the other hand, perhaps iPhone users will be missing out on good apps that would have been released if not for this rule, but won’t now. I don’t think iPhone OS users are going to miss the sort of apps these cross-platform toolkits produce, though.

I used to believe this. I thought about Tcl/Tk apps, which are always fumbly and unpolished, versus native Apple and Windows apps, which at least sometimes have slick UIs. Thereofore, cross-platform toolkits are bad. It was a hasty generalization, however. Applications based on web frameworks, Java, or .Net are much better than those based on Tcl/Tk. They look just as good as native apps, and they fit the native look and feel just fine. Thus it comes down to an issue of functionality, and on functionality the native apps don't compete very well.

I spent a couple of years recently trying to use a Mac laptop and live the Apple dream of everything being compatible with everything. One by one, I grudgingly stopped using almost all of the native Apple software in favor of cross-platform software. Specifically:

• Mail, contacts, and calendar form a trio that take good advantage of interop. However, the mail program can't thread, which I ultimately admitted is a show stopper for anyone participating on mailing lists. The calender program is okay, but I can't share events on it with other people, which again is a really important bit of functionality. I switched to web-based versions of both of these, after which the built-in contacts program had nothing to interoperate with. Thus I switched to a web-based contacts solution as well.
  
• For editing documents, I tried to love the built-in NeoOffice. It's not really any better than stock builds of OpenOffice, though. Ultimately I stopped using OpenOffice, because there's no good problem for it to solve. For simple documents I used web-based tools, with their improved sharing and publishing affordances. For documents where I work harder, I use Latex.
  
• For software development in Java, Intellij, Netbeans, and Eclipse are the heavy hitters. There wasn't even a native app for me to try. Apple supplies XCode, but I never really tried it. I'm not sure it even supports Java at all.
  
• For all other software development, Emacs is so good I never even considered an alternative.
  
• For web browsing, I initially tried to like Safari, and it's pretty good. However, I ended up wanting to use Firefox for a lot of things, for reasons I can't remember now. Ultimately, I ended up using Chrome.
  
• For command-line access, I initially used the built-in Apple terminal program. I later switched to a different Apple-specific program called iTerm.
  

As can be seen, in almost every case, the best of breed software for Mac Laptop is built on a meta-platform--exactly the kind of meta-platform Jobs is banning from iPhones. Good thing he hasn't done so for Apple laptops, or they'd instantly become third-rate for working professionals! The native apps are okay for very basic usage, and they are sometimes prettier, but they're woefully underpowered once you try to do anything with them.

This emperor has no clothes. Anyone who currently believes that native Apple-specific software is better, ask yourself: what software do you use day to day? Is Apple-specific software really any better, or is it just cutesy demoware that is good enough if the main thing you do with a computer is show it to people?

I'm checking out of that game. If you use your computer to get work done, then you need good application software, not just a good OS. For that, you want a large pool of candidate software to draw from.

Apple trying to block choice of source language?

Much is being said about Apple's newly launched attempt to stop programmers from writing in a language they don't approve. Lambda the Ultimate is a good place to find lots of links.

This is a large grab. Apply is trying to control not only the technology used in the distributed software for an application, but also the methods used to make it. The requirements on those methods are not even that they be good methods; restricting the programming language does little to enforce good programming by itself. And the languages allowed aren't especially great for good programming.

Jobs claims--in the few terse comments Apple has made about this move--that he wants to prevent the iPhone from being commodotized. This is a standard lock-in kind of approach to doing well in business, but it's slightly odd given Apple's reputation for distributing quality software. One thing we can be sure of: if programmers aren't allowed to use good tools, they aren't going to make good software.

It's unclear whether this will be enforceable. Among other reasons, practically all software makes some use of its non-primary language, but presumably Apple doesn't want to ban all software from their market. Any configuration language is a programming language. The expression language of a spreadsheet is a programming language. If you do a web search for "cell phones -iphone", you're writing the query in a programming language. Heck, if the developers use use ant or make or Maven to build the program, they're writing their build rules in a programming language.

Little languages are just part of how software is written.

Some sanity on network neutrality

PC World writes that the courts have ruled against the FCC for throttling BitTorrent connections:

The FCC lacked "any statutorily mandated responsibility" to enforce network neutrality rules, wrote Judge David Tatel.

As I wrote before, I didn't understand how the FCC had this authority:

Part of my curiosity is exactly how the FCC has the jurisdiction to do this. The last I heard, network neutrality was voted down in Congress. Did it come up again with no one noticing, or is the FCC just reaching again?

I want a neutral network, but I don't see much our governments can do to help. I'm glad to hear that at the very least, the FCC must await enabling legislation to do any of this nonsense. It means that U.S. agencies are still to some degree bound by law.

It's a good thing in this case, too. The FCC wanted to prevent Comcast from throttling traffic. How is this really going to work out profitably in the long run?

The problem is that plenty of throttling is not just acceptable, but a good idea. Eliminate the bad throttling, and lots of good will be thrown out, too. The clearest example is that the diagnostic packets used by ping and traceroute should surely be prioritized higher than packets carrying regular data. Another is that streaming video should likely get down prioritized so that it doesn't hog the whole pipe. Another is that any individual node that is spamming would be good to get throttled down. Another is that a large network might have some parts of its network better connected than others; to prevent the low-bandwidth areas from being clogged, they might want to throttle incoming data into the well-connected parts. There are really quite a lot of legitimate uses for throttling.

Those examples are all compelling and ordinary, but it gets worse when we consider possible future business models. For example, suppose an ISP of the future openly advertises that it prefers some traffic over others, e.g. that it allocates sufficient bandwidth for VOIP that there are never any glitches in a conversation held over their network. Such a company could provide a great service to the general public, but good luck getting it past an FCC that categorically disallows any form of throttling. Regulatory agencies tend to clamp down an industry to work the way it currently works; new ways of doing things can't get off the ground.

Again, though, I'm all for trying to make a more neutral network. It's just that the U.S. government is so terrible with everything computer that its solutions are worse than the problems. If I desperately had to think of something for our governments to do, I'd suggest looking into last-mile issues: decouple Internet service from the service of physically hooking up at the last mile.

IP-level neutrality is not the biggest issue, though. It's already pretty good. A far bigger concern is the constant race between walled gardens and open systems. It doesn't matter if you can send data to any IP, but the only IP that matters is Apple's. The best cure for that is for customers to pay attention to lock-in.

April Fool Picks

Cappuccino has solved the JavaScript memory management problem:

Lately, though, we’re beginning to realize that we didn’t quite go far enough. Memory issues have long plagued JavaScript developers. Because the garbage collector is opaque to the developer, and nothing like “finalize” is provided by the language, programmers often find themselves in situations where they are forced to hold on to an object reference for too long (or forever) creating a memory leak.

The Topeka search engine has some new auto suggests.

The Google Web Toolkit can now compile Quake for your browser.

The U.S.A. is leading the charge on transparent governance and on intellectual property.

Content carriers should not be liable

The liability held by content carriers is a long-simmering political battle that the general public would do well to be aware of. We face a clear choice between establishing some basic principles and rights versus turning over an increasingly important part of our lives to be divided up by moneyed interests.

A content carrier is any business that specializes in the delivery of information from one person to another. They include low-level delivery of data, such as Internet service, radio operators, and postal service. Increasingly, they include higher-level services that organize data, such as search engines (Google, Bing), video sharing (YouTube), special interest groups (meetup.com), and classified ads (Craigslist, ebay). All of these services share the property that the business transmitting or organizing the data has no affiliation with the people and organizations posting data into the service.

The question is as follows. If someone posts something illegal on any of these services, who is liable?

A simple example is that a contractor might bill a client for more than they advertised. A tree remover mass-mails an advertisement saying they will remove trees for $100/tree. You hire them, they remove a single tree, and then they tell you the bill is $200. This tree guy has just committed false advertising.

If that advertisement goes through the postal mail, then no one is liable for the false advertising except the tree guy. A laundry list of enabling companies is not liable at all:

• The company that xeroxed the fliers
  
• The company that made the copy machines used to make the copies
  
• The postmen who delivered the mail from the post office to each addressee
  
• The postal service itself
  
• The company that made the mailboxes
  
• The company that made the software he wrote the fliers with
  
• The company that made the computer that software runs on
  

Obvious, right? We punish the person who committed the crime.

Now consider the same situation if the communication is electronic. Suppose instead of a mass email, it was a web site that listed the false price. Look at all the different groups involved that someone or another is trying to make liable:

• The web site hosting the web page, for allowing the content to go up.
  
• The ISP of the guy who posted the bad advertisement, for failing to cut him off.
  
• The ISP of the web hosting service, for letting the web service stay online.
  
• The ISP of the individuals who encountered the web site, because they did not filter out the bogus site.
  

We should stick to our principles and say no to all of this nonsense. Content carriers should emphatically not be liable for policing the content. The police work easily overwhelms the work needed to do the job properly, thus shutting down advanced content carriers in their infancy. Just as bad, we end up with a society where everyone is the police, and they are all policing each other all the time. It's the electronic equivalent of having postal mail opened before it is delivered.

Charging the person who perfomed the crime is plenty. We don't sue the postman for carrying false advertising, and nor should we sue Craiglist when a "woman" turns out to be a transexual. Whenever it's not possible to catch the guy that actually did the crime, let's not waste our time going after the content carriers. They are bringing us into a new era of human society, and they can't do it if they also have to be a police force.