Re: On the subject of complexity

Hi Martin,

On Thu, Aug 30, 2012 at 9:54 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> It seems that a recurring theme in discussions is the cost to developers.
>
<snip of clarification that this is not about the poll question>

> --
>
> What has not been properly recognized in the debate is the presence of
> a trade-off.

Possibly this is because everyone in the discussion is experienced
enough that this is a given?  That engineering involves trade-offs is
pretty old news, after all.

>Building applications that have parts outside of your
> control sucks.  Sure, it's a natural consequence of trying to do
> anything more than the most trivial application.  That doesn't
> diminish its suckitude when it comes to writing and maintaining
> software.  For me, that's always been the attraction with open source
> software: when it breaks, *I* can fix it.
>
> The problem with a black box is that there is nothing I can do to fix
> it.  All my experience with browsers suggests that it takes a long
> time before you can be certain that the bug has gone away for good.
> Bugs introduced in 2001 are only now on a small enough portion of the
> web that they can be effectively ignored (if you are feeling
> aggressive).
>
> CU-RTC-Web attempts to address that trade-off rationally.  Yes, there
> is more work to get set up.  The advantage is in how applications are
> empowered to deal with problems.  Find a problem and there's a good
> chance that you can fix it.
>

Well, there may be a good chance that *you* can fix it.  But what
you're trading off is power for the power user versus ease of use for
the larger development community.   Perhaps even more problematic is
that it is only a specific species of power user that's going to be
able to take advantage of that ability--those with a deep knowledge of
the network internals that go into making WEBRTC work.  A power user
of javascript whose main focus is building a dating site, a casual
game, or a virtual car lot will probably not want to take advantage of
the power you wish to hand them; they will want the standard API to
work with a minimal amount of effort.

For someone building an application for which WEBRTC is not the main
focus, the ability to re-write a library to fix a problem is neither
going to be particularly practical nor necessarily their desire.  So
your trade-off may be rational for you, but I personally don't believe
that it is rational for the development community that's built the
games/user experiences that have already been demonstrated with the
current approach.  In other words, I agree with you that we're making
a trade-off.  But I personal believe that the current approach makes
that trade-off in a better way for a larger community than CU-RTC-Web.

regards,

Ted Hardie

Received on Thursday, 30 August 2012 17:44:05 UTC