Skip to main content.
home | support | download

Back to List Archive

Re: RE: Combining SWISH++ and Swish-E

From: Paul J. Lucas <pjl(at)>
Date: Mon Nov 02 1998 - 17:34:20 GMT
On Mon, 2 Nov 1998, Mark Gaulin wrote:

> Right now swish-e is the "official" version and swish++ is (correct me if I'm
> wrong) one person's effort.

	Both packages are under the GPL.  I consider them to be on
	equal footing in terms ov availability and changeability.  As
	far as being "official," I would say that, no, SWISH++ is not
	"officially" part of the SWISH-E effort, but SWISH-E is not
	part of the SWISH++ effort either.  Presumeably, SWISH-E is
	endorsed by Berkeley, but, outside of Berkeley, that doesn't
	mean anything.

	As far as being "one person's effort," I fail to see what that
	has to do with anything or somehow makes SWISH++ subordinate to
	a multi-person effort (which is what I infer from what you
	wrote).  The number of people who work on a software project is
	unrelated to the functionality or quality of the software.
	Some big examples of good single-person efforts: vi (Bill Joy),
	emacs (Richard Stallman), Perl (Larry Wall), TeX (Donald
	Knuth), C++ (Bjarne Stroustrup).

> In either case it is difficult for any programmers other than the people
> directly in charge of the code to make changes.  It would be nice if a
> distributed, "open source" system was put in place so that individual
> contributors could get in, make changes, and get out.

	Excuse me?  Both packages are under the GPL.  That mens anybody
	is free to grab the source and makes changes.  If that isn't
	"open" I don't know what is.

	FYI: I've already received some patches for SWISH++ and
	incorporated them.  The authors of said patches apparently had
	no trouble obtaing the source code and making changes.

> And, for the record, I would love to use C++ over C for this, or any project.


> Hey, maybe porting swish-e to C++ would solve those nagging ansi/not-so-ansi
> C porting issues we had when 1.3 was released.

	Well, yes, porting SWISH-E to C++ would solve that problem, but
	so would porting it to ANSI C (which I had always assumed it
	was, but, from reading others' experiences, I guess it isn't).
	IMHO, there's no excuse for having a non-ANSI C program these

	- Paul
Received on Mon Nov 2 09:44:35 1998