And all of them agrees to never use it after university, which is quite telling.

I admit I'm one of those students who never used Racket in a non-academic setting (but mostly because I needed to contribute to already-existing projects written in different languages), and I was taught Racket from one of its main contributors, John Clements at Cal Poly San Luis Obispo. However, learning Racket planted a seed in me that would later grow into a love of programming languages beyond industry-standard imperative ones.

I took a two-quarter series of classes from John Clements: the first was a course on programming language interpreters, and the second was a compilers course. The first course was taught entirely in Racket (then called DrScheme). As a guy who loved C and wanted to be the next Dennis Ritchie, I remember hating Racket at first, with all of its parentheses and feeling restricted by immutability and needing to express repetition using recursion. However, we gradually worked our way toward building a Scheme meta-circular evaluator. The second course was language-agnostic. Our first assignment was to write an interpreter for a subset of Scheme. We were allowed to use any language. I was tired of Racket and wanted to code in a much more familiar language: C++. Surely this was a sign of relief, right?

It turned out that C++ was a terrible choice for the job. I ended up writing a complex inheritance hierarchy of expression types, which could have easily been implemented using Racket's pattern matching capabilities. Additionally, C++ requires manual memory management, and this was before the C++11 standard with its introduction of smart pointers. Finally, I learned how functional programming paradigms make testing so much easier, compared to using object-oriented unit testing frameworks and dealing with mutable objects. I managed to get the project done and working in C++, but only after a grueling 40 hours.

I never complained about Racket after that.

In graduate school, I was taught Scala and Haskell from Cormac Flanagan, who also contributed to Racket. Sometime after graduate school, I got bit by the Smalltalk and Lisp bugs hard....now I do a little bit of research on programming languages when I'm not busy teaching classes as a community college professor. I find Futamura projections quite fascinating.

I'm glad I was taught programming languages from John Clements and Cormac Flanagan. They planted seeds that later bloomed into a love for programming languages.

▲

kbutler 2 hours ago | parent [-]

To be fair, "write an interpreter for a subset of scheme" is a core use case for lisp-family languages.

If it had been,"write a real-time driver for a memory-limited piece of hardware", you may have had a different preference.

	▲	attila-lendvai an hour ago \| parent [-]
		that's an often repeated misconception about lisps. lisps are pretty good at low-level programming, but then you'll need to make some compromises like abandoning the reliance on the GC and managing memory manually (which is still a lot easier than in other languages due to the metaprogramming capabilities). there are lisps that can compile themselves to machine code in 2-4000 LoC altogether (i.e. compiler and assembler included; https://github.com/attila-lendvai/maru). i'm not saying that there are lisp-based solutions that are ready for use in the industry. what i'm saying is that the lisp langauge is not at all an obstacle for memory-limited and/or real-time programs. it's just that few people use them, especially in those fields. e.g. i'd easily prefer a lisp to put together a specialized byte-code interpreter to shrink firmware size for small embedded devices (e.g. for a radio https://github.com/armel/uv-k5-firmware-custom/discussions/4...). and there are interesting experiments for direct compilation, too: BIT: A Very Compact #Scheme System for #Microcontrollers (#lisp #embedded) http://www.iro.umontreal.ca/~feeley/papers/DubeFeeleyHOSC05.... "We demonstrate that with this system it is clearly possible to run realistic Scheme programs on a microcontroller with as little as 3 to 4 KB of RAM. Programs that access the whole Scheme library require only 13 KB of ROM." "Many of the techniques [...] are part of the Scheme and Lisp implementation folklore. [...] We cite relevant previous work for the less well known implementation techniques." BIT inspired PICOBIT (last changed in 2015): https://github.com/stamourv/picobit racket (only a .so into an already running VM): http://download.racket-lang.org/docs/5.1.3/html/raco/ext.htm... scheme: gambit, chicken

▲

alcidesfonseca 4 hours ago | parent | prev | next [-]

If it taught them the core concepts of writing good software, that's a win in my book.

	▲	3 hours ago \| parent [-]
		[deleted]

▲

Zambyte 4 hours ago | parent | prev [-]

Agree? Or maybe none of them graduate into a role where they get to decide what language to use?

▲

dleary 3 hours ago | parent [-]

Everyone gets to choose which language they use for their personal projects.

Where are all the Racket personal projects?

N.B. I say this as someone who personally contributed small fixes to Racket in the 90s (when it was called mzscheme) and 00s (when it was called PLT-Scheme).

	▲	linguae 3 hours ago \| parent [-]
		I view Racket as an academic language used as a vehicle for education and for research. I think Racket does fine in its niche, but Racket has a lot of compelling competitors, especially for researchers and professional software engineers. Those who want a smaller Scheme can choose between plenty of implementations, and those who want a larger language can choose Common Lisp. For those who don't mind syntax different from S-expressions, there's Haskell and OCaml. Those who want access to the Java or .NET ecosystems could use Scala, Clojure, or F#. There's nothing wrong with an academic/research language like Racket, Oberon, and Standard ML.