人文科学プログラミングを教える方法

すべての人に挨拶！



この記事では、経験の少ない技術者が教える人文科学プログラミングの教育の特徴を強調したいと思います。 特異性は、さまざまなタイプの人文科学とそれらへのアプローチを包括的に研究する機会がなかったことです。 私は主に哲学を主な道として選んだ人たちと仕事をしました。 主に哲学者の文脈でさらに詳細に説明します。







説明した結論に基づいた私の経験は、プログラミングを学びたい、または考えたいと思っている人々との約6年間の総作業から生じました。 その過程で、グループクラスと個人クラスの両方が学生（16〜26歳）で行われ、グループのサイズは平均で約11人、いくつかのグループが並行して行われました。



グループは考え方によって分けられ、平均して同程度の知性を持っていました。 これにより、プログラミングのさまざまな分野で知覚速度がどれだけ異なるかを観察し、生きる機会を得ることができました。これにより、学習パスが変化すると、座標系と情報処理方法のレベルで理解された基礎を使用すると、遅れているものの速度が大幅に増加する可能性があるという疑念が強まりました。 人道的な考え方の人々への正しいアプローチを見つける試みは、人文科学を特に対象とした方法論的および心理的マニュアルを使用することなく、徐々に実施されました。 最後に私のコースを修了した人のほとんどは、趣味で発生する問題を解決するアプローチに成功し、プログラミングの使用が理にかなっています（いずれにせよ、私には見えます）。



「プログラマーを人文科学から解放する」というタスクの解決策を3つの大きな質問に分けたことは注目に値します。

1.動機付けの問題、または「なぜこれが必要なのか？」

2.トレーニング方法の質問、または「コンピューターに自分を理解させるにはどうすればよいですか？」

3.エントリポイントを見つける問題、または「特定のタスクに直面したときにどこから始めるか」



基本的に、この記事では2番目の質問だけを明らかにしようとしますが、残りは簡単に説明します。

ところで、この記事は素晴らしいです。 読書に飽きても、私がした結論が興味深い場合、結果は最後にあります。



私は、最後または最後から2番目の事例、または広く一般化されたアプローチのいずれにおいても真理のふりをすることは決してないことをすぐに言わなければなりません：私が話すことは、ヒューマニスト、主に哲学者、プログラミング方法を教えるために見つけた最も効果的な方法の説明です。 人によって違いがあります。この記事では、私が出会った人文科学の学生の大部分に特徴的な主要なもののみをリストします。

モチベーションの問題

アクティブなプログラマーの大多数と、これを教える人たちは技術的なメンタリティのある人だと言っても、私は間違いないと思います。 技術者の間では、動機付けの問題-なぜ彼らはプログラムを学ぶ必要があるのですか？ -それは特に苦痛ではありません。彼らの多くは、コードを読んだり、理解したり、書いたりできることの利点、趣味や将来の仕事でのプログラミングの適用性を理解しています。 原則として、経験から、このレッスンの少数の技術者のみが強い否定的経験をします。

状況は人文科学とは異なります。



「人文科学とは誰であり、数学者/プログラマー/理論物理学者とどのように違うのか」という用語の問題を残すことを提案しますか？ インターネットには多くの定義があり、通常、あるタイプを別のタイプと区別する実用的な方法に基づいています。 直感的なレベルでは、人が自分の考えをどのように考え、表現するかは、この人がどのキャンプに属しているかというかなり短い時間で理解できます。 私は今のところ、決定と停止のそのような直感的な方法を提案します。



人道的な考え方の人々の動機は、原則として、活動と趣味の分野では、プログラミングの使用（いずれにしても、高次ではない）が非常に制限されており、プログラムの助けを借りて解決できるタスクが表示される場合、その後、それらはまったく単純ではなく、たとえば遺伝的アルゴリズムの分野で適切な準備が必要です。



