状態, 同一性および変化という複雑性の下に潜む, 中心的論点は, 代入を取り入れたため, われわれの計算モデルに時(time)を認めさせられたということである. 代入を取り入れる前は, プログラムには, 値を持つ式は常に同じ値を持つという意味で, 時はなかった. それに対し3.1.1節の最初に述べた銀行口座からの払出しと, 結果の残高を返すモデルの例を思い起そう:
(withdraw 25) 75 (withdraw 25) 50同じ式の連続する評価は異る値を生じている. この振舞いは, 代入文の実行(この場合は変数balanceへの代入)が, 値が変る時の一瞬 (moments in time)をかいま見させることによる. 式の評価の結果は, 式そのものに依存するだけでなく, このような瞬間の前か後に起きたかにもよる. 局所状態を持つ計算オブジェクトを使ってモデルを作ろうとすると, プログラミングの本質的な概念として, 時に立ち向わざるを得ない.
われわれは更に, 計算モデルを, われわれの物理世界の概念に一致させる構造化に進むことが出来る. 世界にあるオブジェクトは, 一時に一個ずつ順々に変るわけではない. それらはむしろ, 並列的に(concurrently)---一斉に起きると思っている. 従ってシステムを, 並列的に動く計算プロセスの集りとしてモデル化するのが自然なことが多い. モデルを, 別々の局所状態を持つオブジェクトを使って組織化することで, プログラムを部品化出来たのと同様に, 計算オブジェクトを別々に, しかも並列的に進化する部分に分割するのも適切であることが多い. プログラムは逐次型計算機で実行することになるにしても, プログラムを並列的に実行されるものとして書く習慣は, プログラマに非本質的な時の制約を避けさせ, プログラムをより部品化的にさせる.
プログラムがより部品化的になるだけでなく, 並列計算は逐次型の計算より, 速度の点で利点があり得る. 逐次計算は, 一時には一演算しか実行せず, 仕事をするのに要する時間は, 実行した演算の個数に比例する.34 しかし問題を, 比較的独立で, 通信が殆んど必要ない部分に分解出来るなら, その部分を別々の計算処理装置に配分し, 利用出来る処理装置の数に比例した速度の改善が得られるかも知れない.
残念ながら, 代入で取り込んだ複雑性は, 並列性の前には, 更に問題になる.
並列実行は, 世界が並列に動いているからか, 計算機がそうだからかで, われわれの時の理解を更に複雑にしている.
34
実際には,
処理系の大部分は,
パイプライン(pipelining)という戦略により, 一時に数演算を実行する.
この技法はハードウェアの実効的な利用度を大きく改善するが, これは直列の命令列の実行を高速化しただけで, 逐次的なプログラムの振舞いは変らない.