2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

もう古い形式のプログラミングは止めにしよう

1 :水毒:01/09/14 02:00
昨今、どの言語で開発するにも統合開発環境と一体で供給されるものが
非常に多い。にも関わらず、既存の言語は突き詰めれば結局テキストファイル
の編集に過ぎない。ここで特にOOPLでは言語+IDEという図式ではなく
言語とIDEはもっと密接な関係であっても良いと思う。どうせコード
記述が多くなって全員がコード補完を使っているならば最初からそれ専用の
ダイアログで入力するようにすればいいのではないか。第一その方が見易くて楽だ。
というわけでこういうネタについて色々真面目に語って欲しいと願う。

2 :デフォルトの名無しさん:01/09/14 02:04
ダイアログでの入力は
非常にストレスがたまりまーす。
いちいちダイアログが表示されるのは嫌。
結局のところ、現状のコード補完が
一番すばやくて扱いやすい。

故に、二種類の方式を選択できるように。
ダイアログ入力もヨシ、コード入力もヨシ。

3 :水毒:01/09/14 02:09
>>2
うーん、そうかあ。自分で言っといて何だが分からんでもない。
その辺りの折り合いをどう付けるかが悩ましい。

4 :デフォルトの名無しさん:01/09/14 02:17
JavaStudio とか。

5 :デフォルトの名無しさん:01/09/14 02:28
UMLの図をソースに落とすんじゃなくてそれをそのまま
コンパイルって感じではたして完結できるんだろうか?
結局メソッドの内部はやっぱりコード書かなきゃいけないか?
シーケンス図その他でなんとかなる?

6 :デフォルトの名無しさん:01/09/14 02:52
せっかく昔の人が字を発明してくれたのに、
君たちはまた絵に戻るのか!!

7 :このスレは:01/09/14 02:54
板の中でかなり頭の悪いスレに認定されました

8 :デフォルトの名無しさん:01/09/14 02:54
>>6
それこそが、真の新人類の原始時代の幕開けなのです。

9 :デフォルトの名無しさん:01/09/14 03:06
テキストエディタがあまりにも成功してしまったんで、
他のものをEditする方法の進化が遅れた、ってのは有ると思う。

たとえばVector絵の標準フォーマットが21世紀になってやっと
(SVGとかとして)決まりそうだ。MacDraw(ぷ)から数えても一体
何年の出遅れであろうか?

さて。ビジュアルな言語ってのも有るね。UMLもそうだし、
http://www.crca.ucsd.edu/~msp/Pd_documentation/index.htm
こんなのも有る。

あと>>1は、Smalltalk(Squeakとか)では、満足できないのかな?
getして即満足するかは怪しいが、自分でいじって拡張すりゃ済むことだから、
逆にいえば、まだ誰も見たことのない強力な環境の案が有るなら、実現手段として重宝するかも。

10 :デフォルトの名無しさん:01/09/14 03:19
SELF は?

11 :デフォルトの名無しさん:01/09/14 05:34
例えば C とか Java の include や import はファイル毎に書か
なきゃいけないし、ファイルスコープとか前方参照とかも、プロ
グラムが1つ以上のシーケンシャルファイルに置かれることを前提と
した構文になってるわけだから、その辺のシバリのない GUI-IDE
環境では、言語そのものをファイルという概念から分離して設計する
ってのはアリだとは思う。LabVIEW みたく完全グラフィカルな言語
とまで行かないにしてもね。

けどいわゆる UNIX文化というか、プログラムテキストを sed,awk,
perl などで自動処理したいという要求もあるだろうし、それに
テキストファイルって依然として もっともポータブルで堅牢な
ファイル形式じゃないかな。

そもそも GUI な環境がテキストエディタによるプログラミング
よりも使いやすくなくちゃ意味がないわけで、その辺のバランスが
難しいよね。うっとうしいダイアログやメッセージボックスが突然
開いたり、ひんぱんにマウスを使わざるを得ないような環境は
あまり使いたくないな。

