[racket] Blog post about Racket

Greetings.

On 2014 May 13, at 13:36, Matthias Felleisen <matthias at ccs.neu.edu> wrote:

> This is not a misconception. It's an understanding based
> on spending 15 years next to a top-10 department in scientific
> computing, in a computer science department that was spun off
> from that department, and a huge research group in the latter
> that supported the former. 

Maybe it's their misconception...  There are certainly plenty in the simulations community who see 'scientific computing' and 'dirty great honking big-iron simulations' as synonymous (with the possible inclusion of 'dirty great honking big-iron databases' if they're feeling generous).

> What has changed is the world and what it calls scientific
> computing :-) 

This is and isn't true.

Certainly, the world has changed in the sense that machines are more pervasive, and that (physical) scientists therefore will expect to do a wider variety of tasks on computers, and a wider variety of scientists will seek to do their work on computers (this changes the set of research possibilities, but that's not the point here).

However the class of scientists-doing-computing has always been a community of 'users who write code', and in that sense 'scientific computing' hasn't changed at all, even if the types of codes the users are writing has expanded somewhat.  Successful scientific computing frameworks or packages, or visualisation/data-reduction systems have typically been extensible or reusable or otherwise hackable.  Performance matters, but hackability matters a lot more (cf IDL).

So Python is successful for the same reasons that Fortran was: people who aren't interested in computing can pick it up and do useful stuff, by imitating what their officemates do.  That's partly because of library support: SciPy and AstroPy have 'scientific batteries included' , such as the ready access to file format readers, mentioned elsewhere in this thread.  However it's also, crucially, the immediate intelligibility of the syntax.

That's why languages like Racket (and Haskell and Clojure, but not Julia; see <http://arstechnica.com/science/2014/05/scientific-computings-future-can-any-coding-language-top-a-1950s-behemoth/>) will have severe difficulties in this area.  They look too much like something you have to read a manual to use.  They look, indeed, too much like Computing Science (which, for the more unreflective physicist, is the undergraduate subject for people who've dropped out of physics, and which is, to hear some people talk, entirely populated by aesthetes with cool spectacles, who get all the girls and who don't know anything about _real_ computing).

> Having said that I know that the above-mentioned group have
> moved to Java and claim to get decent performance -- but their
> programming style is, well, peculiar. 

With enough determination, you can write Fortran in any language.  Though it's really _hard_ to write Fortran in Racket, which is the disadvantage I mentioned above.

And another '+1' from me, for Software Carpentry.

All the best,

Norman
(with alternate signature, below)


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK
Editorial board, A&C  :  http://www.journals.elsevier.com/astronomy-and-computing/