plans within plans within plans: September 2009

2009-09-25

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.

2009-09-16

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!

2009-09-14

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.

2009-09-11

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

2009-09-10

Steve Presents New iPhone

2009-09-09

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 ...

2009-09-08

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

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).
Scheduling should be done in the OS. If your OS' scheduler sucks, make it better, instead of implementing your own scheduler.
RAM/SSD storage means that we'll probably be CPU-bound in the future.
Real programming languages let you implement your own concurrency models. Try that with Erlang.