12 :デフォルトの名無しさん:01/09/14 05:40
>>11
>例えば C とか Java の include や import はファイル毎に書か
>なきゃいけないし
書かなきゃいけない(それが推薦される)理由がある筈だったが。

13 :デフォルトの名無しさん:01/09/14 05:48
>GUI な環境がテキストエディタによるプログラミング
>よりも使いやすくなくちゃ意味がないわけで
GUIとエディタを比較するの?
君の言うことはよくわからん

14 :デフォルトの名無しさん:01/09/14 06:05
まあ、GUI開発環境とテキストファイルのソースをエディタで編集
することの比較だと思うが、
エディタの方がシンプルでとっつきやすいが、ドップリ浸かれば
GUI環境の方が仕事は速いでしょうね。
ボタン押下事の処理コード探すとき、ボタンの「クリック時イベント」
がすぐ見つかる。

15 :11:01/09/14 06:11
>>12
> 書かなきゃいけない(それが推薦される)理由がある筈だったが。

理由も何も、ファイルがコンパイル単位になってるからに決まってる
でしょ。その必然性を問うているわけよ。

>>13
については ちょっと言葉が足りなかった。>>14 の言う意味。

16 :デフォルトの名無しさん:01/09/14 06:13
え!?
ちんぽ!?

17 :デフォルトの名無しさん:01/09/14 06:34
物を作って出してくれよ>>1
皆が使って納得したら流行るぞ。完全GUIな環境。
(sqでもいい気がするけど、完全ではないんだろうな1の言い分では)

18 :デフォルトの名無しさん:01/09/14 12:01
>>1
>既存の言語は突き詰めれば結局テキストファイルの編集に過ぎない。

ここがすでにダウト。既存というのが「自分の知ってる○×言語」
のみを指すならもっと謙虚になれ&ベンキョウシロ。

19 :デフォルトの名無しさん:01/09/14 12:13
とりあえずバージョン管理は専用ソフトでやろうや。
ソースに旧コードや履歴コメントを残していくのは
長期的なメンテではあきらかに非効率的。
第一ロクにリファクタリングできん。

20 :デフォルトの名無しさん:01/09/14 12:17
昔、結構長いプロジェクトのメンテに関わった事があるが
ソースの半分以上がコメントアウトされたコードや
履歴のコメントだった。
アホだと思った。

21 :デフォルトの名無しさん:01/09/14 12:23
>>20
>ソースの半分以上がコメントアウト
おれも見た。
つーか、結局作り直した。
そのほうが圧倒的に早かった...

22 :デフォルトの名無しさん:01/09/14 12:34
>>21
歴史が長いコードは、動作が承認されている、という点で強力な
アドバンテージがあるが、「誰も知らない理由によって」変なコードがあって
その結果目的の動作を果たしているという状態が往々にしてあるね。

これを安易に新規に書き直してしまうと、上記「誰も知らない理由」の詳細が
解明されないと、「動いていたものが動かなくなった」と責められることになる。
不必要な検証コストの増大、などと言われたり。

ただし、これで解明できれば、今度はそれをきちっとドキュメンテーション
できて、以後の保守は格段にやりやすくなるわけだが…。

23 :デフォルトの名無しさん:01/09/14 12:35
>>11
> 例えば C とか Java の include や import はファイル毎に書か
> なきゃいけないし、ファイルスコープとか前方参照とかも、プロ
> グラムが1つ以上のシーケンシャルファイルに置かれることを前提と
> した構文になってるわけだから、その辺のシバリのない GUI-IDE
> 環境では、言語そのものをファイルという概念から分離して設計する
> ってのはアリだとは思う。

IDEが(半)自動的にやれば、「ファイル」スタイルでもいいじゃん。
(・∀・)チョトズレテルネ

24 :デフォルトの名無しさん:01/09/14 15:25
Rational Roseの出番

25 :..:01/09/14 17:59
コンパイルは有りですか?

26 :デフォルトの名無しさん:01/09/14 18:44
ハードウェアが CAD(図)による開発から HDL(コード)による開発に移行しつつあるように、
ソフトウェアもコードから図に移行するのか。。。。

