天機果是難知︰

《黃帝陰符經》又稱《陰符經》，全書一卷三篇，傳聞是黃帝所撰，學者大多認為是後人偽托，現有三說：戰國時的蘇秦，北魏的寇謙之，或唐朝的李荃。這部經即使在中國古代的哲學和兵法中都有一定的地位。《陰符經》更是道教的一部重要道經，歷代對它的註解僅次於《道德經》和《南華真經》。《陰符經》有多種版本，在此僅舉一本，略探其自然人生之旨。

《黃帝陰符經》

觀天之道，執天之行，盡矣。天有五賊，見之者昌。五賊在心，施行於天，宇宙在乎手，萬物生乎身。天性，人也；人性，機也 ；立天之道以定人也。天發殺機，斗轉星移；地發殺機，龍蛇起陸 ；人發殺機，天地反覆；天人合德，萬變定基。性有巧拙，可以伏藏。九竅之邪，在乎三要。可以動靜。火生於木，禍發必克，奸生於國，時動必潰；知之修練，謂之聖人。

天生天殺，道之理也。天地萬物之盜；萬物人之盜；人萬物之盜也。三盜既宜，三才既安。故曰：食其時，百骸治；動其機，萬化安。人知其神而神，不知不神而所以神。日月有數，大小有定，聖功生焉，神明出焉。其盜機也，天下莫能見，莫能知也。君子得之固躬，小人得之輕命。

瞽者善聽，聾者善視。絕利一源，用師十倍；三反晝夜，用師萬倍。心生於物，死於物，機在於目。天之無恩而大恩生，迅雷烈風，莫不蠢然。至樂性餘，至靜性廉。天之至私，用之至公。擒之制在氣。生者死之根，死者生之根。恩生於害，害生於恩。愚人以天地文理聖，我以時物文理哲。人以愚虞聖，我以不愚虞聖。人以奇期聖，我以不奇期聖。沈水入火，自取滅亡。自然之道靜，故天地萬物生。天地之道浸，故陰陽勝。陰陽相推，而變化順矣。是故聖人知自然之道不可違，因而制之至靜之道，律曆所不能契。爰有奇器，是生萬象，八卦甲子，神機鬼藏。陰陽相勝之術，昭昭乎盡乎象矣。

─── 摘自《天地文理聖,時物文理哲？！》

 

變數實在難了︰

Variable (computer science)

In computer programming, a variable or scalar is a storage location paired with an associated symbolic name (an identifier), which contains some known or unknown quantity of information referred to as a value. The variable name is the usual way to reference the stored value; this separation of name and content allows the name to be used independently of the exact information it represents. The identifier in computer source code can be bound to a value during run time, and the value of the variable may thus change during the course of program execution.

Variables in programming may not directly correspond to the concept of variables in mathematics. The value of a computing variable is not necessarily part of an equation or formula as in mathematics. In computing, a variable may be employed in a repetitive process — assigned a value in one place, then used elsewhere, then reassigned a new value and used again in the same way (see iteration). Variables in computer programming are frequently given long names to make them relatively descriptive of their use, whereas variables in mathematics often have terse, one- or two-character names for brevity in transcription and manipulation.

A variable storage location may be referred by several different identifiers, a situation known as aliasing. Assigning a value to the variable using one of the identifiers will change the value that can be accessed through the other identifiers.

Compilers have to replace variables’ symbolic names with the actual locations of the data. While a variable’s name, type, and location often remain fixed, the data stored in the location may be changed during program execution.

Actions on a variable

In imperative programming languages, values can generally be accessed or changed at any time. However, in pure functional and logic languages, variables are bound to expressions and keep a single value during their entire lifetime due to the requirements of referential transparency. In imperative languages, the same behavior is exhibited by constants, which are typically contrasted with normal variables.

Depending on the type system of a programming language, variables may only be able to store a specified datatype (e.g. integer or string). Alternatively, a datatype may be associated only with the current value, allowing a single variable to store anything supported by the programming language.

Identifiers referencing a variable

