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 arrive at the solutions on their own. Instead, it eaches explicit methodology that enables students to solve problems of surprising complexity on their own, whether they are 11 or 55, whether in a classroom, a training facility, or your home. Extensive documentation, material, and software to support this methodology is available for free."
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]).
Thanks for sharing. Nice. I'm not a programmer but I have taken many courses all over the web (I think I only lack practice). This talk reminds me of the Edx course on functional programming using DrRacket. As the talk suggests about the boring and bureaucratic aspect of the recipe design, I think that's exactly the reason why I couldn't finish that Edx course twice, though I am convinced that this design/recipe methodology to learning to program, is the right solution (which is absent from the pedagogy of a lot of courses). This talk makes me want to try and take that edx course again, the third time!
If a methodology doesn't motivate you to actually do the work (i.e. finish the course) no matter how intuitive it might be, it will not work. That said of course everyone is different, and what motivates one person, may not motivate another.
Racket 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) add, ex-post, a type system, b) fix the Gordian knot of modules and macros, and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance, deserves my respect. In addition both Flatt and Tobin-Hochstadt give excellent presentations where it's impossible not to notice their passion for Racket. They're definitely among my nerd heroes right now.
I just want to point out that you can use other editors: emacs, vim, vs code. If you really want to stay with DrRacket, feel free to open a feature request about this on the github racket/DrRacket repo.
Actually, not using paredit (or equivalent) for editing Lisps is something I'm unable to do anymore. I sometimes use DrRacket for debugging, but racket-mode and paredit make Emacs hundreds times more efficient for me.
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/).
Currently working with DrRacket 7.2 on Mac OS X. What bugs me is that everything becomes unresponsive while executing heavy stuff or code that does not terminate. The stop/kill button usually does nothing and force-quitting the app is the only option. I tried the latest Racket-on-Chez build which seems much better in this regard, but is over-all rather sluggish. Hope this will improve.
I test drove Racket-on-Chez the other day by attempting to use the pict3d module (since 3d is an application that needs speed). My experience was as follows:
1) Install pict3d through DrRacket's built-in package manager - sudden, silent crash. Luckily I ran it from a terminal, which indicates an out of memory error.
2) Raise DrRacket's memory limit to "unlimited" and retry. Same result.
3) Google how to install packages from the command line. Wait for package to build. Build hangs during documentation. Eventually give up and ctrl-c. Hopefully it still works without docs? Racket packages aren't transactional, so every failed build leaves Racket thinking a package is installed, but it's actually broken.
4) Run DrRacket. Load pict3d and type oneliner. Incautiously press an F-key I assume will run the program. DrRacket crashes.
5) Run DrRacket. Load pict3d and type oneliner. Carefully run the program. Scene is incredibly slow but works! Then DrRacket hard crashes and locks my entire desktop so I have to go to a TTY to recover. My graphics are corrupted in a minor way. I haven't rebooted since then, and they're still corrupted.
I really, really like the look of Racket and want to use it in anger for a project, and I have a specific one in mind that would benefit from 3D, but this user experience is singularly bad. It's probably pict3d's fault, but there's no indication of this module being of "pre-alpha" stability. Or maybe it's an interaction with Racket-on-chez and C library interfacing. Let's hope it gets better.
> It's probably pict3d's fault, but there's no indication of this module being of "pre-alpha" stability. Or maybe it's an interaction with Racket-on-chez and C library interfacing.
Racket-on-Chez is what's pre-alpha. I don't think there's been requests for anyone to test it unless they were going to dig into the guts and try to fix things.
> since 3d is an application that needs speed
if the slowest part of your 3D is how quickly you can make calls into OpenGL, you're in a pretty good place.
Out of curiosity, is there a particular reason you were trying to use Racket CS for this?
AFAIU typed Racket currently adversely affects performance on Racket CS (in certain cases) and pict3d looks like it's a non-base package written in typed Racket so it's likely not the best candidate for running on Racket CS right now.
python comes with IDLE. Which looks dated w.r.t current IDEs. I guess for most languages, stability is the key - changing UI also means maintaining two different UIs(the old and the new)- that time could probably be better spent on language features.
DrRacket is a bigger deal to Racket than IDLE is to Python. Specifically because it provides a graphics capable REPL, which is used by a lot of the pedagogical languages and intro to programming courses that racket is perhaps best known for.
> changing UI also means maintaining two different UIs(the old and the new)-
Why would you need to maintain the old UI? Backwards compatibility isn't an issue, since no one is screenscraping and doing image recognition to interact with the UI.
Besides, what we're discussing are relatively minor changes to update appearance, such as different font, color scheme, graphics assets, etc. No significant changes wrt UX--with how the user interacts with the program.
For more extensive changes, I imagine a whole load of screenshot-heavy documentation would need updating (probably a load of course notes, inherited from long-gone lecturers too).
I agree that shouldn't be an issue though. Those who don't want any change (e.g. lecturers) can stick with an old version.
> 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 slower to load, takes up twice as much memory, takes more than twice as long to build, takes twice as long to compile Racket code, and the compiled code generally runs slower than it used to. (They expect that this last one will improve, but they have never indicated that they expect it to actually match or exceed the speed of code compiled with the old backend.)
Also, the new back-end, by design, permanently removes support for the Racket C API.
This trade-off is hard for me to understand. I don’t maintain Racket, so I don’t have any idea how much effort this will ultimately save those who do. 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; and I have never seen explained, and can’t even imagine, what new features the maintainers will now be able to implement that would actually make Racket development more productive or enjoyable.
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).
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.
The new backed is overall faster according to that post.
No, according to that post, the new back-end itself is massively slower than current Racket by every single measure shown. To reiterate, I’m talking about startup and load times, memory use, expand and compile times, and build times (i.e. time to compile the back-end itself). All slower. (Are you sure you're not referring to code compiled using the new back-end?)
I grant that there is some benefit in that the longer compile times result in an improvement in some benchmarks, but that doesn’t negate that the new back-end is still slower than the old one by every measure.
> Racket is much faster than python or PHP.
This is funny because although you will find benchmarks out there to support this point, in my experience of writing and using Racket programs it has never hold up. Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution.
I love the Racket language, and there are some DSLs like Pollen that do things I simply can’t imagine attempting anywhere else. But it’s for sure my last choice for speed, based on personal experience.
> Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution.
Can you point me to some examples of this? I haven't done AoC and so don't know where to find solutions posted to compare. It should be very rare for idiomatic python or php to be faster than idiomatic racket.
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?:
I think the smaller example Matthew Flatt used in a talk about the expander is a better example. From the old expander's conception (many many years ago) only 2 people commited any changes and one of those only committed smaller instrumentation changes.
Since the rewrite (that was about 1.5 to 2x slower) less than a year ago 6 people had made commits.
What one could hope for would be some chez scheme interoperability for the really speed demanding parts.
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.
Using Firefox on Android with uBlock Origin enabled, I was redirected to some "onlinexperiences.com" site that displayed "System Check" and then a constantly growing number of lines containing only "Browser".
Then I tried the stock Android Browser and it passed the browser check, but redirected to a login page.
Going back to Firefox and disabling uBlock Origin, I was able to access a description of the talk and the video itself. So I conclude that the video is available without login, but you have to use Firefox and allow yourself to be tracked.
Pretty grating "online experience" for something hosted on a mozilla.org subdomain.
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 is an absolutely gorgeous language. It's the kind of language that might look complicated but the important thing is to start with the basics. Yes, there are complex features in the language and big words that might be scary : continuations, impersonators, collapsible contracts, macros. However most of the time you don't really need these features.
Even the basic features of the language are enough to make your software shine. After you have a basic grasp, start to tackle other features of the language refactoring your code as you go.
Another great feature is the community. racket-users mailing list (hosted in googlegroups) is a great place to start asking questions.
You'll have a lot of fun. Enjoy your time in Racket lang. #not-a-typo
Seems like the most common answer to this might be SICP (Structure and Interpretation of Computer Programs -- you'll find course videos pretty easily from Google; the ones from the authors are really great). Note that it's based on Scheme, which is a ancestor of Racket, but Racket has a language pack that papers over the differences and works with the code from the book. Official course website: https://mitpress.mit.edu/sites/default/files/sicp/index.html
You might, as a novice coming to Racket, find "Realm of Racket" to be more approachable as an intro: http://www.realmofracket.com/
> 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 approachable
Or, as an experienced programmer, be bored to tears by the slow pacing and didactical style. It's a great intro to programming and to Racket, but more focused on the former, which makes it ill suited for experienced devs who want to learn Racket.
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 couple thoughts that might be beneficial. I'm glad you feel confident enough in your interpretation of what was being asked and the OP's personal background and motivation to flame someone else without, I don't know, answering the question.
EDIT: I see you did answer him below, but my general response is still valid.
EDIT 2: Your response makes more sense given context. Sorry I got internet angry a little too quickly.
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.
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... :)
My "please don't" was directed at the potential learner as in "please don't use this particular book if all you want is learning Racket" - not at you, in any way.
Also, I said it's a bad book for learning Racket In My Opinion. Of course it's all based on opinions and I just presented my own. No flame intended, at all.
Thank you for this. Time and again I have come across this book, but always assumed that it was something like The art of Programming series, so never even opened it.
First thing is to get rid of the syntax feeling unfamiliar. As a beginner, you need 3-4 chapters of a book for this. As an experienced dev, what you need is an overview, a cheatsheet, and reference docs.
I think you can get an overview from the Wikipedia on S-expressions[1], then there's Dylan cheatsheet[2] which translates Scheme syntax into equivalent forms in a language with more "normal" (infix) syntax, which also happens to be object oriented, so it should feel quite familiar(EDIT: thinking about it some more, maybe Dylan is still a bit too far from Algol-like syntax, but I can't find such right now). Then, there's Racket cheatsheet[3], and the Racket Tutorial[4]. After writing some Hello Worlds and getting familiar with the syntax, start branching into interesting libraries (like plot, pict; see the list on [5] or search on [6]). See `raco pkg` docs[7] for installing additional libs.
Advice about editor: find an S-exp support plugin for your editor and just go with that until you want some graphics support, in which case try DrRacket. Advice about weird things: try not to focus on weird things which are historical incidents - you can learn why CAR and CDR are called that way later, just remember that they are first/rest operations on lists.
After this I think Beautiful Racket along with the rest of the Racket docs should be enough to learn most of it. You can also skim How to Design Programs (linked at the end of tutorial) for intro to contracts.
Yeah, but that's not Racket (technically, the first one is, but it overrides the reader; the second is a Python-based transpiler of some syntax into S-exps) - it won't help someone new to the language, if only because it adds yet another dependency and mental conversion to keep in mind when reading examples and such. They're there if you want them, though.
I agree about the extra dependency and indirection; although the syntaxes (syntaxen?) are equivalent, so examples can be translated automatically if copy/pasted.
> They're there if you want them, though.
Yep, although as I wrote on my blog:
"Whilst the parenthesis-heavy format of s-expressions is not necessary, it usually crops up in anything discussing Lisp and its derivatives, simply because it's much more popular than these alternatives. To me, that mostly indicates that concerns about "too many parentheses" are really a non-issue, despite being made by many who are new to the format."
I am not sure one would count it as “production”. But I am pretty fond of Racket whenever I want to develop a quick-and-dirty tool for one of the persons in my lab.
The performances are meh (correct for a script language, but not much), the standard library is very large, it is portable, the integrated GUI and plotting facilities are absolutely priceless, and the ability to generate a fat ELF/.exe/.app for all of the three platforms is priceless.
Sure, distributing a 100MB executable is not something I would envision for a largely distributed software, but when hacking up (on Linux) a quick GUI tool for my lab colleague (on Windows), the advantages more than compensate for the drawbacks.
And I like LISP/Scheme languages, but that's subjective.
Yes, but the APIs design is very far from what you'd expect from a typical dynamic language. When you tell a typical Python/Ruby/Perl/PHP/Lua programmer that you can't just call `length` on anything collection-like, but need instead to call `string-length`, `vector-length`, `hash-size`, etc. - they remain unconconvinced, to say the least. The higher-order abstractions, like collections, sequences, streams are there, but rarely used (if at all) in the stdlib itself and you won't encounter them in tutorials. Then, some APIs are incomplete, like the date and time support, even with relevant SRFI.
The language is expressive enough, fortunately, for people to build their own stdlib replacements, like Alexis King's collections-lib (and related), gregor library for dates, or rackjure lib for thread-first/-last macros. But you need to know about them, otherwise you're going to invent lots and lots (because it's so easy) of your own conveniences and will do it poorly for the most part, while also losing time.
Well, it's still orders of magnitude better situation than with Pharo, which was also released in 7.0 version recently. In Racket, all of the stdlib is covered with extensive documentation comparable (sometimes favorably) with Python docs. Most additional packages are also documented the same way, it's great. As long as you can get past the base distribution lack of conveniences (or sometimes features), though, Racket is one of the most beautiful languages and language ecosystems I've encountered.
I did two little projects in Racket, recently: one was using Slideshow for making slides for a presentation, the other was using plot for making some graphs. In Slideshow, I ended up writing some 200 loc for it to display syntax-highlighted, colored code of non-Racket languages, which would be free in any JS-based presentation framework. After that it was a relatively smooth sailing, although the outline-generating API is definitely overcomplicated. In the other case, I had to parse a bit of text and then do a lot of computation on dates and times. Very frustrating experience initially, until I found gregor lib and megaparsack. The 5+ other solutions (for parsing) were too heavy-weight and inconvenient to use and I was just going to fall back on regexes (which are also not very convenient to use), but fortunately I found Alexi's megaparsack lib, which is almost as good as PyParsing.
Anyway - lots of rough edges in the stdlib, a lot of cruft - but at least well-documented - and some interesting libs you can use to bring it up to modern standards. And the module system makes using these packages painless - even if they rewire lots of stdlib - which is something Smalltalk/Pharo guys are yet to achieve.
Is it in fact implemented in Racket? It used to be limited to PLT Scheme, which is the old name for Racket. But one of the changes that lead to the name change was making cons cells immutable. Arc was, at least at the time, mutating cons cells so Arc continued to use old versions of PLT Scheme instead of newer Racket.
I don't know if that situation with Arc has since changed though.
Well don't let Hacker News overhear you. The specialized lang they used to make and run the site, Arc, is written in Racket.
Moreso than being mainly created for teaching, Racket was created mainly as an environment for creating languages. Its forte is language development and implementation. This is useful in education, because it allowed them to easily create a number of 'teaching languages,' which are all essentially Racket with training wheels.
But that doesn't mean the base language + environment is only useful in education. I might even call it the most usable and productive LISP currently in wide use. (I greatly prefer it over Clojure, for instance.)
I’ve used Racket in the past. Personally, I’d still never use it for production because the learning curve is fairly steep AND as this post highlights - there are still bugs being worked out in basic features like “set”.
However, overall I like the language. So, overtime I think it’ll have its day in the sun.
> there are still bugs being worked out in basic features like “set”.
You are misreading the release notes.
What was fixed is a Redex model (a tool used in semantics to model computer languages). A change to the modeling of `set!` (assignment) was made. It has no impact on Racket itself.
If it is in fact the case that only some redex models of `letrec` and `set!` were fixed, then it is indeed misleading that the release notes say "Racket's implementation" of them was fixed.
Unless you're the one who did the work, I'd rather trust the release notes than your unsourced assertion.
That said, just because a bug was fixed in an important function shouldn't be an indictment against the language. Racket is stable and productive, and formal modeling can reveal all kinds of corner cases which may not have been exposed in typical use, and may not have security implications. Maybe it was edge-case performance, maybe garbage collection, the release notes simply don't say.
I'd rather use a language whose authors improve their tools to discover and fix issues than one where this doesn't happen.
Ahhh, my bad. I thought you were the same commenter as the first guy, and I doubly goofed by misreading the comment in the first place. The dangers of commenting before coffee. You're right, the difference between redex models and racket's implementation of them would be confusing, and I don't have enough direct knowledge to provide any insight there.
There was indeed a bug fix to the actual Racket implementation, but in extremely hard-to-find corner cases, which was why it was only found via model-driven random testing.
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 arrive at the solutions on their own. Instead, it eaches explicit methodology that enables students to solve problems of surprising complexity on their own, whether they are 11 or 55, whether in a classroom, a training facility, or your home. Extensive documentation, material, and software to support this methodology is available for free."