[joesb]

"Solve problems. Make languages."

That basically sums up my problem learning Racket. "What is Racket the language? What language am I supposed to learn? What language am I supposed to use in production code? Will one language be compatible with another?

I got lost reading Racket document. One section talk about a class syntax of a language. Another talk about some other stuff that never utilize a class. What am I supposed to do with this?

I don't want to learn languages, I want to solve my problem.

[lomnakkus]

> I don't want to learn languages, I want to solve my problem.

The more languages you learn, the more problems become trivial. Well, if you're just doing imperative languages, you're not liable to learn much new stuff, but... learn O'Caml[1] and Haskell and you'll be all the richer (and more worried!) for it.

One particular aspect of Racket that is truly amazing is the modularized language support for macros. One would generally insert a caveat here, but I do think they are actually "best in breed" at the moment -- even going so far as: http://www.ccs.neu.edu/home/stchang/popl2017/

EDIT: Just wanted to add, because I'm a "state your effects" weenie: http://lambda-the-ultimate.org/node/5401

[1] Mostly because Functors. (No, not the Category Theory Functors.)

[bad_login]

> I don't want to learn languages, I want to solve my problem.

I think the idea is that there is one good approach to solve a given problem (eg: use class to do the GUI code, use match to traverse some xml, use thread for async io instead of an event loop approach).

[agumonkey]

It's not Racket per se. Any lisps and even FP to an extent are like that. The notion of "language" is distilled to bits of recursive evaluation patterns (which make me believe [never tested this claim though] they are all compatibly-nestable), that you can adapt.

I just read the same sentence about Forth. There's almost no language, the principles are exposed, you make them what you need instead of pushing information flow into ad-hoc data structures as many people do in other languages (IMHO).

Maybe it's too alienating unless you've spent a few years on these languages.

[brudgers]

I had exactly the same experience a few years ago. Now a few years later, more of the Racket documentation makes sense, but many parts are still outside of my background understanding. I still have to trade-off the frustration of not understanding for convenient access to all the documentation. Because Racket's documentation is so good, it's easy to navigate to a subject that's over my head.

I agree there is a problem with 'Racket'.

'Racket' can mean an ecosystem distributed with batteries included. It can mean the language referred to by #lang racket at the top of a source file. And 'Racket' can mean any one of several other languages shipped in the distribution.

Racket the language (aka #lang racket) is a useful general purpose programming language. When #lang racket programs address complex problems they tend to become more complex. When #lang racket programs implement sophisticated procedures, they tend to become more sophisticated. Python, Ruby, C, etc. are similar in that respect. The Racket documentation reflects this. There are parts that are simple and self contained. There are parts that are at the edge of programming language design. And they're all in one place.

[dmux]

I've had the same issues navigating their documentation. About 10 months ago I attempted to write a reddit scraper using Racket. I started out reading their "net/http-client" library and had to turn to the /r/racket subreddit to find out that the "net/url" library was what I wanted. I'd love to see some simple directory that relates development intention with a library: "Web Scraping, JSON parsing => net/url".