An identifier referencing a variable can be used to access the variable in order to read out the value, or alter the value, or edit the attributes of the variable, such as access permission, locks, semaphores, etc.

For instance, a variable might be referenced by the identifier “total_count” and the variable can contain the number 1956. If the same variable is referenced by the identifier “x” as well, and if using this identifier “x“, the value of the variable is altered to 2009, then reading the value using the identifier “total_count” will yield a result of 2009 and not 1956.

If a variable is only referenced by a single identifier that can simply be called the name of the variable. Otherwise, we can speak of one of the names of the variable. For instance, in the previous example, the “total_count” is a name of the variable in question, and “x” is another name of the same variable.

Scope and extent

The scope of a variable describes where in a program’s text the variable may be used, while the extent (or lifetime) describes when in a program’s execution a variable has a (meaningful) value. The scope of a variable is actually a property of the name of the variable, and the extent is a property of the variable itself. These should not be confused with context (also called environment), which is a property of the program, and varies by point in the source code or execution – see scope: overview. Further, object lifetime may coincide with variable lifetime, but in many cases is not tied to variable lifetime.

A variable name’s scope affects its extent.

Scope is an important part of the name resolution of a variable. Most languages define a specific scope for each variable (as well as any other named entity), which may differ within a given program. The scope of a variable is the portion of the program code for which the variable’s name has meaning and for which the variable is said to be “visible”. Entrance into that scope typically begins a variable’s lifetime (as it comes into context) and exit from that scope typically ends its lifetime (as it goes out of context). For instance, a variable with “lexical scope” is meaningful only within a certain function/subroutine, or more finely within a block of expressions/statements (accordingly with function scope or block scope); this is static resolution, performable at parse-time or compile-time. Alternatively, a variable with dynamic scope is resolved at run-time, based on a global binding stack that depends on the specific control flow. Variables only accessible within a certain functions are termed “local variables“. A “global variable“, or one with indefinite scope, may be referred to anywhere in the program.

Extent, on the other hand, is a runtime (dynamic) aspect of a variable. Each binding of a variable to a value can have its own extent at runtime. The extent of the binding is the portion of the program’s execution time during which the variable continues to refer to the same value or memory location. A running program may enter and leave a given extent many times, as in the case of a closure.

Unless the programming language features garbage collection, a variable whose extent permanently outlasts its scope can result in a memory leak, whereby the memory allocated for the variable can never be freed since the variable which would be used to reference it for deallocation purposes is no longer accessible. However, it can be permissible for a variable binding to extend beyond its scope, as occurs in Lisp closures and C static local variables; when execution passes back into the variable’s scope, the variable may once again be used. A variable whose scope begins before its extent does is said to be uninitialized and often has an undefined, arbitrary value if accessed (see wild pointer), since it has yet to be explicitly given a particular value. A variable whose extent ends before its scope may become a dangling pointer and deemed uninitialized once more since its value has been destroyed. Variables described by the previous two cases may be said to be out of extent or unbound. In many languages, it is an error to try to use the value of a variable when it is out of extent. In other languages, doing so may yield unpredictable results. Such a variable may, however, be assigned a new value, which gives it a new extent.

For space efficiency, a memory space needed for a variable may be allocated only when the variable is first used and freed when it is no longer needed. A variable is only needed when it is in scope, but beginning each variable’s lifetime when it enters scope may give space to unused variables. To avoid wasting such space, compilers often warn programmers if a variable is declared but not used.

It is considered good programming practice to make the scope of variables as narrow as feasible so that different parts of a program do not accidentally interact with each other by modifying each other’s variables. Doing so also prevents action at a distance. Common techniques for doing so are to have different sections of a program use different name spaces, or to make individual variables “private” through either dynamic variable scoping or lexical variable scoping.

Many programming languages employ a reserved value (often named null or nil) to indicate an invalid or uninitialized variable.

 

何不直抵根本耶︰

美國數學家阿隆佐‧邱奇 Alonzo Church 對『符號邏輯』symbolic logic 的熱情與對基礎算術『形式系統』的研究持續一生。當他發現這類系統容易受到『羅素悖論』影響時，轉將所設想的『λ 運算』lambda calculus 單獨用於研究『可計算性』問題， 同樣否定的回答了『判定性問題』 Decision-problem ──