将来のアプリケーションの可能性のある分野を拡大するという観点で動機付け、何の場合に需要が増えるのか？ いずれにせよ、プログラミングは彼らにとって異質の規律のままであり、フォースの平和的な流れ、彼らの通常の考え方、行動様式に違反します。 最善の場合に行われることに真剣に努力することは、人生に喜びをもたらさないこと、そして世界との調和を見出すことに寄与しないことを合理的な時間内にしないことは、非常に不快で困難ではありません。



視野を広げるという動機付けはありますか？ 実際、人文科学が視野を広げる方法は技術者ほど多くありません。これらの方法は現在、未来ではなく過去にあります。 歴史、宗教、さまざまな方向の思想家の研究-多くの情報。 ですから、私たちのプログラミングは、祈る偶像としてはまったく認識されていません。 ヒューマノイドのヒューマンテクノエリートであると考える人々による「愚かな人文科学」への攻撃の頻度を考えると、そのような動機付けの試みは非常に迅速に失敗する運命にあります。



実際の応用に関するオリエンテーションを通じて動機付けようとする試みは、いわば、少なくとも彼らの活動の直接的な産物となる何かが失敗します。 この直接の実用的なアプリケーションは無料でforめませんでした...



人文科学がプログラミングを勉強するように動機づける唯一の方法は、少なくとも最小限の肯定的な牽引力を与えるようにすることでした。 人文科学は、原則として、その分野の非常に狭い専門家であることを好みません。 彼らは平均より上であるべきだと信じている彼らの教育の輪は非常に広く、常に彼らのプロフィールに隣接する地域にのみあるとは限らない。 たとえば、言語学者はしばしば宗教の問題で独学し、美術評論家の歴史家（これはもちろん、ほとんど関連する学問ですが、それでも）です。 これは、彼らがこれにまったく興味があるかもしれないことを正当化するために、基板上で再生することができます。 結局のところ、プログラミングは彼にとって別のタイプの思考を生み出しますが、それは最も深いレベルではありませんが、彼らにとって非常に新しく、型にはまらないものであり、最初はもちろん、「これらの嫌われたチーム」との戦いに対する良い渇望を生み出します。

もちろん、より良い理解の結果として、人々との技術的な考え方を達成する可能性を無視することはできません。 しかしその前に、人文科学自体がそれについて考えます。

質問の学習方法

それで、人文科学は組み立てられ、訓練と知識への憧れの準備ができています。 どこから始めますか？



ここでは、被験者からの期待レベルの質的に異なるレベルに関連してすぐに余談をする必要があります。 技術者は、いくつかのクラスでは結果が得られないこと、複雑なプログラムはレンガでできていること、そして最終結果を得るためには各キューブを収集できる必要があることを理解しています。 ヒューマニストもこれを理解していますが、最初はあまり考えていませんが、人文科学ではそのような顕著なスキルの梯子はありません。 N個のブリックの複数のタスクを設定する場合、技術者は、すでに書かれているものを再利用して、将来的にはできるだけ少ないブリックを実装する機会を探しています。 ヒューマニストは、取るに足らない結果を得るために、どれだけ小さくて骨の折れる退屈な仕事をする必要があるかを非常に迅速に実現するため、落胆しています。 間違ったアプローチでは、人道主義者がこの骨の折れる仕事をする意欲を殺すことは非常に簡単です。そして、あなたはニンジンで彼を誘惑しません。 技術者は簡単です—彼らはプログラミングを嫌うので、より長い拷問を受ける必要があります。



私は別の余談をしたいと思います。 多数のその後の物語には、特定の事柄を理解する技術者の大多数の方法のための通常かつ理解可能な方法が人文科学に適していないという兆候が含まれています。 はい、彼の頭をつかんで叫びたいという大きな欲求があります-どのように、それは初歩ですか？！ 私は、基礎における彼らの理解の方法が、これらの方法を世界的に悪化させることのない技術技術的な方法と異なるという事実に最大限重点を置いてみました-それは、技術者によって発明された訓練としてのプログラミングの認識をはるかに難しくします。 同じ結果で、彼らは異なる考え方のために、平均的な技術者よりも特定のプログラミング技術を理解するためにより多くの努力をする必要があります。 少なくともこの記事の枠組みの中で、「疲労が​​仕事の尺度と見なされる世界」に住むようにしましょう。



