We use Racket to teach functional programming in the first semester of the first year at my uni and we never have such horrible feedback from students. We use it again in a compilation course in the first semester of the third year of the same curriculum and it works well. Could you elaborate?

Not the querient, but my first experience with Racket was something to the effect of:

  > (cons 'foo 'bar)
  ! error: bar is not a list

There were several other condescendingly-reported gross implementation defects like this, most damningly a inability to define macros, which meant that Racket is not in fact a LISP, and the syntactic homogenity that makes LISPs annoying to work with (at the benfit of being able to generate and rewrite arbitrary program fragments on demand) serves no purpose whatsoever.

I later found out that this was apparently due to having been provided with a "teaching" version of the interpreter intended for beginning students (who presuably don't know any better), which makes it even worse.

I would definitely characterize my attitude toward Racket as "hate", and if acbart made the same mistake my (generally quite reasonable and competent) CS professor did, I wouldn't be surprised if their students felt likewise.

It does sound like you were expecting a full Lisp and instead were greeted with one of the Beginner Languages, intended to teach first time programmers in a very structured way. See https://docs.racket-lang.org/drracket/htdp-langs.html

The example that you give is not an error in full Racket:

  Welcome to DrRacket, version 6.12 [3m].
  Language: racket, with debugging.
  > (cons 'foo 'bar)
  '(foo . bar)

Similarly, full Racket has multiple, powerful macro systems, and more besides, deliberately excluded from the Teaching Languages.

* * *

I'm not an academic, but the community and core Racket team are incredibly supportive, and any Comp Sci professor running into difficulties teaching a Racket-based course can easily access plenty of support and guidance, starting by contacting the user mailing list.

> I later found out that this was apparently due to having been provided with a "teaching" version of the interpreter intended for beginning students (who presuably don't know any better), which makes it even worse.

I think you still misunderstand; racket doesn't have different interpreter/compiler versions with different language features, racket code explicitly can request different languages via a language directive (I think there is a corresponding UI option in the Dr. Racket UI.) Among the preinstalled options are a series of teaching languages designed to accompany the textbook How to Design Programs, among others.

That's unfortunate. Perhaps people should be informed about `#lang racket` first, but I'm not sure how you missed this. It's fairly easy to see in the documentation.

As you point out: Racket is different from the teaching languages.

Genuinely curious as to why this was so.

Did these students have prior programming experience? Was their reaction due to a particular fault of Racket or would they have disliked any language to which they were not accustomed? Perhaps their reaction was to the idea of functional programming which would have provided a distressing challenge to intuitions developed through object-oriented or imperative programming? What textbook did you use?

I would suspect that at least part of it is the same reason that I disliked having Pascal as taught as doing my programming introduction course: It's not a main stream language and it's sufficiently different that you cannot directly apply what you're taught in most commercial settings. The languages they will be using in the future, or expect to be using in the future are C-style object oriented languages like C# or Java (depending on where in the world you live).

It's not that languages like Racket, Rust, Haskell or even something like Prolog and other languages aren't interesting or useful, in many cases they're a better fit for your problems. It's just that without the background in the C-style and object oriented languages it's pretty hard to appreciate the more "niche" language and the problems they solve.

The industry will probably still be using C#, Java and JavaScript in the future - but those languages and environments evolve over time. Teaching the languages as it is used in the industry today is not preparing the students for the future. C# 3.0 is in many ways closer to ML than it is to C# 1.0.

I have seen developers complain they had to learn an unpractical "ivory tower" language like Haskell - and then the same developers get totally lost when C# introduced type inference and closures and deferred evaluation of queries.

>The languages they will be using in the future, or expect to be using in the future are C-style object oriented languages like C# or Java

Between Go Rust, F#,Nim, Kotlin etc I think ML-style syntax, and composition over inheritance is generally being preferred in a lot of newer up and coming languages. As well languages like C#/Java/Rust are so multi-paradigm these days the crossover relevance is very high from any one language to another.

I've never seen most languages as drastically different really. Lisps and Prolog certainly are, Rust is a little with the borrow checker, but otherwise I feel like people make much ado about "int x" vs "x :int" and "f(thing)" vs "thing.f()"

Go isn't a strong example of ML syntax.

As a counterpoint, I have taught Racket every semester for the last decade. Students are highly enthusiastic and give the course outstanding evaluations.

How did you approach teaching it?

I guess it depends then. Having been taught Racket in my intro programming class by Olin Shivers I can say I adored it and his class turns people into computer science majors using functional programming

That's sad to hear. I started learning Racket as my first Lisp. Not because I had to, but because I wanted to. I guess that's a major point, especially when it comes to exotic languages like Racket, that just don't look and feel like the everyday programming language you play around with in your college time.

Speaking for myself, it was hard to appreciate a language like Racket until I had a few years of experience (5?) solving problems with imperative languages.

Interesting, that's odd! Racket is taught to first years here too, depending on the sections some Haskell as well, it is pretty popular especially along with the "How to Design Programs?" textbook.

Perhaps you're not a very good professor.

Always a strong possibility. Although since I've always received high evaluations in the past, I'm not sure that's a good hypothesis.

I suggest getting in touch with Andrew Runka at Carleton University. He teaches with Racket, albeit at in the context of a programming paradigms course at a third year level. He is more or less successful in doing so.

Source: took the class with him.

Thank you for your advice. I am not going to do that. I have talked to many professors over the past decade who are successful in teaching the class.

I would love to have some elaboration. Why did they hate racket?

My son is changing out of computer science as his major after a semester of Scheme. Not sure it’s a direct correlation but I think it had a lot to do with it.

>>I think it had a lot to do with it.

Your son's case aside.

But CS for a while has been sold as something that anybody can do, is generally the easiest place to be where you can make big money. Even accidental, brush with hardships can make people quit as of this point.

Also read: The perils of Java schools: https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...

Some people think in dependency graphs. But it's much more common for people to think in steps. I put two apples in the cart, the cart has two apples; I put two more apples in the cart, it has 4. Something like Racket that forces you to think about what you want, rather than helping you iterate to get there, is going to be harder to teach to new programmers unless they already have this type of thinking experience from advanced mathematics etc. It's possible that the class wasn't primed to learn functional programming before imperative programming.

I think the idea is that a course using Racket or one of its teaching language has to teach that style of thinking, and any course that doesn't teach it will be doomed to fail. HtDP is a great example of how to do it right, which puts the design process in steps rather than the programming steps. I suspect the parent comment failed in this aspect of the course.

Possibly. Of course, there is little evidence that the HtDP curriculum "does it right" while all others fail to do so. It seems to have a strong cult following, with little evidence to back up its touted advantages over other approaches.

I never said all others first of all, I just know that's one example I have a lot of positive firsthand experience with. Generally as well it's not like curriculum approaches have any evidence either way, so while there may not be evidence, I would ask what curriculum does have evidence that it's better than another. I've done some digging explicitly in that area and there's really no good evidence for anything from language choice, object oriented vs functional, everything. Not surprisingly either, it's quite the hard problem to solve and get rid of bias towards one approach in a study to start with.

I'd say this though - a "cult" following I would note as a likely symptom of a good curriculum, one that does such a good job that it inspires those that go through it to advocate for it strongly. Is that not itself evidence of some indirect sort? I'd say it's better than most out there.

In terms of its advantages, I think a reasonable person can decide if both the advantage is actually an advantage and at least gauge how a curriculum fares on executing on the advantage. For example, the ramping up of difficulty from the teaching languages. Instead of saying "theres little evidence", I would go through the curriculum and its advantages (and disadvantages) like that.

Please say more - what was so hateable about it?

Did the students give specifics?

Why didn't they like it?

We used its predecessor Dr. Scheme at Rice University around 1997-1998. It was weird for those of us with previous programming experience but I don't recall us hating it. I didn't hate it.

I'm a big fan of lisp but I dislike racket. In general, I recommend clojure. If you're motivated, arc on top of common lisp.

Why do you dislike racket?

I don't remember everything on top of my head unfortunately, but it was things like, weird choices all around like long names, no real OS threads, that kind of stuff. Sorry, I don't remember, I just know I tried it a couple of times and disliked it.

I have to agree on you regarding OS threads, although there are places, but they're processes. For long names, most names have an abbreviation like call-with-current-continuation has call/cc, and in any case, you can make your own abbreviation using make-rename-transformer so this shouldn't be an issue

Why would one bother when clojure has core.async, short names and everything else?

The tooling is complicated with Clojure. If you are teaching an introductory class, having a single simple install of DrRacket is a big plus.

Good point. Though I'm not so sure it's such a big deal in comparison of using a language that's not entertaining.

Because racket has hygienic macros and #lang, and syntax-parse.