程式是什么？
不同的人或许会给出不同的定义。不过如果让程远用最简单的话语来描述的话，那么程式便是“输入，处理，输出”！
没有输出的程式当然是存在的，只不过它没有任何意义。以计算机为例，无论一个程序是要计算一个数字还是绘制一个图形，它总要将结果输出到屏幕、打印机或者其它的输出设备上，否则这个程式的作用也就只有让芯片发热而已了——甚至严格说来，产生热量也算是输出的一种。
没有输入的程式当然也存在，然而如果换一种说法的话，我们也可以认为它们是“输入为一个空集”的程式，而每次调用一个这样的程式时，它都会返回完全相同的结果。什么，你说有那种产生随机数的程式？不好意思，严格地来说，这类程式需要一个隐含的“随机数生成种子”作为输入……它不能算是“没有输入”的程式。
除此之外，其它的程式都可以看做是接收一到多个输入参数，最终产生一到多个输出的演算过程。而且曾经有数学家证明过，每个“接收多个参数”的程式都可以被化简为数个接收“单一参数”的程式的形式——当然，这个说法并不严谨，而且那也是后话了。
程式间是可以进行组合的。
只要类型相同，那么我们便可以将一个程式的输出接到第二个程式的输入上，从而将二者组成一个更大的程式。那如何理解“类型相同”这个概念呢？举个例子：其实除了集成电路之外，其它的物件也是可以用于演算的——例如帕斯卡的计算齿轮组，而只有当齿轮的模数(即齿的间距)相同时，两个齿轮才能卡到一起。那么如果我们将一组齿轮看做执行一类演算的程式的话，那这组齿轮中的第一个齿轮的属性，便相当于这类程式允许接收的参数的类型。而同理，芯片的引脚电压，以及计算机程序中的字符数字，它们都有各自的类型。如果不关注运算过程是否正确的话，只要类型相同，那多个程式或者说计算系统间便可以借此进行组合了。
当成千上万，成百上千万的程式组合后，便形成了一个巨大的系统。这个系统也是一个程式，只不过它可以接收很多类型的输入，并借由各种各样的输出实现多种多样的功能，譬如我们常按的计算器，常玩的电子游戏，常用的操作系统……支撑它们正常工作的，正是它们内部运转的程式。
而在这个神奇的位面中，虽然载体不同，但是这里所特有的各种各样的神奇魔法，奥术，技能……
它们的内核，亦是如此。
——
——
程远用好奇的目光打量着浮现在他眼前的“源代码”。
虽然构成这段代码的并不是他所熟悉的任何一种地球位面的程序语言，不过幸运的是，构成这种语言的文字和算符，他绝大部分都认得。
不知道为什么，这个位面，或者说至少这个小镇所使用的文字和符号，都是标准的中文、英文、阿拉伯数字以及数学运算符，而他面前的程式也是如此。
说起来，地球位面的很多华国人总是对那些写满了英文字母的程序感到不满，并且希望出现一种使用中文的编程语言。然而可惜的是，这种做法实际上并没有太多的好处……或者说正因为中文的能力太过强大了，所以它并不适合进行编程。打个比方，一名外国人可能很难想象“中国队大胜韩国队”和“中国队大败韩国队”表达的是同一个含义，而这种二义性正是程序的天敌。因此，即使使用中文编程，人们也必须使用一种没有二义性的语法。
但这样的话还是会有问题：按照目前的键盘输入方式，中文字符的输入难度远大于英文字符，再打个比方：我们平时在做计算题时一般没有人会愿意写汉字的“壹加贰等于叁”，同样，写程式的人也很少有人愿意去使用“设甲为乙的平方与丙之和”这种写法。而且话又说回来，现代的很多程序语言已经完全支持中文命名了，只不过很少有人会这样用而已。
甚至如果要进一步来说的话，程序语言其实根本就不是英语，它们其实是一种独立的符号语言，只不过是设计语言的工程师在挑选符号时，恰好使用了他们熟悉的英文字母而已。对于程式来说，真正重要的是它所代表的执行逻辑，只要逻辑相同，那使用什么文字来编写程式其实都是无所谓的。
“怎么样大笨蛋，看明白了嘛？”望着似有所悟的程远，依灵调皮地戳了戳他的肩膀并问道。
“嗯，似乎能看懂一点。”程远一边审视着这些普通人看一眼就会觉得眼花的符号，一边下意识地回答道。与此同时，他想尝试用意念翻动一下面前的文字，可惜，他的操作没有成功。
“大笨蛋你肯定是在吹牛皮！”依灵白了他一眼。就算是品学兼优的高中生，面对这么多的程式指令时也会感觉头痛，更何况是程远这个从来没有接触过程式的菜鸟呢？
“这个还是很好懂的啊。”程远不以为意地回答道：“不过这段程式有点长，我这一时半会可能还看不完。”
“那这样吧。”依灵想了想后，收起了展示在程远面前的弹窗。
“哎等等，我还没看完呐！”程远手舞足蹈，不对，张牙舞爪地抗议道。
“初学者不要好高骛远。”依灵敲了一下青年的脑袋：“你先看明白这段入门程式再说吧。”
依灵一边说着，又一边在她的核芯系统中重新打开了另一个界面，随后，另一段“源代码”展示在了程远的面前。
如果将这段源代码翻译成中文的话，它的逻辑是这样的：
##
导入标准信息操作程式库；
导入超距作用程式库；
导入【花火】程式库；
定义程式：【Sequential Spark-连环花火】，接收输入参数：[能量]，[信息点]，“目标位置”，“攻击强度”：
1 -如果目标位置在超距作用场外，则退出程式，返回“法术施放失败”。
2 -执行程式【花火】，传入：[能量]，[信息点]，目标位置，攻击强度，并记录“执行结果”。
3 -如果执行结果为成功，则回到步骤2，否则如果执行结果为“能量用尽”或“信息点用尽”，则退出程式，返回“法术施放完成”。
##
望着这段眼前简短了许多的“源代码”，程远罕见地皱起了眉。
“这段代码是谁写的啊？”程远一边皱着眉头一边喃喃自语道。
“是人家小时候写的，怎么了嘛？”见程远表情有些奇怪，依灵疑惑地问道。
“哦，没什么没什么。”程远知趣地收回了话题。不过青年还是在心底不停地念叨着：“这是什么奇怪的语言啊，异界版的半吊子Basic？居然还有跳转语句这种东西……而且这个判断的写法有问题，会漏掉一部分条件的。”
可惜，我们的主角还是忽略了一点，女孩子的直觉可是很可怕的。
依灵微微噘起了嘴，她隐隐地感觉到，程远绝对是在心底默默地说她的坏话！
“那大笨蛋你觉得，这个程式的作用是什么呢？”少女悄悄地开始了反击。
“是循环执行【花火】这个程式吧。”程远不假思索地回答道：“使用者在调用【连环花火】这个程式的时候，输入的能量和信息点越多，能够施展的【花火】的次数就越多。”
少女惊奇地睁大了眼睛。
——他竟然真的看懂了！
“而且如果我猜得没错的话。”程远一无所觉地继续说道：“使用这个程式时，设定的攻击强度越强，能够发动的【花火】程式的次数就越少——因为能量的总量是有限的。”
少女的眼睛越睁越大。
“不过我还有一点不太确认。”程远又一边皱着眉头一边说道：“按照这个程序的逻辑，这两个参数[能量]和[信息点]应该会在执行【花火】这个程式的过程中发生改变吧，否则这个程式就无法终止了。这样说来，'方括号'的含义是代表'引用传递'么？不过我有点好奇，能量和信息点这两种实体是怎样传进程式里面去的，如果我在程式中写一行‘能量=能量+100’，会有什么效果呢？”
程远用虚心求教的眼神望向依灵。
“咳咳。”依灵连忙收起了自己有些震惊的表情，并故意用稳重的语调说道：“分析得还不错，不过人家必须纠正一点，这个方括号代表的其实是‘特殊参数’，比如[能量]，[信息点]，以及你以后可能会学到的[动量]等。这几类参数不能直接用数字进行赋值，只能通过分配的方式与同类型的参数间接地参与运算。”
依灵一边说着，一边在空中写写划划。
“比如，我们可以这样写：取二分之一的[能量1]→[能量2]，这样的话，我们就将能量1平均分成了两份，随后我们就可以把它们分给不同的子程式了。我们还可以写：[能量1]←[能量2]，这样我们就又将两份能量合并到了一起。”
这次轮到程远惊讶了：“这样的话……有意思！”
之前他也一直在疑惑，如果只是敲两行“程式源代码”就可以施展法术的话，那他如果将程式中的攻击力数值设成一万亿，那岂不是随手毁天灭地？不过现在看来，这个位面的人似乎是使用“类型系统”完美地避免了这种逻辑错误的发生。
“那人家也考你一个问题吧。”见程远也并不是无所不知，依灵的小心思又活络了起来：“如果人家执行刚才那个【连环花火】的程式，并传入T2.0的能量与足够的信息点，每次【花火】的攻击强度是T1.7，那这个程式执行时总共能发动多少次【花火】攻击呢？”
“嘿嘿，这个可难不倒我！”程远略加思索便得到了答案，随后他得意地回答道：“八次！”
按照这个位面的奇怪计数法，T2.0相当于T1.9的两倍，T1.8的四倍，T1.7的八倍，所以除一下就得到答案了嘛，程远这样想道。
“回答……错误！”依灵的嘴角翘起了一个小小的弧度：“因为程式自身在执行时，也会消耗能量和信息点，所以最后的答案是……少于八次！”
程远大惊：“怎么还有这种设定啊？”
“然而这就是事实呀！”依灵坏笑道：“大笨蛋你要是不信的话，可以自己执行一下这个程式试试看呀。”
依灵一边说着，一边随手在系统中敲了几个参数，并将“程式执行”的权限也开放给了程远。
“行呀！”程远随手就是一个“确认执行”的念头发了过去。然而他瞬间便意识到不对，如果按照依灵敲的那几个参数执行这个程式的话……
“啪！啪！啪！啪！啪！啪！啪！”
一连串有着鞭炮爆炸般威力的小火花在程远身边炸开，程远狼狈逃窜。
“捉弄大笨蛋真是太开心了！”
望着被吓得远远跑开的程远，少女的脸上久违地露出了一丝轻松的微笑。