標準的な方法論で人がどのように教えられているのか、なぜサイクルが必要なのかを見てみましょう。 たとえば、1〜30の数字を印刷する必要があります。

最初に、1番目の番号に対してこれを行うことが提案されています。 次に2に、次に3に、というように。 最初は、次の数字を表示するコマンドを列に単に書くだけであることは明らかです。 学生は、繰り返しの数が多い場合、この戦略が成功していないことにすぐに気付きます。 その後、一般的な形式への移行が行われます-1からNまでの数字を印刷します。ここで、Nは、たとえば30です。対応する構造を訓練します。そして、このサイクルは学習されたと言えます。



だから、これはそれがどのように機能するかです-もちろん、技術者と-そして人文科学の第3部でのみ最高の場合に。



実践では、人文科学は少なくとも2つの兆候によって明確に分けられていることが示されています。 これは脳の外挿法の初期利用可能性であり 、人が知覚できるレンガサイズのカテゴリーです 。 2番目の機能のブリックとは、タスクの一般性、つまり抽象化の一種の抽象的な尺度を意味します。トートロジーについては申し訳ありません。 一般的なオウムの抽象化の量。



最初の兆候の有無から、2番目の兆候が非常に論理的に続くように見えるかもしれません。 ただし、実際にはこれは起こりません。 少なくとも、外挿は常に抽象化を引き起こすわけではありません。 ただし、この理由の説明は興味のある人に任せましょう。 これらの基準に従って、人々をどのカテゴリに分類できるかをリストします。



a）人は外挿が何であるかをよく理解でき、小さなサイズのレンガだけを知覚することは良いことです。

b）外挿の使用には大きな問題があるかもしれません。小さな断片だけを知覚するのは良いことです。

c）または-3番目のオプション-外挿に問題はないかもしれませんが、同時に大きな知識ブロックのみを一度に理解します。

もちろん、4番目の組み合わせが発生します。外挿を理解せず、大部分の知識しか認識できません。 しかし、それはまれであり、他の3つよりもはるかに一般的ではありません。



将来、私が最も経験したのは哲学者であったので、人が大きな知識の塊をすぐに知覚することができるだけであるとき、私は主にオプションに対処します。 それらの大部分は、理解する能力を萎縮させ、その結果として、小さな断片を推定します。そして、大きな抽象化のない課題は、克服するのが難しくなります。 サイクル問題のどのアプローチがより簡単に吸収されるかを示します。



したがって、人にサイクルを教える必要があります。 アプローチを取ります：配列があります（1からユーザーが入力した数までの数の合計を計算するのではなく、これは数学的問題であり、人文科学にとっては当たり前です）。 配列は、抽象的なデータ型、つまり内部に同じタイプ（たとえば、数字）の要素の束を持つコンテナとして説明されます。 金額を取得する必要があります。 どうやってやるの？

問題番号1：学生にとって興味深い非数学的な問題を思い付くために、それは明らかな方法で必要になるかもしれません。 たとえば、本のホームライブラリにある特定の著者の出版物の数を数えます。 「ここで平均を計算する必要があり、後で計算するために量を計算する必要がある」という概念で操作することはできません...これが失敗への道です。 数学的計算との関係は、難読化されていない場合、生徒にとって重大な内部緊張を生み出します。



問題番号2：正確なアルゴリズムや、神の禁断のフローチャートを描くことなく、概念レベルでこの問題を解決することを提案します。 生徒が「キャビネットを見て、本を一列に並べる」段階に到達すれば十分です。 この著者による本を見つけるたびに、指を曲げます。」 その後すぐに（私たちはまだ大人について話しています）、指を曲げて数枚の大きな本を考慮に入れる代わりに、紙の上に杖を描くことができると考えられます。

