Joel Neely on LtU:

The pattern that I've observed repeatedly is that of a visionary who thinks in large terms of how Things Could Be Better. In order to gain support, funding, etc., the visionary feels obligated to make grand promises to sell the vision. Hype and bandwagoning follow. The hard work to realize the desired benefits takes more attention span than the hypesters and bandwaggoners, who were hoping for a Quick Win and a Big Payday. Their enthusiasm turns to frustration, and The Bubble Bursts. The trade press consensus is that the the vision is unrealistic, and attention turns to The Next Big Thing After That.

Meanwhile, seeds continue to germinate (and to interact with other contemporary big ideas in unexpected ways). After sufficient time, the true long-term benefits of the original ideas begin to emerge into routine practice, although in specific forms that nobody - including the original visionary - predicted.

I still don't have a flying car, but our 'Net connected cell phones and Blackberries far surpass the capabilities of Dick Tracy's "2-Way Wrist Radio".

Alex Payne ftw:

In a perfect world we’d like every tweet to have its own key value store for whatever metadata [developers] want.

This week in user control

Facebook: Setting a new standard in user control

Apple: United States Patent Application: 0090265214: Advertisement in Operating System

the user may be prompted to press a certain button or keypad key in order to confirm that they are paying attention

Get into my bubble

Does Scoble get the internet?

He seems to operate under the old paradigm where everybody knows/reads/uses the same services (he knows/reads/uses).

Does anyone have a good explanation as to why Google would buy a real-time text editor for a price in the low eight figures?

I guess it's a patent thing.

Move over, Google

[Y]ou can now run pretty much entirely on a Google stack.

This is a totally vertically integrated single source solution to the Internet.

(Worried About the Googlenet)

I think the internet is big enough for Google and everybody else.

A scenario:

• The real-time web will level the playing field for news access. (No more crawling.)
• Something like Salmon will tie together distributed conversations.
• Hypermedia-enabled microdata will flow freely among hosts.
• WebFinger will provide web-wide single sign-on and service rendezvous.
• Everybody can store the web on his USB drive.
  

What happens then?

• No more lock-in in evil silos.
• Ecosystem of competing clients/user interfaces.
• Millions of database-indexed copies of the Giant Global Graph.
  

In this hypothetical world, Google would have to work even harder than now (!) to stay ahead as the premier Brand=User Interface.

Mark Nottingham: I wouldn’t say that SPDY is competing with WAKA — yet.

The sign of a platform, its gravitas, macho-ness comes from the possibility of developers eclipsing the platform itself with utility and coolness. — Dave Winer

As I was originally an industrial designer, I would analyze those games while I played them, trying to figure out what it was about the way the games were put together that made them enjoyable and made people want to play them again.

And basically, I concluded that this was born of the players being mad at themselves. So I would try to analyze how the game made players feel that way. — Shigeru Miyamoto

Thomas Lord over on LtU:

We should recognize, therefore, that the "Open Source" narrative was invented for a specific economic and political purpose. A handful of firms and a lot of money wanted to *use* publicly licensed source code and the labor of volunteers, but wanted to *thwart* the goal of giving all software users personal freedom. For that purpose, it would not do to have a charasmatic figurehead (love RMS or hate him) defining the branding term "free software". Just as RMS could embarrass Gosling or expose the lie in Cygnus' problems, RMS and the FSF - left unmolested - could have organized volunteers to eliminate any need for companies like VA Research and Red Hat. Rather than let this happen, "Open Source" was invented (and the OSI chartered), as a kind of "hostile rebranding".

Dave Winer: Tech note -- the first piece was written on a WordPress site, the second on a Tumblr site and the third on my Posterous. My authoring tools let me write for all these platforms, in exactly the same way.

El Reg:

Google hadn't even warned devs that a new version was on the way - unless you count a Youtube video of giant eclair.

This has been a pretty good week for getting things to work together. — Dave Winer

webfinger.org

Looks like I got some catching up to do...



Or, I could just wait until the dust settles.

If you long for the time when programmers were programmers and wrote their own network stacks, take a look at content-centric networking:

A New Way to Look at Networking from PARCinc on Vimeo.

Website.

Code.

Every time I hear the phrase "Web of Data", I'm reminded of this quote by Henry Baker:

Because "algebraic relation theory" was much more respectible than "data processing", database theoreticians could now get tenure at respectible schools whose names did not sound like the "Control Data Institute".

Salesforce Chatter looks like it could actually be useful...



One of the reasons is that Chatter features hypermedia, as opposed to Wave, which lives in its silly pre-Web email world.

