[sword-devel] Why Sword?

[David White]

I am the developer of a GNU GPL-based Bible program (found at
http://www.whitevine.com/biblereader) that is not based on Sword. I
usually just lurk here, to catch up on happenings in open source Bible
s/ware development, but I thought I would response to this, explaining
why I chose not to use Sword.

I started my project about two and a half years ago; I was in college at
the time. There were three major reasons why I chose to do everything
myself, rather than use Sword, these were (1) it's so much cooler to do
your own stuff; (2) some professor or another had deceived me into
thinking that C++ was a horrible, inelegant language, and that C and
Java were much nicer; and, (3) the searches in Sword seemed very slow.
Naturally, (1) is silly, but is always going to crop up, particularly
from students and younger programmers. (2) is fairly silly, although in
the Unix world, C is still often preferred strongly over C++ (I seem to
remember a survey of some Linux distribution, which found that around
70% of the code was in C, with only around 15% in C++).

Initially, I put a substantial amount of effort into writing my program,
but since this has slowed, largely because I started working, and
because I realised that community-developed projects, such as Sword are
the way to go. I would be perfectly happy to deprecate my project, and
point users to Sword and Sword-related projects, except that I feel
there are two legitimate reasons for someone to use my program rather
than a Sword-based program. I think Sword has some nice features, and I
would love to see it get better; the two areas in which it lingers
behind though are:

(1) Searching in Sword is slow.

I have seen people comment on this for a long time, and I have seen
little effort to fix it. In my opinion, searching is by far the most
used feature in a Bible program, it should thus be the most concentrated
on. For example, searching for the exact phrase "in the beginning", case
insensitive, through the KJV takes over 10 seconds using BibleTime on my
computer. It takes a few milliseconds using my program. Even grep (I say
"even", because grep cannot benefit from any kind of optimisations, due
to knowing the type of data it is dealing with, or having the file
preloaded, etc etc) can complete the search in about 1 second the first
time, and then less than a tenth of a second for subsequent searches
(obviously due to fs caching). I have no idea why Sword is so slow
compared to other programs, but I think if you are to convince people to
use Sword rather than do it all themselves, you *have* to make searching
fast.

(2) Sword is difficult to install.

I don't know about other platforms, but on Linux (and I would imagine
other Unix variants), Sword, and whatever frontend people are going to
be using it in conjunction with, is difficult to install. There have
been many occasions on which I have tried to get BibleTime working on my
system, and I haven't been able to, because of compilation errors, or
library dependencies, or I forget-what-else. Other people experience the
same problems; I can't count on my fingers the number of times people
have written to me and said, "I tried installing Sword, but it didn't
work...I tried installing your program and it just came right up!"

Looking at the Sword website, it seems to me that substantial effort has
been done to make the Windows version of Sword easy to install, but not
the Unix/Linux version. I would suggest that it is a mistake to assume
Linux users are technically apt, and able to follow complex installation
procedures. Today I received an email from a user asking why, when he
typed "Make", it told him the command isn't found. In developing an
application for Unix, I think it's still very important to make it as
easy to install as possible.

I think that once Sword addresses these two issues I have listed above,
it will be an excellent library. Until it does, too many users will give
up in frustration to even see its full potential. This has been
confirmed to me by many users of my program, who have written to me,
comparing my program favourably over a Sword-based program; every one of
these users cites one or both of the above reasons as the major problem
with Sword.

I hope this doesn't sound like a rant, it's not meant to be. I am simply
trying to point out reasons why programmers may choose to use libraries
other than Sword when developing Bible-based applications, and how Sword
can improve to address these issues.

God Bless,

David White.

On Sun, 2002-02-10 at 11:51, Chris Little wrote:
> 
> > > Sword removes much of the burden of designing new Bible software.  
> > > Most of the underlying issues, such as search, file access, verse 
> > > reference parsing, markup format interchange, i18n/l10n, etc. have 
> > > already been dealt with, allowing you the opportunity to focus on 
> > > interface design and unique features.
> > 
> > Well, i18n and l10n are still quite at the beginning. You 
> > should not say 
> > "have been dealt with". The versification scheme is still to 
> > come -- is that 
> > what you mean by l10n?
> > 
> > > Custom
> > > translation APIs provide the means for building l10n 
> > support in your 
> > > applications without needing to add or depend on additional 
> > 3rd party 
> > > libraries.
> > 
> > What are you referring to?
> 
> To my understanding, based on what Troy has told me, the translation
> functions we have could be used for any string.  All our
> library/front-end strings could be put into the locale files with
> translations to provide l10n across the library.  So, I think the
> functionality exists in the library, though it hasn't yet been used to
> its full potential.  Correct me if I'm wrong. I may have misunderstood
> Troy. :)
> 
> Versification is a different issue entirely.
>  
> > > Sword provides a simple to use and easy to learn API.
> > 
> > =) I really hope it were so. ;) We should work more on 
> > documentation, esp. 
> > making the api-ref more complete and explaining.
> > 
> > But in general I really agree!
> 
> I agree.  The API primer that we keep directing potential users to could
> really use some cleanup.  It's confusing, out of date, and doesn't
> reflect the kinds of things implementers would actually do.
> 
> --Chris
>