I just wanted to say that Racket docs are the best docs I have ever seen. It feels they document everything -- so much detail. Treasure trove of knowledge. Thanks guys!
Racket v7.2
61–70 of 77 posts
Re: Racket v7.2
#62Earlier quoted context omitted.
> Seems like the most common answer to this might be SICP Please don't. SICP is beautiful and all, but it's neither an intro nor practical/immediately useful. There's a lot of enlightenments to be had by reading it, but they have very little to do with Racket specifically. IMO, it's a bad book if your purpose is learning Racket. > You might, as a novice coming to Racket , find "Realm of Racket" to be more approachabl…
Please don't what, have an opinion? I read SICP as an experienced programmer and I didn't find it impractical at all; in fact, it kickstarted my interest in other lisps. I read Realm of Racket as an experienced programmer (after knowing Common Lisp and Clojure well) and it was entertaining and, yes, a gradual introduction to Racket. I'm sorry if you disagree, but was answering the question that was given with a coupl…
And on a more general note - let's leave the misunderstanding to the separate thread - I'm glad you liked the books! I'm not saying you can't enjoy them - far from it - but if your goal is to just learn Racket quickly (where I interpreted "experienced dev" as "short on time working adult") then they are not the best resource for that. SICP is not even about Racket at all and RoR includes a lot of introductory material you wouldn't need. Instead of learning by accident, ie. reading weakly related material and hoping that an understanding will somehow form (which seemed to be default mode in education), I prefer using materials which are strictly on topic and are dense enough to be efficiently absorbed, but not so dense that it takes a day to go from one page to another. And to that my answer is: Wiki, tutorial&cheatsheet and the docs.
What is obvious is that YMMV - I'm just saying what I'd do if I wanted to efficiently learn Racket today. That's it.
Re: Racket v7.2
#63Racket is such a cool project. I keep telling myself I'll find the time to do something serious with it, but I never get around to it. One minor bit of criticism - would be it be so hard/expensive to hire a designer to do some minor touching up of the DrRacket GUI? It looks like a toy, and the icons didn't even look good in 1998. I'll balance this criticism with the remark that any language/platform that manages to a…
> and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance Unfortunately they are not doing it for performance reasons. They are doing it solely to make the code base cleaner and easier to maintain. Based on their most recent blog on the subject ( https://blog.racket-lang.org/2019/01/racket-on-chez-status.h... ), the new backend is almost uniformly s…
The new backed is overall faster according to that post. In addition, looking at raw Chez, the results are even more one-sided. Chez is always faster and often 2-8x faster. New racket is usually faster and where it isn't is mostly due to new IO. Sure, compile times get bigger -- Chez is doing way more optimization passes than Racket (Chez is the only scheme I know of that can get close to SBCL in performance).
http://blog.racket-lang.org/img/posts/2019-01-29-racket-on-c...
According to them, fixing things takes much less time and is much easier to understand. For a system where lots of development is free, ease of understanding and fixing is extremely important.
> But I do know that I the main thing holding me back from investing more development time in Racket is its poor performance compared to languages like PHP, Python or Go
Racket is slower than Go because racket is dynamically typed, is a much higher-level language, and has to implement continuations. Racket is much faster than python or PHP.
My big issue with racket is dev tools. DrRacket isn't very good IMO. They need to make a server that implements the Language Server Protocol with some additional hooks for more dynamic lisp stuff. At that point, devs can choose to use all kinds of actually good editors (sublime, VS Code, Vim, Emacs, IntelliJ, etc) for coding. They can even add the LSP to DrRacket and continue to use it.
Re: Racket v7.2
#64Mike Sperber used Racket in his excellent 35c3 talk "How to teach programming to your loved ones": https://media.ccc.de/v/35c3-9800-how_to_teach_programming_to... From the abstract: "A word of warning: The resulting approach is radically different from most teaching approaches used in universities and schools. In particular, it avoids teaching purely through examples and expecting students to develop the skills to ar…
Sperber is an amazing speaker and fantastic programmer. This is a great talk. He'll be talking about similar things at Racketfest, the Racket conference I'm currently organizing (https://racketfest.com). The idea is to build on what are called design recipes, a brilliant idea (or family/scheme of ideas) developed by core Racket guys (see their How to Design Programs [https://htdp.org]).
Re: Racket v7.2
#65Earlier quoted context omitted.
Please don't what, have an opinion? I read SICP as an experienced programmer and I didn't find it impractical at all; in fact, it kickstarted my interest in other lisps. I read Realm of Racket as an experienced programmer (after knowing Common Lisp and Clojure well) and it was entertaining and, yes, a gradual introduction to Racket. I'm sorry if you disagree, but was answering the question that was given with a coupl…
And on a more general note - let's leave the misunderstanding to the separate thread - I'm glad you liked the books! I'm not saying you can't enjoy them - far from it - but if your goal is to just learn Racket quickly (where I interpreted "experienced dev" as "short on time working adult") then they are not the best resource for that. SICP is not even about Racket at all and RoR includes a lot of introductory materia…
Yes, I totally agree it comes down to YMMV. Everyone's learning style is different -- some like dense documentation, some like book-style progressive walkthroughs. I certainly didn't learn CL by reading the HyperSpec, for instance... :-)
Re: Racket v7.2
#66Earlier quoted context omitted.
> and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance Unfortunately they are not doing it for performance reasons. They are doing it solely to make the code base cleaner and easier to maintain. Based on their most recent blog on the subject ( https://blog.racket-lang.org/2019/01/racket-on-chez-status.h... ), the new backend is almost uniformly s…
The new backed is overall faster according to that post. In addition, looking at raw Chez, the results are even more one-sided. Chez is always faster and often 2-8x faster. New racket is usually faster and where it isn't is mostly due to new IO. Sure, compile times get bigger -- Chez is doing way more optimization passes than Racket (Chez is the only scheme I know of that can get close to SBCL in performance). http:/…
At least for people who want to use Emacs and Racket, it seems like this Emacs project provides the client/server kind of setup you're talking about. Or no?:
Re: Racket v7.2
#67Earlier quoted context omitted.
And on a more general note - let's leave the misunderstanding to the separate thread - I'm glad you liked the books! I'm not saying you can't enjoy them - far from it - but if your goal is to just learn Racket quickly (where I interpreted "experienced dev" as "short on time working adult") then they are not the best resource for that. SICP is not even about Racket at all and RoR includes a lot of introductory materia…
Yes, I totally agree it comes down to YMMV. Everyone's learning style is different -- some like dense documentation, some like book-style progressive walkthroughs. I certainly didn't learn CL by reading the HyperSpec, for instance... :-)
Yeah, that's why I included the "but not too dense" part ;) Personally, I actually did learn Common Lisp mostly from HyperSpec (plus reading code - I used StumpWM for a while and wanted to script it), but at that point it was my 4th Lisp (after PLT Scheme/Racket, Emacs Lisp and Clojure) and I was well prepared for it, I think, because of my focus in PL research (hobbyist). I certainly wouldn't say that HS is the way to go for new CL programmers without special preparation.
But, Racket reference docs are not a language definition like HS, RNRS or the Dylan book. The tutorials especially are quite friendly, but the reference is also full of examples, overviews, summaries and introductions, along with the links to the Guide - which can further help in comprehending the content (but only if needed, otherwise they stay out of the way). They're basically amazingly well done and I think more people should read them, if only to learn something about how to write docs and technical prose in general... :)
Re: Racket v7.2
#68Racket is such a cool project. I keep telling myself I'll find the time to do something serious with it, but I never get around to it. One minor bit of criticism - would be it be so hard/expensive to hire a designer to do some minor touching up of the DrRacket GUI? It looks like a toy, and the icons didn't even look good in 1998. I'll balance this criticism with the remark that any language/platform that manages to a…
I used to (and sometimes continue) to think that way, too. DrRacket does look terribly retro or unpolished at times. But despite appearances, DrRacket offers unique power tools for working with Racket programs that's hard to replicate at the terminal or in Emacs/Vim/etc. I work with multiple (Racket) languages, and DrRacket shines there because it supports Racket's "multi-lingualism" out-of-the-box. What's also not immediately visible is DrRacket's extensibility. Take a look at Laurent Orseau's quickscript (https://docs.racket-lang.org/quickscript/).
Re: Racket v7.2
#69Racket is such a cool project. I keep telling myself I'll find the time to do something serious with it, but I never get around to it. One minor bit of criticism - would be it be so hard/expensive to hire a designer to do some minor touching up of the DrRacket GUI? It looks like a toy, and the icons didn't even look good in 1998. I'll balance this criticism with the remark that any language/platform that manages to a…
> and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance Unfortunately they are not doing it for performance reasons. They are doing it solely to make the code base cleaner and easier to maintain. Based on their most recent blog on the subject ( https://blog.racket-lang.org/2019/01/racket-on-chez-status.h... ), the new backend is almost uniformly s…
First they need to make it correct, then they will make it faster.
A major mistake in any porting is to do big refactoring changes during the process.
As for why they are doing it, to remove the dependency in C, have a safer runtime that everyone in the Lisp/Scheme community would enjoy contributing to and have a bootstraped environment, removing the 2 language syndrome that plagues a few runtimes.
Re: Racket v7.2
#70Racket is such a cool project. I keep telling myself I'll find the time to do something serious with it, but I never get around to it. One minor bit of criticism - would be it be so hard/expensive to hire a designer to do some minor touching up of the DrRacket GUI? It looks like a toy, and the icons didn't even look good in 1998. I'll balance this criticism with the remark that any language/platform that manages to a…
I came here to say the exact same thing (but just quickly scanned to see if someone'd said it already).
Call me a snob, but I think it's a bit eclipse-ish to have a splash screen. I'll stick with tmux + vim + parinfer + rainbow parens.
Favourite Scheme implementation. Offline searchable docs, libraries for everything. And developers are making it faster now with Chez?