I believe that software design especially the design of interactive software, is literally a branch of filmmaking. No body has discovered that yet. Movies are events on a screen that affect the heart and mind of the viewer. Inter-active software are events on a screen that affect the heart and mind of the viewer, and interact. Also, they may have some side effect in terms of data. The interaction with the heart and mind may very well be the primary. — Ted Nelson

Bruno Pedro:

I'd say that RSS *is already* the basis for an open distributed version of twitter, facebook and so on.

So, what's missing here? Simple: someone please create a feed reader where I can also directly publish to my blog. Better yet, WordPress.org or any other blogging tool could have an embedded feed reader.

What would happen if we already had that? Well, I could be reading this post on my feed reader (aka distributed twitter) and then I could directly write a post on my blog replying to this post (aka distributed retweet or reply).

Grab on to something that's moving pretty fast. Let yourself be carried on when you're in the right place at the right time. — Dennis Ritchie

Don't collaborate, communicate

I think collaboration is a flawed metaphor for getting actual work done, as opposed to the kind of activity people are paid to do in offices.

For the office stuff, a "collaboration tool" like Wave might be a good tool. You can create a hidden conversation and chat with your loser peers about the sociopaths and clueless.

But in my experience, actual work happens almost exclusively offline, intuitively, in the back of the mind, on scraps of paper with coffee or bourbon stains.

Once you get results from that kind of work, you don't want to collaborate, you want to communicate.

Jeff Bone:

If you provide some binding / embedding to Tk and you think that's
sufficient to satisfy your GUI needs, then IT'S A NON-STARTER!  If you
DO NOT provide a CANONICAL cross-platform GUI toolkit, IT'S A NON-
STARTER!

If it's more than 5 readable lines to produce a "hello, world" web
server --- NON STARTER!

If sending an e-mail isn't a one-liner --- NON STARTER!

Getting a web page or making a simple http post > 1 line --- NON
STARTER!

Figuring out the number of days between two dates > 1 line --- NON
STARTER!

Alan Perlis:

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

If there's going to be a war for the web, fine, I already know what I'll do. I'll build the refugee camps. They will be very nice. Hiltons. You can have a beautiful ocean view or a view of the battlefield.

We'll all take pictures from our balcony. — Dave Winer

Break out in dance

The Blackeyed Peas compel the employees at the Microsoft Store in Mission Viejo, California to break out in dance, let their hair down and have some fun. This is an amazing store, the employees seem really excited and engaged, almost happy to be at work.



(via Paul Watson)