タスク番号3：アルゴリズムではなく、概念レベルで既に発明された問題の解決策を予測する。 フローチャートではありません。 人がプログラムすることを学ぶ言語にすぐ。



プログラミングの本質は、アルゴリズムを作成する能力であることを忘れてください。 これを正確に頭に置いている技術者に任せてください。 今の私たちの仕事は、彼の考え方が全く準備されていないことをするように人に教えることです。

アルゴリズムのコーディング方法を教えようとしないことが重要です。 これを可能にするために、人文科学はまずアルゴリズムを作成する必要があります。これは常に難しく、不快で、面白くないものです。 そのようなアルゴリズムが既に存在する場合、アルゴリズムが実装されるプログラムを見つけるか、計算機でカウントされます。 アルゴリズムが複雑すぎて計算機や紙で数えられない場合、人文科学はそのような問題をまったく解決しません。まったく解決しなければ、不幸になります。 一般に、アルゴリズムという言葉は、一般に心の安らぎを奪い、特にプログラミングに従事したいという欲求を奪います。



このような投影では、紙のシートが要素の数を格納する変数になり、行の本棚を通過すると、配列の要素を1つずつ見ていきます。 1つのアクションの結果として解決されるようにタスクを単純化しないことが重要です-たとえば、すぐにOOPに切り替えてリストになると言いますが、このメソッドはパラメーターでフィルターによって要素の数を返します-痛みではありません。 それでも、タスクはプログラミングの人に教えることです。つまり、脳の構築のすべての機能を使用して、レンガの家を建てる方法を学ぶ必要があります。元の高さ10メートルのパネルスラブと自己拡張階段から超高層ビルよりも家を建てる方が簡単です。



次のプログラミング手法についての話の後に、それを何に使用できるかを示すことが非常に重要です。 多くの技術者にとって、サイクルの本体に別のサイクルを配置できること、または最悪の場合は別のサイクルをプロシージャコールに挿入できることは直感的に明らかです。 ほとんどの人文科学では、プログラミングツールと従来の家電製品との基本的な関連付けがあり、特定のオブジェクトのみを入れることができます。出力は、この手法の結果のリストの指示に示されているオブジェクトの1つになります。 プログラミングツールも抽象的なものであり、ある程度の範囲があることを示す必要がありますが、特定の例のリストだけでなく、このツールが動作するものとしてより広いクラスのオブジェクトを使用できます。 猫を電子レンジに入れることを禁止するという精神で、「反対」の制限の原則はうまく機能しますが、常に、ツールが動作できるクラス、タイプ、入力データの形式、および他のプログラミングツールと組み合わせることができることを正確に指定する必要があります。 「何でも機能する」というフレーズは間違っています。なぜなら、彼らはそこに実存性についての一般的な質問を入れようとし、どのような結果を期待するのか理解できないからです。



また、予期しない/他の種類のデータが入力された場合などに、ツールがどのように動作するかを試してみたいという希望を生徒の間でほとんど感じませんでした。 結局のところ、ツールが機能するルールはアルゴリズムによって決定されます 。つまり、それらを理解しようとするのは苦痛で、長く困難であるため、少なくとも最初は行われません。 部分的に、この好奇心の欠如は、入力データ型を抽象的な方法で知覚する能力によって補われますが、それにもかかわらず、動的データ型およびオブジェクトでトレーニングが開始されると、教師にいくつかの追加条件を課します。 この問題では、逆説的に、人道主義者は技術者よりもはるかに具体的です。



少数の知識の問題のある認識を人文科学に教えるとき、特別な場合と境界条件は痛い点になります。 残念ながら、保存されたデータ間の各タイプの接続の最も一般的な境界条件を検討する価値があるかどうかを思い出させることほど良いものはありません。 蓄積された経験とコーンに基づいて、できるだけ少ないゆっくりとさらなるテストが配置されます。これは良いことです。そのようなテストはそれぞれ、人道主義者の決意の重大なテストです。



