Hi Matthias, Thanks for your comments!
> Hi Konrad, thanks for the post. It is quite illuminating because > I wouldn't have thought that we're that close to 'performant' in > this domain. I was a bit surprised as well, but I found that the math library is really a pretty good foundation for scientific computing. Note however that I didn't look at performance, which is not really important for most of what I do. > In order to turn a Racket (Lisp, Scheme) program into Rackete data, > you to perform (roughly) the following actions: add '( to the > beginning of the program and add ) to its end. In order to turn a > Python (C, Java) program into a piece of Python data, you need to > add " to its beginning and " to its end. I am ignoring module or > package structure here. > > The difference between those two methods is the amount > of parsing left to the implementation. I perfectly agree with that summary, but to me this difference is very important. 90% of the people I work with do a lot of programming but have never taken a CS course. Show them s-expressions, and they will immediately see that this is something they could work with. Tell them to parse Python code from a string, and they will stop listening. It's too far from what they feel comfortable with. BTW, there is another practically relevant difference: the Lisp family gives programmers a well-defined hook into the compiler for pre-processing specific expressions. Most other languages don't. Python gives you the option of reading a whole module as an AST, and then modify and compile it. But that's a lot of overhead and it doesn't provide much flexibility because the parser limits the syntax so much. > We don't think of Racket's syntax system as a 'macro' system and I > personally do not use the phrase. Instead I say 'syntax system' and > when asked I call it a compiler API. I agree that the term "macro" should be banned, but I don't think I can contribute much to that. > 3. Well, minor point but when you state that "I am aware of only > three other languages developed in a similar context: OCaml, > Haskell, and Scala." please do keep in mind that GHC is a Microsoft > product, OCaml comes from INRIA, which compares to a university the > way Versaille compares to a MacMansion in a Dallas suburb. I know that the means behind these projects are very different, but my point about the roots of the languages in academic research is valid nevertheless. I'd like to see more of this. > Could you port your framework and use the FFI to get data > via some existing HDF5 and net CDF library for now? That's an interesting idea. For my own domain, I think it would be much easier to interface the HDF5 library directly using the FFI. The reason is that everything written on top of HDF5 is written in Python, whereas HDF5 is plain C. Making languages with different garbage collectors work together is such a pain that I am not very motivated to try. I guess this problem will ensure the survival of C for many years to come. An HDF5 wrapper using the Racket FFI looks definitely possible, but getting it efficient is perhaps not trivial. The fundamental problem is that the datasets being read and written are potentially huge. Any interface that ends up converting or even just copying arrays of 2 GB is going to be too slow for use in real life. If the FFI can provide C-pointer access to something like a flvector, and ensure that it's not garbage-collected for the duration of a C function call, then a good interface should be doable. > We have separate educational mailing lists for instructors, > and we never see any of the 300-400 students from Northeastern > alone that use Racket on a semesterly basis. Most of these > students never figure out that there is a 'user' mailing list :-) If they don't see a need for it, great! Konrad. ____________________ Racket Users list: http://lists.racket-lang.org/users