Perspectives on Swift in Education (using a Linux Environment)

I'm beginning my fourth year teaching Swift at one of the largest high schools in the United States. I'm documenting some of my experiences with the hope that others may benefit with the possibility of further collaboration.

A Very Short Brief About Me (and Some Nostalgia)

My interest in computer science began at a very young age building small "computers" using relays before moving on to Olivetti's A5, Texas Instrument's TI-99/4A, and the great Apple IIe. I earned my degree in Computer Science and then spent many years in the San Francisco Bay Area working initially as a software engineer and then working my way up through management in a Fortune 500 company. Several years ago I decided to focus my efforts on education with the following guiding principles in mind:

  • Everyone deserves and is entitled to study Computer Science
  • The skills acquired in the study of Computer Science are valuable, regardless of a student's ultimate field of study
  • Studying Computer Science can help bring equity to the disadvantaged
  • The best learning is fun
  • There's no substitute for real experience

Why Swift?

While learning multiple languages is no doubt beneficial, I wanted to focus a three year curriculum on only one language which would serve as a great starting point yet not be a limiting factor in later years. I wanted a practical language that could be used in the "real world". I wanted a language which could be compiled. I wanted a language which would work on a variety of platforms, including Linux, with support for a robust REPL. Finally, I wanted a language with an enthusiastic group of supporters. I chose Swift.

Challenge: Infrastructure

While I absolutely adore Apple's products, owning an Apple product in order to learn, study, and practice Swift was a non-starter. While I think Apple is doing a great job developing a learning environment using iPads and Playgrounds, too many students and their families (as well as their school districts) aren't able to afford adequate equipment. I needed a solution which could easily be run on a low-priced Chromebook.

Solution: Linux + Screen + Emacs + LSP + Flycheck + Magit + Igis + Scenes …

The solution was to build out infrastructure enabling students to study (in a realistic environment) using nothing more than a browser and a shell. (The Chrome browser provides a very good "Secure Shell Extension".) Students learn about computer theory, hardware and software using a wiki and then practice their skills in the shell. Their toolset includes:

  • screen - launch and use multiple shell sessions (for example to edit, view output, and compile simultaneously). No less important, is the ability of teachers and other students to log on remotely and assist others.
  • emacs (along with LSP and Flycheck) - edit in a syntax-highlighted environment with completion
  • Magit - provides a UI from within emacs for Git interaction
  • Igis + Scenes - provides the ability to develop complex, browser-based graphic applications using only server-side Swift
  • Mission Manager - provides students with the ability to perform exercises and gain instant feedback regarding correctness. Also servers as a platform for quizzes, exams, and competitions.
  • Other - A wide variety of tools, mostly bash scripts, that enable students to deal with dynamically linked libraries and their versions.

Feedback from Students and Parents

The feedback from students and parents has, overall, been overwhelmingly positive. The program has doubled in size and demand is high. On occasion, a few students (and/or parents) will complain that Swift is a "proprietary" language belonging to Apple and that Java should be taught instead. Also, some students have some initial difficulties working their way around a CLI. Graduates of the program who have begun their studies in college inform me that working only in a CLI has greatly boosted their confidence. Likewise, the program has received praise from student's professors.

Remaining Challenges

Of course, many challenges remain. Some material on the wiki is still quite sparse. Learning emacs and git are significant hurdles for some. Differences in behavior between the REPL and compiled programs are sometimes a source of confusion for students. Alternatives to the lldb CLI would be helpful.

I hope that this post will serve as a starting point for discussion; questions and comments are welcome.

37 Likes

Hi Merlin,

I very much share your opinions and goals.

