Hi Liwei, I believe disabling debugging and tracing does accelerate the evaluation quite a bit from inside DrRacket. On my system, it seems to be running my code at the same speed as the main racket binary.
Dex On Sat, Apr 25, 2020 at 7:35 AM Liwei Chou <wanpee...@gmail.com> wrote: > Dexter Lagan於 2019年7月22日星期一 UTC+8下午4時52分42秒寫道 >> >> From my perspective the only barrier of entry to Racket is the >> documentation: it is very clear, detailed and well-written, but to certain >> of my students they can also be quite obscure, especially to those who >> don’t have comp-sci background and those whose first language isn’t >> English. The best example is the few pages about continuations. For quite a >> while I could not understand what they were about from the Racket docs, and >> it took quite a bit of web crawling to find meaningful examples of their >> use. I also found the pages about macros lacking simple examples, and it’s >> not until Beautiful Racket that I finally found very basic uses. >> > > I agree with Dexter's opinion about documentation. > > I was reading "The Racket Guide" and found it too verbose for a newcomer > with some programming experience. Then I discovered "Teach Yourself > Racket", which is easy to read and I'm really enjoy. > > https://cs.uwaterloo.ca/~plragde/flaneries/TYR/ > > I strongly recommend to include "Teach Yourself Racket" in the beginner's > guide section of Racket 's official website. Or produce some more materials > like that. > > Another aspect is about the tooling. > > Stephen helpful forwarded my feedback here. > https://groups.google.com/d/msg/racket-users/PftpYnJt49c/2abSsQOYAgAJ > > I just quote here. A little bit about my journey as a newbie. > > When I started to learn Racket, due to the slow startup time and huge > memory consumption of DrRacket, the overall impression given to me was that > it’s very inefficient. > > After done some micro-benchmark, it did show that it did not perform well, > and It did make me hesitate. *(barrier for beginners)* > But I still want to try it, because I am very interested in its > expressiveness. And I’m happy to find out it’s actually quite fast. > > The micro-benchmark I ran is. > > > (time (for ([i (in-range 10000000)]) > (void))) > cpu time: 115 real time: 115 gc time: 0 > > (Now I know it’s due to the debugging stuff...) > Turn out in DrRacket, it’s about 16x slower than in Racket REPL. > > However, there isn't a convenient way to separate normal build/run from > debug build/run, which conventional development environments usually do. > > My point is, the impression of this language is not very efficient, which > is bad, and will scare some people out. Which is a barrier also. It would > be better if not the case. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/140e226d-ed25-4aac-ae95-4f5f347bb3ba%40googlegroups.com > <https://groups.google.com/d/msgid/racket-users/140e226d-ed25-4aac-ae95-4f5f347bb3ba%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CACUENr%2BPNW-6dzf04jWiP1TPXKD%2BkfbwEukf3%3DLVwqRcWq3_vA%40mail.gmail.com.
