From Spells to Syntax (Part 4: final)
Advanced Concepts
Welcome back to the final part of the series.
I hope you had a fun time with it and it, maybe, even give you food for thought.
Let us wrap up my ramblings with some other more ‘advanced‘ programming techniques and how they work in a similar way in writing.
If you haven’t seen the previous post, be sure to check it out here:
At the bottom, you can see the index of all previous posts.
Hope you will enjoy this one, and see you at the end.
Chapter 8: The "It Just Works" Principle: From Spells to Software
Now that you've reached this chapter, we'll delve into arguably the most important part of our comparison. Don't worry, it's not as difficult as the previous chapter, I promise. Even better, it's relatively short.
Let me ask you this: Do you know how your TV works? Not just the software, but how your remote signal is interpreted by the TV? How does the software logic in your smart TV understand and respond to that signal?
Raise your hand if you don't know. I certainly don't!
I have no idea how the TV does what it does. I could guess, but the chances of me being totally wrong are high. But you know what? It doesn't matter. As long as I can watch my anime and YouTube, I'm happy.
Thinking back at it, didn't Elena also not know how it worked? Let's see what she answered to Erik.
I don't know how it works, but I'm happy it did the trick.
Ah, yes. You see? Elena didn't know how it worked either, just as we might not understand how our TVs function. But as she said, it did the trick. There's no need to delve into the spell's intricacies. This principle is crucial in both coding and storytelling.
Let's start with coding for a change. In previous chapters, I discussed functions and their outputs, but I never explained what is actually happening inside the function. And that is totally fine.
Whenever someone writes a program, they will use functions they write themselves, or take them from the libraries we spoke of in the previous chapter. You know the code you write yourself, naturally, but the libraries are often a different story. Often, a single function within a library utilizes many others. Think of it as a main story with several spin-offs. These spin-offs contribute to the overall narrative, but you don't need to know their details to understand the main story. Take The Lord of the Rings, for example. You can watch the trilogy without seeing The Hobbit movies and still grasp the world. The reverse is also true, though you might be left with some unanswered questions.
To further illustrate this point, recall the discussion about magic in The Lord of the Rings from Chapter 5. The movies never explain how magic works, but do we really need to know? As long as it seems believable within the context of the story, we don't need detailed explanations. This principle applies to both storytelling and coding.
This principle holds true in coding as well. We can utilize functions that provide a wide range of functionality without necessarily understanding their internal mechanisms. Take our 'makeCapital' function, for instance. It might be incredibly useful, but I don't need to know its inner workings. As long as it transforms text to uppercase as expected, I'm a happy developer.
Naturally, there are situations where understanding the inner workings is essential, particularly when writing a story or program yourself. However, readers or users don't always need to grasp every detail. Generally, people prioritize functionality over intricate mechanics.
That wasn't so bad, was it? Relatively short and sweet, with a simple conclusion: 'I don't care how it works, as long as it does.' I must admit, I don't always follow this principle myself. In my novel, I wrote a backstory that extends all the way to the Big Bang. But that doesn't mean my coding is the same. _Often, I prefer not to know what's happening under the hood. Code gives me headaches enough already._
With this chapter all done and dusted, I want to leave you with one final chapter before we close off. I have pushed the subject away for far too long now and this is the moment I have to push through the barrier and face my fears.
Exceptions...
Chapter 9: "But It Worked on My Machine!"
The world isn't perfect, and things inevitably go wrong. Now, don't get me wrong, I'm not implying you have flaws. I wouldn't dare suggest such a thing. But mistakes happen, and when they do, how do we recover?
As the heroes walked toward the nearby village, the world suddenly froze. Birds hung motionless in the sky, sound disappeared, and time seemed to stop, freezing everyone in place.
“What is goi…“
** ERROR: Fatal exception occurred. Failed to load asset 'textures/ancient_ruins/stone_wall_03.dds'. Asset not found or corrupted. (Exception code: 0xC0000005)
Something went wrong here, that much is clear. But what exactly? The message provides a clue. Even without coding experience, you might sense the issue. But how does this relate to writing? In storytelling, the most obvious error is a misspelled word, flagged by a helpful squiggly line. However, hidden mistakes in writing can be far more detrimental, potentially undermining the entire narrative. Let's examine the source of this comparison.
When writing code, vigilance against typos is crucial. A single misplaced character can crash an entire program. While writing doesn't suffer such immediate and dramatic consequences, errors can still be disastrous, potentially derailing the narrative or breaking the immersion.
Picture yourself as a developer. You've written some code and are eager to test it. You launch the program, and—BOOM!—a big red error message appears on the screen. Your mind races, trying to identify the issue. Suddenly, you remember a missing element in your code. You fix it, restart the program, and it works flawlessly! Fantastic work! Now it's time to release your amazing program to the world and achieve fame and fortune.
Well, that's because it was. In programming, mistakes can sometimes be simple to fix. Other times, however, they can cause weeks of frustration before you discover that one missing character. But what about writing? How might an 'exception' manifest in a story?
Now imagine yourself as a writer. You've just completed your incredible action-fiction story. It's being printed, shipped to stores, and you eagerly await the reviews. You've meticulously reviewed your story, searching for any errors. Finding none, you're convinced it will become a bestseller. The next day, reviews arrive, and people start pointing out a plot hole.
There's your example of an exception in writing. The only difference is the potential for lasting mental anguish. Okay, maybe not that drastic, but you did make a mistake that ended up in the published book. Ironically, developers experience similar situations. The upside for developers is the ability to fix errors even after release. On the downside, the mental anguish might be just as real.
That amazing program you just released? It seems the personal information users entered wasn't adequately protected. Someone hacked your program, and now bank details are circulating online. In this scenario, as with the book, you can't undo the damage. You can only address the vulnerability and hope to prevent future breaches. While the repercussions for a book might be less severe, a writer's mistake could still damage their career and reputation, potentially leading to dire consequences. The same holds true for a developer who might lose his job over the mistake.
That took a bit of a dark turn, didn't it? Let's steer back towards a more positive outlook. Mistakes are inevitable, and hopefully, we all learn from them. This blog post likely contains its fair share of errors, and you might have cringed along the way. But just as I'm learning from writing on this subject, the mistakes I've made and the experience gained will help me write an even better post next time.
Throughout my coding years, I've encountered countless errors, all my own creations. But I've fixed them, learned from them, and ultimately become a more competent programmer because of them. The same applies to writing; we all learn by doing what we enjoy and doing it often.
Having reached this point, let's wrap things up with one final chapter. Don't worry, it's nothing major. I simply want to express my appreciation. So let's finish this journey together.
Chapter 10: That's All, Folks! (But Seriously, Thanks for Reading!)
It's been quite a journey, hasn't it? This was the first piece I've ever written. It's likely filled with grammatical errors, punctuation mistakes, awkward sentences, and more. But even so, I feel like I've learned a lot from writing it. As mentioned in Chapter 5, the goal of writing or coding can be as simple as learning something new. We learn by doing, and that's precisely what I've done here.
I put a lot of thought into this post, and I hope it shows. Writing it has been enjoyable, and I sincerely hope it's been informative for you to read. My greatest achievement would be if you grasped the coding concepts I've attempted to explain. Explaining a fictional world is far easier than explaining how coding relates to it.
If you have any questions or feedback, please share your thoughts in the comments. I'll do my best to respond to each one and will take all feedback to heart.
As promised, I'll keep this brief. Thank you for joining me on this journey. I hope you've learned something new, gained a fresh perspective on coding and/or writing, and most importantly, had fun.
I'll leave you to your own adventures now and hope to embark on another writing journey soon, perhaps inspired by my next shower session.
Have a great day and stay safe out there.
Cheers!
Haven’t read the previous entries? You can read them here:
Part 4: Two-sided <You are here>