プログラマーとして、メモリ価格の急速な低下と2年ごとの計算速度の2倍のおかげで、選択肢があります。 アセンブラーで6か月の書き換えサイクルを費やすか、ロックバンドでドラムを演奏するのに6か月費やすことができます。これらの各ケースで、プログラムはより速く動作します。 アセンブラープログラマーにはファンがいません。
ジョエル・スポルスキー
私はいつも疑問に思っていました-なぜBasicは国内のプログラマーの間でそれほど人気がないのに 、西洋ではかなりの分布があるのか。 旧ソ連の広大な地域では、すべてのプログラマがチェリャビンスクの住民であり、マシンコードで直接書くため、1と0以外のキーがないため、BASICなどの高レベル言語で書くことはできないという疑念が忍び寄っていました。
この投稿に触発されました。
偶然にも、私が適用された問題を解決しようとした最初のプログラミング言語（PL）はVisual Basic（IDEバージョン6）でした-他のPLの資格が明らかに不十分であり、さらに、私の大学の専門分野はITに関連していませんでした科学。 私の父はバスステーションを持っていた（そして持っていた）、そしてその時彼はどういうわけか顧客を追跡する必要があった-したがって、彼は会計クライアント-機械-注文-仕事-スペアパーツとすべてに関するレポートこれに。 当時のオープンソースソフトウェアは存在しなかったため、1Cには多くの費用がかかりました。 その結果、書かれたプログラムをさらに2つのサービスステーションに販売することができました。最初の経験に関しては、良い結果だと思います。
同じ頃、私の仲間の多くは、まだ学生でしたが、すでにDelphi、C ++、およびJavaを勉強していました。 YPに関する私の知識ベースはあまり成長せず（php4の経験はほとんどありませんでした）、OOPのイデオロギーは私に要求されませんでした。 個人的に、実際にどこでも使用しない場合、Cまたは同じカプセル化のメモリの構成を理解することは、実際的なメリットを理解していませんでした。 今、私はすべての種類のエイジールとかんばんにも注目します。
そして今、何年も経って、私はこの考えに立ち会いました：PLは特定の問題を解決するための技術であり、それ以上でもそれ以下でもありません。 プログラムを書くときの動機は問題の解決策であり、プログラムを書くという事実ではありません。 問題を解決する効果は、作成されたツールの品質ではなく、必要な品質に応じて実現される品質です。 すべてが些細なようです。 YaPのようなVisual Basicは、初心者でも簡単に使用できるほどシンプルです。 Visual Basicは、他のより複雑な言語ツールが実装できるほぼすべてを実装できるほど複雑です。 それは普遍的であり、もちろん普遍性の観点からは、コンピュータの世界のWindowsのようなものです。 さらに、10年半後、彼は実質的に変化せず、VBAでの古典的な実装に住んでいます！
今では、すでに欧米の大企業の駐在員事務所でITマネージャーとして働いていたため、他のはるかに複雑な応用問題を解決する方法を模索する必要がありました。 約3年、1つのプロジェクトを解決するためにかなり限られた時間を割り当てました。 現時点では、このプロジェクトにはデータベースサーバーとアプリケーションサーバー、OutlookとExcelのアドオンが含まれています。 しかし、私の娘は成長しており、私のベビーベッドで安らかに眠るだけでなく、彼女と一緒に遊んだり、教えたり、自分自身を学んだりするために夜も見たいと思っていました。
間違いなく、このプロジェクトの請負業者を最初に見つけた場合、アナリストと一緒に多くの時間を費やしていました-おそらく自分の実装に費やしたよりも長い時間でした-そして最終的に、データベースとアプリサーバーを備えたコーシャシステムを手に入れました、ある特定の会社に幸福が訪れますよね？ しかし、どういうわけかそうではありません。 動的な環境でのビジネス要件はスペースの速度によって変化し、外部サプライヤーとの作業にはかなりの時間がかかるため、その多くはさまざまな承認、予算編成などに費やされます。
もちろん、aksakalsは、社内に独自の開発スタッフを置くことを勧めることができます。開発スタッフは開発とサポートに従事します。 しかし、これは不運です-現在、ほとんどすべてのビジネスの世界的な傾向は、逆に、非コア（製造された製品に関連しない）リソースを社外に持ち出すことです。 今日、私のシステムをサポートする自立モデルは最も費用対効果が高く、さまざまなバンの開発は「ローレット付きレール上で」行われ、最小限の時間しかかかりません。 実際、このためには、適用されたPLが必要です。
短時間で限られた人的資源で実行される適用された問題の解決策は、記憶組織のニュアンスを研究する余地がないため、学習するのに最も便利で簡単なツールを選択する以外に選択肢がありません。 あなたは今、そしておそらく明日働くものを取り、それをする必要があります。 これで私のプロジェクトは一種の巨像に変わりましたが、粘土のカウンターパートとは異なり、何世紀にもわたって立つ必要はなく、中期的な視点がなくても、今ここで行動を印象づける/実行するだけです。
このテーマに関する私の考えはすべて、かなり論理的な結論に至りました。 私たちロシア人は、物事を最適に行う方法を知りません。 私たちは何か素晴らしいことをすることができます-例えば、人を宇宙に打ち上げ、世界で最も広々とした航空機を作ります-しかし、それに多大な労力、時間、そしてお金を費やします。 ソビエトの軽工業を思い出してください。 許容可能なレベルで物事を行う方法はわかりません。さらに先に進むと、ほとんどすべてのレベルで許容できるレベルがわかりません。 そして、たとえできたとしても、使用するのを忘れることが非常に多いです。
西側はこれを私たちよりもはるかにうまく行うことができます。たとえば、約1世紀にわたって80/20の原則を非常にうまく使用してきました。これはパレート法とも呼ばれます。 Appleは、新しいヘッドフォンを作成し、数千人の耳の構造を研究し、耳の80％に適合するようにその発明を行いました。 私はこれらのヘッドフォンで音楽を聴きましたが、それらは本当にクールに聞こえます。私は80％で、間違いなく自分で購入します。
エネルギー、時間、お金など、消費されるリソースの最適性に注目して、物事を行う方法を学びましょう。 これには、繁栄への道が見えます。 プログラミングの学習への道を歩み始めたばかりの人を励まし、「プラス」のためにすぐに座ってはいけません。
公平には、Colossusは既にリファクタリングに合格しており、主な目標である安定性を高めるというより長い期間（プロジェクトによると-2年）の運用が期待されています。 目標は達成され、稼働時間はすでに204日です。 ロジックがさらに複雑になると、システムの安定性が雪崩のように低下するため、必要に応じて、Colossusのリファクタリングのさらなる反復がサードパーティの開発者によって実行されると確信しています。 しかし、これはまったく異なる話です。