Intro To Magic

An excerpt from the fictional tales of Way of the Wizard: Modern Magic

So the question becomes, how do we program our world? There are those among us that claim such alteration is possible and we have no cause to doubt them. Skepticism is certainly not reason enough, as that’s merely a form of stodgy conservatism. To make any change, great or small, we must believe in its possibility.

Typically, when we start using computers, we’re not even aware that computer-programming is a thing. The operating system, and the applications running on top, just exist. And when we learn that actual people wrote said software, we believe it to be a feat apart from ourselves, a task undertaken by geniuses tucked away in a laboratory. We could never do that, it’s simply not possible.

We wouldn’t even know where to begin. What do we write, where do we write it? And if we dare look it up, we’re deluged by complexity. What if we look for a book? Which book do we pick? And once we start, how do we keep our head above the sea of uncertainty? Plus, a simplistic step-by-step guide is one thing, an unguided project is a far different beast.

It turns out that software development is more art than math. It is not so much completing equations, but a constant treadmill of trial-and-error. We should therefore expect world-level programming to be quite the same. For instance, let’s examine a realistic scene from the desk of a software developer:

“Will it work? Let’s see. Nope. Okay try something else. Nope. Wait, why’s it doing that now!? Okay how about this. Hmm. Okay let me look something up. Ah, okay, I’ll try this. Ooh better. Ahh, nope, now the other part doesn’t work. Okay let me take a break and see if inspiration strikes. [Later that day…] Aha, that’s it! [Fervent typing ensues…] It works! Now onto the next problem….”

This common scenario plays itself out again and again. The solution so often comes from outside the programmer. Either it comes from an actual archive of answers (a forum for programmers), or from some mystical source of inspiration that’s accessed by the programmer’s subconscious once he engages in another task.

Let’s not gloss over this point, that the key to a programmer’s code comes from external sources. One source is a repository of discussion compiled by programmers over the years. And another source is some other-worldly well-of-knowledge that provides solutions for problems posed to it while the mind is no longer actively searching.

So a wizard should expect much of the same. First, he needs to grasp that magic exists. Second, he must believe it’s a process he can proficiently navigate. Third, he must dive into some introductory materials that provide a cryptic set of rules and steps for completing basic but essentially useless projects. Then as aspirations expand, on comes a contentious time of attempting to self-solve a particular problem. This is accompanied by research into the ways of others who solved similar issues, alongside bouts of inspiration from one’s own imagination. Voila! A wizard is born.

In programming, there is no set canon of introductory materials. Programmers learn their craft by various means. There are a myriad of languages and techniques and styles of programming. There’s countless sources of introductions. The common theme though, is the intent and determination of the practitioner. And there is one other commonality: every programmer begins by writing a small program that prints a simple phrase, a very telling phrase: hello, world

Advertisements

Ancient Bindings

An excerpt from the fictional tales of Way of the Wizard: Modern Magic

Okay Rich, blah blah blah computer-programming, but what about magic?

But don’t you see, if the world is a computer simulation, then programming IS magic:
World.place(object)

But here’s the thing, the easiest programming to understand is typically the most restrictive. In the high-level environments you’re granted access to a few preset commands that aren’t very customizable. In order to tap into the low-level stuff that alters individual pixels of the interface, you’ll need to delve into the ancient API.

The problem with ancient APIs though, is their archaic format and overall complexity. For instance: in high-level programming, objects are managed for you, whereas in low-level, you need to account for their maintenance and dissolution. To call something with the ancient API typically takes more consideration and is much more prone to error.

And of course, if you attempt to build an entire program by invoking the ancient API, then the complexity and bugginess is going to compound. To account for this, programmers oftentimes use bindings that simplify access to the ancient API using a more modern parlance. This also allows the program’s heavy-lifting to be done in a high-level style whereas certain customizations can be made with bindings to the ancient API.

This is what we wizards seek, the bindings into the ancient API. It is simply not worth trying to create a program from the ancient API, the time and complexity are too much. We’d be decades working on a teetering foundation — we need instead to stand on the shoulders of giants. But this takes great discernment of course — because how can we recognize what we don’t know?

Yet that is the wizard’s gift — the ability to recognize a source of power. It’s no different than how a chef recognizes a source of flavor — it’s a built-in attribute of the character. And like a programmer, a wizard conjures whatever needs programming. Either he sees a hole that needs filling or he’s the middleman between clients and their vision.

Through observation we can witness that this world is not merely a pre-compiled binary, there’s also some scripting on the fly. As in a scripting language, code can write code. But of course we must know the correct keywords and syntax as well as the appropriate method of code execution. Programmers for instance don’t simply open up a text document and write random words and symbols.

No, wizards must learn their interface, they must study syntax and keywords. They must seek out repositories of source-code, deciphering the instruction-sets within. They must understand where and when to apply such commands and obtain the tools by which to evoke their spells. This is the way of the wizard, programmer of worlds.

Program For a Good Day

//##########################################
//Program for a good day
//version 1.0

//##########################################
//This function is called by the system whenever 
//self-awareness activates - its contents can be customized.
//If this function is not called frequently enough,
//run meditation routine
func selfAware()
{
	//this is a good opportunity to poll the emotional state
	currentMood = getCurrentMood()
	if(currentMood != pleasant)
		improveMood()
}

