投稿者 スレッド: TBasic 事始め(1)  (Read 2079 times)

sokuhan

  • 新ユーザー
  • *
  • 投稿: 19
TBasic 事始め(1)
« 投稿日:: 2019年 8月 01日 , 午前 05:14:24 »
TBasicという言語(処理系)は、初心者向けの簡単な言語体系だと一般的に説明される。

「簡単な」という意味は、インタプリタであるから、いくつかの文を書いて即実行でき、
その文の機能や役割を直ちに確認できる。
あるいは、ダラダラと文を書き下ろしていき、冗長極まるプログラムでも破綻なく完成できる。
あるいは、制御構造文を知らなくても、Goto文で辻褄合わせができる。

しかしながら、いつまでもそのような「横着な」作法がまかり通るはずもなくて、
いわゆる「構造化プログラミング」という作法が当然自明なこととなった。

TBasicは、」この「構造化プログラミング」を正当に学べる言語処理系であるのだが、
「初心者向け」という言い方にはもう一つの意味があって、
TBasicを学ぶことによって、
次のステップへ更に成長発展を遂げる道筋が与えられているという、
そういう意義を持つものであって、
それが「コントロール画面」の設定であって、
この活用によって、WindowsというOSに立脚したGUIが学べるシステムとなっている。

GUI(グラフィカルユーザーインターフェイス)が先ず学ばれなければ、
どのようなデータを入力して、そのデータをどう処理していくかをプログラミングしていくのだが、
その「最初の一歩」たるデータ入力をどうするか、どのように処理を進めていくか、
全く見通しが立たなくなる。

TBasicでの「コントロール画面」の設定は、
このGUIの簡便な活用をガイドするものとなっているから、
ボタンやラベル、テクストボックスも使えますよ、といった付加的・補充的な機能ではなくて、
これらのコントロール部品を充分に活用できるプログラミング作法を習得することが、
TBasicを最初に学ぶべき意味が実感されるだろうと思う。

ところが、TBasicに準備されているドキュメントには、
余り熱心にコントロール画面の説明はなされていまい。
他の言語(例えば、JavaやPythonその他)についての概説書等でも、
GUIについての概説はほとんどなされず、
あるいは別な単著として刊行されていたのかも知れないのだが、
いずれにせよ、「この教科書をマスターすればアプリケーションが作れる」という
そういう作りに放っていないようである。

この点については、
GUIは直ちに理解するには難しいから初心者にハードルが高いという配慮があるのか、
という理由からきたものかとも考えるのだが、
実は、そうではなくて、
かつてのDOSの時代に翻訳・刊行されたC言語に関する概説書のスタイルが、
そのまま、現在の入門書・概説書の叙述・編集のスタイルにそのまま踏襲されてきたと、
だから、現在のWindowsの時代のプログラミング学習にそぐわなくなっていると、
私なんかはそう考えてしまうのだが。

TBasicの「はじめの一歩」として、この点に集中したのだった。

(この項、続きます)

sokuhan

  • 新ユーザー
  • *
  • 投稿: 19
Re:TBasic 事始め(1) 言語体系を見渡す
« Reply #1 投稿日:: 2019年 8月 03日 , 午前 07:34:22 »
Basic言語についてまったく知らないというわけではないので、
先ずは、全体の成り立ちを見渡す。
通例ならば、当該の言語についての「入門概説書」「マニュアル本」等を買い込んで学のだが、
TBasicの場合、「ヘルプ」からそれぞれの「文」や「関数」を解説している項目をひたすら読む。
既知の知識と同じであるか、あるいは、変更・補強・修正されているかいないか、確認する。
「既知の知識」と言っても、かなり曖昧なところもあったりして、
DOS-Basic時代の参考書等もとっくに始末されているから、
結局のところ、新たに「学び直す」ことになる。

「ヘルプ」の各項目を漫然と読んでいても身につかないから、
必要なメモをとる。
後で自分なりの「言語マニュアル」として活用しようという企図もあるから、
「メモ」というよりも、「ノートをとr」と言うべきかも知れない。