For the past few years, I’ve been working on a textbook to teach Swift as a first and primary language in a higher education curriculum (I'm a CS lecturer myself). My goal is to develop a series of 2-3 books that can serve as the core to this curriculum, and then supplement this with books/materials from the Swift community.

The core books will be 100% cross-platform and not assume the reader is using an Apple device. Students should be able to use any editor or IDE on any supported platform to solve the exercises and programming challenges in the books.

I’ve just finished writing the first of these book and would love to hear your thoughts on it. Feel free to send me your contact info by PM and I'll send you a free copy once the book comes out of the pipeline.

5 Likes

How do they run Swift from a Chromebook, on the device using the Crostini container somehow or accessing an external linux server on the network?

If the Chromebooks have Android support and AArch64 chips, the easiest way would be to install the Termux app and use its Swift toolchain. You could probably get that working on x86_64 Chromebooks too, with some work.

1 Like

That's a +1 from me.
Am also a swift teacher but in Nigeria, Africa and I think this is the best way to expand swift community base

3 Likes

Steven,

Yes! This is exactly our philosophy as well. It's great to be able to learn to code on an Apple device but it's not a requirement.

Best of luck on completing your series of books. I'd be honored to read a copy as soon as you're ready. I'll PM you with contact information.

Thanks!

Our goal is to simplify any setup requirements and to do our best to provide a great experience to all students. As such, the students run Swift by accessing a remote server. This has the advantage of not only teaching them about using Swift on Linux, but also familiarizing them with the bash shell, git, GitHub, emacs, etc.

Of course, the disadvantage is that they need to have internet connectivity in order to participate.

This is amazingly cool! It's awesome how we're able to connect around the world yet have a common goal. I have many questions. :)

  • What materials are you currently using for teaching?
  • What hardware are you using?
  • What type of internet connectivity is available?
  • Which grade levels are you teaching?

I'm hoping that we'll have an opportunity to collaborate.

Why use Emacs, which requires a course in itself, instead of VS Code?

I appreciate your question. Our goal is to enable students to begin learning with a minimum of technical requirements, ideally nothing more than a browser, shell, and internet connection with the simplest possible hardware, such as a Chromebook. emacs requires nothing more than these minimal requirements.

VS Code, on the other hand, requires either a client-side installation of the product itself, or a client and configuration to support X11 forwarding. Either of these options exceeds our goal of minimal requirements.

While I agree that there is a substantial learning curve to gain a thorough understanding of all of the capabilities of emacs, learning a few key strokes is really all that's required to get started. The students also use emacs, in conjunction with git and GitHub for non-programming writing assignments.

Again, thank you for your question.

If cost is an issue, you can try to find free/cheap laptops for the students to use? Most coding initiatives near me rely on written-off laptops donated by companies. I've also seen students get by with a second hand machine they got for €50-100. Once you install Linux, those machines should still be good enough to do some simply coding, and should result in an easier setup than using Chromebooks.

For my book, I don't assume any particular platform or editor. Project setup is done from the command line with SwiftPM. I teach basic commands such as cd, mkdir, and so on, in the book, but I avoid any additional complexity, such as Git.

I use a progressive disclosure style, where the first example is typing 1 + 1 in the REPL, and the book ends with the student having programmed complete games (Tic-Tac-Toe, Blackjack, and Yahtzee) with a command-line interface.

1 Like

This is a great idea and may be very helpful to some students. There are others, however, who receive Chromebooks from their school or University, and I want to make sure that we're always using the minimally-required hardware.

I think it's awesome that you're doing all of this with a CLI. That definitely aligns with our goals and strategy. It's where we begin and spend the first semester. However, toward the end of the second semester, we begin learning to use some libraries to break out of a strictly CLI environment while still remaining in a browser-based world. We use Curses which is a Swift wrapper around the underlying C library to enable students to experiment with color, text fields, and keyboard processing. They learn how to use the library to construct maze-like games. Later, we use Scenes which provide students the capability of creating complex graphics and animations using server-side Swift while displaying the results in a browser.

Like you, we also make extensive use of the REPL. Many students will experiment from within emacs splitting their screen between a text file that they're working on and a shell running the REPL. They can then easily copy their working code from the REPL to their file (and vice versa).

One issue that I've encountered with the REPL, however, is the occasionally different behavior it exhibits vs. an actual program. For example, within the REPL it's fine to do:
let x = 4
let x = 5
var x = 6

But of course in a Swift program this wouldn't be permitted. Students are sometimes confused by this discrepancy.

1 Like

[offtopic] Since a lot of people participating in this thread use REPL, I would like to ask a question. Is it possible to use LLDB from Swift code in REPL? Access LLDB frame and other features just like LLDB Python scripts do?

@frrbn I appreciate you sharing your enthusiasm!

Yes, I've tried this site. There are also several others that are similar. I've used them when introducing Swift at all-day competitions. However, because one of our goals is to have students become intimately familiar with the terminal, I don't generally use them in high-school classes.

After an initial learning curve the experience has, overall, been quite good. In previous years we've used a modified version of flycheck which provided syntax highlighting and indications of some errors. It met most of our needs but things became more complicated when we began using dynamic libraries. I'll post separately about that issue. This year, we've moved to using Apple's SourceKit LSP which provides syntax highlighting along with code completion and much more. Keep in mind that all of this functionality is provided server-side; the student needs only a shell for full functionality.

