@alexknauth are you intending that for a single definition of an f that accepts two arguments, we would be able to invoke it using either f(x, y) or (f x y) ? In other words, there is nothing special in the definition of f that explicitly deals with tuples.

No, I am not intending that. However I am intending that if someone writes define f(x, y) = .... Then f(x, y) would work. And if someone writes define f x y = .... Then f x y would work. I expect most functions exported by modules to use f x y, but for their own functions programmers would be free to use either one. I expect the main use for f(x, y) to be for mathematical functions that conceptually should take a point in 2D or 3D space anyway.

Of limited value, but on the subject of popularity, over the years (2009 through 2018) I’ve periodically run some Google searches for various phrases that have at least some correlation to programming language popularity. The latest is here: https://blog.lojic.com/2018/08/23/programming-language-popularity-part-twelve/ I think the earliest post that included Racket is: https://blog.lojic.com/2013/02/23/programming-language-popularity-part-six/

The goal is accessibility, not popularity. As I understand it, we want to remove barriers for people who wanted to learn racket but couldn’t. Not try and attract people who don’t want to learn racket at all.

It’s a little hard for me to fully remember my thought processes while deciding to use Racket (probably more so for folks that are decades in!), but in my case, I came to lisps very late in my programming career (decades after undergrad), so I was already heavily biased toward “traditional” syntax (as well as an OO style). After a few languages in my career, I became interested in a functional style of programming (there are a lot of those), I then determined that I preferred dynamic typing (there are a lot of dynamically typed languages supporting a functional style of programming). I then saw value in “writing code to translate code into other code” - aha! Lisps seemed to have a significant advantage for this. I then determined I preferred Scheme over Common Lisp. Getting closer. I then determined Racket was the best supported Scheme in terms of active development, breadth of libraries, etc. I understood how the s-expression syntax enabled macros, so even though I had yet written any macros, I hoped that there would be a payoff down the road when I began writing them.

If Racket’s “hook” is language oriented programming - it does seem to me that for people for which that hook is compelling, the parens are either a very small barrier, or perhaps even viewed as an advantage. Now, for people who don’t find language oriented programming compelling, the parens may be a larger barrier.

When I picked up Ruby in 2006, it was entirely motivated by a desire to be as productive as I saw I could be using Rails. To use Rails, I needed to learn Ruby, so I learned Ruby. I think this is a very common pattern. People learn a new programming language to be able to accomplish some goal, and often that goal is to be able to use a library/framework/etc. that’s written in the new language.

Maybe I’m simply very atypical, but to me, the idea that I would want an easy to visualize & parse representation for code to enable me to transform that code was obvious, so I’m having a hard time visualizing the programmer who thinks code transformation is cool, but wants a harder to visualize/parse format to use.

I realize the professors are encountering people for which parens are a barrier, but I guess my question is - are these people already super motivated by language oriented programming, or are they encountering both concepts together & indicating they don’t like parens, when maybe they don’t like both?

I strongly believe that language-oriented programming and macros do not require parens at all, and that parens do not give any significant advantage. After all, Racket’s macro system uses syntax objects instead of lists - in that sense we’ve already moved away from the simple “code is data and data is code” model of Lisp s-expression macros.

@notjack I suggest you to try Elixir for the experience os writing macros, them compare that experience with Racket

Despite I never used Racket, it seems clearly to me that having no difference between the visual and internal representation of the code makes macro writing more easy. Thus is no to say that it is too difficult to write macros in Elixir, but sometimes I feel that with s-expressions could be easier

Note that I still succeeded writing very complex macros in Elixir indeed.

What sort of problems do you run into?

O ly that sometimes I do not know where to do the unquotes/quotes as t the level of the surface notation, and in that case I need to dig into the Ast

For example, an Elixir macro receives as arguments the internal representation of the code, which resembles s-expressions!

So there is always this mix of having to deal with both representations, instead of just one

That’s already the case now though with syntax objects

What if syntax parse expressed patterns in the surface syntax? syntax-parse(stx, [foo(arg, ...) #'impl(whatever(arg), ...)])

That is not possible to pattern match with surface syntax in Elixir AFAIK

That would be something very nice to see…

It could be possible in racket2. The syntax-parse, syntax-rules, and syntax-case macro systems are all just regular racket libraries after all

They’re not special builtins

@dedbox Btw, not too long ago, I used to be one of those beginners that didn’t understand the relationship between quote and eval. And I’m not alone, plenty of the students I’ve worked with have had the same trouble