「文」や「関数」について、
確認の意味で、何行かの自分なりの「サンプル・プログラム」を作って動かしてみる。
この際に、「編集画面」の活用が、ほとんど何の事前準備もなしに可能だということが、
TBasicが学びやすい最大のメリットと言うべきかもしれない。

一般的に、言語習得に際して、あるいは、プログラミングに際して、
各種の「エディター・ソフト」が照会されるのだが、
これがまた、膨大な体系で、分厚い解説本での学習を強いられる、
日本語対応が行き届いていればまだしも、英語版のままだと「堪忍してくれ」ということになる。
数千行・数万行に及ぶテキストを書こうというわけではなくて、
せいぜいが数十行・数百行のテキストにまとめていこうというのがプログラミングの基本姿勢だから、
TBasicの編集画面は、記述しやすく、実行画面との連携も確かなものだから、
OSに」装備されている「MEMO」を使うまでもない。

「関数」の項目を観ていくと、
数値処理に関する関数が充実していることが分かる。
理工系学部・学科での研究データの収集と分析のために開発された言語体系か?と見えるのだが、
かつては、N88-Basicが理数系の学生たちに大いに活用され、
そのためのライブラリィもさまざまに創出され活用されてきた歴史を思い起こせば、
TBasic言語が単なる「入門者・初心者向けの簡易言語」という触れ込みに留まらない、
従前よりのプログラミング資産を正統に継承していこうとする使命を持つものと理解しないといけない。

私がやろうとしているプログラミングは「テキスト処理」がほとんどであるわけなのだが、
この点でも、「不安」は全くないと断言できそうである。

この項は、更に続きます)

« Last Edit: 2019年 8月 03日 , 午前 07:39:05 by sokuhan »

sokuhan

  • 新ユーザー
  • *
  • 投稿: 19
Re:TBasic 事始め(1) データ型とデータ構造
« Reply #2 投稿日:: 2019年 8月 04日 , 午前 07:14:37 »
TBasicでは、データ型として「数値型」と「文字列型」の2つが用意されており、
「数値型」には、いわゆる「実数型」のみがあって、特に「整数型」が用意されているわけではない。
他の言語システムでいくつかの「整数型」が提供されているのだが、
1バイト、2バイト、4バイト・・・というデータ単位の演算処理のルーチンの違いが反映されているのだが、
8ビット・16ビット・32ビット・64ビットというパソコンのCPU(レジスタ)の処理能力の発展と、
パソコンに装備されるべきメモリ領域の大きさの拡大がそこに反映されているということである。

従って、実数で演算した結果を、必要に応じて、整数に変換するルーチン(組み込み関数)があれば、
プログラミング上、混乱を招くという事態はかなり回避できる。
「型キャスト」を経ないとエラーが出るという事態は、ほとんど抑止される。

数値型にいくつかの「型」が用意されてきた理由として、
整数型と実数型とではその演算速度が大きく変わってくるという点があって、
そのため、無駄に大きなバイト数を要するデータ型を使わないという弁えが要求されたのだが、
現在のパソコンのデータ処理能力を考えれば、
そういった弁えの必要性は強く意識されるべきことにはならない。
TBasicにおけるデータ型の設定は、むしろ実態に即した明解化を果たしたものと言えるだろう。

データ型の異なる個々のデータを1つに取り纏めるべき「データ構造」として、
かつてのBasic言語では「レコード型」というものがあり、
あるいは「構造体」というものが準備されていた。
現在の言語処理システムでは、オブジェクト指向プログラミングという流儀の元で、
更に複雑精妙なデータ構造が用意されていて、
それらが上手く使いこなせそうもないとすっかりたじろいでしまう始末である。

