- Posts tagged Software
- Explore Software on posterous
Oracle-Google Java Suit Needed a Special Master Not a Jury
What a freaking stupid mess.
There's a legal mechanism called a "special master" whom a court can appoint to oversee such trials. A special master is someone with technical expertise, impartiality, and the authority of the court to conduct hearings, review evidence and report to the judge.
A jury of 12 people whose combined knowledge of programming languages in general, APIs more specifically and Java APIs even more specifically amounted to bupkus, has declared that programming languages are subject to copyright. Even if they're in the public domain. Sort of.
Trials like this one, in which Oracle sued Google for copyright infringement on some Java APIs they acquired when they bought Sun Microsystems, don't belong in public courts with public juries made up of people who are specifically selected for their ignorance of the underlying technical issues and who are furthermore unimaginative enough to avoid jury duty. I'm not blaming the jury here; the problem is the system.
There's a legal mechanism called a "special master" whom a court can appoint to oversee such trials. A special master is someone with technical expertise, impartiality, and the authority of the court to conduct hearings, review evidence and report to the judge.
This case cried out for such treatment in my lay opinion.
The result, as we have it, is borderline useless and yet will become binding law for the foreseeable future if it's not overturned.
Yeesh.
Yet Another gMail Bug: Screen Update Lag
I've been really annoyed lately with a new "feature" in gMail.
I send an email. The recipient responds. The list of emails in the main email window updates to show an excerpt of the new email (see the first image). I click on that link to see the email. The window displays the email I sent (or the entire thread up to that point) but not the newly received email (see the second image). Refreshing the screen corrects the problem.
This is happening on OS X Snow Leopard with Chrome. If they can't get this right in their own browser....
Apple-Amazon Dust-Up Is All About Money and Control
Apple and Amazon.com are playing chicken over the question of whether those of us who use the Kindle app from Amazon on Apple desktop, laptop and hand-held devices will continue to be able to buy new items easily. The real battle -- as usual -- is over money and control. The question of which of the behemoths will blink first is up for grabs.
The problem: Apple has warned app developers like Amazon.com that they have to remove users' ability to buy items directly within an app by taking them to a Web site to effect the purchase. This is because Apple can't figure out how to get its 30% of that revenue stream. Amazon.com's Kindle apps all have links to the Web-based Kindle store at Amazon.
Where thing stand: Apple says that as of June 30 when it begins to enforce the new licensing terms, apps like Kindle will have to comply or be yanked from the Apple AppStore. Amazon is mum on whether they intend to comply or fight back.
Who Wins? Who Loses? Simply put, you lose if you're a Kindle user and Apple carries out its threat. You will either not be able to read Kindle books on your Apple device or you'll be able to read them but have to go outside the app to buy new titles. User convenience suffers. Apple's historic claim to being concerned first and foremost about the user experience on their products will finally give way to the long-known ugly truth that Apple will ride roughshod over your user expectations in pursuit of more money.
Prediction: Apple has to crumple on this one. Amazon.com is too important a content provider for Apple to lose them -- and with it, potentially, millions of users who will see Apple as the greedy capitalist here and switch platforms or at least grouse publicly about their anger. Furthermore, Apple's on shaky anti-trust ground here with their own book selling service (iBooks) that, by all accounts, is a real bust. My bet is that cooler heads will prevail and Apple will modify the licensing terms to allow it to save some face, perhaps by allowing the off-site purchases with some sort of way of tracking them to get a 10% commission for the sales. That's what Google did with the Android phone and its new One Pass technology.
On Solving Solved Problems
Someone sent me a link to a JavaScript framework called SproutCore today. I'd heard of it before. I think I even took a quick look at it. But it didn't seem interesting, I guess, because I didn't remember it. So I pop into their area, click on a link to a Slideshare presentation on it and I am faced immediately with the stunning news that it is an MVC implementation. OMG. That is so, like, startlingly new and exciting. Oh, and it has this tiny bit of overhead you have to put up with called setters and getters. Yeah, there's a new idea alright. Can you say Smalltalk-70? How about Algol?I have a sense that a great percentage of the people designing and developing these frameworks is completely ignorant of the history of computer programming and languages, that they keep re-inventing the same old wheels over and over again. Aren't there any interesting unsolved problems left? Do we have to go around doing the same old stuff over and over and over again in new languages as if doing so would prove something to someone about how great the language or the framework or the app is? Strange. I'd have thought that those drawn to programming at that level would be intent on solving big, interesting problems. Guess not.
NOLOH's Statefulness is a Big Boon to Developers
It's no secret or surprise to regular readers of my blog that I have become a huge fan of NOLOH. I've decided to undertake a few demonstration projects on my blog to explain why I feel this way and to make it easier for my programming friends to understand this foray into the otherwise cruel and unusual punishment that goes by the self-reflexive acronym PHP. One of the most interesting -- and at the same time distressing -- features of the Web has been its statelessness. Each interaction between the client browser and the HTTP server is an isolated event. Information is not automatically preserved between such interactions; rather the Web developer must spend some considerable time and effort both planning and managing the flow and preservation of data throughout a Web transaction. This was a major feature of the Web in its earliest days because it allowed for tremendous efficiency on the server side; the server essentially opened a socket for an event, processed the event, sent something back to the client and closed the socket. This enabled relatively low-powered systems to act as servers because they could have a limited capacity for simultaneous open connections without breaking the sense of interactivity the user would experience. One consequence of this design was that when a browser sent a server an event that required that some portion of the browser display be modified, the entire window content (which roughly corresponded to a page) would have to be refreshed because nobody was maintaining the state of the page between messages. This resulted in a fairly herky-jerky kind of experience but users quickly became accustomed to it and increased speed of hardware and software on both ends of the exchange as well as of the network linkages made the experience seem a tad less discontinuous than it was in reality. Still, the programming problem of maintaining state remained. And as Web pages and sites gave way to a desire or a need for Web applications, the problem became acute. NOLOH solves that whole problem with what I think is a unique approach. It maintains user state between interactions completely transparently to the programmer. Let me be clear here: user state management is completely automatic. The programmer needs to do nothing to make a stateful application work like a desktop application. You can read here about how NOLOH does this but the fact is, as a programmer all you really have to know is that all of the effort and code that now go into creating a more fluid user experience despite a stateless protocol can now be spent making the app behave better, more smoothly and more intelligently. In my first published NOLOH project here, I'll reproduce my now-famous Counter application in NOLOH and you'll get a chance to see how this benefits you as a developer.Stay tuned.
Developers Beginning to Drop iPhone Plans?
It appears from this article on Ars Techica today that Apple's widely publicized and uniformly hated iPhone AppStore policies and management are beginning to catch up with the snazzy company. A couple of key developers have publicly announced that they will no longer develop apps for the Apple smartphone platform due not to the market but to the channel. This is a ridiculously untenable situation for Apple but the company has passed up numerous opportunities to do the right thing by its developers and has turned a blind eye and a deaf ear to their legitimate complaints. Arbitrary rejections of software submissions based on ill-considered and poorly documented reasoning by an apparently largely bureaucratic neophyte group of screeners has frutstrated dozens if not hundreds of iPhone developers. While it is hard to know whether the underlying policies on which rejection is based are sound and logical or just anti-competitive, it is clear that both the process and communication with developers are deeply flawed. Apple needs to fix this. Now. It is only a matter of time before this attitude -- on the parts of both Apple and the developer community -- causes Mac developers to begin to reconsider their commitment to Apple platforms and technologies. And without that particular flavor of loyalty, Apple oculd be in big trouble, fast.
Looking Back 10 Years at My Vision for Smalltalk
My old colleague Laurence Rozier forwarded me an email tonight which was sent earlier today to members of the Squeak developers list. The email contained a link to a chapter entitled "The Future of Squeak" that I wrote for a compilation of essays and discussions about the Squeak variant of Smalltalk back in 2000. It was strange enough to see that piece being referenced after so many years. But it was stranger still to read it over and realize that it could still elicit such passion in me for this, the Best Computer Programming Language Ever, tempered by my usual chagrin that its curators and caretakers were unable (and in some ways unwilling) to do what it would take to make Smalltalk the broad language of choice for software development I always thought it deserved to become. (On some level, I still think that, though the intervening years have taught me to be less certain of my own certitude.) With the benefit of hindsight, it seems to me that Squeak ultimately did itself in with its "cuteness". Many of its creators and defenders were focused so intently on the language's proven utility as a language with which to teach children programming that they neglected the ways in which their UI design would perpetuate the notion that Smalltalk was a "toy language". I had recently become aware of a Squeak fork called Pharo that showed some promise. In one of my "I love this stuff, why can't I work in it?" free-form explorations one night, I downloaded it. At first blush, it appeared these guys (including one of Squeak's major developers, Stephane Ducasse) had done what I thought had needed to be done to Squeak but didn't have the expertise to do myself. Tonight as I started this note, I decided to update my Pharo image. It's in process as I write this and has already failed once due to a connection timeout problem but I'm going to stay with it and perhaps explore Pharo a bit further even though there's no way I can justify taking the time to do so. Smalltalk does that to me. It just gets under my skin and into my blood like no other programming language I've ever learned.