//##########################################
//activeThoughts is a system-populated array
//containing all thoughts currently in mind
func improveMood()
{
	foreach(thought in activeThoughts)
	{
		emotionalIntensity = getEmotionalIntensity(thought)
		isPleasant = determineDelightfulness(thought)
		
		if(emotionalIntensity > 0 && !isPleasant)
			defuseThought(thought)
	}
			
	generatePleasantThoughts()
}

//##########################################
func getCurrentMood()
{
	currentMood = null
	
	if(stressLevel == high)
		currentMood = unpleasant
	else if(aggravationLevel == high)
		currentMood = unpleasant
	else if(mouth != smiling || mouth != neutral)
		currentMood = unpleasant
	else if(posture != relaxed)
		currentMood = unpleasant
	else
		currentMood = pleasant
		
	return currentMood
}

//##########################################
func getEmotionalIntensity(thought)
{
	intensity = 0
	
	if(body == tense)
		intensity++
	
	if(gaze == focused)
		intensity++
		
	return intensity
}

//##########################################
func determineDelightfulness(thought)
{
	if(mind + thought == delight)
		return pleasant
	else
		return unpleasant		
}

//##########################################
func defuseThought(thought)
{
	isEasilyDismissed = dismissThought(thought)
	while(!isEasilyDismissed)
	{
		hasFlaw = findFlaw(thought)
		if(!hasFlaw)	
			imaginePositiveAlternative()
	}	
}

//##########################################
func generatePleasantThoughts()
{
	goodThoughtsArray = recallPastPleasantThoughts(5)
	foreach thought in goodThoughtsArray
	{
		visualizeThought(thought)
	}
}

//##########################################

Government Sauce

An excerpt from the fictional tales of Alien on Earth.
A story of an extraterrestrial’s warped interpretation of life on planet Earth.

When I was a software developer, I’d get requests for functionality that if fulfilled would result in imperfect code. So I resisted including features that cluttered the code-base. For my satisfaction, the underlying logic needed to be sound and neatly designed. Government is like that. It provides a functionality that users require yet it cannot be implemented cleanly. It’s spaghetti code.

Government therefore, is an art. Its imprecise sloppiness is a brutality on the idealistic brain. As in software design, it often seems easier to scrap the preexisting code and start from scratch. But that is a mirage that tricks inexperienced programmers. The complexity and functionality of the original system is not fully understood and not so easily replaced.

An idealist nature is apparent within the founding documents, but the implementation is pure pasta. But what choice is there? It’s a legacy system that must be maintained. Replacement would only lead to unforeseen catastrophes popping up everywhere as functionality was missed or poorly reimplemented. It’d be plugging one leaky hole after the next.

In software, sometimes major functionality can be abandoned due to requirement changes. Sometimes a better methodology is introduced that simplifies major aspects of the implementation. Government tries to fulfill the new as well as the legacy functionality expected of it, which is difficult. So either the requirements change or some innovative technique comes along — lest it gets even more unmanageable.

What’s the problem with spaghetti code? It’s difficult to improve and add new features. And even worse, subpar and confusing design leaves a system highly vulnerable to exploitation. Those seeking to profit can take advantage of inherent weaknesses in the system while those seeking to do good are stymied by the mess.

Like software, Government is a living system that requires constant monitoring, patching, and updating. If such mechanisms are not in place, then it’ll be rife with exploits. In other words, if the underlying process of government is not regularly maintained, then the system is likely compromised and controlled by exploiters.

A hacked system is one whose resources are diverted for use by the hacker. The exploiter might steal data or use the actual processing power to commit other attacks. Whatever the goal, the hacker gains at the end-user’s expense. Without effective monitoring and corrective measures, these actions can continue indefinitely unbeknownst to the end-user.

Like an operating system, the goal of a democratic government is to manage resources amongst all the processes and programs. If some are getting inordinate amounts of processing power, then the system is malfunctioning. The rogue process must be terminated before it destabilizes and crashes the entire system. Again, this requires monitoring and the ability to shut down resource hogs.

There’s a lot of creativity and maintenance involved in software and government. They’re living systems vulnerable to decay and exploitation. The most successful incarnations feature an honest and continuous dialog between developers and end-users, with feedback influencing design, where vulnerabilities and exploits in the framework are quickly patched, and the goal of each is cooperation toward an improved product.

Sweet Source

One of the problems I had with software development was finding something to make. Being more technical than creative, I only ever came up with the most mundane projects. And on top of that, I needed the source-code to be well-ordered with a logical flow, the functionality couldn’t be hacked together — if it was going to be kludgy, then I wanted no part of it — it had to be clean and tidy.

I tried my hand at commercial software development for a few years in the “shareware” markets. I made some sales but nothing major. Eventually when I needed some real money, I found a work-at-home programming job as an independent contractor developing websites. I was more experienced creating desktop software, so it took a little bit to get comfortable writing backend code for websites and tying them to databases.

Through subcontracting and sometimes sub-subcontracting, I even did work for a few large well-known companies. I had to be on conference calls and act all business-y. Prior to this, I had worked part-time at my father’s business doing computer related stuff, so it was somewhat familiar, the calls and talking to business people and being the tech guy and such.

But in the end, clients were no better at coming up with interesting projects to work on than I was. So with a lagging interest, combined with my persnickety approach to programming, it just didn’t work out in the end, me and software development. I can’t say I miss it, but I can’t say I’d never go back either. And technically, I still sell a small amount of software but no longer update it, so it’s likely to become obsolete.