TBasicで用意されているデータ構造は「配列」であって、
数値型や文字列型の型の違うデータを1つのまとまりとして使おうと考えるから無理が出るのだから、
すべてを文字列型データとして配列にまとめれば単純明快な処理ができる。
配列の個々の要素のうち、それが数値データであるならば、
その処理ルーチンにおいて数値に変換し、
処理が終わればそのデータを文字列に変換して配列の要素にに再び格納する。
配列というデータの並びに構造を付与するか否かは、プログラマの側が決めることなのである。
二次元配列を活用すれば、かつての「レコード型」なり「構造体」と同じ構造が実現でき、
三次元配列にすると更に複雑な構造が実現される。
TBasicでは五次元配列まで可能とされているから、
実は、五次元配列を活用すべきデータ構造というものは如何に可能なのか、
このこと自体がプログラミング能力が問われる課題の1つになるだろう。

TBasicでのデータ入力でInputBoxを使う場合、
入力されるのは文字列データのみで、
入力後に、必要に応じて数値データに変換すべしとされているのは、
入力データは取り敢えず配列に格納すべしというプログラミング技法を示唆しているのではなかろうか?

(この項、更に続きます)





sokuhan

  • 新ユーザー
  • *
  • 投稿: 19
Re:TBasic 事始め(1) 言語処理系としての使い勝手
« Reply #3 投稿日:: 2019年 8月 16日 , 午前 04:17:09 »
パソコンでもってデータ処理をするということは、
必要とされる指定データ項目をそれぞれ正確に入力して、
定められた目的に向かって正しく処理が行われ、
その処理結果が適正に表示される、という一連の流れを実現することである。

その観点から見ると、先ず正確なデータ入力のために、、
TBasicでは、この入力作業に豊富な手段が準備されていることが直ぐに分かる。
Input文では、入力すべきデータをガイダンスするべき項目内容がガイダンスでき、
入力データを入力時に取り違えるという誤りをかなりの確率で抑止される。
InputBox文だと、前回入力したデータと同一のデータを前以て準備され、
確認さえすればそのまま入力されるから、同じデータを再度入力するという二度手間が省ける。
LineInput文を使うと、シラブル単位ではなく一行そのままに入力可能だから、
個々の単位句を入力した後にそれらを結合させて一行文字列に仕立て上げるという作業が要らない。

かつてのBasic言語処理系でLocate文を多用したのは、
先ず入力すべきデータ項目を表示させて、
その右横で必要なデータ入力を行うという手順だったからなのだが、
TBasicでは、いっそう効率的に間違いのないデータ入力が可能になっている。

データ入力に際して、一文字入力を可能とするInput$(1)が用意されている意義が大きい。
先ず、文字列の一文字ごとに格納できる配列を準備し、
Input$(1)で入力した一文字を順次その配列に格納していく。
この配列を操作することで、文字の挿入や取り出し、部分削除や並べ替えなど、自由に操作できる。
もちろん、TBasicでは文字列操作のための関数は充分に組み込まれているのだが、
普通にはそれらを活用することで問題はほとんど解決されるものなのだが、
明示的・自覚的に、文字列を配列に置き換えるという作業はかなりな有効性をもたらすと考える。
(他の高級言語でも、文字列変数と配列変数との「置き換え」は、むしろ「原則」とされているようだ)

Input文やInputBox文、LineInput文、Input$(1)文で入力されたデータを、
一覧表示する必要はある。
例えば、20~30項目の入力データを一覧表示させようとする場合、
コントロール画面を使って表示させると分かり易い。
CLabei(n).Textでデータ項目名を示し、
CTextBox(n),Textで、当該のデータ内容を表示させる。
必要があれば、CTextBox(n),Textの内容を置き換える(訂正する)ということが可能となる。

入力されているデータを一覧表示させるという場合、
実行画面上で、Print文でずらずらと表示させるとすれば単純なのだが、
表示されたデータに誤りがある場合、その場で訂正できるようにしておかないといけない。

データ入力を如何にスムースに行えるかの見通しが立てられてやっと、
プログラミングを始めることができる。

(この項、もう少し続きます)

sokuhan

  • 新ユーザー
  • *
  • 投稿: 19
Re:TBasic 事始め(1) プログラミングの流儀
« Reply #4 投稿日:: 2019年 8月 16日 , 午前 05:08:58 »
「流儀」というと大仰なことなのだが、
つまり、出来上がったプログラムを実行させる場合、
マウスの使用を求めるか否かをプログラミングの段階で決める、ということである。

