Same here, really enjoying it. I have/had a few pain points, but I'm writing a detailed review of the book as I go through it and those will be in there.
The fact that the documentation is written in a form of Racket really helps with that, I think.
Having the documentation be parsed by the same infrastructure that understands the programs that you're annotating really goes a long way toward making the documentation cross-referenceable and easy for developers to work with.
I just wish there were an established way of documenting Packages (the PLaneT replacement).
It is nice! My main issue is that Dr Racket is so pleasant I'm sorely tempted to use it and it brings my laptop to its knees (that feature that draws arrows from uses of identifiers to their definitions always freezes my computer for half a second to a second; if I evaluate something that consumes any non-trivial amount of memory Dr Racket starts swapping like it's 1999 and becomes unresponsive). I used Racket for a while from the REPL and everything worked beatifully but I constantly missed the Dr. In the end I switched to Chicken, which at least for my programs seems to be quite a bit faster too (I mean compiled Chicken code vs JITed Racket, of course, the Racket JIT is usually substantially faster than interpreted Chicken). Chicken also has great library support, so switching was not painful at all.
(Of course, I don't write fancy macros, so I wasn't taking advantage of Racket. For 99% of the macros I write syntax-rules is good enough.)
A few other things I prefer the SRFI way, for example, Racket's comprehensions seem awkward compared to SRFI-42 (in particular Racket decided to call the main comprehension for*/list, leaving prettier and shorter names to less useful variants such as the exotic parallel-by-default for/list, or the execute-for-side-effects and parallel-by-default for); but all in all I agree that Racket is pretty sweet. If ever own a computer with more than 2GB of ram I'll definitely give it another shot.
Some years ago though. Wrote the "style browser" stand-alone application in DrScheme. Damn! Feeling nostalgic about Scheme as I browse through some old code :)
If you're looking to dabble in Racket and are looking for pet project ideas, here is one I've had in mind for years --
Make a "browser"!
By that I don't mean make something that renders HTML/CSS, runs JavaScript, etc. Instead, make a browser whose "HTML page" is actually a Racket program that loads off a http URL and runs in the "browser"'s window. racket/sandbox is a candidate for sandboxing these runs. Give the script access to drawing on the window, making a sound, limited file system access, etc over time. A standard http server can serve these files, but something extra fun would be a server that also runs Racket that you can use s-expressions to communicate with (bye bye JSON).
It's a Javascript VM that interprets Racket bytecode. It's complete enough to run, eg. World/Universe games or render HTDP2e pictures. Might be useful for some of what you're doing.
I keep using it from time to time. I have some java libs I am forced to use so I am using clojure.
I use it for personal projects and as some glue in my larger projects (processing text / html documents etc) now but I hope I can ship a full project related to work in it soon.
This was a bug-fix release. In Typed Racket, one set of fixes adds support for struct:, define-type, and require/typed at the REPL. The DrRacket bug with [ on some keyboards was also fixed. For the rest, see the log above.
20 comments
[ 3.0 ms ] story [ 58.7 ms ] threadThe racket docs (http://docs.racket-lang.org/) have a list of tutorials at the top. There's a visual art/programming tutorial for those new to lisp (http://docs.racket-lang.org/quick/) and a webapp one (http://docs.racket-lang.org/continue/) that demonstrates Racket's built-in web framework.
Having the documentation be parsed by the same infrastructure that understands the programs that you're annotating really goes a long way toward making the documentation cross-referenceable and easy for developers to work with.
I just wish there were an established way of documenting Packages (the PLaneT replacement).
(Of course, I don't write fancy macros, so I wasn't taking advantage of Racket. For 99% of the macros I write syntax-rules is good enough.)
A few other things I prefer the SRFI way, for example, Racket's comprehensions seem awkward compared to SRFI-42 (in particular Racket decided to call the main comprehension for*/list, leaving prettier and shorter names to less useful variants such as the exotic parallel-by-default for/list, or the execute-for-side-effects and parallel-by-default for); but all in all I agree that Racket is pretty sweet. If ever own a computer with more than 2GB of ram I'll definitely give it another shot.
Some years ago though. Wrote the "style browser" stand-alone application in DrScheme. Damn! Feeling nostalgic about Scheme as I browse through some old code :)
https://code.google.com/p/muvee-style-authoring/
If you're looking to dabble in Racket and are looking for pet project ideas, here is one I've had in mind for years --
Make a "browser"!
By that I don't mean make something that renders HTML/CSS, runs JavaScript, etc. Instead, make a browser whose "HTML page" is actually a Racket program that loads off a http URL and runs in the "browser"'s window. racket/sandbox is a candidate for sandboxing these runs. Give the script access to drawing on the window, making a sound, limited file system access, etc over time. A standard http server can serve these files, but something extra fun would be a server that also runs Racket that you can use s-expressions to communicate with (bye bye JSON).
I'm hoping that the prototyping can lead to Racket being the tools and authoring platform.
Racket is a great environment for developing DSLs and graphical tools.
http://hashcollision.org/whalesong/
It's a Javascript VM that interprets Racket bytecode. It's complete enough to run, eg. World/Universe games or render HTDP2e pictures. Might be useful for some of what you're doing.
I thought that Whalesong was a Javascript code generator rather than a VM ?
Unfortunately JS performance on iOS rules that out for our purposes.
I use it for personal projects and as some glue in my larger projects (processing text / html documents etc) now but I hope I can ship a full project related to work in it soon.
This was a bug-fix release. In Typed Racket, one set of fixes adds support for struct:, define-type, and require/typed at the REPL. The DrRacket bug with [ on some keyboards was also fixed. For the rest, see the log above.