Turbo復活

http://ascii24.com/news/i/soft/article/2006/09/06/664420-000.html
http://yasushikondo.no-ip.info/win32api/bbs5/img/71.pdf

「ソフトウェア業界では上流工程重視の傾向が強く、
現場でコードを書こうとか、勉強しようという意識が
薄れているのではないか。でも、UMLを描いても、
ただの絵だから動かない。コードに立ち返っていかない
といけない」。UMLとは、プログラムやシステムの設計を
抽象化された図で示す標準的な方式。UMLよりも、まず実際の
コードを書くことが重要だという指摘だ。

 コーディングが馬鹿にされて、UMLなど訳の分からん話題ばかりになったら、今度は、コーディングに帰ろうですか?

 今の若者にコーディングは無理です。今の若者が馬鹿とかじゃなくて、コンピューターが複雑怪奇になって理解できません。結局、どこか決めてこれ以下をブラックボックスにしないと駄目なんですよね。勿論、私の世代もブラックボックスがありました。
 私の世代は、CPUの命令セット以下は完全にブラックボックスでした。それゆえ、私は、IntelだのAMDだのCPUには拘らないのです。使う命令セットが揃っていたら、速度の違い以外同じって感じです。

 さて、私の世代が「当然あるべき物」として空気の様に思っていたCPUの命令セットと言うのは非常に多くの時間を割いてテスト&デバッグされた物だったのです。それゆえ、単なるうんちく目的以外にその内部の仕組みなど、うかがい知る必要など無かったのです。そして、80386DXから続いているIA-32の命令セットの様にコロコロ考え方が変わる物では無くて、むしろ上位互換性が非常に重視された物だったのです。

 そして、私の時代なら、CP/M-86やMS-DOS上で動き、画面に文字を表示するだけのプログラムでも非常にブラックボックスとなるソフトウエア層が薄く、ここにバグが潜んでいる確率は少なかった。この上、NECPC-9801上で動くMS-DOSは、私の経験した範囲では、ver3.1からver6.2まで、基本的に非常に互換性が高かったです。

 さて、今はどうでしょうか?

 今回復活するTurboシリーズがターゲットとしているOSであるWindows環境って、16ビットWindowsと同じような32ビットAPIにCOMを用いてDLLとして実装したAPIが混在。この上に、.NETFreamework混在。

 結局、今の若者ってブラックボックスにすべき物がコロコロ変わって行く上に、CPUの様なハードと違って十分なテストやデバッグが行われていない。つまり、「たらかしながら使う物」なんですよね。勿論、たらかすには、その原理などの洞察が必要です。

 この上、OOLのライブラリーは排他的で、見え方・使い方が乱立状態。
 例えば、「Windows上のアプリをC++で組む学習している」と言っても、昔の様に、「DOS上で動くアプリをCで組む学習をしている」とは全然違うんですよね。

 DOSの時代なら、MS-CとTurboCは違いはあれども見え方・使い方は良く似ていました。でも、今は全然違う。VCを使っているプログラマーはBCBを理解できないし、その逆も理解できない。
 また、同じRDBMSに接続するアプリを同じ処理系を用いて組んでいても、ミドルウエアとなるオブジェクトの乱立で、共通点はSQL文程度。この上、ミドルウエアは乱立だけでなく次々と新たな物が出来ては、従来の物が消えていくんですね。

 結局、今の若者の環境って、学んだ中で抽象的な物しか残らない。そして、抽象的な物を残せた者しか生き残れないのですよね。

 結局、「ブラックボックスとする物の仕様の固定と完全なるテストとデバッグ」、「ライブラリーなどの規格乱立の禁止」、「ミドルウエアなどの完全な上位互換性の義務化」がプログラミングが出来る若者を増やすと思うんですよね。

 「簡単に開発できる処理系を新たに作りました」って、「また、新しく学習して理解してください」って同義なんですよね。そら、コーディングから若者が遠ざかります。結局、「マイコン」って言われた頃からプログラミングをしている世代しかプログラミングが出来なくなるのは当たり前のような?

手軽にプログラミングを学べる環境が失われてしまっていることも大きな要因だろう。

 処理系の価格の壁より、処理系の学習の壁の方が高いと思うよ。
 これと、繰り返されるバージョンアップの壁。

 無料配布とかも良いけど、5万円程度できちんと全くの入門者から学べる処理系が強く望まれると思う。まず、「入門モード」「標準モード」「フルモード」って処理系の起動時にモード選択が出来て、同じTurboC++でも、IDEで表示されるメニューやダイアログボックスが全く変わる様にすべきだ。「入門モード」では、バイナリーコードの最適化など不要だろう。デバッグ情報を削除した実行ファイルの生成も不要だろう。あと、K&RのCに準拠した古いコードは、エラーとして弾き返すのが親切だろう。C++でも、名前空間などが無い古いC++に準拠したコードはエラーとして弾き返すのが親切だろう。
 「標準モード」では、「入門モード」ではIDEで表示されなかったバイナリーコードの最適化も出来て、デバッグ情報の削除も出来る様にする。「フルモード」では、K&Rに準拠した古いコードや古い規格のC++に準拠したコードもコンパイル出来る様にする。
 とにかく「学習を妨げる余計な物を見せない」って大切と思う。

自分の日々のルーチンワークを自動化するといった目的で
プログラマーが扱えるレベルを超えてしまっている。

 これは、AccessExcelのマクロの担当するエリアって思うけど、、、。
 まぁ、テキスト処理用のフィルタープログラムを組むなら、C/C++も使うけどね。

Turboシリーズは、1980年代から1990年代にかけて、C言語Pascal
アセンブラといったプログラミング言語の開発環境として幅広い支持を
得たボーランドのブランドだ。現在、第一線で活躍するプログラマー
多くは、その名前を懐かしく思うだろう。

 TurboPASCALver3のコンパイル速度。そして、その実行ファイルの実行速度はショッキングだった。V30(8MHz)のマシンで、80286搭載のマシンをN88-BASIC(86)で動かしているより遥かに高速だった。たとえ、TurboPASCALの方が遅くても、構造化プログラミングを行えたのは便利極まりなかった。再帰呼び出しを理解したのもTurboPASCALででった。
 そして、TurboPASCALver4でコケて、TurboPASCALver5で盛り返した。TurboPASCALver5/TurboCver2/TurboAssmbler1.0/TurboDebugger1.0って組み合わせは本当に便利だった。
 TurboPASCALver5って意外とTurboAssemberと相性がTurboCより良くて便利だった。

Turboシリーズは、同社の上位製品の開発ツール“Borland Developer Studio 2006”
シリーズと同等のコンパイラーやデバッガーを備え、開発に必要な環境はひと通り
そろう。Borland Developer Studio同様に、デスクトップ/ウェブ/ウェブサービス/
データベースアプリケーションの開発ができる。TurboシリーズとBorland Developer
Studioの主要な違いは、Turboシリーズでは開発ターゲットとなる言語は1つだけしか
選べず、C++C#など複数言語の開発ができないこと。また、無償のExplorer版では
カスタムコンポーネントを利用した開発環境の拡張ができないなどの制限がある。
ただし、Explorer版でも商用利用や商用ソフトの開発は可能だ。

 なんか、今度のTurboシリーズはコケる様な、、、、。