Like others have said, I'm not sure that syntax is really the issue with Racket adoption. For me, the difficulty in moving to Racket from other languages is not the syntax, it's other things. Lot's of parentheses don't bother me. Writing (2 + 2) as (+ 2 2) is a little weird but It's not going to stop me from using Racket. Maybe there are other examples of infix notation where it really helps for the syntax to be more like natural language but I can't think of an example right now.
One issue is that Racket is documentation assumes more of a computer science background than I have. My single biggest suggestion in this regard is to use examples... lots of examples. The documentation shows you the syntax but that's not the same thing as understanding how something actually works or where it fits in with other elements of the base language. Also related to the background of the users is, for example, the family of functions including car, cdr, caar, cddadr, etc.. I puzzled over the question of why these functions even exist for quite a while. I had never heard of this way of doing things before. As I understand it, these functions are basically around for historical reasons. There is no compelling need for me to learn them for the purpose of writing my own code and so I haven't been using them. It's only a matter for understanding other people's code. During Racket Week and Racketcon, when I saw these functions being used, I understood to the point of realizing that the point was to pull a value out of whatever they were used on. I couldn't tell you which value. There has to be some compromise between having flexibility to do things lots of different ways and having limits to what a programmer needs to know to read other people's code. I have had the experience of writing a Perl script and then looking at some one else's Perl script, which does the exact same thing, and not being able to make head nor tail of it. AppleScript is much more limited and easier to understand. Part of that is just the limited scope of the language but they also have the philosophy that it is more important to make code easy to read than easy to write. I agree with that decision a lot of the time. R seems to me to strike a pretty good middle ground position in this area. A phrase which came up several times during Racket Week and Racketcon was "...a trap for the unwary." There seem to be a lot of these in Racket. I'm already pushing the TL;DR boundary pretty hard so I'll just suggest looking at the video and seeing where these this phase came up and whether there are any general categories of problems where something can be done. -- 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/4AB42B7E-DF83-4CF8-A14A-F92C2259B3DC%40biomantica.com. For more options, visit https://groups.google.com/d/optout.
