lunduniversity/introprog

This is the repo of a course given by Lund University called "Introduction to Programming" using Scala. The repo contains course material in Swedish and some English along with code examples and libraries used in exercises and labs.

Course homepage (in Swedish): https://lunduniversity.github.io/pgk

This is on-going work, and the first instance of the course was given in 2016 at Lund University. A new instance of the course is given each fall semester. In 2021 the course migrated to Scala 3.

How to use this repo

• Download latest stable version of the on-line course material from the course homepage

• Use a cached version or re-compile the latest snapshot version, possibly in an inconsistent state under update, of the most recent version of the course material via LaTeX.Online (if your click triggers a re-compile it may take very long before the pdf is ready; if the server gives timeout then try again later):

  • compendium1.pdf with lectures and assignments for the first half of the course, formatted for print.

  • compendium2.pdf with lectures and assignments for the second half of the course, formatted for print.

  • compendium.pdf with both parts above in one pdf formatted for easy screen readability and Ctrl+F search.

  • Thanks to LaTeX.Online for their amazing cloud service!

• Build it locally using sbt build as explained in "How to build" below.

• Download a stable, but possibly old, released version course material on the release page frozen at time of printing. The release page is updated at least before the start of each course instance in August each year.

Contents of this repo

The main directories are:

• compendium with the course teaching material including lecture notes, exercises, labs, etc.
  • modules with lectures exercises and labs for each week
  • generated with output from execution of plan/Main.scala included in the compendium
• slides with lecture notes in projector-friendly format
• compendium-en and slides-en are generated English-side mirrors of compendium and slides (see "English translation" below) — do not edit them by hand and do not commit them; they are git-ignored and re-created on each run of sbt autotranslate
• workspace with student workspace including lab code skeletons, examples, code libs etc.
• plan with module contents and concepts per week
• img images used in compendium and slides
• refs extra readings, background material
• teachers information for teachers

How to build

• Install sbt: https://www.scala-sbt.org/download.html

• Download and unpack this repo: https://github.com/lunduniversity/introprog/archive/master.zip or make a fork and then a clone as explained below

• run these sbt commands in a terminal window in the introprog directory:

  • sbt compile to compile all sources
  • sbt gen to generate the planning files, alias for sbt plan/run
  • sbt pdf to make slides and compendium using pdflatex
  • sbt build run both the commands gen and pdf in sequence

English translation (work in progress)

An English edition is being built up incrementally and is not finished yet. It lives in the generated mirror directories compendium-en and slides-en, produced by the autotranslate sub-project:

• sbt autotranslate (re-)creates compendium-en and slides-en, mirroring the directory structure of compendium/slides and copying each X.tex to X-en.tex. The text is not translated yet — for now the content is still Swedish; only the file names get an -en suffix and the local \input/\include references are rewritten so the mirror is self-consistent and buildable. Translation will be wired into this step over time.
• sbt pdfCompendiumEn builds compendium-en/compendium-en.pdf and sbt "pdfSlidesEn w01" builds slides-en/lect-w01-en.pdf, so the English side can be verified to compile even before the text is translated.

Because these directories are regenerated from the Swedish source, never edit compendium-en or slides-en by hand — any manual change is overwritten the next time autotranslate runs. They are git-ignored.

How to contribute

Fork and clone

• Learn the basics about git, especially the "Getting Started" and "Git Basics" sections in this book: https://git-scm.com/book/en/v2

• Get an account at github if you don't have one already. Recommended user name if in doubt: firstnamefamilyname with no capital letters and no hyphens.

• Install git: https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

• Make a fork of lunduniversity/introprog in GitHub to your own GitHub account: https://help.github.com/articles/fork-a-repo/

• Clone your fork to your local computer: https://help.github.com/articles/cloning-a-repository/

Keeping your fork in synch

• If you install the GitHub client (avaliable for Win and Mac but not Linux) called "GitHub desktop" https://desktop.github.com/ you can keep your fork in synch with the upstream repo by a single click in the GUI.

• Otherwise, this is how to pull changes from upstream to your fork with git commands: https://help.github.com/articles/syncing-a-fork/

Making contributions

• If you find a typo or minor issue that is straight-forward to fix you are very welcome to create a pull request directly as explained below. But if your contribution is more significant you should open an issue first and start a discussion about your proposal. In the latter case, click the issue tab at the top of this page.

• Before you change locally, make sure your fork is in synch (see above). Frequently do git pull or press the synch button in the GitHub desktop GUI.

• You must check that your fix compiles (to Latex or bytecode) before you commit.

• Whenever you are ready with an incremental change, do git commit -m "msg" and then git push, or commit in the GUI and press the synch button. Think carefully about your commit message, as discussed in the next section.

• When you are ready with a contribution that is good enough to be incorporated in upstream, then create a pull request: https://help.github.com/articles/creating-a-pull-request/

