Wow thanks for all the feedback.
First, I don't think that you don't want MATLAB code to run in Octave. But it is now obvious that some of you do not care if Octave code runs in MATLAB.
I personally do not have MATLAB on my own machines. I do have MATLAB at work. The problem is that our organization's IT department is more or less controlled by a branch of the Department of Defense. Octave is currently not approved for use on the network, but I am working on that. Under tight budget constraints we have been forced to have so few licenses that having access to that tool is limited. For ~2000 employees (60% or more engineers) we only have 8 floating license seats. To make matters worse, we only have one seat of the Signal Processing Toolbox! I do signal processing all the time.
I can't do anything about the budget, but I can do my job and advocate for something other than MATLAB.
Most engineers I know have no clue about Octave. (I'm spreading the word!) MATLAB has been taught in our schools, is used by all major suppliers, and is known as the standard (for better or worse). Engineers, especially the babey boomer's generation here in the USA tend to be very conservative and risk adverse. Something different, no matter how good it is, is a risk. I'm fighting this all the time! I tend to embrace FOSS solutions. I've advocated for Linux since I was in high school, worked with Octave at home for about as many years, and use LibreOffice. I believe in what you guys are doing.
So, when I can take the Signal Processing Toolbox from Octave and run it in MATLAB it allows me to prove (in a more credible way) that Octave is a sound alternative.
You shouldn't have to run Matlab to prove that Octave is a sound alternative. You should run Octave instead.
(I've done that, thus eliminating the constraint of only one seat of the Signal Processing Toolbox) If you write any portion of Octave toolboxes such that they will not run on MATLAB it is a risk that some portion of code that we develop will not run on a customer's machine who is running MATLAB. Industry is settled on MATLAB, and not being able to collaborate with customers and industry partners is a huge risk factor.
Everybody is free to develop toolboxes in Matlab-compatible way or not. But I think the goal of octave-forge packages is to develop toolboxes primarily for Octave. It's not to develop toolboxes that can be used as a drop-in replacement in Matlab, allowing users to work around Mathworks license fees. I even think it's wise to do it that way. As someone mentioned a few months ago, Octave is not a concern for Mathworks. But doing what you suggest has the potential to change that.
JAVA. I've developed specialized GUIs using the MATLAB/JAVA interface. Scroll panels, trees, tabs, splitpanes, and much more are not in the default MATLAB handles graphics system.
Indeed. And you can do (at least partially) the same using the java package from octave-forge (except that java GUI does not work on OS X, because of limitations on that platform). But if you're thinking about mixing regular Matlab handle graphics object and plain Java GUI, then afaik you're using Matlab undocumented/unsupported internals and what you do now can break on the next Matlab release if Mathworks decides so.
Michael.
Jacob, no pressure here ;), but getting the IDE is a key for the engineers I know to be willing to adopt Octave. I've subscribed to your blog as well as most of the other summer of code participants. Keep us informed.
I might be able to help Ben Lewis with the Wavelets. It is an area of interest and I should be picking up an ATI short course at the end of February.
I think I can come up with a good oct2mat solution, but that will have to wait until this winter.