もちろん、スタックコーンは、プログラムのエラーが原因で発生します。 ここでは待ち伏せが待っています：初心者プログラマーにコンパイラー/インタープリターの言語で読むように訓練する必要があります（以下、単にコンパイラーです。実践が示すように、インタープリターは人文科学をいくつかの理由で思慮深く導いていることを示しています。さらに、コンパイラーを使用する言語では、エラーを探すのが簡単です。たとえば、人文科学者は変数に間違った型の値を入れることを考えないでしょう。好奇心を持っています。 これは非常に異なる性質）。 コンパイラは、原則として、プログラムの真のエラーを示すのにあまりフレンドリーではありません。多くの場合、これらは「予期しないコンマ」の精神のエラーです。 そのような場合、学習者が以前に記述されて動作しているコードの同じ構造の例を見ることができます。 コードは常に同じスタイルで記述されることが重要です。 私はこれで人文科学の問題に会ったことがありません。 絶対に。 このスタイルで書くと言われています-彼らはこれで書くでしょう。 それが彼らにとって何らかの形でより便利であれば、彼らはそれを修正します。



重要！

ほとんどの人と同様に、人文科学にとっては、できるだけ少ないコードの結果を連続して見ることが重要です。 いいえ、ほとんどの人とは違います-はるかに強いです。 これは彼らに継続するために非常に必要な動機を与えます。 同時に-パラドックス！ -彼らは本当に不要な作業をすることを好みません。つまり、完成したプログラムを取得するために削除する必要のある追加の印刷物を書きます。 良い方法は、画面上ではなくファイル内に表示したいこの行を書き込む事前に作成された小さな関数を提供することです。これにより、ファイルは常にバックグラウンド（または2番目のモニター）で開かれます。 仕事の結果を熟考するプロセスは、自分の力への信仰を著しく強化します。



実践は、「感じられない」（または基本レベルでこれを意図していない）抽象的なものは、人文科学によって、あたかも簡単に受け入れられることを示しています。 たとえば、これはCのポインターの場合です。 主なことは、演算子、単項式、バイナリ、およびコンピューター内のデータの表現の使用の詳細には触れないことです。 これはすべて非常に具体的であり、興味の対象ではなく、原則として使用したいレベルでの将来のプログラミングの支援でもありません。



データ表示の抽象化を改善することも簡単です。 したがって、トレーニングが困難な場合は、常に一時的に基本データ型のレベルを超え、うまくいかないものを学習することで受けるストレスを軽減し、その後慎重に戻ることができます。



これらの抽象的なことを具体的に扱う必要がある場合に問題が発生します。 つまり、2つの問題があります。最初の問題は、特定のタスクから特定の要素とやり取りする特定のタスク（特定のものを一般的なものに変換する）であり、タスクのこれらの特定のコンポーネントを操作するために必要なツールを理解し、再びこれらの統一レベルに達しますツール（つまり、プライベートの変換+一般的なツールの操作方法）。 人文科学は、一般に、かなり正直に、何らかの技術的基礎を持っていると認識している言語ツールを恐れており、このツールを提出する際に置いたフレームワークの外では使用できません。 何も彼らの行動から世界的に破壊されることは何もないことを何度も強調する必要があり、彼らは次にどの行動を実行すべきかわからないという事実から、先に進む必要があり、 人は違った試みをすることができ、悪いことは起こりません 。 彼らの見解では、タスクは一種のグローバルクラウドとして提示され、与えられたツールと対話できるオブジェクトを具体化および分離するためにそれを凝縮するタスクは、このタイプの思考にとって非常に困難です。



残念ながら、このタスクの複雑さは、分割しようとするため、タスクを単純化して利用可能なアクションとして拒否するという事実にあります。 実際、彼らの考え方では、抽象化を2つの部分に分割しても、抽象化が得られます（2つの抽象化ではありません）。 私の実践では、これは異なるタイプの思考の形成における重要な瞬間でした：学生が彼の脳内に別の操作を作成し、これらのプログラマーの抽象化は他の人のようではなく、分割可能であり、分割することができ、分割する必要がある場合、それはさらに進んだはるかに簡単。