一九零零年德國大數學家大衛‧希爾伯特 David Hilbert 在巴黎的國際數學家大會上作了場名為《數學問題》的演講，提出了二十三道待解決之最重要的數學問題，這就是著名的希爾伯特之二十三個問題的由來。這裡的『判定性問題』 就是二十三個問題的第二題『算術公理之相容性』，一九三零年已為庫爾特‧哥德爾所否證 ──。美國 UCLA 大學 Enderton, Herbert B. 教授寫了一篇名為
《INTRODUCTION
Alonzo Church: Life and Work》的 Alonzo Church 小傳︰
…
In 1936 a pair of papers by Church changed the course of logic. An Unsolvable Problem of Elementary Number Theory presents a definition and a theorem:
“The purpose of the present paper is to propose a definition of effective calculability which is thought to correspond satisfactorily to the somewhat vague intuitive notion . . . , and to show, by means of an example, that not every problem of this class is solvable.” The “definition” now goes by the name Church’s Thesis: “We now define the notion . . . of an effectively calculable function of positive integers by identifying it with the notion of a recursive function of positive integers (or of a λ-definable function of positive integers).” (The name, “Church’s Thesis,” was introduced by Kleene.)
The theorem in the paper is that there is a set that can be defined in the language of elementary number theory (viz. the set of G ̈odel numbers of formulas of the λ-calculus having a normal form) that is not recursive—although it is recursively enumerable. Thus truth in elementary number theory is an effectively unsolvable problem.

A sentence at the end of the paper adds the consequence that if the system of Principia Mathematica is ω-consistent, then its decision problem is unsolvable. It also follows that the system (if  ω-consistent) is incomplete, but of course G ̈odel had shown that in 1931.
…

─── 摘自《λ 運算︰淵源介紹》

 

 

 

 

 

 

 

 

 

比較兩版『星圜』程式差異

 

 

能否得知『子程式』之好處的耶？？！！

Subroutine

In computer programming, a subroutine is a sequence of program instructions that perform a specific task, packaged as a unit. This unit can then be used in programs wherever that particular task should be performed. Subprograms may be defined within programs, or separately in libraries that can be used by multiple programs. In different programming languages, a subroutine may be called a procedure, a function, a routine, a method, or a subprogram. The generic term callable unit is sometimes used.^[1]

The name subprogram suggests a subroutine behaves in much the same way as a computer program that is used as one step in a larger program or another subprogram. A subroutine is often coded so that it can be started (called) several times and from several places during one execution of the program, including from other subroutines, and then branch back (return) to the next instruction after the call, once the subroutine’s task is done. Maurice Wilkes, David Wheeler, and Stanley Gill are credited with the invention of this concept, which they termed a closed subroutine,^[2][3] contrasted with an open subroutine or macro.^[4]

Subroutines are a powerful programming tool,^[5] and the syntax of many programming languages includes support for writing and using them. Judicious use of subroutines (for example, through the structured programming approach) will often substantially reduce the cost of developing and maintaining a large program, while increasing its quality and reliability.^[6] Subroutines, often collected into libraries, are an important mechanism for sharing and trading software. The discipline of object-oriented programming is based on objects and methods (which are subroutines attached to these objects or object classes).

In the compiling method called threaded code, the executable program is basically a sequence of subroutine calls.

Main concepts

The content of a subroutine is its body, which is the piece of program code that is executed when the subroutine is called or invoked.

A subroutine may be written so that it expects to obtain one or more data values from the calling program (its parameters or formal parameters). The calling program provides actual values for these parameters, called arguments. Different programming languages may use different conventions for passing arguments:

Convention	Description	Common use
Call by value	Argument is evaluated and copy of value is passed to subroutine	Default in most Algol-like languages after Algol 60, such as Pascal, Delphi, Simula, CPL, PL/M, Modula, Oberon, Ada, and many others. C, C++, Java (References to objects and arrays are also passed by value)
Call by reference	Reference to argument, typically its address is passed	Selectable in most Algol-like languages after Algol 60, such as Algol 68, Pascal, Delphi, Simula, CPL, PL/M, Modula, Oberon, Ada, and many others. C++, Fortran, PL/I
Call by result	Parameter value is copied back to argument on return from the subroutine	Ada OUT parameters
Call by value-result	Parameter value is copied back on entry to the subroutine and again on return	Algol
Call by name	Like a macro – replace the parameters with the unevaluated argument expressions	Algol, Scala
Call by constant value	Like call by value except that the parameter is treated as a constant	PL/I NONASSIGNABLE parameters, Ada IN parameters

The subroutine may return a computed value to its caller (its return value), or provide various result values or output parameters. Indeed, a common use of subroutines is to implement mathematical functions, in which the purpose of the subroutine is purely to compute one or more results whose values are entirely determined by the parameters passed to the subroutine. (Examples might include computing the logarithm of a number or the determinant of a matrix.)

A subroutine call may also have side effects such as modifying data structures in a computer memory, reading from or writing to a peripheral device, creating a file, halting the program or the machine, or even delaying the program’s execution for a specified time. A subprogram with side effects may return different results each time it is called, even if it is called with the same arguments. An example is a random number function, available in many languages, that returns a different pseudo-random number each time it is called. The widespread use of subroutines with side effects is a characteristic of imperative programming languages.

A subroutine can be coded so that it may call itself recursively, at one or more places, to perform its task. This method allows direct implementation of functions defined by mathematical induction and recursive divide and conquer algorithms.

A subroutine whose purpose is to compute one boolean-valued function (that is, to answer a yes/no question) is sometimes called a predicate. In logic programming languages, often^[vague] all subroutines are called predicates, since they primarily^[vague] determine success or failure.^{[citation needed]} For example, any type of function is a subroutine but not main().

 

 

 

 

 

 

 

 

 

難道 TurtleArt 之『積木』不該以『組合』為依歸的嗎？

電腦裡的『中央處理器』 CPU Central Processing Unit，是計算機的心臟，從開機後就『不停的』執行著指令，這些 指令構成了 CPU 懂得的指令集，按照  CPU 硬體設計架構分成了複雜指令集 CISC ，比如 PC 上用的 Intel 的 x86，和精簡指令集 RISC ，就像樹莓派上用的 ARM。這些指令和資料構成的程式存放在隨機記憶體 RAM ── 可以想像成『編了地址』，可以用任意地址讀寫的『記憶單元』 ── 上，由 CPU 依序『解譯』執行程式裡的指令，存取程式裡的資料。這種『儲存程式』的計算機模型依循著 Von Neumann 先生的計算機『建築學』architecture 而設計。在這個 CPU 指令解譯器裡，有一個『指令地址指標』── 稱作程式計數器 Program Counter ── 告訴 CPU 『下一個』指令在 RAM 上的哪個地址。每個指令不論是『算術邏輯運算』、『記憶體資料存取』和『控制陳述』 …等等的指令執行時，都會『更新』這個程式計數器。於是 CPU 就能從硬體設計上開機時所固有『起始的』地址上『讀取』fetch 第一個指令，然後開始『執行』execution，再讀取下一個指令再執行，一直的讀取．執行持續不停。由於指令與資料並不區分，都放在相同的記憶體上，就可能發生把資料當作指令或是將指令當成資料的情況，一般會導致『當機』。這個前面說的指令集，就是 CPU 唯一會的『機器語言』── 以二進制方式儲存在記憶體上的一長排位元組。即使最簡單的『組合語言』Assembler 功能僅僅提供機器語言的『助憶碼』Assembly Mnemonic ，也得把用它寫的程式『組譯』成機器碼 Machine Code，CPU 才能執行；更不要說這個組合語言自己也得能執行才能進行組譯。假使你覺得組合語言很有意思，你可以看看劍橋大學開的烘焙 Pi 開發作業系統公開課；或是裸裸金屬樹莓派編程打算寫的一本書；以及樹莓派組合碼部落客。這裡藉著簡單介紹『思考著的極客』一文上用 Gnu as 組譯程式寫的 first.s 原始碼，欣賞程式組譯這回事︰