• Keep your pull requests minimal and coherent to create a small change sets that will be easy to merge as a single unit. Don't pack a lot of unrelated changes in the same pull request. Take a look here for examples of previously accepted pull requests.

• Don't include pdf:s or binaries in the pull request. The maintainers will recompile the repo after your pull request has been merged. You can then checkout your pdf:s before you synch with upstream.

Writing commit messages

• Write concise and informative commit messages that explains why the commit was made.
• Start each commit message with a direct verb, preferably one of the following:
  • add when you have created new stuff that was not there before
  • update when you have changed existing stuff
  • fix when you have corrected a bug or fixed a typo etc.
  • remove when you have removed stuff
  • rename when you have renamed files or other stuff without changing appearance/meaning
  • refactor when you have changed things structurally but not changed actual appearance/meaning
• Example of commit messages
  • git commit -am "update exercise w03 to improve explanation"
  • git commit -am "add task in exercises w05 vector copy"
• Make small commits and commit often. Try to keep commits atomic and only within one file if meaningful.
• Make sure your change compiles before committing. Do not push code that does not compile!

AI assistants and commit attribution

• Contributors to this project may use AI agents in their work to improve the introprog course material, if applied responsibly. We only ask that the git history stays clean and human-attributable.
• Do not credit an assistant as a commit author or co-author. Please leave Co-Authored-By: <assistant> trailers and "Generated with " badges out of your commit messages. Each commit is attributed to the human contributor who makes the change and stands behind it.
• Instead, tell us how you used an assistant in the pull request. If an AI assistant helped, a short honest note in the PR description or a comment (what you used it for, and what you checked yourself) is welcome and genuinely useful, and tells a future reader far more than a boilerplate trailer.
• The point is not to discourage AI help. It is to keep authorship and responsibility clearly human, and to put any AI assistance where it is most informative: in the discussion of the change.

Coding style

When learning how to program it is more important to write something and start experimenting in a playful way, than to forcefully adhere to a particular coding standard; but students should also (eventually) understand the benefits of having a coding standard.

In this course we pragmatically follow these style guides:

• Scala style:
  • The Scala style guide: http://docs.scala-lang.org/style/
  • A Scala best practice guide: https://github.com/alexandru/scala-best-practices
• Java style:
  • http://www.oracle.com/technetwork/java/codeconventions-150003.pdf

When you make contributions to code in this repo and when you review pull-requests, check that the contributions follow the above guidelines pragmatically. In particular, lab assigments stubs and answers to exercises should, if there are no special reasons not to, follow the above style guides.

Here are some other inspiring style guides that illustrate the variety in what different organisations impose:

• Scala:
  • http://twitter.github.io/effectivescala/
  • https://github.com/databricks/scala-style-guide
  • https://github.com/paypal/scala-style-guide
• Java:
  • https://google.github.io/styleguide/javaguide.html
  • https://wiki.eclipse.org/Coding_Conventions
  • https://www.securecoding.cert.org/confluence/display/java/Java+Coding+Guidelines

Latex guide

• Make sure you have your TeX editor set to UTF-8 encoding. If you get strange errors in relation to Swedish characters, this is likely due to problems relating to non-UTF-8 encodings on Mac or Windows. Linux usually works out-of-the-box.

• Install texlive-full to get all extra latex stuff that is needed to compile the tex code in this repo. If you don't know which tex editor to use, try texworks.

• For Mac OSX users: there are some problems with El-Capitan and TeX. For some users there are problems compiling .tex-files in the terminal out of the box. You may get this error message: 'mktexpk: No such file or directory' or similar. Using TeXShop to compile the document seems to resolve the issue. To configure TeXShop correctly on El-Capitan, follow the guide https://www.tug.org/mactex/UpdatingForElCapitan.pdf

• Check out the .cls files in compendium/ and slides/ that provide many useful latex commands.

  • compendium.cls
  • lecturenotes.cls

• Check out some similar, already written .tex document and compare with the compiled .pdf to see the commands and conventions we use.

• Some custom latex commands in our .cls files:

  • \begin{Code} ... \end{Code} and \scalainputlisting{examples/hello-app.scala} are used for Scala code
  • \begin{Code}[language=Java] ... \end{Code} and \javainputlisting{examples/Hi.java} are used for Java code
  • \begin{Slide} and \end{Slide} defined in slides/lecture-notes.cls and in compendium/compendium.cls is used to generate beamer slides and to generate framed text in compendium chapters together with lecture notes that appear after each slide.

License

This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.

Copyright © 2015-2022 Bjorn Regnell

Contributors: https://github.com/lunduniversity/introprog/blob/master/contributors.tex

You are free to:

• Share — copy and redistribute the material in any medium or format
• Adapt — remix, transform, and build upon the materia for any purpose, even commercially.
• The licensor cannot revoke these freedoms as long as you follow the license terms.

Under the following terms:

• Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
• ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.
• No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.