次世代BTRONをものすごい勢いで妄想するスレ
ヲチ板の”【コップの中の】TRON Fan Watch【あらし】”
http://kaba.2ch.net/test/read.cgi/net/1017059553/l50
スレで話題が技術的なものに流れた時の避難用スレとして立てますた。
BTRONの話題以外は極力禁止。
いわゆる初心者発言禁止。
話題に関する突っ込みは歓迎。
さあ使え。 http://kaba.2ch.net/test/read.cgi/net/1017059553/311
で書いたんだけども向こうだけじゃ拙いと思ったんでここにも書いとこう。
超漢字のプログラミングについて話し合うための掲示板の件だけども
JBBS→http://www.jbbs.net/
JBBS@したらば→http://jbbs.shitaraba.com/
とかで掲示板をレンタルするのはどうだろう。
運営者はナニだけども一応独立した掲示板になるから、ここと違ってほっといても
人が集まるというような事は無く、宣伝が必要にはなるだろうけれども。 >>103
オレ自身はソフトウェアで報酬をもらえる技量の持ち主ではないので
よくわからん。2000円 × 時間って事になるの?
お金のやり取りは難しいと思うよ。下手に前金をもらってしまったら、
逆にモチベーションが下がったりするかもな。
前金は例えで、要は善意や、思想に共鳴したなどの抽象的なことに
頼る以外に、ソフトと物の物々交換とか(お礼に使っていない少し
古い周辺機器をプレゼントするとか)、ソフトウェアを作るやる気の
元を増やそうという事なのよ。 >>104
管理者がしっかり仕切るのは必須条件、に近いな。
中上級向けと、入門者向けの2つ要るかも。 >>104
こんな便利なところがあったとは知りませんでした。
有難うございます。もし需要があれば、自分が
管理人になって掲示板レンタルしてもかまいません。
削除人なら出来ると思います。
ただちょっと心配なのはほかにこういった場を必要と
している人がいるのか、ということです。
とりあえず、今の時点ではOS板に都合よく :-) 立った
BTRONプログラミングスレを使って様子をみてみる
ことにしようかな、と考えています。
http://pc.2ch.net/test/read.cgi/os/1024452632/
もしここが荒れたり同時進行のトピックが増えすぎて
話の流れがわかりにくくしたら、そのときに掲示板をレンタル
して移動してもいいかな、と。どんなもんでしょう? 今テレビを見たら、イングランドがリードしてますね。と思ったら同点だ。
>>109
削除係というより、有用なlogの整理係です。への道掲示板のように有用な
情報が失われてしまわぬように……。誰か気長なお方が請け負ってくれない
ですかね。
>今の時点ではOS板に都合よく :-) 立った
スタート地点で爆睡しているうさぎのような勢いのスレですが。
どうもねぇ、あのスレって書き込んでる人間に
「1人も超漢字使ってる奴居ないんじゃねぇか」
と思うことしきりなんですが。 >>112-113
あのさ、そういうネタは>>1のリンク先に書いてくれないかな。
一応このスレはそこの避難スレなんだわ。
名無しさんと言えどもヲチの対象には変わり無い訳だし。 >>1
GUIに加えて、対話型インターフェイスになるでせう。 >115
いまでもパネル出しまくりで充分対話的なんですが(w >>114
....なのに>>111みたいなのはおーけーなのかと問いたい。
>>117
>>111はプログラミング用の掲示板の話題なのでヲチとはちと違うような。
>>110
あそこの>>1さんはもうすぐ超漢字の寒い現状に気づいていなくなるはず
なので、それからあのスレをリサイクルするのも悪くないかと思います。
>>111
まあまあ、マターリといきませう。 >いまでもパネル出しまくりで充分対話的なんですが
説明不足でした。「音声認識対話型」と言いたかったのれす。 >121
ITRON飲料製造業向けプロファイルですか? 鯖がdだので新しい元スレが立てられました。
【コップの中の】TRON Fan Watch【あらし】第2版
http://kaba.2ch.net/test/read.cgi/net/1025139893/
ありがd↑の>1。君は神だ。 一寸ばかり下がりすぎたのでage。
G研の妄想に対抗して、誰かもう一寸現実的な次世代BTRONを妄想してくれないかなぁ。
せっかく「妄想するスレ」って付けたのに。
だいたいあそこの次世代BTRONを実装するための組織って妄想以外の何者でも無いよな。
一体どこの誰がコーディングだけなんて奴隷労働を喜んで只でするというのだ。 >>124
では俺の後向きの妄想を一席。
BTRONのBはBusinessのBなんて片腹痛いわ。1BもTiPOも超漢字も所
詮PIMソフトとしてしか実用、人気を得る事ができなかったのさ‥。
なので、PIMとして使うため限定に機能をそぎ落した仕様を作り、
BTRON2.9として発表する‥。仕様を縮小するたびにBTRON2.8,
2.7...と減らして行く。信者からの反発があったならば幻のBTRON2
に近づいているのだと説明して煙に巻く‥。
>>125
仕様を縮小するという案、ネタとしては面白いけど、実際に仕事で使ったことないでしょ。
仕事で使うと、便利よ。特に超漢字4になって検索機能が付いてから、
ますます便利。
仕事関係への可能性については、かんちゃんが以前まとめてます。
Btron いいですね。ちなみに、TRONとは、TAPE RECORDING ON の略です・・というのは嘘ですが。
ちなみに、BはBASICの略です。basic とは binary associated symbolic input code
の略ですね。・・・というのも、嘘です。
>>124
たぶんPMCには、ユーザのアイデアだけは余るぐらいにたまっていると思われ
>>124
>>80のようなネタが欲しいという事なのか? んー。微妙に違うんだよな。今思いついたのを列挙してみる。
・基本的には新規に作るものは極力少なくする。
・TADが使えて、仮身/実身(風でも可)が使えて、TACLっぽいスクリプトが
使える、即ち見た目BTRON風なら下は何でも構わない。
・kernelにはたとえばLinuxを使う。ウインドウシステムにはXより軽い
Xのようにヴィジットを規定していないものを使う。
・言語マシンにしてしまえばファイル数2^16問題やアプリの機能不足の
問題の解決も比較的楽では?
・APIが今迄のBTRONと何の関係もなくても良いのでは?
とかそういうのを↑よりは説得力のある文で誰かかかねぇかなぁと。 もう一寸書いておこう。
BTRON2よりメジャーバージョンが1上がったからどんな凄いシステムかと
思ったら、何の事はない見た目(APIも含めて)BTRON486としか言い様の
ないもので一寸失望した奴は少なからず居ると思う。
スレタイに超漢字と書かず次世代BTRONって書いたのは、ある意味古臭く
なったBTRON3を改良したもの、それどころかTRONですらないかもしれない
ものが欲しいなぁって思ったからなんだ。 そうそう、← (おばちゃん風)
>>130
の構想みたいのをLinux上ではなく、B-right/V (超漢字) 上に構築
するのが吉ではないかと前に思ったのよ。超漢字上にBTRONエミュ
レーション環境、疑似BTRON環境を乗せると。超漢字のBTRON APIは
なるべく使わないで、セルフ開発環境などの他のOSでもありきたり
のAPIを使うの。 OS本体とは関係ないけど、早めにアプリケーションのレイアウト機能を強化して欲しい
ですね。前職(官公庁事務職)ではいろいろ活用してみようとしたんですが、複雑な書式が
作りにくくて断念しました。PMCは超漢字の利用者として官公庁を想定しているようで
すが今の貧弱なレイアウト機能では作業能率が落ちまくって使い物にならないです。 TACLがまだまだ先の話なら、取りあえずFORTHを載せてみるというのはどうだろう?
文字コードはTRONコードを直接扱えるようにしておけばTADのハンドリングなんかに
便利だと思うんだけど。次の超漢字でどう?>PMC >>133
そういう紙至上主義には TAD って合わないんで、
スピリットは買いますが、向いてないものは向いてない、かと。
そういう業務向けのアプリを、サードパーティが開発して
くれるだけの土俵になってないのが根本的問題なんすよね。
いろんな意味で。
PMC 的には、漢字が使えるのはウチだけだから、
発注いただければ窓口業務アプリでもなんでも作る、とか
いうつもりなんでしょうけど。
>>134
PMC はマイクロスクリプト程度でさえ、あれで手一杯と思われ。
ところで皆の衆に一寸質問。
仮身を FORTH のワードとしてみなすとしたら、
その正しい挙動がどうあるべきかしばらく悩んだのだが、
1 スタックに、それが指す実身 ( の f_id ) を積む
2 仮身のオープン起動
3 FORTH インタプリタに「仮身ハンドル」という概念をつくり、その値を積む
となった。なんかコメントあったらキボンヌ
>>133さんではないんですけど、
>>135
> そういう紙至上主義には TAD って合わないんで、
> スピリットは買いますが、向いてないものは向いてない、かと。
ここのところもうちょっと説明してくれないかな。えらい断定的なんだけど、
これはそんなに自明じゃないと思うよ。何でTADって「紙至上主義」
にあわないの? 紙の書類が当分なくなりそうにないことはわかりきってるし、
超漢字の売りが多漢字機能で文字に強いことなのに、なぜPMCでなく
サードパーティがレイアウト機能の強化をしなければならないの? >135
変数ワードと同じ動作でよいのではないでしょうか>仮身ワード
・仮身IDを名前として仮身セグメントの内容をパラメータフィールドに記録。
・仮身ワード(仮身ID)を実行するとパラメータフィールドの先頭アドレスをスタックに積む。
・仮身操作用ワードはこのアドレスを使用して仮身の操作を行う。
でもって、仮身登録用ワードの名前をTS_VOBJ(0xE6)にしておけばTAD主レ
コードの読み込み時に自動的に仮身を登録できてウマー。(実身のレコードを伝統的な
FORTHの様に読み込み時にプログラムとして解釈すると仮定してます。) あ〜、いろいろ突っ込みどころ満載ですね>137
練り直してきます。
>>136
それは "TADって何よ" みたいな深遠を覗く話で結論なんか簡
単に出ないのだから自分で考えて自分なりの結論を出しなさい。
なるべく人に手間を取らせないように。 >なぜPMCでなくサードパーティがレイアウト
>機能の強化をしなければならないの?
「機能の強化をする」んじゃなくて、例えば表計算みたいな、
「紙至上主義応用向け文章編集」(もしかしたら図形編集かも)
を作るサードパーティがあったらなぁ、てこと。
PMC に「まともさ」を期待するのは、原稿プロセッサが出ない
あたりから見て諦めてるんで (w ってことは、まともな
プラットフォームにしてくれることを期待してる点で
漏れも同レベルに厨だな。欝
TAD は、まず第一に「実身/仮身モデル」のサポートの
為に存在している。
それに対し、紙至上主義が電子メディアに要求する機能に
ついて、結論はただ一つ「印刷結果こそがすべて」。
この要求を TAD が満たせるというのか ?
>>140
TADの思想からすると確かに高品質の印刷結果って要求には答え辛いんだが、
現状のTADの1次元データ用付箋って文書構造の表現とかじゃなく、見た目
重視になってないか。
しかもモニタ用ともプリント用ともつかない中途半端な。
その他は大方同意。 >>139
俺は>>135さんに聞いてたんで、あんたにゃ誰も聞いてないよ。
それに話したくないんならここに書き込む必要なんてないわけだし、
手間を惜しんでたら何も話がすすまないでしょ。
俺だって手間を惜しむつもりはないし、それなりに努力してるよ。
>>140
>>142
DTPとかのことを考えるとTADで全部まかなうのはむりかも
知れないね。ただ>>133でいわれているようなレイアウト機能
の強化はTADを拡張して今の図形編集を強化することで十分まかなえる
と思うよ。今のTADはもろに印刷を意識したつくりになってるし。
話はちょっと変わるけど、コンピュータの上だけでデータを扱うんなら、
文章の論理構造を記述するためのTADとかデータベースのためのTADとか
あってもおかしくないと思うけどどうよ? マイクロカードとか見るとため息がでちゃうよ。
手帳用紙とかとも互換性ないしね。本来ならデータの交換がスムースにできて
しかるべきなんだけど… >>143
文章の論理構造だの修飾だのレイアウトだのはplanetext(ってなんだそりゃ?)の
Markuplanguageにしちまった方が良いのかも知れずとか思う今日この頃。
せっかく仮身/実身が使えるのだからタグの間にplanetext(ってなんなんだよ)を
収めた実身の仮身が入ってるだけとか。
しかしそんな事をすると実身のネットワーク構造が無茶苦茶になる罠。
うむ、妄想の面目躍如。
>>139
出来ればお前の考えの拠り所ってのを説明してやっては貰えぬか。
煽りでも何でも無く。
こう言う所では「説明するの面倒臭い」てのは「知りませんでした」てのと
同義だからなってコレは煽り。 >>143 >>144
あー、誤解を与えてしまったようね。
今までさんざん見てきたBTRON界のプログラマと非プログラマ(?)の意見の
相違からプログラマがやる気をなくして去ってしまうパターンの入口なので
水を差しただけよ。 >>145
うむ。なんとなく判った。オレ的には不問とします。
そう言う訳で皆の衆。>143最後の段落と>144最初の段落への議論の継続キボン。 >140
データベースは実体関連モデルなんか実身仮身ネットワークと相性がよさそうな気がしますね。
(でも、本当に実装しようと思ってあれこれ考えると結構難しい罠。)
しかしBTRON界ってRubyとかPerlとかPostScriptプリンタ用
プリンタイメージドライバとかの縁の下の力持ち系ソフトに
動作テストで協力する人が極めて少ないね‥。 >RubyとかPerlとかPostScript スキルが必要で敷居が高いのだと思う。 ユーザは入門レベルから始めないといけない人がほとんど? UNIXは目的が決まっている人が多いからそう感じるかも。 それ&T000090; 久しぶりのBBBで失敗した。
今度はMozillaから
>150かぶった。スマソ。
それから、BTRON名無しさんの夢はSqueakに行きそうな気もするがどうなのだろう?
煽りでなく聞いてみたい。
オレは基本的に「パーソナルコンピュータは言語マシソでなきゃいかんでしょう」な
ヤシなので当然です。
でも、Squeakじゃ無い方が良いなぁとか思うがSqueakしか今のところ選択肢なさげ
なのも事実だ。
その昔オレが学生でパソコン上のSmalltalkとUNIX WS両方使って色々したり
世間じゃコンピュータを使う=プログラムするってコトが未だ少しは認知されてた頃、
unixみたいなコンパイル済みのアプリを走らせるOSとp-codeやSTなんかの言語マシソ
の両方のいいトコ取りを狙った(と、当時のオレは理解した)BTRONやTADやTLUSや
TACLなんかの構想をみて凄く期待してたんだけどねぇ。 >>145
いや、俺は必死こいてアプリを組んでる側の人間なんだが。
お願いだから水を差す相手を間違えないでくれー。
ただでさえ超漢字の開発環境その他にはげんなりさせられっぱなしなんだからさ(泣
>>144
たしかにTADで記述できないデータにはXMLとかを使うのが一番いいんだろうね。
ネットワーク構造云々については、他のアプリが対応すればいいんではないかと。
>>153
言語マシンはともかく(w TULSやTACLについては禿しく同意。
ユーザー用のまともな言語処理系があればどんなにいいかと思う。
俺としては次世代BTRONに一番期待するのはきちんとした開発環境。
NeXTのInterface Builderみたいなのと巨大なライブラリがあれば
開発の効率が全然違ってくる。あとはJava VMを超漢字に標準で付けて
Javaで開発、ぐらいかな。想像しただけで涎が出そうだ。 >>154
アプリレベルでやっちゃうとせっかくの仮身/実身の意味が無くなるんだよな。
やっぱり。
タグの間のテキストを新しい実身(虚身じゃ無いぞ、次世代なんだし)に書き込んで
編集して元の実身のタグの間に書き戻すてな感じが順当なのかねぇ。妄想だが。
NeXT STEPかぁ。BTRONと同時期のアレが、実用に供されたエンドユーザ
コンピューティングのあの時期の最高にエレガントな解だったんだろうね。(遠い目
TACLなんて所詮ヴェーパーだった訳だし。 TRONプロジェクト'xx〜'xx とかを見るとさ、
写身に対するアクセスメソッドを提供するのは、
もとの実身を開いたアプリ(のプロセス)である
みたいな感じだから...
やはり BTRON2 談義になってしまうな (爆)
>>156
脳内自動変換してたんで全く気づかなかったよ。。。
>>155
そっか、ここは妄想スレだったんだ。じゃあ現実のことはあんまり考えなくていいんだな(w
それだったらOSで全部サポートしてくれたほうがいいよねえ。アプリケーション作る人たちは
楽になるし、データの互換性はあがっていうことなし。
昔大学で黒NeXTをいじるのに熱中したけど、画面上でオブジェクトを
つなげただけでプログラムの大半が出来あがってしまうのには本当に感動した。
同じ開発環境がMac OS Xにただでついてくるこの御時世にEmacsでしこしこと
超漢字のアプリを書いていると激しく時代錯誤な気がするよ。BTRONはソフトが
ないっていうけど、OSベンダがいい開発環境をととのえれば
アプリケーションの自社開発も楽になるしオープンソースのソフトウェアも
出やすくなるだろうから後で必ずペイオフすると思うけどな。
これをPMCに要求するのは酷だけど、とりあえず1オタの妄想ということで。 妄想大歓迎だ。どうも次のBTRONの話をしても超漢字を始めとするPCで動くOSだの
マクだのとリソースは豊かになったがソフトウェアに関しては古臭いシステムから
半歩踏み出した程度の話しかしない奴が多くて困る。オレもそろそろヤヴァイけど。
黒NeXTが弄れる大学…。ほぅ、やはりオレの様に怠惰な人生を生きてはいかんと
言うコトだな。ウラヤマスィ。
て訳で>>130をもっと説得力ある形に書き換えてもらえない?とか書いてみるテスト。 一部に知られる「シェルだっちゃ」でぐぐったら、はぎゃ先生の
文章が出てきたので提供。妄想の燃料にだうぞ。
ttp://nicosia.is.s.u-tokyo.ac.jp/pub/essay/hagiya/kaisetsu/unix_window
GMWとはこりゃまた懐かしい。使ったことは流石に無いけど。
Wnnとかもこれが出自じゃなかったっけ。 >>162
>>42で既出だ。
漏れに対する>>1であるBTRON名無しさんの
返答は>>43だよ。 >>42の主旨は
全然ものすごい勢いじゃない
で否定。>>162の主旨は
ものすごく遅い勢い
で否定せず曲解。ガイシュツではない罠。 しょうもない揚げ足取りはいいからさ。
お前ら、もっと妄想してください。 夏バテで妄想エネルギーが低下中だよ。もうちょっとまってね。 他のOSで実身・仮身が使えるようにならないかな。
OS全体でと贅沢は言わない、アプリレベルでなんとか。
会社で超漢字が使いたいが、
会社のパソコンにWindows以外のOSを入れるのはちょっとまずい。
バーチャルPCもまずい。
超漢字を使って2年ほど、実身・仮身って相当便利と感じたが、
超漢字上だけでは悲しい。
他のOSで実身・仮身の便利さが享受できるものってできないかな。 >167
HTMLベースの軽快なハイパーテキストエディタってありそうなもんだけど、
探してみても意外とないんですよね。(あったら、とっくにBTRON-OS卒業
してるでしょうね。) >>169-170
Wikiはイマイチなじめなかった。
ネタで素マンが、、、
もしもTADベースのPIMソフトを作ったら、使う奴いるか?
妄想してみてください。 >>171
「仮身/実身ベースの」と、あえて誤読。
ユーザみんなが欲しがっては居るが、一向に誰も作らない物の1番だな。
昔々1Bの頃、”B-cron”って無償で配布されてるアプリが有った。
時間決めで指定した実身を指定したアプリに読み込むだけなんだけど、上手に使えば
スケジューラとして便利に使えた。
だから、ホントにPIMとして仮身/実身ファイルシステムをそれなりに有効に使う様に
作りこまれたアプリが存在したら金払っても使う奴の数はそれなりにあるんじゃ
ないかなぁ。 >PIMとして仮身/実身ファイルシステムをそれなりに有効に使う様に
作りこまれたアプリ
で、他OSともデータがしっかり共有できれば、うれしい。
で、Palmなんかと合わせて使えるようになってるといいな。
ついでに、寝言を言うと、他OSでのデータ共有の際、
実身・仮身のリンク関係も持っていけるようになってたら、
なおうれしい。
ああ、でも、データ共有とかは、PIMソフトに欲しいっていうか、
いっそのこと超漢字に欲しいことだったかも。 171だ。ネタで素まん。書くのを忘れた。クロスプラットフォームで動く、TADベースのPIMソフト、ね。それで感触を得たいのは、開発言語は何が向いているのだろうか、という事。 とりあえず、基本表計算で作ったカレンダーに
仮身を貼り付けておくだけでも不便はないけれど。
μPIMに仮身が貼り付けられれば特に言うことはなさそう。
あとは基本メールが小細工なしで仮身として使えれば
BTRON自体でPIMという気も。 クロスプラットフォームで動作する、TADベースのPIMソフトだぞ。
妄想を膨らましてみよう。 >>177
某Wikiの発展したイメージ?
あれをTADにしたもの? >>178
>某Wikiの発展したイメージ?
>あれをTADにしたもの?
なるほど、そういう考えもあるのね。俺はかなり違う事を
考えていたのだが。
その道では有名な、「TADビューワ」の編集可能版のイメ
ージ。それをスクリプト言語で作るならば、どの言語が向
いているのかな、と思う訳。
>>180
ガイシュツ。>>130-132見れ。手前味噌でスマンが。
…って、一寸違うな。
>>180の言いたいのはオレの妄想「LinuxのBTRON風ディス鳥」とかではなくて
Squeak見たいなのをデータフォーマットはTAD決め打ちでみたいな感じ? >>180
Squeakかぁ。前に試そうと思っていたのに、すっかり忘れていたよ。
SqueakもどきのTAD限定版のイメージはうまいな。
俺がぼんやり考えていたのは、TADビューワもどきをスクリプト言
語で作るとしたら、Perl/Ruby/Pythonその他の中でどれが一番向い
ているだろうかという事。 >>183 そうだけど、、、自分で95%作って、残り5%を協力してもらえるに はどれが向いているかなと思うのだが、どれも同じだろうな。 Tkを使うという発想は忘れていたよ。SketchというX上で動く、ま ずまず良くできたドローソフトがPython/Tkだった。 >>171
Perlが理解不能で、Pythonは二時間しか使った事なくて、Rubyをよく
使ってる人間から言わせてもらえればRuby一押し。 ageとくか…。
しかしT-Engine使ったワープロ専用機みたいなの、
本気で作って売る奴が居るとは思わなんだ…。 >>189
あの会社ホントにモノ出すのかな?なんかすげぇちぐはぐな感じがするんだけど。
開発案件の分野に統一感が無かったり、案件の数の割には商品化されてる
物の数が少なかったり、商品化された物も売れなさそうだったり…。
おまけに新聞発表があったのにサイトのほうは更新されてないしな。 >>190
会社案内のところを見ると、
設立一年ちょいの会社みたいだし。
そんなものなのかも。
製品ラインナップは確かに、
子供が考えたのみたいなのが、いくつか目に付く。
実験的な会社なのかも。
もの出すかどうかは不明だね。
ただし、>>189が出れば、TRON端末も出ると思われる。 保守ageを兼ねて思いつきを書こう。
ピンチェンジの例のブツに対する要望つか妄想
1.せっかくDynabookを彷彿とさせる外観なんだからスクリーン上での
ペンオペレーションをキボンヌ。感圧でも静電容量でもいいから。
2.テンキーの追加キボンヌ。
3.テキサスインスツルメンツがhttp://www.naoco.com/calc/ti-92plus.htm
こう言うポケコン(電卓じゃなかろ?)を作ってるんだが、こんな感じの
ソフトウェアのプリインストールをキボンヌ。コンピュータ以外の技術者用
になるけどな。
PCじゃ大げさ、関数電卓じゃ一寸めんどうねって領域が確実にあるのよ。
しまった。
http://www.naoco.com/calc/voyage_200.htm
新型も出るのな。買っちゃおうかな通販で。
ついでに書いとくと、アメちゃんは此れを教育用として使ってるらしいぞ。
>>193
あの形状でマウスはいかんですね。やはり電子ペンを…
ソフトウェアはご自分で開発されてはいかがでしょう(w
>>194
奴らは中学生のときからTIの電卓を使っているので
計算能力はまじでぼろぼろです。
便利になりすぎるのも考えものです。複雑な気分。 >>195
ポケコンレベル或いはExcelのマクロ以上にややこしいプログラムは
やる気ないんでヤダ。
そうかー。計算能力の低下の方が目立っちゃうのか。
グラフィカルに数式が表示されて理解しやすいんで数学を得意とする
生徒が増えるかもとか思ったんだが…。
やっぱり公文式のほうが良いのかのう。
日本でもあの機械を前提とした高校数学の教科書が出てるんだがのう。
>>193
>せっかくDynabookを彷彿とさせる外観なんだから
言われてはじめて気がついた。
そーいえばそーねー。狙ったんかなあ、やっぱ。
プリンタのついたポケコンは窓口においておくと便利かも。 >やっぱり公文式のほうが良いのかのう。
あれはやりすぎると、逆に機械的になって頭が空っぽになりそうな気がする。
>能力の低下の方が目立っちゃうのか。
っていうか教授がいつも言いたいのは
安易な便利さや効率は、頭を空っぽにするというもので
BTRONインターフェースはそうならないためのこだわりって気がする。
無農薬農作物を食べるとのたとえをどこかで読んだよ。 >安易な便利さや効率は、頭を空っぽにするというもので
>BTRONインターフェースはそうならないためのこだわりって気がする。
そこまで考えられていたんですか?やはり超漢字はすごい!!と言わざるを
えない。その能力を引き出せずにいる昨今ではあるのだが。 Night氏のB-Free復活か?
リンクのページの説明によると、Night氏抜きの
B-Freeはサーバごと吹っ飛んで消えたらしい。
☆ B-Free Collection project top page
http://bfree-info.sourceforge.jp/ 次世代かどうかわかりませんが、昔tipoをちょろっと使っていた自分としては、
http://www.watch.impress.co.jp/pc/docs/2002/1112/sharp1.htm
ここのSL-C700の液晶の横幅が800ぐらいに増えて、ペン入力が出来るような奴が
出てくれると買ってみたいなぁと思うのですけれど、いかがです?
ま、動作時間はtipoには及ばないでしょうが・・・。 >>201
今アクセスしたら、
http://www.tron-net.gr.jp/
繋がりましたけど…。
氏のページは
http://tron-net.gr.jp/
になっている。そりゃ繋がらなん罠。
内藤氏がやる気になったのなら、
それはそれでめでたい。