別に完全にGUI-IDEにならなくても、インラインアセンブラのように、
GUI-IDEでのパーツの一部としてテキストがあるって形ならイケル気がする。

27 :デフォルトの名無しさん:01/09/14 19:58
VisualAgeはBeanとBeanを線で結んで、
引数はその線のプロパティで指定

って感じでコード書かずにプログラムができるよ


ただこの環境依存になっちゃうのは痛いな。

28 :デフォルトの名無しさん:01/09/14 22:30
>>27
本当にそれが効率的なの??

29 :デフォルトの名無しさん:01/09/14 23:02
>>27
すまん、VisualAgeってシリーズのうちのどれをいっているの?
単にVisualAgeっていうとsmalltalk環境そのものだよね。
ちなみに for C++ と for Java は持ってる。

30 :29:01/09/14 23:04
あ、beanって書いてあるから for Java だね。

31 :水毒:01/09/15 00:46
1です。
>>18
返す言葉が無い。自分は多くの種類の言語に触れているとは正直言い難い人間です。
そして現在は今までにこのスレで挙げてもらった環境等について調べている。不純では
あるが、そういう既存の、自分の知らない目標に近い環境について述べた書き込みを
貰う事もこのスレを立てた動機の一つでもある。今後もなるべく謙虚になり勉強します。
>>17
という訳で現在はまだイメージがはっきりしていない。おおまかなインターフェイスは
浮かんでいるのだが細部の実現方法が操作性や可読性等の兼ね合いで数個実現する候補
があったりするのが現状。大雑把なインターフェイスだけなら早期に公開できるのだが...

とりあえず、わざわざ人間がやらなくても環境側から提供出来るものは極力分かり易い形で
押し付けがましく無いように提供する、というのが第一目標です。後はコンパイルの概念を
出来るならば少し変えたいなと。折角テキスト依存をしないのならば更にコンパイル単位を
分割すれば実質体感のコンパイル時間をかなり削れるのではないか、そしてエラー検出も
容易なのではないかと、まあこの辺はまだ想像の域を出ていないので机上の空論かもしれないが。
具体的な要望等、建設的な意見を切に願う。

32 :デフォルトの名無しさん:01/09/15 00:55
>>1
そういうもので一番普及していて一番成熟しているのはたぶんVisualBasicだな。

現状、文法を厳密に定義する手法は存在するが、ユーザインターフェイスを
厳密に定義する手法はほとんど未開拓であると思われる。
つまり、現状ではその手のものの言語仕様(この場合はIDEの操作法になる)が定義できない。

そうなると、開発環境がIDEの実装に大きく依存することになる。
VBで開発しようと思ったら、VBのIDEを使わざるを得ないように、
そのような開発環境はすべて、必然的に激しく実装依存になる。
(VBみたいに極めて狭い目的にしかつかわれないものならそれでもいいけどな)

実現するためには、まずユーザインターフェイスを標準化する
手法を確立しなきゃならん。

33 :デフォルトの名無しさん:01/09/15 20:30
ユーザインターフェイスを統一する必要はないんじゃないかい。
各開発環境開発者が最善と思うユーザーインターフェースでいいと思う。
統一にはメリットもあるが、強制すると画期的な新開発環境が出てこなくなるかも。
開発者が自由に作ったものを、ユーザが自由に選ぶ。で良いのでは。

34 :デフォルトの名無しさん:01/09/15 20:33
Delphi...

