# How to embed TIC-80 into Computer science 101 course

I'm planning to design an introductory course to CS and programming for kids of 8-12 grade and see that we have Scratch for catching an eye in the beginning and getting instant result on place.

But I need something about procedural programming as a replacement for Pascal, where kids could do something step by step without any abstractions. What I see is that I can potentially use either PICO-8 or TIC-80 fantasy consoles, but I don't see any materials or attempts to use Lua language for this goal. So the question is - why?

What are the drawbacks of teaching this way? (If we had non-dead Pascal with advanced graphical library like in DrRacket and good contemporary API - I'd rather have used this instead).

UPD: The question is inspired by the post of my colleague on Medium: https://medium.com/@astynax/%D0%BD%D0%B5-%D0%B2%D1%81%D1%91-%D1%82%D0%B0%D0%BA-%D0%BF%D0%BB%D0%BE%D1%85%D0%BE-%D0%B5%D1%81%D1%82%D1%8C-%D1%87%D0%B5%D0%BC%D1%83-%D1%83%D1%87%D0%B8%D1%82%D1%8C-30e4f50213a1 (Google translatable to english from Russian)

• I've come back to revisit this question a few times now, and I'm mostly perplexed. If you want to text procedural, imperative programming, there are just so many options. What are you having trouble locating? – Ben I. Jun 27 at 3:45
• Can you enlist these options? I mean not Just Programming language, but Programming ecosystem like in DrRacket with documentation and non-cryptic error messages. – paus Jun 27 at 5:11
• DrRacket isn't procedural, though, it's functional. After Scratch, a natural direction to take might be Greenfoot, which uses Java, but teaches it in a rather unusual way that is very friendly to beginners. (There is a book purchase for the instructor, though the software itself is free for the students.) – Ben I. Jun 27 at 16:44
• Java, like Python and others, is an industrial language starting with OOP from the ground up. It never been designed for educational purposes, like Pascal. I'd like to start with procedural language and next move to OOP with Squeak or Pharo. And only then, when we have two approaches on opposite sides like "everything is built by hands, no abstractions at all" and "everything is an abstraction, starting from numbers" will try to build something in between the procedural way and object-oriented way and explain industrial compromises developers of compilers have taken. – paus Jun 28 at 8:00
• «Pascal is superior as a teaching language to most of what followed» is a view which I whole-heartedly endorse. If you try to effectuate that into something pedagogically meaningful in 2020 you have my sympathies! You can try Delphi or Lazarus (free Pascal) or something... I don't expect the benefits will be worth the pain. I've written more on this here – Rusi Jun 28 at 8:56

Being on this site since the beginning, I have many times now encountered this notion that for introductory courses, higher level languages mean that students will deal with more abstraction and lower-level languages mean that they will deal with less abstraction, but I believe that this is fundamentally incorrect.

I'm going to actually recommend a frame-shift that I hope you will find helpful, and along the way, I hope to also persuade you to a different way of thinking about introductory programming courses.

I myself learned on BASIC and Pascal, so I have no specific objections to these languages. There is plenty of learning to be had in such languages! But there was also plenty of abstraction. It's not as if the "Read fetch execute" cycle, memory management, operating system architecture, or secure program memory segmentation are somehow magically apparent to a Pascal beginner, nor is that an appropriate goal for a beginning programming course. All of these languages (even C) are truly "high-level languages" full of metaphors and abstract ideas, and none of them will give a student any sense of what is going on under the good.

Don't believe me? Consider how much is "explained" to a student in this Pascal code:

type
color = ( red, black, blue, silver, beige);
car_color = array of [color] of boolean;
var
car_body: car_color;


Contrast that with this Java code for Greenfoot, which is a system made to teach beginners in Java, and spawns a Zombie at location (50, 50):

world.addObject(new Zombie(), 50, 50);


How much of what is going on "under the hood" will be understood in either example by a beginner? How clear is the expected behavior from what we type?

The purpose of high-level languages is:

1. To abstract away what is happening inside of the computer. People didn't want to learn new assembly languages, architectures, and capabilities for every new processor. Abstracting away what computer do is #1 on this list because it is the most important, and it is what drove us away from assemblies and into high-level languages in the first place.

2. To make some kinds of tasks easier to accomplish. The above code example is great. The compiler makes and manages an array for you! No multiplication to find the offset from the initial memory location on the stack needed! And the fact that I can now, in that same Pascal program, write:

if car_color[blue] then
writeln('blue paint has been applied' );


...is fantastic. It's useful! It makes the programmer's intentions clear! But it tells me nothing about blue not existing in the run-time execution at all, since it was remapped by the compiler to a 4-byte integer, or how writeln sends information to the console. The compiler allows me to work at the level of a metaphor, and handles the details all the way down.

I guess here's what I'm getting at: when you study any programming language, you are studying at the level of that programming language. Importantly, all of the stuff below that level is 100% opaque, and this is by design. It is in no way true that studying a non-OO imperative language will leave students feeling like everything makes sense, but studying an OO language will leave students feeling like everything is a mystery.

Both approaches uncover a tiny bit about one particular layer, and still leave basically everything as a mystery. It will take your students many more years of study before they feel like they have a handle on what computers actually do.

This is not to advocate for OO specifically, but rather to suggest that you reframe your question like so: since no particular programming language choice is going to explain things at a higher or lower level than the particular metaphors employed by that specific language, which language choice will get my students a lot of mileage as they go forward, both in terms of what they are capable of in my course, and in terms of what explorations it opens up for them afterwards?

My recommendation for that question is probably Java, Python, or JS. Since you're starting from the language Scratch, you might naturally go a game-building route to start, using PyGame in Python, Greenfoot in Java, or GDevelop in JS (Note: I have no experience with GDevelop, I just found it with a Google search).

Good luck with your course! Hopefully it will be a very satisfying and enriching experience, both for you and for your students.

• No. Java, Python, or JS - the worst choice for all of the educational purposes. JS is a: 1) leaking scope 2) arrays are objects 3) the weakest typing I've ever seen 4) huge amount of the special-case behaviors. You cannot escape OOP in both Python and JS, the most part of the API in stdlib has an object-oriented interface. Specifically for python: kids need arrays and strings out of the box, not heterogeneous lists and dictionaries. Python has a complicated debugging. Lots of cases like: >>> l = [[]] * 5 >>> l[0].append(42) >>> l [[42], [42], [42], [42], [42]]. And so on and so forth. – paus Jul 2 at 6:21
• @paus JS scope-leaks and lua doesn't? (That incidentally is why I said lua is worse than python in above comment) For the rest I broadly agree; just that what you call OO I would call "reference semantics". But if you prefer old fashioned arrays plus modern graphics you need to ask how consistent your wish is. Haskell will save you from reference semantics/OO and give you modern goodies but it's not (currently packaged for) children! – Rusi Jul 2 at 12:55
• @Rusi well, python has OO but we have to start from ground up, object oriented approach was created for people who already faced the code complexity and want to decompose/beat it. Kids have no complexity at the beginning. They see "for x in range". What is range? It's iterator. What is iterator? It's pattern. (pain) Also, it's implemented in a strange way: multiple inheritance, no information hiding. Paradigm, first time met in such implementation, may cause serious damage to students, making it hard to retrain them in a right way. If we want OO, maybe it's better to start with Squeak/Pharo? – paus Jul 2 at 14:00
• @paus I dislike oop. Period. Children. Adults. Big programs. small programs. Etc. So you're not going to get any disagreement from me in that regard! As for range, range(5) is just [0,1,2 3,4]. Python2 is kinder to beginners than python3. I've been teaching python for nearly 20 years; python3 has been around for nearing 10 but I always start with 2 not 3. Many reasons like this one... – Rusi Jul 2 at 15:32
• @Rusi but even in 2nd version of python, there is no code consistency in the language itself: l.append(x) BUT at the same moment map(f, l) and so on. Lots of special-cases like magic methods, casting to boolean here and there, mutable values by default for arguments... I can continue endlessly. Python is an industrial language, created by an artisan from programming and long ago, carrying with itself a bunch of legacies, not the most pleasant sometimes. – paus Jul 3 at 9:15