Windowsプログラミングの場合、マウスの活用・利用が当然の前提とされるのだが、
この点はよくよく考えるべき問題であると、私は強く主張したいのである、

データ入力に際して、
左手に、入力すべきデータが記載されたメモやノート、文書等を持ち押さえ、
右手でキーボードを叩いてデータ入力を行うのだが、
私自身は、マウスの操作を左手で行っている。
マウスの操作は右手で、というのが原則的な使い方とされているようだが、
生憎、私の作業机では、右手でマウスを操作できるような配置は不可能なのである。

この点のそもそもの始まりを辿ると、
取り扱うべきデータは数値データが主なものなのだから、
テンキーだけの操作でデータ入力が完結できるようにすべし、というのが、
ROM-Basicの時代からの私の流儀なのである。

もちろん、現在のアプリケーション・ソフトを活用する場合、
マウスの使用は必然的・不可避な手順になっているのだが、
私の場合でのデータ処理に際してのデータ入力数というのが、
一件あたりのでのデータ項目数がほぼ30項目で、それが300件ともなると、
半端な作業量ではなくなるから、
言わば電卓感覚での連続作業にしないと身が保たないという差し迫った事情がある。
従って、テンキーのみの使用でデータ入力が完結し、Crキーで次に進む・・・とプログラミングする。

この流儀を今更改めるべき理由はないと、堅く決意していたのだけれども。

さて、TBasicの場合、
データ入力に際して、Okボタンがいちいち表示される。
一見したところ、「これはやっかいなことだ」と感じたのだったが、
なんのことはない、
マウスでOkボタンをスリックするのと、Crキーを押すのとが「等価」とされていて、
このことは、私のような流儀の持ち主に対する「カスタム仕様」かと、喜んだ次第である。

むしろ、ことの実態は、
マウスで処理もできますよ、というのが「付加的」なサービス仕様とされているのではないか?と、
そう受け止められる節もあるから、
TBasicという言語処理系におけるユーザー・インターフェイスという点で、
言語設計の段階からかなりな配慮が傾注されているのではなかったかと、
非常に有り難く受け止められるわけである。

(「事始め(1)」は、ここで区切ります)

takeuchi

  • 管理人
  • *****
  • 投稿: 93
Re:TBasic 事始め(1)
« Reply #5 投稿日:: 2019年 8月 16日 , 午後 12:13:41 »
sokuhanさん

> (「事始め(1)」は、ここで区切ります)

 tbasicについての随分詳しい分析・指摘,多くのコメントありがとうございます。
私の言いたかったところだけでなく,私の気が付かない視点からの意見もあり,参考になります。

 tbasicの仕様は元々確定しているものではありませんから,色々な意見を参考にして,
可能な変更・追加はこれからも行っていきたいと思います。

sokuhan

  • 新ユーザー
  • *
  • 投稿: 19
Re:TBasic 事始め(1) この項を終えて
« Reply #6 投稿日:: 2019年 8月 16日 , 午後 12:50:35 »
早速のご対応をありがとうございます。

いきなりプログラミングに取り組むという「冒険」はできないことで、
ああでもない、こうでもないと、いろいろと見通しを立てた上で踏み出すわけなのですが、
良く組み立てられたシステムだと、むしろ感銘を覚えます。

当初、フリー・ソフトという位置付けから、
システム構築者の「個性」が強く反映されているのではないのか、
分かる者だけが分かったように活用すればいいと超然とされているのではないかと、
当初には、私の側に「思い込み」や「偏見」や「身構え」があったことは確かなのですが、
徐々に、行き届いたユーザー・インターフェイスが設置されていることに気付き、
むしろ「教育的配慮」に満ちた言語体系だと、信頼するに至っています。

これらの点については、次項の「TBasic 事始め(2)」で、
「何故のプログラミングか?」という論点で幾つか論議させていただきたく思います。

拙い素人話を書き綴るばかりで恐縮に存じますが、
今暫くお付き合いいただければ幸甚に存じます。