35 :Delギコ:01/09/15 22:32
 ∧ ∧   ・・・・・・・
 (;゚Д゚)   イッタイ ナニヲ ハナシテ ルンダロウ??
 (|  |つ
〜|  |
  ∪∪  WinとLinuxで動いちゃだめ?
      GUIもApacheモジュールも作成できちゃだめ?

コンパイル時間、C++と比較にならないほど早くちゃだめ?

36 :デフォルトの名無しさん:01/09/16 10:20
>>34-35
Delphiがいいてのはは十分わかるが、
そんなレベルで話してるわけじゃないのよ

37 :Delギコ:01/09/16 11:45
   ∧∧   / ̄
@_(,,゚Д゚) < >>36 スレ流れを止めてシマタ
⊂,,__つつ.  \_ ちょっちスマソ

>そんなレベルで話してるわけじゃないのよ
そんな気はしてたから、楽しみにROMってたが
それを話せている人はほとんどいないぞ。
特に1はほとんど何もわかってらっしゃらない。

それなのに、何か理想のものを作ろうと思ってるのかな?

RAD&2wayを超えるなら
まずは現実に存在している物をある程度知ってから
超える話をしないと意味がない。

VisualAgeの話は面白いぞ。
JavaStudioも面白そうだったがアレ見事に失敗したな。

既存のコーディングスタイルと互換性を
とりつつ、新スタイルに移行という形をとらなければ
恐らく普及はしないだろう。

38 :デフォルトの名無しさん:01/09/16 14:36
真面目な話をするのであれば
まずは現状のスタイルにおいて
何が生産性のボトルネックなのかを
明示するところから始めるべきじゃないか?

39 :29:01/09/16 15:10
>VisualAgeの話は面白いぞ。

VisualAge for Javaは単体でもバージョン管理機能あるし、
既存のbeanがそろってさえいれば、サーバーサイドな開発においても
27のいうようにある程度はコードを直に書く量を減らしてはくれる。
でも、グラフィカルな表示に頼るから、メッセージのやり取りが
多くなると画面ぐちゃぐちゃになるし、そうするとじゃぁ、ここは
テキストエディットで...って感じで必然的に 2Way をやることに
なる。で、こんどは画面上で組むロジックと裏側の素のソースで
組むロジックをどう切り分けるか、そもそもそれは一つのクラス内
でやることなのか、っていう設計のセンスで生産性が決まる感じかなぁ。
とりあえずサードパーティの支援ツールは必須。
#でも、日本IBM監修で売られているVAJの参考書にほとんどビジュアルプログラミング
#が取り上げられていない/邦訳時に削除されているってことは、IBMではこの方向は
#間違いだったって認識なんだろうな。

40 :デフォルトの名無しさん:01/09/16 15:52
それは手段であって目的ではないから。
効率化が目的ではない。
というより、コード補完て本当に効率的かい?
というより、本当にプロかい?
普通にコード書いたほうが速いぞ。

41 :29:01/09/16 16:28
一応、プロだけど、VAJを使って金もらったことも
もらうつもりもないです。
それに普通にコード書くより速いとかコード書かないほうが
いいとかいうつもりもないです。
ただ27のいうようにbeanを線でひっぱってつなぎゃそれで
おしまい、それでおーけーって感じではないし、他にも考えなきゃ
いけないとこはいろいろあるよってことを書きたかっただけです。

42 :Delギコ:01/09/16 16:55
>>27のいうようにある程度はコードを直に書く量を減らしてはくれる。

  ∧ ∧    /
  (,,゚Д゚)  < GUI開発では限界があるって事ね。
  |⊃ ,⊃   \
〜|  |
  ∪∪
いまだにその手のビジュアルプログラミングシステムで
成功しているのは見かけない。
日立も数年前そういう製品を出してたはずだが
(アプリケーションギャラリーとか逝ったかな)

DelでもDBのテーブル間接続やDBのGUI表示部分には
似たようなコトが出来る。(VAのEJBと似た感じかも)
でも
所詮、DB表示するだけの部分だけで
きめ細かい事を出来るようにサポートはされてない。

開発者の要望に大方、対応できるように
実装するのは不可能じゃないだろうが
まだコストが合わないのだろう。

DBとは関係なく、設計時にインスタンスを作成して
それをGUIから触れる所は便利だね。Beansもそうじゃないの?

GUIのインスタンスをコーディング時に触れるという視点でのRADから
GUI関係なく全てのインスタンスをコーディング時に
設定するという視点でのRADに着目するといい感じ
ではないでしょうか。

43 :Delギコ:01/09/16 17:09
  ∧∧     / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  (,,゚Д゚)  <  スマソコ。文章グチャなので補足
 ヽ/つ且~~  \___________
  (__ _)

> 日立も数年前そういう製品を出してたはずだが
流行りもせずに行方不明になりました。

> 開発者の要望に大方、対応できるように
> 実装するのは不可能じゃないだろうが
> まだコストが合わないのだろう。

一般的ないろんな開発環境の事です。


> DBとは関係なく、設計時にインスタンスを作成して
> それをGUIから触れる所は便利だね。Beansもそうじゃないの?

DelphiRADのことでし。でも設計時に触れるのは一部。
そのようなものを自作は出来るけど手間(コスト)がかかりすぎる。


注目株はMacOSX、ProjectBuilderのObjectiveCなんかではない?
http://www.big.or.jp/~crane/cocoa/
"割 り 勘 計 算 ソ フ ト を 作 ろ う "
この辺り、読んだらわかると思う。

44 :デフォルトの名無しさん:01/09/16 19:12
>39
画面が線でぐちゃぐちゃになる場合は、
その画面の各パーツをBeanにするとよい

とヴィジュアルプログラミングのチュートリアルに書いてあった(藁

おれも最初はビジュアルプログラミング便利かなと思ったが
何故か使わなくなってしまったぞ

45 :デフォルトの名無しさん:01/09/17 01:10
だってマウスでプログラミングなんてたるくてやってらんないもん

46 :デフォルトの名無しさん:01/09/17 23:17
長年業界にいたような奴には
「プレーンテキスト至上主義」のようなものがあるような気がする
WordやExcelを毛嫌いする理由の一つは
「自分が見れないバイナリ形式で保存するのは安心できない」
という不安感があるのではないか?
プレーンテキストならばそのデータをスクリプトを書いていくらでも加工できるし、
どのような環境でも読めるという安心感がある
だがそろそろそんな常識を打ち破る時期ではないか?

47 :デフォルトの名無しさん:01/09/17 23:23
>>46
そんなあなたにはXMLをどうぞ.

48 :デフォルトの名無しさん:01/09/17 23:24
>>46
そしたら互換性がなくなってみんなマイナーな話しするんだろうね

49 :デフォルトの名無しさん:01/09/17 23:26
>>46
ネタか?

50 :46:01/09/17 23:37
>49
ネタじゃないよ
事実、最近考えが変わってWordやExcelを結構使い出した
昔は自分で読めないデータ形式が嫌いだったけどね
プレーンテキストじゃないと、ていう思考は過去の遺物

51 : :01/09/17 23:42
>>46
そんなややこしい理由もちださなくても、
GUI開発環境ってのは色々覚えることが多くて面倒でしょ。
GUIだから特別能率がいいことってあるのかな?
(ボタン一発コンパイル!とか・・・?)

52 :49:01/09/17 23:44
>>50
プログラミングとは関係無い話か?
プログラミングするときの話としても、なにかメリットがあるのか?

53 :デフォルトの名無しさん:01/09/17 23:45
>>52
emacs厨房逝ってよしってことだよ

54 :51:01/09/17 23:47
やべ・・・なんかイタイ発言しちゃったかな。
プレーンテキスト編集でも覚えることは多いよね、それなりに。

55 :46:01/09/17 23:55
>52
プレーンテキストに落とせないデータを許容する言語があってもよいだろう
だが言語でのいい例を知らない(あるだろうけど)のでWordやExcelの話に持っていった
それに現在のRADのように一度作ったGUIがコードに落とされて、
後から修正しづらいような例もある
それなら独自バイナリデータのままで保存すればよい。
無理にコードに落とすことはないだろう

56 :デフォルトの名無しさん:01/09/18 01:49
ttp://ryujin.kuis.kyoto-u.ac.jp/ylab/yamakaku/Visulan/

57 :デフォルトの名無しさん:01/09/18 01:55
どんなデータでもプレーンテキストに落とせると思うが。。。
情報の表現をテキストにするかバイナリにするかの違いだけ。
大抵はバイナリの方が読み書きの効率が良いが。

58 :デフォルトの名無しさん:01/09/18 02:36
Lyeeの話が出てこないな(藁

59 :デフォルトの名無しさん:01/09/18 04:07
46さんに近いと思うけど。
GUIソフトはGUI開発環境が作りやすい。
ボタンをクリックした時の処理が、ボタンにくっついていた方がわかりやすい。
テキストのソースだと、目的の場所に行くまでが大変。
バグを修正しようとしても、実はそこは通ってなかったってこともある。
最後は生産性によって淘汰されるだろうけど、多分GUIが残ると思う。
テキストのソースに落とす機能はあると便利だと思う。

60 :_:01/09/18 04:20
Cのヘッダがウザイ。
#if〜#endifで囲って多重定義防止なんて
なんてダセーやり方なんだとも思うし。
C#でなくなるらしいから期待。

61 :デフォルトの名無しさん:01/09/18 04:56
>>60
特にif/endifが悪いんじゃなくて、マクロと構文が完全に
分かれてるからだね。マクロ式の中でsizeofが使えなかったり。
lispのマクロを体感してみると良いと思うなあ。

62 :デフォルトの名無しさん:01/09/18 05:31
>>60 Objective-Cで解決済み

63 :デフォルトの名無しさん:01/09/18 06:50
>>1
じゃぁ、おまえが作れ(w

64 :デフォルトの名無しさん:01/09/18 09:01
>>60
そもそもヘッダを別ファイルに作ってインクルードという形式がダサイよね。
using, uses, importカコイイ。

65 :デフォルトの名無しさん:01/09/18 10:05
>>64
require と autoload と fileIn: も入れてくれ。

66 :デフォルトの名無しさん:01/09/18 10:06
あ、肝心の COPY句 を忘れてた。

67 :デフォルトの名無しさん:01/09/18 15:40
>>46
> だがそろそろそんな常識を打ち破る時期ではないか?

メリットをちゃんと書かないと…
XMLに代表される"印字表現も持つ"という流れとは逆行しているし。> binary only

68 :デフォルトの名無しさん:01/09/18 15:52
というか、話が小手先の話になってきてるな。

69 :デフォルトの名無しさん:01/09/19 04:02
>>46 は見え方と内部形式の話をわけようぜ.
まずはユーザインタフェースを問題にしたいんだろ?

70 :デフォルトの名無しさん:01/09/19 04:09
Cはプリプロセッサが分かれていてカコワルイが、
実用的ではあった。
(分かれている利点として、文が中途半端でも切り分けができる)
実装は、パーサーを2つ書く必要があるのでめんどっちい。

71 :デフォルトの名無しさん:01/09/19 09:55
もともと1の話は統合開発環境でコードの入力をエディタという
形から進化させたいということじゃないのか?

話題が「いいとこどり言語スレ」と化しているような。

72 :デフォルトの名無しさん:01/09/19 14:25
あんまり簡単にプログラムが作れるとプログラマの立場が危うくなる。
これ以上簡単にしてはいけない。

73 :デフォルトの名無しさん:01/09/20 00:10
>>72
C++のジョークテキストでそういうネタがあったな。

74 :水毒:01/09/20 01:12
慣れている人は別としてわざわざ新起参入者までもが実現すべき処理と関係の
無い単純作業を押し付けられる必要は無いと思う。何事においても間口をわざわざ
狭める必要は無いだろう。正直、「プログラムを知っている」程度でそれが仕事になる
現状はもういい。「できる」と「必要である」は違う

75 :デフォルトの名無しさん:01/09/20 03:20
基本的にできることや情報量を制限すれば学習曲線が早熟型になる。
1が言っているのは CUI を GUI にすると初心者が覚えやすいのと同じ。
「それ専用のダイアログで入力」などね。
Javaで基本API を使うだけのプログラムや、
RADで出来合いのコンポーネントを使うだけなら簡単なのも同じ。

ロジックを考えるのが一番時間がかかる。

76 :デフォルトの名無しさん:01/09/20 23:02
OMGのもでるどりぶんあーきてくちゅあ。

77 :デフォルトの名無しさん:01/09/22 03:30
Visualあげ。

・・・スマン

78 :デフォルトの名無しさん:01/09/22 03:34
>>77
おにいさん、ちんちんが丸見えですよ?
隠しなさい。隠しなさい。

79 :デフォルトの名無しさん:01/09/22 14:20
大学時代、IRIS Explorerっていう、データの3次元可視化ソフトを
使っていたよ。シリコングラフィクス系から出たソフトだけど、
いまはNT用とかもあると思う。

コンポーネントをドラッグ&ドロップして、パラメータ決めて
データを加工して、、
コンポーネント同士をパイプみたいなので繋いでデータを流す。
アニメーションとかも出来た。ファイル入力ダイアログとか、
パラメーター調整用のダイヤルとかもコンポーネントになってる。
完成すると、操作部と表示部だけにして、単独のアプリとして
使えるようになってるの。

内部では、コンポーネントごとにコンパイラーが動いていて、
多分、実行時に名前つきパイプでデータを流していたんだと思う。
CかC++かフォートランでプラグインみたいなのも作れたし。

用途は限られているものの、ある意味、1が言ってるのに近いのでわ?

80 :デフォルトの名無しさん:01/09/22 14:25
技術系板からは去って欲しい。

81 :デフォルトの名無しさん:01/09/23 14:22
>>79
商用でAVSとか、Free(おぷそ)でOpenDXとか、どうよ?
特に後者はおぷそだから、気楽に試せるぜよ。
unixもwinも対応してるはず。

作れるソフトのアーキテクチャが結構限定されるってのが
たまに辛く感じるが、まぁそれ言ったらunixとかのScript言語も
限定されるという意味では同じ運命なわけで、
あーいうビジュアル言語はそれはそれで役立つ。

見とおしが良いとは言わない(量的に多くなると結構辛い)が、
見とおせる範囲なら判りやすいし、その見とおせる範囲自体が狭いという
わけでもない(てきすと言語と比べて)んで、十分OK。

あとはエディタだろうな。てきすとエディタならぬビジュアルエディタ。

とりあえず検索と置換を改善したいなあ。
大昔のSTed2というMIDIデータ作成ソフトに「検索」機能があったが、
あーいう風に、文字以外の色々なもの(ここでは絵)を検索の対象と出来るようになるべきだ。
そーでねーと本当に児戯でオワる。使い物にならん。

今のマウスオンリーなとろくさいInterfaceは、そういう意味ではヤバイね。
計算機でデータをいじってるくせに、そのデータの中での移動手段として
マウスという手動手段しかないわけじゃん。
検索置換みたいに、計算機にカーソル(=注目点)を移動させることが出来るべきなんだよ。

82 :Delギコ:01/09/23 17:13
      ∧∧  />とりあえず検索と置換を改善したいなあ。
 @' ― (,,゚Д゚) < だとしたら、2wayは必須ではないでしょうか。
   し― し-J   \ビジュアル を 常にテキストデータとして持っておくというアレ。

C#の[±]でコードを閉じられるエディタ知ってる?
折れも画像でみただけなのだけど、あれって面白そう。

あの[±]を発展させて
関数やメソッドをアイコンや画像で包んでしまって
それの呼び出し、呼び出されを線で結べるようにしてみたら
面白いものにならないかな。

関数の引数によるInOutが矢印になる感じ。

テキストエディタ上で動作させて
既存のコードの存在と互換性を取りつつVisual表示も可能というもの。

どうでしょう。

83 :デフォルトの名無しさん:01/09/23 17:46
                   
―――――――――――――――――――――――
それでは次のコーナーです
__  ____________________
    .|/   ‖      ‖ ____   
        ‖      ‖ | ON AIR.|
   ∧ ∧ θ     ‖  ̄ ̄ ̄ ̄
   (,,゚Д゚)__ /[] ̄ ̄θΛ_Λ
  ||(.  つ_/    //(´∀` )/|  
  ┗┳ /      ̄/⊂    ||_/
    ┻| ̄ ̄ ̄ ̄ ̄|  (  ━┳┛      
      |_____| /ヽ」┘┻
____________|\____

「Rubyはクソです。ゴミ箱逝きです。 いじょ 」
この発言をコピペしていただければ幸いです。

28 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)