Unix in 14 lines of Ruby (it's trivial)

Anyone under 17 knows that Ruby is so extremely dynamic, that Google's complete Map.Reduce framework can be implemented in one line of code:

data.map.reduce

(Note the expressive and elegant object-orientedness that lies at the core of Ruby's efficient syntax...)

But now R is giving Ruby a run for it's money: Map/Reduce has been ported to R with just one line of code, too!

So clearly, we need to raise the bar here: I will show you how to implement Unix in a couple of lines of Ruby.

Yes, you heard that right. Ruby is so elegant and dynamic, that Unix takes just a couple of lines of code. Take that, C.

Other languages, like LISP, have lambdas and closures, but Ruby not only has these, but also continuations, blocks, procs, scopes, dos, and bacon! Mmmmh, bacon. (And btw, Ruby can implement Common LISP in a couple of lines.)

(There are a lot of articles that explain the differences between these, but as of Ruby 2.1.003m the schemantics of most of these have changed slightly, so the articles are out of date. As a rule of thumb: a continuation is a block that has been captured inside a scope where a do is in effect, and cannot be passed to a proc, only to a lambda. It's really quite simple. Matz has recently proposed a ten-year moratorium on Ruby development, so that we'll finally be able to understand all these.)

So here it is!



A sample run of this Unix for you're pleasure:

You have no mail.
$ uname
Runix 1.0
$ halt

All it takes to implement Unix in Ruby is 14 lines of elegant code.

It doesn't do processes yet, and it has no filesystem, but apart from that, it's a fairly complete Unix.

Ruby is a butterfly.

The future of print is ...

... writing something interesting.

Duh.

But with all this talk about Content, I had actually forgotten that.

Until I bought the newest issue of brand eins. Which is simply fantastic.

A Solution for Noise on Twitter

This is a mock-up for an application that hides the noise on Twitter:



Nice, huh?

Networking Named Content

You MUST read Networking Named Content from the good folks at PARC:

Network use has evolved to be dominated by content distribution and retrieval, while networking technology still can only speak of connections between hosts. Accessing content and services requires mapping from the what that users care about to the network’s where. We present Content-Centric Networking (CCN) which takes content as a primitive – decoupling location from identity, security and access, and retrieving content by name. Using new approaches to routing named content, derived heavily from IP, we can simultaneously achieve scalability, security and performance.

Steps Towards an Acceptable Lisp

Houston, we have a problem

I think that these two quotes capture perfectly the dilemma Lisp is in:

Common Lisp: The king of programming languages. – Slava Pestov

Lisp is Not an Acceptable Lisp. – Steve Yegge

On the one hand, Lisp is totally lovable, on the other hand my heart aches when I look at current Lisps.

Here are my thoughts about what an acceptable Lisp would be:

Generic

An acceptable Lisp would be generic, or protocol-based, meaning that all data types are defined by interfaces, rather than concrete implementations. Think STL, not conses.

Orthogonal

An acceptable Lisp would be built from orthogonal primitives.

One example is control flow. An acceptable Lisp could for example include call/ec and unwind-protect, and be done with it. No need for Common Lisp's salad of catch, throw, tagbody, go, block, and return.

Modular

An acceptable Lisp would include a serious module system, like O'Caml's, that really allows for programming in the large.

Object-oriented

An acceptable Lisp would be as object-oriented as Smalltalk, which means that the only way to get at an object's internals is via messages.

CLOS's generic functions show that OO integrates beautifully with Lisp's semi-functional approach to programming.

Extensible

An acceptable Lisp would be as extensible as existing Lisps, which means at least macros and reader macros, and maybe even OMeta-style completely extensible parsing.

Cutting-edge

An acceptable Lisp would have to bite the bullet, and do some language research, and/or adopt some of the novel results of the Scheme community.

One example is clear staging, aka phase separation. eval-when is simply ass-backwards.

Another example is a hygienic defmacro. It's the Lisp spirit, as evidenced by PLOT's use of hygienic macros.

Proven

Lisp is still lightyears ahead of most other dynamic languages, and an acceptable Lisp would have to carry forward these proven features: rich arithmetic, meta-object protocol, restartable conditions, optional dynamic scope, compiler-at-runtime, generalized references, etc, etc, etc.

Realistic

An acceptable Lisp would have a BDFL, a single implementation, focus on UNIX only, include lotsa batteries (or even better, power generators!), etc, etc, etc.

Unfriendly

I think an unfriendly community is a great feature, because it keeps idiots out, and there's no place for idiots in the world of Lisp.

This is (a wee bit) tongue-in-cheek of course, but the community should demand from n00bs that they do their homework, and do it well.

I'd much rather have a plainspoken, occasionally angry Linus-type character as BDFL, than a Guido-type, who tries to be n00b-friendly and forthcoming all the time.

Conclusion

Designing an acceptable Lisp is no walk in the park.

The designer of the Next Big Lisp has to keep a large area of the Lisp design space in his head, and make tasteful design decisions.

So, go ahead and just do it!

Python Community in Anguish, Pain, Despair Over Web Server

First they had the guts to punk TechCrunch, now Facebook picks a fight with the Python community by releasing a web server, called Tornado, developed by recently acquired Friendfeed.

Terry Jones, CEO of Fluidinfo, probably best expressed the pain felt by Pythonistas: "Words fail me on this one. I’ve spent some hours today trying to put my thoughts into order so I could put together a reasonably coherent blog post on the subject. But I’ve failed."

Facebook's Bret Taylor explains the reasons for such a highly unpopular move: "We ended up writing our own web server and framework after looking at existing servers and tools like Twisted because none matched both our performance requirements and our ease-of-use requirements."

The performance myth was quickly dismissed by an article which shows that Twisted performs almost as well as Tornado.



Pwpwp looked at the Twisted documentation, to dispel the ease-of-use myth. The wiki page Twisted Web Plan (aka What's Going On With Twisted Web) explains:

Currently there is a lot of confusion as to what to do and where to go to get a good, supported twisted.web server. Users are confronted with 3 options and an infinite number of permutations of those options: twisted.web, nevow, and twisted.web2. This confusion is made manifest in the lengthy explanation of web development with twisted hosted here on this wiki.

This is mostly a problem of perception, but there are some real issues. For example, there is a lot of redundant maintenance going on in, for example: twisted.web.static, twisted.web2.static, and nevow.static; twisted.python.urlpath and nevow.url; nevow.appserver and twisted.web.server.

As you can see clearly, it's mostly a problem of perception. The page continues with inspiring optimism:

However, at some point in the future, there will be one supported, good web server in the Twisted community, and that will be twisted.web.

A second page, titled Web Development With Twisted functions as a "roadmap to the wilderness that the landscape of web development with Twisted has become."

In conclusion, Twisted performs almost as well as Facebook's "cobbled together" newfangled Tornado, and Twisted developers have provided a clear roadmap to the "wilderness that the landscape of web development with Twisted has become".

Why Facebook/Friendfeed decided to create a new web server is completely beyond us.

Gadgets o' the Second Week of September '09

Samsung six monitor setup for AMD Eyefinity



iBUYPOWER Gamer Paladin



Logitech Drum Controller



USB Anti-Slouch Posture Alert



USB Mosquito Repellent Dongle



Bonus Dr. Hunter S. Thompson

Steve Presents New iPhone

Explaining Dave Winer

Phil Jones does it best:

What I'd suggest is that Winer understands, maybe better than anyone, how these things work as an "ecosystem". ...

Look carefully. Whatever Winer is promoting, he always has a tool and a format and some kind of hosting or central server and he's "dog-fooding" it and talking it up on his blog and he's finding new, quick-win, applications to extend the platform and he's making new connections into a user community and he's on the offensive, smacking down any potential rivals or threats to his authority ...

Why I don't want lightweight threads in my programming language

1. Integration with your virtual machine, be it Linux, the JVM, or Python, is integral to success. None of these platforms support lightweight threads, so you'll always be "foreign", and not "native" (cf. Erlang C nodes).
2. Scheduling should be done in the OS. If your OS' scheduler sucks, make it better, instead of implementing your own scheduler.
3. RAM/SSD storage means that we'll probably be CPU-bound in the future.
4. Real programming languages let you implement your own concurrency models. Try that with Erlang.
   

Gadgets o' the First Week of September '09

Philips Cushionspeaker Laptop Stand (Philips is really thinking about what moves us!)



Spider-Man Backpack (how did this get on this list??)



LG Widescreen Phone



Nooka SpongeBob Watches (uh)



Linux on Kindle



200$ HMD (gives you that winning smile)



Casio Retro Gold



Keyscraper Custom Keyboards



Fujitsu Esprimo Q 1500 ("about the size of a CD case according to Fujitsu")



Thinkpad Keyboard



Bonus Magritte (via the fantastic Lemonodor Auxiliary)

Laugh along with Dave!

Gadgets End of August 09

BrainPort (translates visual images into electric signals on the tongue "like champagne bubbles")



Platinum iMac



Sanyo Xacti



Nintendo football controller



Phyto-purifying shower



Paris Augmented Reality (don't show this to the French)



Samsung FINDmyTIME (I don't get what it does but it looks kinda cute)



Sharp Netwalker



Lenovo USB to DVI adapter



Bonus Image (via Antifuchs' wonderful µblag)

What I don't get about Wave: Robots

(Originally written as a comment on Writing a Wave Robot @ Science in the open.)

I think that having applications in the cloud edit what I wrote is wrong on many levels.

Obviously, trust in the robot provider is the biggest issue here.

Then, bugs in the robot implementation run the risk of completely destructing our data (which is balanced somewhat by Wave’s unlimited undo/playback, IIUC).

Then, this makes auditing content much more difficult, since robot contributions aren’t clearly marked (unless all robots use some common annotations…). Wave proposes the playback feature to discover the trail of changes that led to the current state, but I think that’s a bad idea: I don’t want to watch a possibly very long animation just to see who wrote what (Note: all of this is based on my limited understanding of Wave, which I haven’t tried yet.)

Then, there’s the engineering question of what happens to the robot-generated content when I edit what I wrote. The robot will have to reparse the text, and update its inserted content. But I may have moved, edited, etc, that content by purpose or accidentally. I think that’s just a big stupid mess altogether.

Introduction to Content-Centric Networking

By Van Jacobson:



There's also a Google talk, A New Way to Look at Networking, which is very worth watching:



Tip o' the hat to neuraxon77.

Zero-Latency Internet GUIs Using "Multiple Worlds"

I have discovered an interesting way to write zero-latency user interfaces for internet services.

It's similar in spirit to Alice ML's first-class futures, promises.

The basic idea is that every user operation that hasn't been acked yet by the server, results in a new "possible world" in some part of the user interface, that may have to be rolled back (if the server fails, for example).

The model (if you're a MVC person) is represented as a tree of operands, which are basically futures, containers for variables that reside on the server. GUI widgets subscribe to operands as listeners, and GUI operations are represented as first-class objects that change an operand.

/** A usually high-latency action that changes the states of one or
   more operands. */
interface Operation {
   public String getDescription();
}

interface OperandListener<OP extends Operand> {
   public void onOperandChange(OP operand);
   public void onOperandFailure(OP operand);
}

/** An observable variable with a last known state (usually retrieved
   from the server), and optionally a pending operation and a
   tentative state (a state that the pending operation would like the
   operand to have, but that hasn't been acked by the server yet).

   Clients of the operand should usually just call getState(), which
   returns the operand's tentative state if there is one, or the last
   known state otherwise.  This guarantees that the user sees an
   up-to-date image of the operation's progress.  (There is a danger
   however, in that the tentative state of an operand may be invalid
   from the client's perspective.)

   There can be only one pending operation on an operand at one time,
   and trying to start a new operation on an operand with a pending
   operation will result in an error. */
abstract class Operand<T> {
   protected T lastKnownState;
   protected T tentativeState;
   protected Throwable currentFailure;
   protected Operation pendingOperation;
   protected Set<OperandListener> listeners;
}

A GUI operation simply puts an operand in a tentative state, which locks the operand, so that it cannot be changed (by another operation) until the server has acked the change.

This means that a user can edit multiple objects on the screen, and each of these changes results in a zero-latency screen update to the new tentative state, and a background thread that tries to update the state on the server.

(I haven't implemented this yet, but it would also be possible to merge commutative operations.)

Storing JSON as Protocol Buffers

I love JSON (and I think that my HyperJSON format is the best data model in existence) but for some reason or other, I always have trouble with JSON libraries for mainstream programming languages.

As a way out, I have defined my own data model, similar to JSON's, but I'm serializing it as Protocol Buffers using this .proto file:

message Data {

    optional Text text = 1;
    optional Link link = 2;
    optional Entry entry = 3;
    optional Feed feed = 4;
    optional Date date = 5;
    optional Bool bool = 6;

    message Text {
        required string string = 1;
    }

    message Link {
        required string href = 1;
        optional string rel = 2 [default = ""];
        optional bool rev = 3 [default = false];
    }

    message Feed {
        repeated Data element = 1;
    }

    message Property {
        required string key = 1;
        required Data value = 2;
    }

    message Entry {
        repeated Property property = 1;
    }
    
    message Date {
        required int64 millis = 1;
    }

    message Bool {
        required bool bool = 1;
    }

}

There are a lot of different ways to store JSON in PB, and the details are pretty much irrelevant. An important point though is how the JSON objects (Entry) are stored: simply as a list of Property objects.

It's the same as with object-oriented programming: you never want to model extensible records (business objects, documents, etc) directly as objects (Protocol Buffers in this case). Instead, you want to compose your business objects from your programming language's native objects.

See Being poor at modeling is essential to OOP.

The Ideal Internet Information Object

Microsoft Announces Food Search Cooperation With Cuil

Redmond, WA - Microsoft (MSFT) today announced a cooperation with Google killer Cuil Inc. The next major release of Microsoft's search engine, Bing 2012, will incorporate the special Cuil Theory developed by Cuil, along with recipe search technology by Google killer Powerset, which Microsoft acquired earlier in a $100 million deal.

In an interview with the press, Microsoft CEO Steve Ballmer told reporters that Cuil Theory will further enhance Bing's standing as a so-called decision engine, especially when it comes to food-related decisions. "Others do nonfood searches quite OK, but the next big thing is food decisions," Mr. Ballmer said. "There is no better way to decide for, say, a grilled-meat restaurant, than Cuil's prized technology."



Mr. Ballmer declined to give any new information about .EAT, Microsoft's rumored major entry into the food decision market, but predicted that ".EAT will be bigger than Java" in an obvious blow to Oracle CEO Larry Ellison. He also told the press that this will be an opportunity to sell some of the tablet computers stacked in Washington warehouses. "What's better for food decisions than a table—t," Mr. Ballmer jokingly asked the reporters. "Get it, you dumb _____?"

Analysts were cautious, however. While both Cuil and Powerset were "quite effective" as Google killers, they weren't as successful as Wolfram|Alpha and other newcomers to the scene, a Silicon Valley analyst noted. "Hunting and killing Google will remain a favorite pastime of startup companies for some time. There's still more than enough Google to go around. Happy hunting!"

Gadgets o' the Third Week of August '09

iPhone Soap



MSI GT628



VTech KidiLook



ATS ULTra



Weird "Burn After Reading"-Inspired Sony Patent (source?)



Bonus Graphic (from this magnificent thread)