Racket v6.6(blog.racket-lang.org)
blog.racket-lang.org
Racket v6.6
http://blog.racket-lang.org/2016/07/racket-66.html
27 comments
A(nother) cool thing about Racket is that they use GNU Lightning for JITing. Not only is the generated code decently fast, but the actual JITing is very fast. Last time I looked, the runtime compilation was considerably faster than LLVM. It matters more than you'd think.
John Carmack once said that he is developing VRScript based on racket. Does anyone know if there's any news regarding it's development?
He showed it off during a live coding session last year:
https://youtu.be/ydyztGZnbNs
https://youtu.be/ydyztGZnbNs
I emailed him in December, asking about the possibility to cross-reference VRscript snippets like you can with HTML and JavaScript. He replied he was hoping to take it in "a URI like direction", but that there was a "significant security review that needs to go on".
Right, the last I heard he shifted focus to Minecraft VR I believe and I haven't looked into it since then.
However, You can embed Racket in the Native C SDK examples if that's what you're looking for..
However, You can embed Racket in the Native C SDK examples if that's what you're looking for..
Of all the lisps, Racket appeals to me the most. It lacks the many warts that common lisp has, and has a very clean feel to it. I had tremendous fun solving problems on Project Euler and Rosetta Code using Racket. I highly recommend it for anyone even remotely interested in learing a lisp.
Why Racket rather than Clojure? I'm surprised.
I see that static typing is become a high priority development goal now, even in traditionally dynamic lisps. I see this as a positive for sure.
Matthias Felleisen, one of the developers of Racket, recently gave a talk about the motivation behind typed Racket; it can be found here: https://www.youtube.com/watch?v=XTl7Jn_kmio
I wonder if you could do something like prototype in dynamic (original, if you will) racket and then release in typed racket for performance/safety reasons.
I think that was one of the purposes of Rackets typesystem, to fit idiomatic Racket code well enough that you wouldn't have to rewrite most of it to introduce static typing to a Racket program.
Excellent talk. Nice to see it a Clojure conference. The points near the end about contracts vs. types was enlightening.
Minor correction, Matthias created Racket.
[deleted]
It seems that Racket became for Schemes what Common Lisp was for Lisps, which is really good.
Racket is famous for carefully chosen design decisions and nerdy attention to details, so in this sense it is much better than Common Lisp which was a dump.)
Racket is famous for carefully chosen design decisions and nerdy attention to details, so in this sense it is much better than Common Lisp which was a dump.)
I'm not really sure what you mean, but I don't see it. Racket did not develop a new standard that pulled together common practices across existing Scheme implementations, and other implementations did not adapt racket compatibility features, nor did additional racket implementations pop up. Racket does not appear to have supplanted use of other scheme implementations either. So, I'm looking for the analogy, but I'm not finding it. In fact, racket claims to have changed their name to "racket" in the first place because they were so far from Scheme that it was confusing to everyone (http://www.racket-lang.org/new-name.html). I wouldn't say that about Common Lisp vs predecessor lisps.
The analogy breaks down in quite a few places. In addition to the ones you mentioned, there are no multiple implementations of Racket.
That said, there is a similarity (and contrast) with CL in that, as a relative novice, there is enough of a cohesive system that I can imagine writing software in Racket. With other schemes, I've had the distinct feeling of starting from ground zero. Outside Racket, Chicken comes the closest, but is still a long ways off.
Take my comments with a grain of salt; I'm a neophyte who has pretty minimal experience writing any dialect of lisp.
That said, there is a similarity (and contrast) with CL in that, as a relative novice, there is enough of a cohesive system that I can imagine writing software in Racket. With other schemes, I've had the distinct feeling of starting from ground zero. Outside Racket, Chicken comes the closest, but is still a long ways off.
Take my comments with a grain of salt; I'm a neophyte who has pretty minimal experience writing any dialect of lisp.
Yeah, this analogy isn't perfect. The idea is that they are trying to collect and unify the best idioms and utilities from the Scheme world while continuing to develop their own packages.
In my opinion, it is Common Lisp that is famous for carefully chosen design decisions and nerdy attention to details, given the situation and the constraints (Darpa saying 'fix the situation or we cut funding', and lots of implementors anxious to push /their/ way.) Sure, everything isn't "just right" (e.g. READ-FROM-STRING, no 'parse-number'), but that's a universal problem.
Look at my comment below.
In what way was Common Lisp a "dump"?
Obviously by incorporating many pieces from various dialects without proper, careful unification in naming, ordering of arguments, eliminating redundancy, etc.
The examples of good care taken are library/base of Haskell (they really do rewrite core libraries when they have implemented a better idiom) and stdlib of Erlang and Racket.
The examples of good care taken are library/base of Haskell (they really do rewrite core libraries when they have implemented a better idiom) and stdlib of Erlang and Racket.
Some interesting reading on Dependent Types in Typed Racket: http://cs.stackexchange.com/a/41538/1709
Typed Racket is gradually typed, right? Does anyone have an example of a Typed Racket application that uses both static and dynamic typing effectively?
Matthew Butterick uses both in his typesetting applications: http://unitscale.com/mb/technique/dual-typed-untyped-library...
https://docs.racket-lang.org/quick/
Highly recommended even if you aren't looking to pick up a new language or delve into functional programming.