I was assuming that the use case cited above by drej was doing a complex, big system requiring numerical computation/analysis. It was mentioned that Julia was rejected on grounds of being immature technology, so I assume we're talking about a big project, perhaps destined to run as a server or as a clustered system.
The use case you imply is different, it is more like a scientist working alone at a workstation for interactive calculations, in which case perhaps Python with Numpy and Scipy is just perfect.
In any case, for the previous use case (complex, big system), i'd use CL for the calculations themselves, for the visualizations I could do interactive web graphics using the extremely nice Bokeh library for Python. I'd use Bokeh under Python (using Flask as a web framework) for the presentation layer, and the Lisp system for the actual calculations.
> Yes it can reach near C/Fortran speeds, but how much time will I spend optimizing it?
I guess you are aware that for maximizing speed in C you need to be very careful on how you write your code. In this sense there is no easy way out in any language. The good part is that Lisp, unlike C, is garbage collected, so working on a piece of code can be easier since there is no need to deal with pointers, allocation, and deallocation. It also supports arbitrary number precision and fractions and complex numbers out of the box, no need to do anything in particular to optimize their performance nor rely on external libs to operate on them. It is particularly good (speedwise) with big integers and arbitrary precision numbers.
As for Common Lisp itself, besides that observation -which applies to all languages-, you need to add type declarations. This improves the performance a lot. You are going to add type declarations on a statically typed language (C, C++, Julia, Java, etc) anyways, so i fail to see how this could take more time than in other languages.
Alright, so slightly different assumptions. You're talking about using CL for just one part of the process which is reasonable if not a little frustrating if one must switch between multiple different technologies.
Binding to GSL was kind of my point. That requires a lot more setup to use the FFI and bind what you need to CL. In Julia I imagine one either does A*b or loads a batteries included library first and then does that. My point being there is a fair amount of overhead to CL to get to that magical development spot :).
I think I've seen that plotting library in the clicki link, but it has a long way to go if you're used to Matplotlib, JS, or what is included in .NET.
The type declarations is another thing that the user would have to research and deal with. In Julia it is just part of what you do, so a bit more natural unless you can declare the types in standard CL without loading a library or something else odd. Can you just (define int(a) 3) and let the compiler guide you? I honestly don't know, but don't recall seeing that in the lisp tutorials and books I've read. My s-exps are probably wrong too lol.
The GSL library is already usable in CL, no need to add bindings, i included the link.
> you can declare the types in standard CL without loading a library or something else odd. Can you just (define int(a) 3) and let the compiler guide you?
Yes, and yes. No need to load anything and the declarations are simple as in "(declare (fixnum a b c))". The compiler does the rest. You can also specify ranges, etc.
"declare" is part of the ANSI standard.
> I think I've seen that plotting library in the clicki link, but it has a long way to go if you're used to Matplotlib, JS, or what is included in .NET.
There are many libs, not just one. But you might be correct, in which case i'd just have the visualization done in JS or .NET (etc), and just load the final for the plot through HTTP from the Lisp server (which is the one which did the heavy lifting.)
I didn't know GSL could be used right out of the box. That's good to know. The declarations part is pretty nifty too. I can't believe I didn't notice that before.
Perhaps easy for you and probably not super difficult for most people considering CL, but it's still a bigger pain than having 1 single tool that can build fast code with very little hand optimization, REPL, analysis libraries, built in plotting, and with a familiar syntax. Thanks for all the comments though. You pointed out parts of the CL ecosystem aren't nearly as bad as I thought. You should consider some blog posts if you've done this sort of thing before!
The use case you imply is different, it is more like a scientist working alone at a workstation for interactive calculations, in which case perhaps Python with Numpy and Scipy is just perfect.
In any case, for the previous use case (complex, big system), i'd use CL for the calculations themselves, for the visualizations I could do interactive web graphics using the extremely nice Bokeh library for Python. I'd use Bokeh under Python (using Flask as a web framework) for the presentation layer, and the Lisp system for the actual calculations.
BTW, CL does have many libraries for plotting: http://cliki.net/plotting
> Are the built-in linear algebra, optimization...etc libraries good, or must I toil with FFI?
You can use the GNU Scientific Library also within Lisp, to do everything you mention and more:
https://www.gnu.org/software/gsl/
https://common-lisp.net/project/gsll/
> Yes it can reach near C/Fortran speeds, but how much time will I spend optimizing it?
I guess you are aware that for maximizing speed in C you need to be very careful on how you write your code. In this sense there is no easy way out in any language. The good part is that Lisp, unlike C, is garbage collected, so working on a piece of code can be easier since there is no need to deal with pointers, allocation, and deallocation. It also supports arbitrary number precision and fractions and complex numbers out of the box, no need to do anything in particular to optimize their performance nor rely on external libs to operate on them. It is particularly good (speedwise) with big integers and arbitrary precision numbers.
As for Common Lisp itself, besides that observation -which applies to all languages-, you need to add type declarations. This improves the performance a lot. You are going to add type declarations on a statically typed language (C, C++, Julia, Java, etc) anyways, so i fail to see how this could take more time than in other languages.