このコースは主にジュニア開発者を対象としており、「なぜPHP（Java、Perl、Bash）が吸うのか」というトピックに関するホリバーの議論レベルを上げることができます。
このコースでは、チューリングコンピューターに基づいたプログラミングのストリームモデル、最新の言語ツールの出現の歴史、およびそれらの適用可能性の領域を検討します。 また、OOPおよび関数型プログラミングとは、明確かつ明確に説明されています。
パート1：言語の表示方法とその理由
パート2：機能を維持する原則
パート3：構文シュガーまたは言語開発の歴史
言語の登場とその理由
データを処理し、処理結果を何らかの形式で表示するには、言語が必要です。
コンピューターには常にデータソースとデータシンクがあります。 概して、コンピューターは単に情報を複数のソースから複数のシンクにリダイレクトし、途中で変換を行います。
プログラミング言語とは、情報を変換するためのルールを、自分自身またはコンピューターに都合のよい形式に設定する言語です。 実際、すべてのプログラミング言語をチューリングマシンでの操作に減らすことができます。
チューリングマシン
チューリングマシンは、無限の磁気テープです（チューリングが機能していた時代を思い出してください-磁気テープは非常に進歩的なデバイスでした）。 テープは論理セルに分割されます-テープの連続したセグメントに1つまたは別の信号を記録できます（たとえば、ASCII文字）。
マシンは、テープを1セル分左または右に移動したり、現在のセグメントを読み取ったり、現在のセグメントに何かを書き込んだりできます。 各操作は、マシンが現在のセルの値を読み取り、遷移テーブルに従ってこの値の意味を確認し、2つのアクションを実行することから始まります。同じセルに新しい文字を書き込むことと、1つのセルを左にシフトするか、1つのセルを右にシフトします。
これらの2つのアクションを実行すると、サイクルが繰り返され、サイクル間でデータは送信されません。 特定の各サイクルで、マシンは現在のセルから読み取った文字のみを処理します。 もう一度-彼女がマシンが覚えていない最後にカウントしたセルからのシンボル。
チューリングマシンのプログラムは、遷移表の形式で設定されます。シンボルAが左へのシフトの場合、Bが右へのシフトの場合、CがセルDに書き込まれ、左に移動する場合、Eが停止操作の場合（など）、文字がなくなるまで）
チューリングマシンによって指定される主な定義の1つは、実行コンテキストです。
プログラム実行のコンテキストは、その動作を決定するすべてのデータの全体です。
ルール設定のパラダイム
チューリングマシンの例からわかるように、PLはデータを操作するのではなく、データ変換を操作します。 ただし、処理のルールは何らかの形で提示および定義する必要があります。 現時点では、処理のルールを定義するための2つの方法が見つかりました。これらは、記録ルールの命令型および宣言型です。
宣言形式
最初の形式は宣言型と呼ばれます。 このタイプの変換の記述の良い例は代数記法です：aはセグメント[b、c]に属します（この事実を仮定します）、dは条件d = f（a、b）が満たされた場合に線（a、b）に属します（この事実も仮定します） 。
宣言的なPLは、ページのHTMLとCSSを記述するためのルールです。 たとえば、後者では、要素が特定のクラスに属している場合、それを赤でペイントする必要があると仮定できます。
宣言型言語は、結果を取得するために実行する必要がある手順を記述しませんが、結果として取得する必要があるものを記述します。
宣言PLは、入力データとプログラムの最終結果に特に注意を払います。 データ変換プロセスにはあまり注意が払われません。
命令形
ルールの表示の2番目の形式は、命令型と呼ばれます。 チューリングマシンは、命令型プログラミングの理論モデルとして機能しました。
命令形式：これは命令で表現された順序のリストです。 たとえば、値を（cb）/ 2に割り当てます。 または、aがbに等しい場合、次のコマンドの実行に進みます。それ以外の場合-他のコマンド。 命令形式の注意は、データ自体ではなく、このデータを処理するプロセスに与えられます。
命令型言語は、変換の結果ではなく、情報を変更するプロセスの記述に焦点を当てています。
ソースデータを結果に変換するために、プログラムの実行はステートメントの順次実行に限定されます。
命令型言語の規則が宣言形式で設定されているのは興味深いことです。ここでは、遷移と情報処理の規則があります。
情報処理パラダイム
PLは、ルールを設定する方法に加えて、処理されたデータへのアプローチ方法も異なります。 PLが変換する情報を注意深く見ると、離散と連続の2つのタイプがあることがわかります。
離散イベントモデル
情報の離散表現の典型的な例は、同じチューリングマシンです。 提出されたすべての情報と処理結果は、等しい部分に分割されます。
離散表現の別の例は、デジタルオーディオデータの着信ストリームの処理です。 このようなストリームを読み取るには、定期的に入力される数値の配列、つまりデータバッファが使用されます。データバッファは、処理されて変換されます。
情報を個別に表示する場合、プログラムの周期的な性質は入力メソッド自体によって設定されることがわかります。バイトを読み取り、処理を行い、結果を吐き出します。
しかし、情報の断片のサイズが揃っていない場合はどうなりますか？ たとえば、長いテキストはプログラムの入力に送られ、プログラムは文字、記号ではなく単語で動作する必要がありますか？
このような問題を解決するために、イベントの概念が導入されています。 イベントは、データソースから読み取られた認識されたシーケンスに応答して発生します。
テキストと単語を使用した例を検討する場合、データをバイト単位で読み取り、補充するメモリバッファに書き込みます。 そして、データストリームでスペースまたはピリオドを読み取るまでこれを行います。これは、イベント「単語の終わり」の発生を意味します。
「単語の終わり」というイベントが発生した後、バッファ内に単語全体があることを確認できます。 これで、分析、意味の理解、指定された処理ルールの適用、次の単語を読み取るための新しいバッファの準備などができるようになりました。
情報処理に対する離散イベントアプローチでは、システムの機能はイベントの時系列のシーケンスとして提示されます。 イベントは特定の時点で発生し、システムの状態を変更します。
イベントの発生は、プログラムにとって1つの非常に重要なアクションを意味します。つまり、プログラムは自身の状態（実行コンテキスト）を変更します。 イベントの発生後、プログラムは、このイベントが発生したというこの知識に基づいて動作できます。 たとえば、「abyrvalg」という単語を見つけた場合、作業中にそれがさらに存在するという知識を使用できます。
連続データモデル
「イベントが発生し、これに対応する必要がある」というプログラミングアプローチは、どこにでもあり、今では自然なことのように思えますが、まったくそうではありません。 連続データでは、多くのことがより自然に記述されます。
たとえば、所定の間隔でプールを水で満たす古典的な学校のタスク（一方のパイプが水を注ぎ、もう一方のパイプが水を注ぐプール）は、代用宣言型言語を使用すると、水の入口と出口の機能の解の違いとして解決するのがはるかに簡単です。
また、連続データを使用する場合、ベクトルグラフィックスに関連するタスクは、はるかに簡単に解決できます。 たとえば、離散データ処理を使用して画面上に円を描くには、ピクセルを操作して、円の条件を満たす各ピクセルの位置を計算する必要があります。 この場合の円は、ピクセルの配列として表されます。 ベクトルデータを処理するプログラミング言語を使用する場合は、円の機能とそのパラメーターを示すだけで十分です。
連続データを使用すると、イベントの概念が失われます。
イベントとデータの一部に対してアクションを実行する手順が必要な場合、処理に離散イベントアプローチを適用するのが最も便利です。 これらは、ユーザーからのイベントに応答し、着信データストリームからイベントを解釈および分離し、情報を連続的に変換するタスクです。
「一般的な」図が必要な同じ場所で、分析言語のアプローチが最も便利です。データスライスの取得、データ構造の記述、数学関数の解法、グラフィックの記述、入力ストリームの連続変換です。