From: Scott Sauyet on
Richard Cornford wrote:
> On Jul 6, 2:16 am, Scott Sauyet wrote:
>
>> In my experience, software tools are very rarely complete.
>
> Is this a "software tool"? It sounded like a browser script, and it
> also sounded like a browser script with a finite scope; to animate SVG
> graphics in an HTML 5 Canvas.

I don't see a good reason to differentiate them. By "tool" I was
trying to distinguish this from complete applications, which are
commonly finished, although competition often requires release of new
versions even of those. Whether the target is a browser or an OS or a
virtual machine doesn't, IMHO, affect the argument.


>> Almost always, there is some reason to extend them, to simplify
>> them, to fix minor or major bugs,
>
> But it wouldn't make sense to extend things in an arbitrary way, and
> after sufficient time a script that does a finite job effectively will
> stand a good change of being pretty much bug free and as simple as it
> is needed to be.

Of course arbitrary extensions are not particularly wise -- although
they are unfortunately common -- but I find that new situations that
sound like good fits for existing tools but don't quite fit are often
the cause for extending said tools. And that is a good reason for an
extension. As to bug-free, I find that I discover very old bugs as I
try software in new environments.


>> to make them compatible with additional systems.
>
> The odds are that the only systems with which this needs to be
> compatible are (ECMA)scriptable web browsers with HTML 5 Canvas
> support. So long as that is based on feature detection instead of
> object inference or US string browser sniffing (and the script follows
> the pertinent standards/draft standards) new environments are unlikely
> to be an issue unless/until someone issues (and someone else
> implements) a new standard that is not back-compatible.

I'm not saying that it can't happen, and obviously your experience is
different from mine, but I would personally be surprised if a tool
based around these standards today and not modified again will be a
preferred solution in half a decade.


>> Mature products certainly slow down and have longer release
>> cycles, but often the end of regular development indicates
>> that the tool is no longer being introduced into new systems.
>
> But that does not have to be true for cross-browser scripts. I
> regularly use script components that are more than half a decade old,
> and the only modification any have seen over most of that time is to
> have branches for Netscape 4 and IE 4 removed (as no longer worth the
> download overhead).

And can you imagine in a few years removing support for multiple event
registration models if that ever settles down? Such simplifications
are part of the process I have come to take for granted.

I have not looked at the tool under question at all, but if the SVG
format is updated, I would expect a useful library to release a
version compatible with the new version of SVG. If the Canvas specs
are extended with some useful features, I would expect the library to
take advantage of them. And quite possibly if someone comes out with
a nicer format to take the place of SVG, I would expect the author to
consider whether the library could be extended to take advantage of it
or possibly release a separate version to work with it. Of course the
author might not find any of these upgrades worthwhile, but if there
is


>> YMMV, of course, but I tend to become suspicious of tools
>> that haven't been updated in a year or more.
>
> Apparently. I tend to regard something that has been in use for half a
> decade and not changed in that time as reliable.

Usually I don't get a good sense on how much such tools are used
unless they are my own. I agree, if they are in regular use, and
especially if they are still being used in new development, I can
expect that they are likely reliable, but I have little experience
with third-party tools like that.


>> Often they've been abandoned, and I will have to find and fix
>> any bugs I encounter.
>
> People certainly do abandon projects, but it must be possible that
> some people just finish them.

I'm sure it's possible. I'm certain it's happened. But in my
experience, it's rare.

--
Scott