One of these days I will go and play with Python. It seems that it is popular. I have not used R, but like you said, it is geared towards stats. The one thing that I really like about the Matlab language is the fact that it handles the input of vectors and matricies so well. It is just as a TI calculator handles it. One of these days I may also try F#. That seems like it could be a nice language for doing numerical analysis. So much to learn, so little time!
I'm not ready to use F# in production (partly because I don't think most other programmers would be able to maintain the code), but after skimming Programming F# I can say it looks groovy. It's also featured in Real World Functional Programming (along with C#). It's real mind expander (in a good way) for most programmers (including myself, although I've been using some functional techniques for years).
Yeah, I almost launched into learning F#, but I will wait for a while. It does look really nice, and the fact that it can be done Visual Studio is also a plus in my book. I really like the Visual Studio IDE. Eclipse is also nice, but I am not the biggest fan of Netbeans. It just has some things that make me scratch my head from time to time. My only exposure to Netbeans has been with MPLAB X, and it was a great step up in features compared to MPLAB 8, but then I started to learn the ARM Cortex M series chips from various vendors and they are all using Eclipse of one form or another. I like it much more over Netbeans. As for trying to learn C#, I have also really also enjoyed Visual Studio.
@Aeroengineer: "One of these days I will go and play with Python. It seems that it is popular"
I started to learn Python in January and this is a very powerful mathematics tool when used in combination with NumPy, SciPy and Matplotlib packages. You can work out filter coefficients and responses in a very similar way to that of Matlab/Octave -- there are a lot of libraries included on SciPy!!
Python is becoming very popular in scientific applications, and a growing number of universities and research centers are using it -- the great advantage of Python for scientific programming is its focus on code readability.
But for sure, a lot of students knows to program in Matlab language, so Octave has been a great alternative for those --like me-- who love Open Source!!
GNU Octave uses the Matlab language, though not all the libraries that are available for Matlab are avaialble for GNU Octave. This does not prevent you from coding these functions up yourself. The GNU Octave team has a reporting method that allows you to report if a function does not work the same as it does in Matlab.
GNU Octave is also uses the interpreted method. Both Python and C# are interpreted, but I am not sure about R. I know of it, but I have not used it.
Yes and no. The fundamental difference between an interpreted and a compiled language is the nature of execution.
In a purely interpreted language like BASIC, the BASIC interpreter reads each line of the source code, converts it to the underlying machine instructions, and executes it, then goes on the the next line. It provides interactive development at the cost of speed, as it must translate each source line to object code before executing it every time.
In a compiled language like C, the compiler does the translation to object code and (assuming things compile and build without errors), the end result is a machine language binary that can be run directly, with no translation required. Develoment takes longer, but execution is far faster.
Python and Java occupy a place between those two extremes.
Python is like Java (and I believe C# is similar). You write Python or Java code, but you don't run it directly in an interpreter, like you would a BASIC program. You compile it, and the output of the compilation is bytecode, which is executed by the language runtime.
This is a major feature of Java, which is described as "Write once. Run anywhere." Java compiles to code targeted at a virtual machine implemented by the Jave runtime. The bytecode is the same, regardless of the machine. You can write and compile Java code under Windows and run it on a Mac. (I sometimes use IBM's Eclipse IDE. Eclipse is written in Java. I use the same binaries under both Windows and Linux.)
Python behaves similarly, and I have several products here that are written in Python and inherently cross-platform.
If raw speed is required, you probably still need to write in something like C++, compile with optimization, and link to build a binary for your platform. But current hardware gets progressively faster and cheaper, and many things are now being written in Java or Python because the underlying hardware is fast enough to provide acceptable performance and you don't have to resort to C.
There's almost nothing about any particular language that makes one an interpreted language and one a compiled language, although most tend to be use in one form, or the other. Almost all of the "interpreted languages" you cited are compilable and have compilers (BASIC has had compilers available for over 30 years, for example). To compund matters, not all interpretation schemes are equivalent. The BASIC example you cited is pretty much the worst-case, and isn't used very much in practice anymore by most languages. Most are reduced to some intermediate language (in varying degrees by one implementation or another) to gain runtime efficiencies.
Conversely, some classically compiled languages also have implementations that exist in interpreted form, for example, "Ch", an interpreted version C (which if memory serves, Jack Ganssle stumbled on and wrote an article about ~5+ years ago).
To confuse matters even more, some languages may be run in a (usually managed), virtual machine environment... or not. The classic Java implementations do the former, although multiple compilers do exist for Java. As far as Python goes, its runtime is in C, and the bulk of what many Python programs do is probably spent running code that was written (and optimized) in C.
Back to MATLAB/Octave... MATLAB is both piecewise and majority-compilable (perhaps to C as an intermediate step) to native code, if you choose to do so (although in MathWorks tradition, it may be something that you have to pay extra for). It's also compilable to HDLs for stuffing into FPGAs. Depending on how you partition/implement your project, it's supposed to get pretty close to native hand-written code speed. Leaving it interpreted can have its advantages, but if you have "the need for speed", that option is there. I can't speak to Octave and what, if any, path to native code it has.
Some of the typically interpreted languages have been optimized pretty heavily to get one fairly close to native speed. In some cases I don't doubt that they can actually be faster than the code that even a decent programmer may write in one of their favorite compiled languages.
Using a relatively mature clasically interpreted language, one's probably going to get 90%+ of native code speed, and in many cases a lot closer than that. In reality, most people don't write code to 90% of their highly-optimized compiled language anyways. Using an interpreted implementation may even be a net-win for most folks.
I am not sure that I could get it done in three. I know that most of the ARM vendors have their tools that can be integrated directly into a generic version of Eclipse, but setting up a toolchain for Eclipse seems to be rather difficult. I can usually get it mostly working, but I always seem to miss something, and instead of spending hours to work out the problem, I usually just sacrifice soem HDD space for another IDE installation.
@Aeroengineer: setting up a toolchain for Eclipse seems to be rather difficult.
Not that difficult, and I've seen an assortment of Eclipse IDEs from vendors with their own extensions built in. Eclipse has a package manager for adding extensions if you don't get a customized version. There are an assortment of customized forks of Eclipse out there, including a few the vendors charge for. See http://texteditors.org/cgi-bin/wiki.pl?EclipseFamily for a no doubt partial list.
It's why Eclipse took over most of the IDE world. It can be extended with custom classes for whatever development you do and language you do it in. There are lots of other IDEs out there - see http://texteditors.org/cgi-bin/wiki.pl?IDEFamily for a list I know of - but as far as I can tell, if you develop for the Windows platform, you use Visual Studio, and if you develop anything else, you likely use Eclipse. And because Eclipse is written in Java, you can run it on anything with a reasonably current Orace/Sun Java runtime. I run Eclipse here under Windows and Linux, using the same binary distribution, and could run it under OS/X, too.
In the good old days of Scope Junction, Michael did a series of blogs evaluating the different options. As we all know the old content is not available (grumble and mutter), but if you contact him (via EDN's Design Ideas I guess) he should still have access to those blogs.
Do you happen to know the title of the post, I may be able to go to the internet wayback machine and pull it up. I will be honest that the main reason that I have gone after GNU Octave is because I already have some familiarity in the language and I needed to get something done without having to learn another language. The specific version of GNU Octave I mentioned is a particularly nice version. It is kept up to date as well as improved rather constantly.
SciCos is another MatLab / Simulink clone from France -- it includes a GUI and Simulink like block diagram editor -- Having done work with French Equipment, and Working For French Companies is how this project is funded -- It also features C code generation and is a reasonable check for Matlab / Simulink -- as a second method to check the simulatiions/results.
Regarding program execution speed, Octave (and of course Matlab) are specialized for matrix computation. The basic native type is a matrix (one-, two- or multi-dimensional collection of real or complex floating point numbers).
Those languages shine for calculations that can be expressed as linear algebra operations: e.g. when you are multiplying a signal vector S(i) by the vector of FIR filter coefficients F(j), which would simply be written as S*F.
Such operation is very quickly passed on from the interpreter to the underlying linear algebra libraries (BLAS, LAPACK, etc). Those libraries are usually very carefully optimized, and for long vectors the overhead of interpreting the commands is well amortized. In fact, it's quite possible that a naive compiled program in C or Fortran might end up being slower than executing such command in Octave or Matlab, unless the C program uses similar tricks as the optimized BLAS library.
Of course it's not always possible to express the compilation in 'vectorized' form, i.e. to write it as a set of linear algebra operations on entire matrices. When the interpreter has to walk through the matrices element-by-element using a similar nested loop construct as would be familiar in compiled C or Fortran for writing matrix operations, the compiled languages will be faster.
One of the things that I really love is as you described, the ability to handle matrix math. In almost all other languages, this is almost an afterthought, but in Matlab, Octave, and others this is a native feature. It strikes me odd that it has not become better handled in other languages as time has gone by.
I was first introduced to GNU Octave during the Stanford ML Class (Fall 2011 - it is now a Coursera class); it was used exclusively, mainly because of the native vector/matrix math. The class was amazing; I hadn't touched vector/matrix math in over 20 years, so I had to do some "brush up".
What really intrigued me, and then it "clicked" - was how to vectorize a process (and how to think about and understand when a process can be converted in such a manner); that was a great takeaway from that class. The light really clicked for me when we had to vectorize a neural network simulation; I finally had found a reason to build/own a Beowulf cluster (or an NVidia Tesla desktop supercomputer)! Not that I've built one (can't really afford the electricity) - but at least I grasped something that was important to me, and could be used on one.
As for Python, it too has some great numerical libraries available for it; playing around with those while using it in the Udacity CS373 course showed it had similar power and usefulness (though not as "native" as Octave's implementation - but close enough!)...
It is very true that often times a system of equations can easily be set up into a vector math. I think that this was the biggest shock when I came to C is that doing vector math is not all that easy, and not native. It is a real pain when you have to take something that is linearized and solve it through substitution.
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...