My son called last night to find out what toolset I would use to build a website.

I had a hard time answering him, for several reasons.

First of all, I wanted to know what his use case was.  And, as I suspected, the aim of the exercise was to build some kind of web application, not just a content site.

But I hardly know what toolset I want to use myself for building web apps.  I spent a surprising amount of (elapsed) time in 2015 dithering about this topic myself.

My reading and talking with tech friends has led me to focus on JavaScript in general and the JS MVC frameworks in particular.  But I wasn’t sure I wanted to urge that on my son.

He’s just learning how to write code, whereas I wrote code for years.  Why inflict a horrible language like JavaScript on someone who’s just setting out?  It’s like the old advice I got to start with BASIC, which I did and then had to unlearn most of it when I started using Pascal and Lisp.

(I was charmed and blown away to read that Paul Graham and Co. had used Lisp to implement their eCommerce startup ViaWeb, and even more charmed by his argumentation about why it was a sound choice.  Bravo, Paul Graham!)

And the MVC bias for me is probably just that, a bias.  I love elegance as much as the next geek, but, as Albert Einstein said so many years ago, “If you are out to describe the truth, leave elegance to the tailor”.  The MVC frameworks like Angular and Ember lay a big trip on you the coder; I’m happy to accept it, since power comes from observing constraints, but why inflict that on my son?

I ended up saying that I thought the #1 criterion for adopting one of the many frameworks was the level of support he could get for his choice.  Support comes in different flavors of course:

1. Online support, like documentation, tutorials, discussion groups
2. Meetups and other real-world interactions
3. People you know well enough to ask them for help at 1 am

I laid stress on the last one, although I was careful to let him know that I was hardly someone whom he could ping for help, not because I wouldn’t drop everything to help him at 1 am or any other time, but because I’m still a babe-in-the-woods about Angular — the one I think I’m going to work with — at best.  My advice would be possibly one step ahead of what he could do for himself, if that.

He mentioned that his girlfriend had mentioned Django as a possible framework that she had used at some Hackathons.  I’ve read a bit about Django and said I thought it would be great if she knew something about it and could help him figure out problems.  But he said she knew very little.

So I ended up plumping for Angular and disclaiming my advice at the same time.

What advice would you give?

As I think about my last post on walled gardens and dumb pipes, a simple thought occurs to me: AOL didn’t fail because it was walled garden.  AOL failed because it was a dumb pipe.

The value proposition of AOL back in the day was, “We’ll pre-digest the Internet for you, and put it in a safe, packaged form that’s good for beginners, children, and digital immigrants”.

Actually, the value proposition back when I signed up in the early ’90’s was, “We’ll give you an Internet ID that’s a name, not a number”.  Recall that their big competitor walled garden at the time, Compuserve, had User IDs that were a pair of numbers.  <300129, 1235> or the like.

But by the time we got to the beginning of the end for AOL, they had a walled garden: they figured that their inmates would be too terrified to leave.

I suspect what happened, however, was that the “inmates” began to receive offers from other service providers that were 1) competitive in price and 2) better in terms of bandwidth and latency.  So it’s not that people became tired of the walled garden, it’s that another service provider — in what became essentially a commodity market — had better service for a lower price.

Classic Dumb Pipe stuff.

Now, to be fair to the argument, the “features” of AOL — especially AOL IM, which was hegemonic for a while — should have kept AOL as a “smart pipe” and didn’t.  But it’s amazing how quickly people found those features irrelevant when the price was right.

I just published a review of Nick Bostrom’s book “Superintelligence: Paths, Danger, Strategies”.

Pdf of the review: Gordon – Superintelligence Book Review (Spring 2015 IST)

My basic thesis?  AIs need a Freudian superego to keep them from getting uppity.

The review appeared in the Spring 2015 issue of Issues, the thought magazine of the National Academies of Science

Let me know what you think.

I’ve been finishing up this book during the week.

The gist of it is: “What can we do now to prepare for superintelligent AI’s who may not have tender regard for us humans”?

Right off the bat, let me say that I’m glad someone is thinking about this.  For reasons that he details in the book, Nick Bostrom believes that we need to be talking this rather abstruse topic before a superintelligent AI comes on the scene, because it could happen pretty damn quickly.  It’s a worthy argument.

As an investor, I’ve run across a species of startup — and sometimes even more than startup — that acts as if it were a technology-powered platform of one sort or another, but is in fact a group of staffers frantically updating, tweaking, massaging, typing in commands, etc. behind the scenes.

I’ve started calling this kind of a company “service as a software”.

There’s some reason to do so.  SaaS companies are famous for having revenue leverage; once you’ve signed up subscribers (and provided they don’t churn) your revenues from them recur without any new cost or effort on your part.

Service-as-a-software companies are just the opposite: you never get out of the customer-acquisition cost, because keeping customers going requires labor power every step of the way.  Instead of recurring revenue, these businesses have “recurring CAC”.

Write in with your favorite examples of “service-as-software”…

I’m giving a talk at MakerCon on 5/13.

The topic is “A Strategy for Getting QS Apps to Interoperate”.

Ok.  It’s not the best title.  It used to be even worse: “Disruptive Standards as a tool to facilitate data interoperability in the quantified self app ecosystem”.  Longer than the 20 minutes of the talk…

But it’s an interesting idea, or at least I think so.

It drafts off a thought I blogged about in this post some years ago.  Gist of the argument is that a certain kind of standard — which I call “disruptive”, after Clay Christensen’s “disruptive technologies” meme — actually aid in ecosystem coalescence.  The standards need to be not-too-strict, but strict-enough.

I’m a big Quantified Self junkie, and it seems like an ecosystem in need of assistance coalescing, so I wanted to workshop my ideas with (hopefully) sympatico minds in the room.

Room 202/203, 3:30 PM PDT

If you’re around and so minded, please join me.