I've been watching Octave mature for some time now. One concern that I have is the trend to move away from compatibility with MATLAB. Allowing endfunction, endfor, etc... makes sense for making Octave a nicer language from a programmers point of view, but it does not help engineers grab pieces of Octave code and use them in MATLAB. (Key for allowing a build up of confidence in the product)
I've adapted and can very quickly convert an Octave Toolbox to MATLAB, but having a good automatic converter would be much better.
If you want to attract MATLAB users to switch to Octave you need to make compatibility a top priority. Our company researched what is the most common language that Engineering students acquire through their studies in American universities, the answer was MATLAB.
To be honest, I think your argumentation a bit contradictory. You talk about Octave->Matlab compatibility (which is not guarenteed and not an octave goal, octave being a superset of matlab). Then you mention attracting matlab users. But these Matlab users shouldn't care at all about Octave->Matlab compatibility, as they're weren't using Octave in the first place. The only thing they care about is Matlab->Octave compatibility.
We've looked into alternatives such as Python, Scilab, R, and Octave. As Octave continues down the road of making its syntax more and more distinct from MATLAB it becomes a less viable option. In my professional opinion if I had to learn a new language I would go for Python.
Octave doesn't force you to write Matlab-incompatible code. You can write m-files using Matlab syntax and run them in Octave or Matlab.
The other compatibility issue I see is that the choice of FLTK for your widget set. If you are not aware, all of MATLAB's UI and GUI tools are based on JAVA AWT and SWING. I'm afraid the choice of FLTK will limit your compatibility in the future.
I don't agree. When using Matlab API, you don't see at all that you're using Java under the scene. This is completely hidden behind Matlab wrappers. So whether you have Java or anything else shouldn't really matter, except if you start using undocumented internals from Matlab, in which case you're on your own and your code can break on the next Matlab release.
Michael.