Thanks, your blog post very succinctly summarizes what I have been looking for as a feasibility analysis. We are in quite similar places of thinking about the scientific computing present and looking to the scientific computing future.
It doesn't look like Racket (or anything) will be an easy replacement for what we do in Python now, but Racket still looks the most promising to me at the moment for what I am looking for in the long run. I look forward to seeing how it progresses. Thanks also for the pointers to these interesting projects! Best wishes, > John, > > > I am exploring whether Racket could be a Lisp replacement for > > Python in scientific and engineering calculations. I currently use > > Python extensively in teaching chemical engineering courses > > (http://kitchingroup.cheme.cmu.edu/pycse/) and in running molecular > > simulations (http://kitchingroup.cheme.cmu.edu/dft-book/), but I am > > interested in transitioning these to a Lisp. > > If "a Lisp" is all you want, the easiest transition path would be to > Hy (hylang.org). That said, Racket has much more to offer in terms of > a "Lisp experience". > > > Python works for scientific/engineering calculations because of > > numpy/scipy/matplotlib which provide the majority of our needs, and > > largely they just wrap C/Fortran numerical libraries. It is also > > distributed with batteries included that make it trivial to install > > these days. It seems like Racket can do this too. > > Yes. The main difference between Python and Racket in that respect is > the size of the already existing ecosystem for scientific computing. > Racket has much less (much, much, much less), although what's there > (the math library, in particular providing arrays and plotting) is > excellent. > > Racket's CFFI can be used much like Python's, with the added advantage > that you can leverage the macro system to generate much of the > boilerplate code associated with that kind of work. It's just that > almost everything remains to be done, whereas in the Python world most > popular C and Fortran libraries already have FFI-based wrappers. > > If you decide to try out Racket, consider a look at > > https://github.com/pedropramos/PyonR > > which is a Python implementation for the Racket universe. It won't help you > with the CFFI stuff, but it will let you reuse pure Python code. > > Finally, you may be interested in a summary of my own experiences with > Racket for scientific computing: > > https://khinsen.wordpress.com/2014/05/10/exploring-racket/ > > > How feasible would it be to use Racket to solve the problems > > described here: http://kitchingroup.cheme.cmu.edu/pycse/pycse.pdf > > I don't expect any difficulties with doing all that in Racket, but do expect > to spend some serious amount of time on it. > > Konrad. -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