Here's an example of code completion:
image

Here's an example of documentation:

Here's an example of real-time diagnostics:

Jumping to a definition within the same project seems to work for me in most cases. Jumping to the definition in a separate library also seems to work in most cases but sometimes seems to be "off" by a line or two.

Please let me know if you have any further questions. :slight_smile:

Dynamic Libraries - Challenge and Solution

One of the issues that we encountered using Packages for dependencies is that some of them can be quite large and take time (and CPU) to compile. For a single user tens of megabytes probably isn't a big deal but multiplying that by hundreds of students created a challenge both in terms of the required space and required compilation time.

Our goals:

  1. Minimize the resources required to use libraries that don't require compilation because they are part of our platform
  2. Provide real-time syntax highlighting, code completion, documentation, diagnostics, etc. even for code residing in libraries
  3. Provide students with the ability to use different versions of a library and/or enable them to develop a library on their own

Initially we simply used dynamic libraries and provided a script to feed parameters for Include and Link directories to swift build. This adequately addressed our first goal. The second goal was addressed by modifying flycheck to accommodate these parameters, providing syntax highlighting and some diagnostics but functionality was limited. The final goal proved more challenging and took some time to develop.

This year, in addition to moving to LSP, we'll be using a series of scripts which establish the environment prior to building or running. As before, the scripts set the parameters for Include and Link directories but the specific libraries to be used are now contained in a separate file (named dylib.manifest). Users simply update this file with the name and version of their libraries for which they have a dependency. Similar scripts are used to generate a .dir-locals.el file used by emacs to setup the LSP server so that the same libraries that are used for compilation are used by the LSP server. The scripts are available here. The guts are in the script makeSwift.sh.

I'm very interested to know of other (hopefully better) alternatives.

Do your students have separate user accounts? If they do, as part of provisioning you could arrange the library search path to include a directory in their home directory that they can use as a “local” install location, as well as an override include and binary path. That will give students a sandbox of this form.

What is this post? Some kind of troll?

I suggest you remove this false citation of the OP.

2 Likes

I will not engage in an attempt to start a flame war.

You have cropped the original sentence which is

On occasion, a few students (and/or parents) will complain that Swift is a "proprietary" language belonging to Apple and that Java should be taught instead.

to imply that the author made a statement which he did not intended to make. Feel free to express your disagreement.

Personally, I don't think the specific language(s) you learn as you start programming are really relevant at all. They serve as a tool to teach you the really valuable things: how to solve abstract problems with logical reasoning, devise algorithms and express yourself precisely. It's important to remember that we're talking about high-school students, here - engagement is more important than job prospects IMHO.

What I think is much more important is the ecosystem.

Kids of that age can start off being very enthusiastic about programming, "oh cool, I'm gonna build a thing that does X" or the game they always wanted, then they start figuring out the details and how hard all of those things are, and if it's too hard to make progress they can lose interest. There needs to be enough reward scattered along the way that they feel motivated to continue.

These days, I guess kids will want to make smartphone apps. That's simple enough if they have iPhones, but much more challenging if they have Android phones. My worry is that it may be more difficult for them to really get excited, and ultimately reach that point where they're so proud of their achievements that programming becomes a genuinely enjoyable creative outlet for them.

But I'm just guessing. The actual teachers are here and can say how important that is.

3 Likes

It's important to remember that we're talking about high-school students, here - engagement is more important than job prospects IMHO.

For high school students, I can recommend Apple's Learn To Code playgrounds. They are challenging enough to teach problem solving, while still being fun. And the APIs for Lego Mindstorms, mini drones, or sphero toys, make it so much more real than just seeing a figure move on the screen.

Unfortunately, that setup isn't cheap, so it’s not accessible to everyone.

1 Like

As for the tooling issue, one thing that I've been dying to try is compiling the Swift compiler to wasm.

It's been known for a long time showing that you can run clang in a browser (Example 1 - working demo, Example 2 - another, independent effort). So the tools to run the compiler (another complex C++ LLVM project) in a browser have existed for a while.

What hasn't existed until recently is a wasm port of the Swift runtime and standard library. Thanks to the SwiftWasm project, we should in theory have all the pieces for a portable toolchain. A wasm version of the compiler is just a static file, so it can also be stored and run locally from a terminal (via a host like wasmtime) or via a web browser. It could also produce native binaries, if you wanted that.

And the web is a platform everybody can enjoy.