The problem with Matlab is that while it is fast for prototyping, it's difficult to write maintainable code in it (which is why I switched to python). Furthermore, you run into the issue of sharing code with people at institutions that don't have Matlab and Octave may or may not be compatible. Sometimes, an institution may have Matlab, but even if they do, they might not have access to the same toolkits you use (for example, I use a savitsky-golay filter as part of a peak finding algorithm--because it's in Matlab and we have a DSP toolkit, I just used that one. Because my collaborators didn't have it, I ended up rewriting the code in python--and this was for a group at a national lab...Now, imagine people at small universities and colleges...)
I like being able to see function signatures in a header file.
In Python or Matlab, I have to read the implementation to see what types it wants. To me, having collections of type signatures in a separate file is a huge boon when I have to come back to code I haven't seen for a while - it's a 10,000 foot view of what the code does that helps jog my memory - and it's guaranteed to be accurate, unlike documentation.
To the extent that static typing supposedly prevents bugs, I agree that it is overrated. My neutron transport solver I wrote in Haskell had plenty of god damn bugs after I got it to compile, thank you very much (perhaps a very deep Haskell-fu is required to attain the mythical "neutron transport solver that works right the first time" - in any case I realized that compiler-aided bug prevention is not a low-hanging fruit in Haskell, so I lost interest).
That was a long-winded way to say that I feel lost and alone without function signatures, and that this preference is possibly only quasi-rational.
Comments
The problem with Matlab is that while it is fast for prototyping, it's difficult to write maintainable code in it (which is why I switched to python). Furthermore, you run into the issue of sharing code with people at institutions that don't have Matlab and Octave may or may not be compatible. Sometimes, an institution may have Matlab, but even if they do, they might not have access to the same toolkits you use (for example, I use a savitsky-golay filter as part of a peak finding algorithm--because it's in Matlab and we have a DSP toolkit, I just used that one. Because my collaborators didn't have it, I ended up rewriting the code in python--and this was for a group at a national lab...Now, imagine people at small universities and colleges...)
I use Matlab mostly as a souped-up excel, for prototyping, and for the parallel computing toolbox.
If I plan on maintaining something, I want static typing, so the whole SciPy/Matlab/Octave/R debate is a little moot for me there.
I don't want to start a flame war, but I think static typing is overrated.
I like being able to see function signatures in a header file.
In Python or Matlab, I have to read the implementation to see what types it wants. To me, having collections of type signatures in a separate file is a huge boon when I have to come back to code I haven't seen for a while - it's a 10,000 foot view of what the code does that helps jog my memory - and it's guaranteed to be accurate, unlike documentation.
To the extent that static typing supposedly prevents bugs, I agree that it is overrated. My neutron transport solver I wrote in Haskell had plenty of god damn bugs after I got it to compile, thank you very much (perhaps a very deep Haskell-fu is required to attain the mythical "neutron transport solver that works right the first time" - in any case I realized that compiler-aided bug prevention is not a low-hanging fruit in Haskell, so I lost interest).
That was a long-winded way to say that I feel lost and alone without function signatures, and that this preference is possibly only quasi-rational.