(1) Introduction
COP-3402, Spring 2024

Newton's Notebook on Grinding Lenses

IEEE Spectrum's Top Programming Languages

• Paul Gazzillo
• Assistant professor
• Research areas
  • Programming languages
  • Software engineering
  • Security
• https://paulgazzillo.com

https://www.cs.ucf.edu/~gazzillo/teaching/cop3402spring24

• Competency questions for each lecture
  • Will have homework questions each week (graded for effort)
  • Final will have similar questions
• Staying on topic, fewer tangents, leaving student discussions outside of lectures
  • 1hr lectures, 15min of questions, discussion per session

• More in-class coding and demos
• Lexer/parser given to you
• More breathing room to cover complex topics

• Webcourses
• Course webpage
• Ed Discussions
• GitHub

• Entrypoint to course
  • Links to webpage, Ed Discussions, GitHub
• Announcements
• Assignments and grades
  • Written homework submitted on webcourses
  • Code submitted on GitHUb
• Final exam

• Syllabus
• Schedule
• Lecture notes
• Project descriptions
• Homework assignments
• Videos to recorded lectures (if available)

• Discussion board
• Your public questions benefit other students
• Your question may have been answered, so check here!
• Faster than email

• Assignment #1: create a git repository in GitHub classroom
  • See webcourses for the registration link
• Do not put coursework repositories on personal account (neither public nor private)
  • Violates UCF's Golden Rule policies
• All code submitted via git
  • Version control is standard for software engineers
• Create a GitHub account today if you haven't already

1. The language
2. Their programming environment
3. Some computational theory

• Can't program without it
• Helps to know language constructs in detail
• Compilers reveal how the language itself works

• Editor, system software (libraries, linkers, loaders), the OS
• Helps you be faster, tackle large software
• Compiler works with system to make an executable

• Provides new mental models
• Algorithmic design and implementation
• Compilers use several models, automata and recursion

https://web.archive.org/web/20211014194234/http://threevirtues.com/

• The program does something wrong

• A program that does what it's supposed to do, but not what we think it does

• The programming language defines the expected behavior
• The compiler is the implementation
• A compiler bug means the program truly does what it's not supposed to
  • Hardware, kernel, system bugs can also cause incorrect program behavior

1. Narrow down the problem by crafting a smaller version of the test case
2. Go to the part of the your code that is related to the problem
3. Trace step-by-step what your code really does (not what you think/hope/feel/guess/divine/intuit/reckon it does)

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" –Brian Kernighan, "The Elements of Programming Style", 2nd edition, chapter 2.

• Easier to get the implementation right
• Gradually expand the specification
• Keep the implementation correct at each step

• Can't keep all code in mind for all time
• Make it easier for yourself
• Delay gratification
  • Finishing code fast feels good
  • Debugging shoddy code feels horrible

(Diagram)

• Breaking problems down takes time, experience, and making mistakes
• Premature generalization can waste work
• Don't be afraid to refactor
  • Easier to reorganize code after prototyping than to write from scratch (for large programs)

• Hides unnecessary details, exposes clear, simple interfaces
• Physical examples: cars, locks, sockets
• Interface decisions determined by use of that abstraction

• One of the most common and powerful
• Names a snippet of code
• Provides a definition of input and output
  • Developer provides documentation of behavior and usage
• You'll get to implement support for functions in your compiler

• Abstractions create software components
• Components can be tested on their own
• Developer can forget about details of the component
  • As long as the component is thoroughly tested and documented
• Large systems are composed of many layers of abstraction

• Bugs are (usually) not wrong programs, but incorrect assumptions
• Break the problem down into simpler specifications
• Use abstractions to build larger programs

• Program Development by Stepwise Refinement
• One methodology for breaking down a problem into abstractions

• Emulates hardware using software
• Fewer surprises during grading
• Applications (usually) can't tell the difference
  • Hardware vs software interpreting machine instructions
• Example: arcade/console emulators
  • https://archive.org/details/internetarcade

• Host: your OS running on native hardware
• Guest: the OS running on emulated hardware (which runs on your host)
• Hypervisor: manages direct guest access to native hardware

Note: if you are an on M1/M2/M3/etc. arm-based macbook, see the arm-based-macos-specific set of instructions

Open your terminal and run the following:

sudo apt install vagrant virtualbox
mkdir cop3402spring24 # create the course directory
cd cop3402spring24 # enter the course directory
wget https://www.cs.ucf.edu/~gazzillo/teaching/cop3402spring24/files/Vagrantfile # get the Vagrantfile
vagrant up # create the virtual machine, this will take some time
vagrant ssh  # enter the virtual machine

1. First, turn on file sharing.

2. Then, open Terminal, and enter these commands

   setopt interactive_comments
   
   # be sure that file sharing is turned on (see step #1 above)
   
   # install the homebrew package manager https://brew.sh/
   /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
   # enter your macos password if/when prompted
   
   # setup environment for brew
   (echo; echo 'eval "$(/opt/homebrew/bin/brew shellenv)"') >> $HOME/.zprofile
   eval "$(/opt/homebrew/bin/brew shellenv)"
   
   # install vagrant
   brew install vagrant
   # enter macos password if/when prompted
   
   # install qemu
   brew install qemu
   
   # install the qemu vagrant provider https://github.com/ppggff/vagrant-qemu
   vagrant plugin install vagrant-qemu
   
   # setup and enter the course VM
   cd # go to home directory
   mkdir cop3402spring24 # create the course directory
   cd cop3402spring24 # enter the course directory
   curl https://www.cs.ucf.edu/~gazzillo/teaching/cop3402spring24/files/arm/Vagrantfile > Vagrantfile # get the Vagrantfile
   vagrant up --provider qemu # create the virtual machine
   # enter password when prompted
   # enter both mac username and password again when prompted
   vagrant ssh  # enter the virtual machine
   

• Here are two ways
• When logged into the VM Guest OS: sudo shutdown -h now
• When in host OS (in Vagrantfile directory): vagrant halt

• If `make`, `gcc`, etc., are not available, use vagrant provision from the host machine
  • This can happen if the provisioning failed, e.g., due to a network issue
• From host OS (in Vagrantfile directory), and the machine is running (after vagrant up)
  • vagrant provision

• Some browsers may add a .txt extension to Vagrantfile. Be sure to remove this so that the file in your directoy is just Vagrantfile. Double-check with `ls` (*nix/mac) or `dir` (windows) that the filename does not have the .txt extension.
• Requires virtualization support enabled in BIOS, SVM for AMD or VT-x for Intel
• In windows, vagrant in WSL is not supported, use windows command-probmpt
• Anti-virus software may be intercepting https traffice (MITM), which vagrant rejects
• VirtualBox has scattered support for arm-based macs. It should be possible to use VMWare instead of VirtualBox by following these directions. These instructions may also help.

• If you want to destroy and recreate the VM
• Be sure you have nothing saved on the VM
  • Keep everything in your shared folder on your host OS
• vagrant destroy