Re: [hybi] Resolving Issue 11 - Amateur programmer requirement [was: Extensibility mechanisms?]

[Pieter Hintjens <[e-mail]>]

On Fri, Jul 23, 2010 at 5:02 AM, Robert Sayre <[e-mail]> wrote:

> Well, I'm not sure. The "amateur programmer" is a pretty terrible construct.
>
> It's unmeasurable and untestable, so it makes no sense as a requirement. The only way to find out whether hobbyists will be interested in writing servers is to finish the standard and see what they do. It's ultimately not that interesting though--many successful standards have relatively few implementations that everyone relies on.
>
> Any argument for simplicity probably has a better rationale than the needs of an imaginary "amateur programmer." Let's stick to substance.

Indeed.  That requirement by itself makes some serious unproven assumptions.

* First, that amateur programmers are somehow lacking in knowledge and
experience.  Many people program for fun, as amateurs, but with years
or decades of professional experience.  If we want to make the
protocol accessible to programmers with less than a year or so of
practical experience, let's say so explicitly.  "WebSockets must be
comprehensible for programmers with less than 12 months of
experience".

* Second, that explaining the protocol in baby steps and using
dumbed-down constructs is easier to understand, for programmers with
more or less experience.  That is patronising and makes no sense.  Are
we trying to address programmers with lower IQs rather than less
experience?  Then we should say so explicitly.  "WebSockets must be
comprehensible for programmers with IQs of 90".

* Third, that this pandering to the weak-minded correlates with
simplicity, while building a protocol for smarter programmers with
sufficient experience ("professionals", to continue this nasty use of
language), correlates to complexity.  No, simplicity comes from
reusing experience and doing it *right*, and that requires massive
experience, which is why organisations like the IETF exist.

* Fourth, that making a protocol accessible to inexperienced, less
intelligent programmers will ensure its success.  That suggests that
the successful protocols of the world were build by inexperienced
idiots, which would be insulting if it was not so obviously taken from
The Onion.  "Schoolkid (5) invents Internet 2, sells to Google for
$50bn".

I'm not sure whether it's more tragic to consider this requirement as
"serious editorial input", or as a sophisticated troll.

If the goal is to achieve wide implementation, the protocol should be
clearly written so that experienced, smart programmers can implement
it without shock or surprise, and build interoperable stacks that work
as expected.  That might make a concrete requirement.

Here are some Twitter comments I found from one (smart and
experienced) developer implementing server-side support for
WebSockets:

* "No! You idiots, do not make HTTP headers in WebSockets *unicode*
when HTTP itself is not: http://is.gd/dz13m  Protocol layers do not
need it!"
* "Putting crap between 0x00 and 0xFF characters is NOT FRAMING:
http://is.gd/dz13m  A frame has a size component so you can send
binary data."
* "Ok, if you've written forty-five (!) steps for how a *client*
connects a WebSocket then you should realize you need to redesign
something."

-Pieter