We would like to add a new page to the Scala website to communicate the fact that Scala is a good tool for teaching programming.
I believe we should create a dedicated page, e.g. https://scala-lang.org/teach.html, with the following content:
- explanations of why Scala is a good fit for teaching programming (I believe this page from Mark Lewis could be a good source of inspiration, but feel free to add more)
- world map of universities / professors who use Scala to teach programming
- testimonials of professors using Scala
- useful links to get started, and to get advice (e.g., a link to this forum)
If you are interested in joining this effort, or if you have any suggestions, please drop a comment here.
Good initiative! I can try to contribute with some of my experiences from using Scala in introductory programming teaching.
I have just drafted such a page, you can see it here: Add page “teach” by julienrf · Pull Request #5 · scalacenter/scala-lang · GitHub.
Everyone is welcome to comment and help improve the content!
It misses the part with testimonials from professors. I would like to ask you all to leave a comment here with a testimonial about your experience in using Scala to teach programming, which I could then integrate into the page!
While we learn new concepts we compare and contrast different but similar concept and relate to what we already know. This is a very important learning principle and many pedagogical strategies build on contrasting and comparing while exploring similarities and differences between concepts and ideas. Scala is an excellent language in supporting this pedagogical principle as it includes a pragmatic mix of concepts and ideas, ranging from simple to advanced, that can be contrasted and compared, step by step. Combined with regularity and concise syntax, Scala makes learning based on contrasting a joy for me as a teacher and for my students!
One example I use in my teaching is contrasting different ways of solving the configuration problem: early on we contrast a global mutable variable versus default arguments and later when we get more advanced we contrast default arguments with context parameters. This way we can get deep into the more general discussion of the tradeoff between flexibility and complexity.
Scala is a fantastic teaching language for illustrating solutions with different tradeoffs between the least complex concepts that does the job, that might have lower flexibility or is less performant, compared to other solutions that may be more difficult to read and maintain. Scala helps learners to get a deeper understanding of such trade-offs as we can choose and compare different ways of doing things related to different contexts and idioms in one and the same language.
Scala is a fantastic teaching language as it is less prone to wear down the grit of my students compared to other programming languages that I have used for teaching introductory computer science, such as Java and Python. This is due to several nice aspects of Scala, including:
Static types. The student get help from the compiler to find bugs before runtime. If a student have too many difficult-to-hunt-down runtime bugs, this can take away the joy of learning and cause fatigue so badly that a student may give up prematurely and get a feeling of bad self-efficacy and loose motivation. Instead, in my experience with Scala, the dialog with the compiler about static errors strongly supports conceptual learning and strengthens self-efficacy: “I can do this and I’m getting a grip of it!”.
The Scala REPL and its type inference echoing. Already before students have understood some basic programming concepts, they can start playing with things they know from math class in the REPL. As they engage further in a “dialogue of types” they boost their understanding of the semantics of data types and what happens when you compute new values based on existing values, etc. Many dynamic languages have REPL-support, but without static types and compiler error messages, you miss out a large part of the conceptual learning from the REPL feedback.
Regularity and principled constructs. Scala has done away with many of the quirks from C-like languages that still remain in e.g. Java and C#. There are, for instance, no surprising restrictions on what can be nested inside what, and no irregular semantic difference between primitive non-objects and “real” objects. The level of regularity and generality of principled concepts in Scala is the best I have seen so far in a multi-paradigm language. Every strange irregularity and tricky exception wear down the grit of students and take up time in teaching that can be much better spent.
I’ve written a fair bit in the past about what I value in introductory programming languages and why I like Scala. I’ve put links at the bottom. I’ll just mention here what I feel were the main reasons I was originally drawn to Scala for CS1 and CS2.
- Scala can be taught as a statically typed scripting language. The language works really well for programming in the small in CS1 without all the drawbacks I feel exist with dynamically typed languages.
- Switching languages is time-consuming and switching too often prevents students from gaining comfort in any language. Scala is a great language for writing larger programs as well, so the transition to CS2 is smooth and I can teach what I want to teach how I want to teach it.
- Full access to Java libraries as well as a large environment of Scala libraries means that I can give interesting assignments. Combining libraries with Scala’s concise, expressive syntax means that the only limitation on what projects I ask students to do comes from what they know. In CS2, I’ve had students do a project that involves graphics, networking, and multithreading and Scala makes that possible with limited overhead.
I’ve been working as the head TA of the undergraduate programming languages course at KAIST for two years. We teach how to implement basic interpreters and type checkers. For this purpose, algebraic data types with pattern matching and immutable data structures, provided by functional languages, are essential. They allow us to focus only on interesting programming language concepts without dealing with tedious low-level implementation issues. Influenced by PLAI, we used Racket as our implementation language until 2018, but we decided to switch to Scala because Racket is too different from the languages students are familiar with. Compared to other functional languages such as Racket, OCaml, and Haskell, Scala is much more similar, especially in terms of syntax, to languages students learn in their introductory courses, like Python, C, and Java. It’s the main reason we are using Scala. In this sense, I always believe Scala is the best introductory language to functional programming.
The textbook for the course written by Sukyoung, the instructor, and I is available online at https://hjaem.info/itpl. The lecture videos will be made public via Coursera this summer.
Here is a little testimonial from me:
Scala is by far the most productive language I have found for teaching compilers to undergraduate students, especially when most are already familiar with the concepts of object-oriented programming. The familiar yet flexible expression-oriented syntax, advanced support for pattern-matching, extensive collections library, powerful type system, and general no-nonsense approach to essential programming constructs are all game changers. After learning Scala, many students don’t want to ever go back to more primitive and ad-hoc languages like Java and C++, unless forced by the curriculum!
Thank you so much everyone for your help! I have just opened a PR to the Scala website: Add page “teach” by julienrf · Pull Request #1402 · scala/scala-lang · GitHub
The page is now live: Teach Programming with Scala | The Scala Programming Language
Thank you again for your help and support!
@julienrf On that Teaching Programming With Scala page, it asks folks to add themselves to the map of teachers. I’ve put in the pull request for that, but there’s multiple other people at West Point who could do so as well. Do you want multiple people from one institution on that map, or do you just want one person per institution?
Hey Chris, good point, I think it would be better to list multiple people from one institution on the map. I will be able to have a look when I am back from vacation, in 10 days (or feel free to submit that change yourself if you are interested!)
I think it would be good if it was even simpler to let us know that a teacher want to be added. Requiring a fork+PR is less easy than e.g. a simple google forms link or similar. I think it would be really good to lower the friction to expand the map of teachers.
Also I think we could advertise this more on all forums: “If you are a scala university teacher let us know by filling in this form:” and there can be a consent question to add the responder to the map.
I’d assume most university teachers would be happy to be visible there, but its important to elicit all the ones we don’t know of that might not hang around on scala-lang-org, but perhaps visit Discord/Gitter/Redit/…?
Hey, thank you for the suggestion. I agree that something like that would be simpler. On my side, it would be even better if there was a way to automatically generate a PR from the form submission. Do you know a possible way to automate that part? (to trigger a script when someone submits the google form)
Well, perhaps this can implement your use case: if you create a Google sheet with responses linked to the form (you do that by clicking in the form response tab in Google formns) you can use a URL from the Google sheet to download a .csv file and you can then create a local program/script that polls this regularly and checks if new responses have arrived.
Revisiting the idea of listing multiple people from one institution on the map. There are two variations of this:
- A separate flag for each person, which would mean multiple flags at the same location, which is probably easier in the code but harder for anybody viewing the map.
- One flag per institution, but with multiple people inside the flag. Probably better for the viewer but might mean more work in the code (unless the name field can deal with a comma-separated list or something similar?).
Either way, two of my colleagues have asked me to add them, which I’m happy to do once I know which of those two options to follow.
I’ve just re-organized the data source to include several teachers of the same institution, and I’ve included Ryan Dougherty. I hope that works fine for you if we follow that structure?