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
edit: Spelling
You might, as a novice coming to Racket, find "Realm of Racket" to be more approachable as an intro: http://www.realmofracket.com/
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.
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.
EDIT: sure, no problem :)
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.
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... :)
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.
Going through the online version now.
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.
[1] https://en.wikipedia.org/wiki/S-expression
[2] https://opendylan.org/documentation/cheatsheets/scheme.html#...
[3] https://docs.racket-lang.org/racket-cheat/index.html
[4] https://docs.racket-lang.org/quick/index.html
[5] https://docs.racket-lang.org/
For example:
https://docs.racket-lang.org/sweet/index.html
https://www.draketo.de/proj/wisp/
Although I prefer to embrace the s-expressions :)
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."
It's discussed once every while on HN: https://hn.algolia.com/?q=htdp
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.
Edit: according to wikipedia Arc, which HN is written in, is developed in Racket
I don't know if that situation with Arc has since changed though.
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.)