Online tutorial pet peeves
————————————

My top 10 points of unsolicited ranting/advice to those making video tutorials:

1. Avoid lots of pauses, saying “umm” too much, or other unnecessary redundancy in speech (listen to yourself in a recording)

2. If I can’t understand you at 1.5 - 2x playback speed and you don’t already speak relatively quickly and clearly, I’m probably not going to watch for long (mumbling, inconsistent microphone volume, and background noise/music are frequent culprits)

3. It’s ok to make mistakes in a tutorial, so long as you also fix them in the tutorial (e.g., the code that is missing a semicolon that all of a sudden has one after it compiles correctly — but no mention of fixing it or the compiler error that would have been received the first time). With that said, it’s fine to fix mistakes pertinent to the topic being taught, but don’t make me watch you troubleshoot your non-relevant computer issues or problems created by your specific preferences (e.g., IDE functionality not working as expected when no specific IDE was prescribed for the tutorial)

4. Don’t make me wait on your slow computer to do something in silence—either teach me something while it’s working or edit the video to remove the lull

5. You knew you were recording your screen. Close your email, chat, and other applications that create notifications before recording. Or at least please don’t check them and respond while recording and not edit it out of the video

6. Stay on topic. I’m watching your video to learn about something specific. A little personality is good, but excessive tangents are often a waste of my time

7. [Specific to YouTube] Don’t block my view of important content with annotations (and ads, if within your control)

8. If you aren’t uploading quality HD recordings, enlarge your font! Don’t make me have to guess what character you typed

9. Have a game plan (i.e., objectives) before hitting the record button

10. Remember that it’s easier to rant and complain than to do something constructive. Thank you for spending your time making tutorial videos. It’s better for you to make videos and commit all my pet peeves listed above than to not make videos at all—don’t let one guy’s rant stop you from sharing your knowledge and experience (but if it helps you, you’re welcome—and you just might gain a new viewer!)

Fave IDE: Rube-Goldberg Distributed Physical Editor (RGDPE)

- 3x5 note cards, rite aid brand
- pilot rolling ball gel pen
- white out
- a scanner with OCR, email
- a raspberry pi running a local email server and dns
- a raspberry pi running an SMTP receiver and language service and a handler to invoke the compiler
- a speak and spell to print out the language service results

Why: why not?

The rear ducking continues. We've built a reliable translator in the dumbest fucking way possible, it's just lovely. I simply reused the structure for feeding data to the VM assembler, an array of arrays, where there's one array of (ins [args]) per node in the parse tree.

It's nice because nodes can be solved out of order without affecting the actual sequence in which the instructions are output. And if one statement (node) equals multiple instructions, you just push multiple entries to the corresponding array, or push nothing if you need to output nothing. Easy as goblin pie.

This is enough to convert an input language to the assembly-like intermediate representation we use for the virtual machine. So then there's doing it backwards: walk the same array of arrays, and map those virtual instructions to a physical architechture. I guess I could do the encoding to native binary myself, it'd certainly be interesting to try, but I'm burnt-out already so I'll just use fasm for now.

Initial test: wrote a test program in my own stupid language, ran the translator, dump output to file, assemble that with fasm, run with r2 -d.

Crashes? No.
Runs fine? Yes and no.

For fuck's sake, I don't have syscalls. Mainly because the VM doesn't have an operating system, lmao. I was testing virtual programs by just freezing state, terminating, then dumping the fucking registers and stack to the console, we have no I/O to speak of. Not even a real 'exit', VM handles that by reading a return value every step like a mentally damaged son of a bitch.

So anyway, I manually paste the linux mambo, you know:

mov rax,60
mov rdi,0
syscall

And NOW our program can end execution without crashing.
Okay then, so does the test code work correctly?

** DRUM ROLL **

Yes.

Ladies and gentlemen, mother fucking PESO is now a compiled language, and going forward I will be expectantly receiving your marriage proposals for reviewing. Oh, but not so fast, we still need a frontend...

Well, we'll handle that in the next few days. I'm just glad to be *nearly* finished with this fucking compiler, I want nothing to do with anything else ever, but we know that's not going to happen, so Lord please end my pain.

No sponsor as this rant has been paid for by tax evasion.

"Unexpectedly found nil while unwrapping an Optional value"

What dev thought this would be a good idea in Swift? Sometimes I hear the compiler's thoughts as it comes across this:

1. The dev explicitly told me this value would be optional.
2. I have a record from the database, and I see a 'nil' in the column for this value.
3. That's not "None" , Oh my god, I need there to be an explicit "None<CustomType>".
4. Shit shit shit shit. Oh my god.
5. PANIC!