teammates - 510
Inspiration
A year before I started my Computer Engineering course, I decided to learn programming. I decided to pick up Python, and I went with Zed Shaw's Learning Python the Hard Way, because it said it was good. Like many before me, I got bored. I couldn't finish it. I heard from various other people about how they also tried and failed to self-learn programming. But when I started Year 1 in university, picking up programming was actually quite easy. What went wrong?
Later, I started reading the book The Little Schemer, which challenged all my perceptions of what a programming tutorial is supposed to be. It taught a very alien language, in a purely Question and Answer format. What LPTHW and many mainstream tutorials did was to teach you a thing, then ask you to apply it. The Little Schemer teaches you by asking a question you do not know, then immediately providing the answer. It was a very tight feedback loop and a very enjoyable learning experience.
What it does
teamtutor is an attempt to hopefully model that experience. There is no 'learn a chapter', then 'apply everything you learnt, at the end of the chapter'. It delivers the Question and Answer style of tutorials in an interactive way so you can actually ponder each question and write out your answer before being revealed the answer. It also contains a built-in REPL (for javascript, not scheme) for learners to immediately try their code out in. It's intended to be a one-stop-shop, batteries-included program for learning programming immediately.
How I built it
I used golang and gocui, using otto for the javascript parser/interpreter. I initially wanted to use C and ncurses, but I was worried about cross-compilation compatibility. AFAIK running cc or gcc only compiles a binary for the current machine, so it didn't work if I ported my macbook-compiled a.out to a linux machine (and thus windows too). Golang on the otherhand provides effortless cross-compilation, you can compile windows programs on a macbook easy.
Challenges I ran into
A primary source of frustration was the rather bare API exposed by gocui. Calling console.log() from otto kept printing text that I was unable to clean up or even read using gocui's Clear().
gocui also seems to lack low level functions like reading or writing to a specific coordinate, only allowing you to read the entire view buffer at once (making reading in a user's latest input a pain) or only allowing you to write to the end of a view buffer (making it very difficult to fine-tune your user's writes).
Accomplishments that I'm proud of
I nearly gave up because I couldn't figure out how to get the user's latest input, since you can only read an entire view buffer at once how do you figure out which part of the text is the user's latest input? Plus gocui doesn't have any generic key event handling, you have to explicitly program every key that a user presses. In the end I figured out how to not write a key event handler function 26 times for all alphabets and 26 times for their capitalized versions and 10 times for each digit and... etc. by looping over a string of characters and a partially applied function
What I learned
hackathons are not good places to find good code
What's next for termtutor
Maybe rewrite it using the lower-level library tcell, so that I have more control over the basic functions. If I have time.
Built With
- gocui
- golang
- otto
Log in or sign up for Devpost to join the conversation.