From help-octave-request at bevo dot che dot wisc dot edu Sun Dec 10 17:01:20 2000 Subject: RE: The future of Octave From: j dot logsdon at lancaster dot ac dot uk To: help-octave at bevo dot che dot wisc dot edu Date: Sun, 10 Dec 2000 23:01:16 +0000 (GMT) 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 -------------------------------------------------------------