[sword-devel] Why Sword?

[John Stovall]

I just read about compile time errors in RH 7.2.  I can fix anything
on any computer if I have enough time.  The problem is that most
of us missionaries don't have enough time.  I also can use windows
but windows also takes time and costs too much money to benefit
my students on foreign soils.  I like most of the ideas presented
on this list.  But for third world missionary efforts in my opinion the
emphasis of Sword needs to be turned towards very easy to use
Linux modules.  Most of the world is very poor.  They can't afford
windows and I can't encourage them to steal it.  Many of them do
because they can't use software like Sword on Linux but the same
software is available in an easier to use windows version.

On Sunday, February 10, 2002, at 05:27 AM, David White wrote:

> 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
>>
>