/* — first.s */
/* This is a comment */
.global main /* ‘main’ is our entry point and must be global */
.func main /* ‘main’ is a function */

main: /* This is main */
mov r0, #2 /* Put a 2 inside the register r0 */
bx lr /* Return from main */

 

人世間所謂『高階、低階』語言已爭議長久的矣？？

雖說第一個高階程式語言是德國Konrad Zuse 先生的 Plankalkül，大約構想於第二次世界大戰末期，然而第一個廣為使用的卻是福傳 Fortran ── Formula Translation 的縮寫。1957 年IBM 當時的工程師約翰·華納·巴克斯 John Warner Backus 因深切體會到編寫程式的困難，需要更好的程式語言所創。他也就是知名的『 BNF 』巴科斯-諾爾範式 Backus–Naur Form 的創始者之一，這個範式 是一種表示無上下文脈絡關係 Context Free 文法之語言，可以用來描述 CF 這一類的形式語言，這包括了絕大部分的電腦程式語言。其後又有了 1969 年在 Bell Labs circa 由 Ken Thompson 和 Dennis Ritchie 所發展的 B 語言，然後於 1971 年之際演變成 New B，最終於 1972 年變成了今天的 C 語言 ── After B ──，形成了美麗的『ABC』語言傳奇。

事實上 Von Neumann 的計算機架構，對於電腦程式語言的發展，有著極為深遠的影響，產生了現在叫做 Von Neumann 程式語言，與Von Neumann 的計算機架構，同形 isomorphism 同構︰

program variables ↔ computer storage cells
程式變數 對映  計算機的儲存單元

control statements ↔ computer test-and-jump instructions
控制陳述 對映 計算機的『測試．跳至』指令

assignment statements ↔ fetching, storing instructions
賦值陳述 對映 計算機的取得、儲存指令

expressions ↔ memory reference and arithmetic instructions.
表達式 對映 記憶體參照和算術指令

John Warner Backus 曾經斷言，由於電腦圈長期過度強調 Von Neumann 的程式語言與計算機架構，已經產生了『惡性循環』，使得非此類的語言由於不符合經濟而日漸式微，比方 APL 語言 ── 註︰有興趣的，可以參照這裡在 Raspbian 上安裝 ──。

行文至此，不得不提及 Charles H. Moore 先生，他認為像 as 或 gcc 那樣的程式語言，依循著 compile-link-go 編譯．連接．執行的步驟都該叫做『第三代』的電腦語言，因而想發明『第四代 FOURTH』語言，但由於 IBM 1130 電腦作業系統，限制檔案名稱長度最多五個字元，以至於 FOURTH 被迫變成了現今稱作『Forth』的電腦程式語言。這是一個以『堆疊 Stack』為中心，用『字典』定義『字』方式的一種交互式 interactive 的編譯．解譯寫程式的環境，十分有趣而獨特。有時還真不好說它算是低階還是高階語言，彷彿是種『由低到高』的程式編寫世界。你可以參考這份文件的說明，進到 Forth 的國度裡『逍遙遊』！！

─── 摘自《CPU 機器語言的『解譯器』》

 

或許『結構化編程』實有所指的乎！

Structured programming

Structured programming is a programming paradigm aimed at improving the clarity, quality, and development time of a computer program by making extensive use of subroutines, block structures, for and while loops—in contrast to using simple tests and jumps such as the go to statement which could lead to “spaghetti code” causing difficulty to both follow and maintain.

It emerged in the late 1950s with the appearance of the ALGOL 58 and ALGOL 60 programming languages,^[1] with the latter including support for block structures. Contributing factors to its popularity and widespread acceptance, at first in academia and later among practitioners, include the discovery of what is now known as the structured program theorem in 1966,^[2] and the publication of the influential “Go To Statement Considered Harmful” open letter in 1968 by Dutch computer scientist Edsger W. Dijkstra, who coined the term “structured programming”.^[3]

Structured programming is most frequently used with deviations that allow for clearer programs in some particular cases, such as when exception handling has to be performed.

