Jonah Thomas wrote:
> When you regard something as "already solved" then you get the benefit
> of using the existing code, and you lose the benefit of improving it.
> And if you do enough of that, at some point it isn't worth using a
> better solution because if you do you have to keep converting to the
> style that the libraries use so you can keep using them.
I am constantly amazed at the cynical spin you manage to put on anything
that doesn't match your world view. I know it plays well in
comp.lang.forth, but where does this cynicism come from? It certainly
don't sound like experience.
Take a look at any library repository for any language that's been
around for a few years (Perl, Python, Lua, Ruby, TCL, PHP, etc.) and
what you will see is that there are often competing libraries for the
same problem. Why? If as you suggest that when problems that are
"already solved" people threw up their hands and said, "well, that's
done" then you wouldn't see that.
You also wouldn't see libraries that over time are marked as
"deprecated" with suggestions to use something newer (and presumably
better) if programmers didn't reevaluate existing libraries with
"already solved" solutions to look for something better.
Yes, there are certainly some programmers who when given a library can
only see problems in terms of that library. So what? If it enables
them to do their work, in what sense is that wrong or bad? And more
im****tantly, why are these programmers given such undue attention in
discussions like this?
I am *delighted* that there are libraries and tools that enable people
who in the past wouldn't be considered programmers be able to get
results. I think it's great, both because it brings more people to
actually making computers work for them they way they want, and it
upsets the priesthood of programmers. And that to me is always a good
thing.
> So we have people who do things with HTML with TCP/IP when it's utter
> overkill for their application, because they need to have all that
> machinery available for unrelated purposes and so it's available. Unless
> they desperately need something more efficient, why go to the trouble of
> developing anything else?
Any reasonably competent programmer can look at a standard like HTML or
a set of protocols like TCP/IP and probably come up with something that
is simpler or more efficient in some sense. But in doing that, you
create an island. And that's fine if you are able to operate in a
closed environment, but these days, interoperability is often a key
aspect of any design.
So it isn't that application developers turn to standards (like HTML and
TCP/IP) because their underlying systems already have it. In the
embedded world, your system rarely has anything by default-- you pick
and choose what you want based on what you need. Standards like HTML
and TCP/IP provide you something compelling you don't get by creating
your own simpler standard-- it gives you interoperability.
People *do* develop alternatives to standards all the time. In a system
I'm now working on, we store sensor data in a unique database format of
our own design. We could have used an existing database (such as
SQLite) for this application, but we didn't like the memory footprint or
some of the overhead. So the good part is we have a highly efficient
database that is tuned for our specific application.
But that's strength is also a weakness. You can't take our database and
read it in with desktop tools because it's a unique format. We've
created an island that works great for the specific things we want to
do, but will be a disappointment for people who may want to do something
more sophisticated. In our case, we don't care-- the pros of a custom
solution outweigh the cons of going with a database standard. But
that's not a general rule. It's specific to the application.
|