人道主義の分野で働く方法に反するため、プログラムを作成する逆の段階的な方法を教え込む試みは成功につながりませんでした。 さらに、ソリューションの完全性という別の側面で大きな困難に直面しました。 研修生がすでに理解していること、それを行う方法を書き留めることを私に教えるのは非常に困難であることが判明しました：彼らがそれを思いついたら、何がそんなに複雑だったのですか、なぜそれを書き留めますか？ 私は学生の「RAM」の不足という問題にすぐに出くわし、発明された解決策の完全性の必要性は、すべての栄光の中で私の前に現れました。 問題に対して提案されたソリューションの「ラダー」を非常に一貫して増加させることによってのみこれを克服できました。各ステップを実装する方法は、ソリューションの開発プロセスでほとんどメモリを必要とせず、問題は正常に解決されます。

エントリポイント検索質問

これは、トレーニングの開始時に最も困難な問題の1つです。



まず、タスクを最初に非常に強く決定する必要があるためです。 目標を設定するときに私自身が非常に深刻な罪を犯すことは許されるべきではありません。不足している条件は、生徒の裁量で満たされます。 たとえば、ソースデータを入力する方法。 そのようなことは厳密に定義されなければなりません。



ここでの重要なポイントは、利用可能なデータ型を、それらが動作する必要のある抽象化にどのように外挿するかを慎重に伝える必要があるということです。 セルの例えは、パラメーターやその他のオブジェクトを保存するオブジェクトです。 そのDNAは、多くの要素、つまり配列に還元されていると考えることができます。 この場合、外挿をよく理解している人文科学の主な説明は、データ型を後の作業で使用する型に外挿することであり、残りの部分では、データ型の固定形式に解決する必要があるものから削減することですプログラミングツール。



第二に、生徒の頭の中の決定の完全性に関する一定の義務が再び出てきます。 残りのソリューションの準備ができたときに、特定の問題領域に対処するのに恥ずべきことや悪いことは何もないことを強調する必要があります。既存のオブジェクトをデータ型に押し込む（またはデータ型を既存のオブジェクトに引っ張る）問題は頻繁に発生する問題であり、学生がオブジェクトのデータ型（構造）に慣れるほど、プログラムの用語と実際の用語の一致を学習しやすくなります。



第三に、ヒューマニストがタスクをどのように解決するかを考えるとき、頭の中で頻繁に行われるのは「このような問題をどのように解決しますか？」を再現することです。したがって、プログラムを書くとき、最初の質問は「新しいデータ型を導入するたびに、この変数/このオブジェクトのデータがどこから来たのかを説明し、それらをデータで埋める例を示す必要があります。そうすると、答えは「私は配列を通して問題を解決しようとしていたので、次の方法がここに収まる...」という精神で人道主義者の頭の中に現れます-そして、プログラムを書くことは通常の方法で進みます。



結論として、プログラミングを教えることは人道主義的な考え方を持つ人々にとって最初はかなり難しいですが、将来的には、多くのプログラマーに愛されている機知に富んだ洗練された洗練されたものではなく、かなり自信を持って、試みた方法をさまざまな組み合わせで適用し始めます。さらに、彼らは技術者の目を通して異常な含意と変容の世界を見る機会を得たという認識を楽しんでいます。

記事の概要

その結果、到達した「ヒント」の短いリストがあります。あなたが緊急に準備する必要がある場合、突然それは誰かに便利になります。

• 数学の問題ではありません。
• プログラミング方法とツールを使用できるフレームワークの定義の正確さ。
• « » , , ;
• — , ;
• ;
• ;
• , , , - ;
• «» ().

これを行うすべての人に幸運を。この記事がこの状況で何かを助け、促すことを願っています。

そして、私はすべての「実験的」に大きな感謝を表明します。



PS他の誰かがこの分野を研究するために人文科学を動機付ける方法を見つけたなら、私は聞いてうれしいです。