Elements

Control structures

Following the structured program theorem, all programs are seen as composed of control structures:

• “Sequence”; ordered statements or subroutines executed in sequence.
• “Selection”; one or a number of statements is executed depending on the state of the program. This is usually expressed with keywords such as if..then..else..endif.
• “Iteration”; a statement or block is executed until the program reaches a certain state, or operations have been applied to every element of a collection. This is usually expressed with keywords such as while, repeat, for or do..until. Often it is recommended that each loop should only have one entry point (and in the original structural programming, also only one exit point, and a few languages enforce this).
• “Recursion”; a statement is executed by repeatedly calling itself until termination conditions are met. While similar in practice to iterative loops, recursive loops may be more computationally efficient, and are implemented differently as a cascading stack.

Subroutines

Subroutines; callable units such as procedures, functions, methods, or subprograms are used to allow a sequence to be referred to by a single statement.

Blocks

Blocks are used to enable groups of statements to be treated as if they were one statement. Block-structured languages have a syntax for enclosing structures in some formal way, such as an if-statement bracketed by if..fi as in ALGOL 68, or a code section bracketed by BEGIN..END, as in PL/I, whitespace indentation as in Python – or the curly braces {...} of C and many later languages.

History

Theoretical foundation

The structured program theorem provides the theoretical basis of structured programming. It states that three ways of combining programs—sequencing, selection, and iteration—are sufficient to express any computable function. This observation did not originate with the structured programming movement; these structures are sufficient to describe the instruction cycle of a central processing unit, as well as the operation of a Turing machine. Therefore, a processor is always executing a “structured program” in this sense, even if the instructions it reads from memory are not part of a structured program. However, authors usually credit the result to a 1966 paper by Böhm and Jacopini, possibly because Dijkstra cited this paper himself.^[4] The structured program theorem does not address how to write and analyze a usefully structured program. These issues were addressed during the late 1960s and early 1970s, with major contributions by Dijkstra, Robert W. Floyd, Tony Hoare, Ole-Johan Dahl, and David Gries.

Debate

P. J. Plauger, an early adopter of structured programming, described his reaction to the structured program theorem:

Us converts waved this interesting bit of news under the noses of the unreconstructed assembly-language programmers who kept trotting forth twisty bits of logic and saying, ‘I betcha can’t structure this.’ Neither the proof by Böhm and Jacopini nor our repeated successes at writing structured code brought them around one day sooner than they were ready to convince themselves.^[5]

Donald Knuth accepted the principle that programs must be written with provability in mind, but he disagreed (and still disagrees^{[citation needed]}) with abolishing the GOTO statement. In his 1974 paper, “Structured Programming with Goto Statements”,^[6] he gave examples where he believed that a direct jump leads to clearer and more efficient code without sacrificing provability. Knuth proposed a looser structural constraint: It should be possible to draw a program’s flow chart with all forward branches on the left, all backward branches on the right, and no branches crossing each other. Many of those knowledgeable in compilers and graph theory have advocated allowing only reducible flow graphs^{[when defined as?]}.^[who?]

Structured programming theorists gained a major ally in the 1970s after IBM researcher Harlan Mills applied his interpretation of structured programming theory to the development of an indexing system for the New York Times research file. The project was a great engineering success, and managers at other companies cited it in support of adopting structured programming, although Dijkstra criticized the ways that Mills’s interpretation differed from the published work.^{[citation needed]}

As late as 1987 it was still possible to raise the question of structured programming in a computer science journal. Frank Rubin did so in that year with an open letter titled “”GOTO considered harmful” considered harmful”.^[7] Numerous objections followed, including a response from Dijkstra that sharply criticized both Rubin and the concessions other writers made when responding to him.

Outcome

By the end of the 20th century nearly all computer scientists were convinced that it is useful to learn and apply the concepts of structured programming. High-level programming languages that originally lacked programming structures, such as FORTRAN, COBOL, and BASIC, now have them.

 

也許『可計算性』與『實務應用』真有所不同的耶！！

故而小海龜繪圖果從善如流也☆