RE: The future of Octave

[j . logsdon]

Picking up a few of the ideas but mainly furthering my own (I must admit),
perhaps the answer to why Linux and R have been successful is that the
syntax etc of the application has been defined before.  Linux follows
exactly the organisation etc of Unix, even picking up coding etc from some
implementations and R follows as exactly as possible the open definition
of that statistical programming language.

For this reason, the bazaar approach will work since there is a target,
which can be modified but only within the open standards.  The developers
can be proactive.

Where software is trying to replace/replicate a piece of proprietory
commercial software, it becomes much more difficult as the developers have
to be reactive rather than proactive.  Some people will get involved but
it is difficult to develop the spirit since there is always the feeling of
not being in control.  For this reason, responding to the 'can we have
feature x compatible with Matlab' is a truly depressing request,
particularly as it presumably generally comes with no attached development
funding.

This mould can only be broken when there is a major step forward.

For example I think most word processors that are not going to challenge
Word since MS will bring out a new copy that is similar with some subtle
alterations or, more pertinantly, MathSoft brings out version 5 etc with a
different internal format.

Most people are 'happy' with the offerings from MS and therefore all the
others are left running round trying to produce software that will 'read'
Word (or Excel, Access etc).  None of them do a really good job
unfortunately - again very depressing.

The solution then is to develop an open standard for a new generation of
mathematical tool - including high dimensional arrays, sparse matrix and
all the other tools (GUI and non-GUI), graphics etc that have been
mentioned in this thread.  I completely agree that the danger of GUI's is
wygiowycc (what you get is *only* what you can click) and would not like
to see a basic command line interface lost but I am drifting into personal
preferences that are better developed in a more structured way ...

Note that I am not suggesting actually doing the coding - it is the
standard that needs to be set.   That is where the S language came from.

In many ways, the R program does provide a lot of what you need although
the syntax is different (and less natural at least to start with).  It
includes multi-dimensional arrays and integrated graphics for example.  I
know (to take fellow statistician and Linux user Ted Harding's point) I
could do some obscure calculation in R and then pass an ASCII file to
Octave but in practice this would be a waste of time - I would just carry
on in R. In fact, ISTR there are Octave reading facilities in R and some
of the R-folk have also contributed to Octave at least in the past (maybe
still now).

If the standard is acceptable, various groups (probably including several
commercial developers) will try and meet it and the product will emerge.
It may well be based on Octave - the syntax is already worked out - but it
could include approaches from various other packages.  Many of the
toolboxes used in S-Plus and Matlab have actually been contributed freely
and the spirit is probably still there.  The big problem with the
commercial packages is that they cost too much.

However this really needs planning.  I get the strong feeling that Octave
has probably reached a natural limit - or at least break - and some
reflection is called for.  Any volunteers to start the standards ball
rolling?

John




-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------