>An imperative API makes functional abstraction harder. What are the main >selling points for Scheme/Racket now?
I am a big believer in functional programming (and static types) for large projects, but there is an undeniable bit of awkwardness compared to just imperatively poking things for small projects. That is one of the wins for Scheme -- I can make it super-easy to get easy things working, but it isn't just a "scripting language" unsuitable for large scale development. I am going to have to sort out my Racket / Chibi module strategy sometime soon, though. As far as language choice goes, I don't claim to have broadly evaluated every possibility and chosen the optimal one. Java or C# would have been more familiar to a broader base of game industry developers, but I really didn't want to drag in all the bulk of a JVM / .NET system, and a class focused world view seems less suited for the smaller scripting tasks. Javascript would have been more familiar to a broader base of web industry developers, but I have basically no experience with javascript, and little desire to explore it (which is admittedly a fault of mine). S-expression reading and writing is a strong factor for network communication, and I like the fact that there are available options for Scheme to interpret / compile / compile-to-C. I can see valid use cases for all of them, and I'm not sure how important each will be. The bottom line is that I have been enjoying myself working with Racket / Scheme this year, and I have evidence that it has been objectively productive for me, so I'm going out on a bit of a limb and placing a bet on it. >Initial impression: 7 years after starting to program in Racket, it still >surprises me how easy it is to do something >useful in just a few lines of code. A big goal here is to make the authored code very clear and simple. I may yet get to a single #lang vr <ip address> declaration that gets rid of the boilerplate at the top and bottom of the file and flips the right switches to make Racket closer to R7RS. There are sets of creative-types that are learning how to put things together in Unity to accomplish fairly simple media related tasks. I think I can make it easier for them with very domain specific helper libraries and a little bit of scheme. >Seems like the first thing anyone does when using the OpenGL API is write >something like `cmd-quad!`. I am probably also going to make something similar to the old immediate mode APIs for building up static geometry meshes at init time. The design usage is to reference pre-processed models loaded from the net, but there will still be cases where you want to algorithmically build something like a camera-specific projection screen. >In case the problems importing SRFI 1 were just finding the proper >incantation, it should be this: > > (import (srfi :1)) I was having pair / mpair issues with the r6rs. >If you're at all interested in a matrix/vector library whose operations have < >4 ulps error (provided floating-point arithmetic is correctly >rounded) and transforming normals even when the affine matrix is >noninvertible, check out > > https://github.com/ntoronto/pict3d/tree/master/pict3d/private/math > >particularly the files "fl3.rkt", "fl4.rkt" and "flt3-unboxed-ops.rkt". >(Warnings: it's rather undocumented, there's a prevalent >`call/data-type-values` pattern that I haven't taken the time to get rid of >yet, and it >relies on some (easily copied) math/flonum macros.) I'll take a look. I am mostly mimicking the math operations we have in our C++ codebase now, and I expect that I will make C versions of at least the expensive matrix multiply / matrix invert operations to accelerate the embedded Scheme code. -- 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.
