トップページ⇒tech
1001コメント354KB

GUIがむずかしすぎる

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2009/10/18(日) 17:54:43
コマンドラインプログラムならなんとかできるんだけど
GUIは私の知能じゃむり
0052デフォルトの名無しさん2009/10/20(火) 11:45:46
ちょっと違うかな。

一般にViewとModelは同一マシン(メモリ空間上)に存在するから、VはMの状態を参照できる。
一方、もし>>51がWebの事を言っているなら、Client(Webブラウザ)とServer(Webサーバ)は、
ネットワーク上で分散しているから、ClientはServerの状態を(直接的には)参照できない、
という違いがある。したがって、ClientもまたMVCパラダイムで設計され、ClientのMと
Server(Mのみ)との間で、規約(HTTP)に従った通信が必要になる。
0053デフォルトの名無しさん2009/10/20(火) 15:26:00
>>41
そういやオカモトのスタンダードタイプは\500〜\3000まであるが、
いったい何が違うんだろう。装着感？
0054デフォルトの名無しさん2009/10/20(火) 16:10:05
うすうす
0055デフォルトの名無しさん2009/10/20(火) 16:10:52
GUIの難しさの本質？
GUIから新しい言語が出来てしまって、それらの言語がデファクト
スタンダートを作っているから
そしてそれらの言語の特徴（矛盾しているわけではないが、
流儀としては排他的）が相互汚染防止の為に反目しあってること
0056デフォルトの名無しさん2009/10/20(火) 17:35:40
Intermediate Rails: Understanding Models, Views and Controllers | BetterExplained
http://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/
これの図を見るとMVCは全部鯖側にあるようにみえるんだけど
一言にMVCと言っても色々あるんだなー
0057デフォルトの名無しさん2009/10/20(火) 17:40:46
Win32++
http://sourceforge.net/projects/win32-framework/

これよさげ
情報、日本語訳求む。
ヘッダオンリーでATLやWTLより簡単げ。
0058572009/10/20(火) 23:26:53
よさげとおもって紹介してみたけどレス無い・。・。
0059デフォルトの名無しさん2009/10/20(火) 23:58:56
MVC ってよくわからん。
M がデータ処理で V がアウトプットで C がインプットで大体合ってるの?
0060デフォルトの名無しさん2009/10/21(水) 00:08:12
>>57
思いつきで作ってみました的なモノでは無く、きちんと公開して多くの人に使ってもらえる事を
意識したプロジェクトに見える。ドキュメントやサンプルも整備されてるし(英語だけど)。
UNIX(C)&Mac(realBasic)プログラマなんだが、C++とWinには以前から挑戦したいと思ってた。
だから、なかなかシンプルで良さげに見えた。とは言ってもWin32 APIは初めて見たわけだが....。

で、一部の翻訳に着手したよ。ヘルブの中にある概要("Win32++ Overview")の章。
明日くらいには公開できると思う。興味あるかな？
0061デフォルトの名無しさん2009/10/21(水) 00:28:18
thx!楽しみにしてます!
0062デフォルトの名無しさん2009/10/21(水) 05:30:37
>>60

日本で唯一解説しているらしいところはここだけみたいです。量少ない。
http://naruishi.hp.infoseek.co.jp/program/w32pp.txt
0063デフォルトの名無しさん2009/10/21(水) 09:50:04
>>58
まともな日本語も掛けない奴のレスなんか、レス返す価値などないと思ったんでね。
# つーか、なんだよ、「簡単げ」ってよ。
0064デフォルトの名無しさん2009/10/21(水) 09:58:13
無理ゲー
0065デフォルトの名無しさん2009/10/21(水) 11:19:25
>>60
>興味あるかな？
私が翻訳権を持ってるわけじゃないのでどうでもいいっちゃいいんですが
許可を得ているのかどうかにはちょっとだけ興味があります。
0066602009/10/21(水) 14:38:51
Win32++の翻訳文書を公開した。

・Win32++概要
　http://www.h6.dion.ne.jp/~machan/win32pp/overview.txt

Windowsプログラミングは未経験なので、不適切だったり誤っている箇所があると思う。
特に、リバーコントロール(Rebar Control)/メッセージの反射(Message Reflection)/
CWndオブジェクト/WndProc関数に関連した部分は、無理矢理に訳した感がある。
Win32 APIに詳しい住人さん達からのツッコミに期待。
0067デフォルトの名無しさん2009/10/21(水) 15:01:25
二次的著作物とは、著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、
その他翻案することにより創作した著作物をいう（2条1項11号）。
二次的著作物に対する著作権法の保護は、原著作物の著作者の権利に影響を及ぼさない（11条）。
著作物 - Wikipedia
0068デフォルトの名無しさん2009/10/21(水) 16:15:34
>>56
MVCは、元々は普通の(ネットワークとは無関係な)GUIアプリ開発の中から生まれた。
それがWebアプリにも取り入れられるようになった経緯がある。Railsは、その代表格だね。
最近では、Webクライアント上で動くJavaScriptアプリにも取り入れられつつある。
SproutCoreと呼ばれるAJAXフレームワークが、その一例。

・SproutCore Documentation / Basics-Introducing SproutCore MVC
　http://wiki.sproutcore.com/Basics-Introducing+SproutCore+MVC

だから、SproutCoreを利用するWebシステムでは、以下の３つのMVCが、同時に存在することになる。

・Webサーバ上で動くアプリケーションのMVC -- 例: Rails
・Webブラウザ自身のMVC -- このスレでの話題の中心となる、GUI向けのMVC
・Webブラウザ上で動くアプリケーションのMVC -- 例: SproutCore

>>59
思いっきり単純化すると、そのイメージで合っているよ。

・Mは、ユーザインタフェースを持たない、データ管理だけのオブジェクト。

・Vは、Mのデータを表示(出力)するオブジェクト。ユーザから見える部分になる。

・Cは、ユーザの操作(入力, 例:ボタンを押す)を受け付け、MやVへメッセージを送って、
　全体を制御するオブジェクト。
0069デフォルトの名無しさん2009/10/21(水) 16:21:57
>>67
翻訳したものに関してはね。
翻訳できるかどうかが問題で
第二十七条　著作者は、その著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、その他翻案する権利を専有する。

だからこそ、翻訳権や翻案権は明記されない限り著作者から自動的に
移譲されたりはしないことになっている。
第六十一条　著作権は、その全部又は一部を譲渡することができる。
2　著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。
0070デフォルトの名無しさん2009/10/21(水) 17:38:05
Win32++はMITライセンス =修正BSDライセンス


前述のGPLやLGPLに比べて、格段に制約の緩いライセンスとなっています。
制約となる条件がたった２点しかありません。
１つ目は「再配布時には著作権表示を残す」という事。
もうひとつは「無保証である」という事。
この２点を守りさえすれば、どのように利用しても構いません。
ライセンスをGPLに変えて再配布するもよし、
改変して独占販売するもよし、
ソフトウェアだけ頒布してソースを非公開にしてもよし。

http://smkn.xsrv.jp/blog/2009/03/summary_for_gpl_mit_cc_etc/
0071デフォルトの名無しさん2009/10/21(水) 17:41:47
要するに、元著作者の名前を入れておけばいいってことだけ。　無保証って言うのは持続しなくてもいい。

利用条件は、
無保証
著作権表示の保持
MIT License (X11 License)
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9#MIT_License_.28X11_License.29
0072デフォルトの名無しさん2009/10/21(水) 19:54:28
>>1に禿同
本質的に難しい（複雑）なのかもしれないけど、
どちらかというとライブラリが足引っ張ってると思う
0073デフォルトの名無しさん2009/10/21(水) 20:12:23
>>68
どうもありがと！
これで MVC は理解して卒業した事にします。
0074デフォルトの名無しさん2009/10/21(水) 20:24:15
駄目
POSAのvol1の130ページあたり読むまで許さない
0075デフォルトの名無しさん2009/10/21(水) 20:25:03
実際に自分でプログラムしなきゃ
理解したことにはならんだろｗ
0076デフォルトの名無しさん2009/10/21(水) 20:39:27
実際のコーディングはどうせライブラリのスタイルに合わせないといけないので、
モデルの話は常識程度に抑えておこうと思ってます。
0077デフォルトの名無しさん2009/10/21(水) 20:39:33
Model View ControllerはArchitecural Patternsだから
詳細設計あたりまでもってくれれば十分
でもそこまで考えたらコードまで落し込んで動かす所まで持っていきたくなるから同じことか
0078デフォルトの名無しさん2009/10/21(水) 21:04:59
もうさ、MVCが基本とかいう幻想は早く捨て去ろうよ
あんなもの、単にオブザーバーパターン使ってみましたってだけじゃん
GUIのGの字も語ってない
それよりも、FRP（Functional Reactive Programming）とか参考にした方がまだまし
0079デフォルトの名無しさん2009/10/21(水) 21:15:00
それなりに効率よく、綺麗に扱うには
Future valueとかMonadとかApplicative Functorとか
普通の言語で使うには難しいfeaturesが必須ですけどね
0080デフォルトの名無しさん2009/10/21(水) 21:20:27
そういう様式論って殆ど実りが無いんだよな…
マーケティングのバズワードとかハイプとかと同じ匂いがする
0081デフォルトの名無しさん2009/10/21(水) 21:22:40
様式論のバズワードの筆頭がデザパタ
0082デフォルトの名無しさん2009/10/21(水) 21:23:05
関数型言語風のMVCとしてはtangible valueというものもあるけどあれも続報を聞かない
0083デフォルトの名無しさん2009/10/21(水) 21:25:01
>>79
「それなりに」の程度によるけど、「実用的」というレベルならHaskellじゃなくても全然いける
連続的な時間を扱いたかったら確かに遅延評価がないと厳しいけど、
離散的な時間でよく、なんちゃってFRPならどの言語でも（もとい、ML系なら）無問題でしょ
実際OCamlでもそんなライブラリがあるし
0084デフォルトの名無しさん2009/10/21(水) 22:42:36
>>72
ライブラリが足引っ張ってる部分というのは、具体的にはどの部分なのかな？

自分が>>1の言う難しさが何であるかを考えるに、コマンドラインの対話型プログラミングは、
メニュー出力/コマンド入力/コマンド実行/実行結果出力をループさせる処理になる。
コードは、フローチャート(流れ図)という言葉があるように、連続した処理の塊(かたまり)として
読む事ができる。これに対して、GUIプログラミングでは、入力イベントごとの対応する手続きが、
断片としてコード全体に散らばってしまう。この為、プログラムを読む側からすれば、
流れるような処理ではなく、実行部分がコードのあちこちを無秩序に飛び回っているように見える。
この可読性の悪さが、GUIプログラミングを難しいものに見せているのだと思う。
0085デフォルトの名無しさん2009/10/21(水) 22:52:46
GUIプログラミングの新時代は関数型言語が開くのか
0086デフォルトの名無しさん2009/10/21(水) 22:53:08
コマンドラインでも curses とか使ったアプリはイベント駆動だね。
>>1 が言ってるのは入力待ちでブロックする様な単純なプログラムか
フィルタ系なのかな。
0087デフォルトの名無しさん2009/10/21(水) 23:10:16
さすがに>>1がcursesを使っている人物だとは、ちょっと思えないがなぁw
0088デフォルトの名無しさん2009/10/21(水) 23:27:55
>>84
足引っ張ってるのは、色々あるけど、一つはレイアウト
あれはクソ

>流れるような処理ではなく、実行部分がコードのあちこちを無秩序に飛び回っているように見える。
>この可読性の悪さが、GUIプログラミングを難しいものに見せているのだと思う。
禿同ですな
イベントからの条件分岐と「目的の処理」を分離して欲しい
0089デフォルトの名無しさん2009/10/21(水) 23:40:25
>>85
いや、その前に関数型言語が一般のプログラマに受け入れられる事が先だ
いかに関数型言語を使うことで美しく簡潔なGUIアプリケーションが書けたとしても、
関数型言語が一般のプログラマに使ってもらえなければ、
(GUIプログラミング新時代への移行に関しては)何の意味も持たない
オブジェクト指向言語も、過去に同じような批判を受け、それに耐えて現在の地位を得ている
0090デフォルトの名無しさん2009/10/21(水) 23:42:33
つ JavaScript

みんな function(){ ... } ってラムちゃんを書きまくってるからオケ。
0091デフォルトの名無しさん2009/10/21(水) 23:47:58
ここで、Win32++を推奨していこう。あとwiki作って広めるか。
http://sourceforge.net/projects/win32-framework/
0092デフォルトの名無しさん2009/10/22(木) 00:19:48
>>91
それさ、何が嬉しいのかいまいち分からないんだが、説明してもらえる？
0093デフォルトの名無しさん2009/10/22(木) 01:06:04
>>90
でも、そのラムちゃんって不純だからなぁ....
0094デフォルトの名無しさん2009/10/22(木) 01:40:15
何か問題あるんだっけ?
0095デフォルトの名無しさん2009/10/22(木) 03:56:29
WPFってかなり素性のいいフレームワークだと思うんだけど
MSと.netというだけで評価されない風潮がある感じがして悔しい

cssのdiv厨ならぬGrid/StackPanel厨になっちゃうのがアレだけど
0096デフォルトの名無しさん2009/10/22(木) 07:00:36
そもそもWPFっていう単語が何なのかまったくわからん。
WindowsPrintFoundation?
0097デフォルトの名無しさん2009/10/22(木) 07:53:15
>>90
あれは関数型言語の一部のガワだけを拝借しているに過ぎない。

プログラミング スタイルが本質的に異なるから、
ラムちゃんを書きまくってるからオケとはなかなかいかない。
0098デフォルトの名無しさん2009/10/22(木) 07:56:57
つまり、純なラムちゃんじゃないと俺の嫁じゃない
そういうことだな？
0099デフォルトの名無しさん2009/10/22(木) 09:30:19
そもそもGUIは本質的に難しさを抱えてるものだから、
どの言語、フレームワークを使っても一定以上には簡単にならないと
マが覚悟を決めないと話にならんよね。
0100デフォルトの名無しさん2009/10/22(木) 09:30:37
そうよ、ダーリン
0101デフォルトの名無しさん2009/10/22(木) 10:08:16
…………。　さぶっw
0102デフォルトの名無しさん2009/10/22(木) 10:42:47
純であることに拘ったって、どうせおまいらが不純にするんだろ。
最初から不純だっていいじゃないか。
0103デフォルトの名無しさん2009/10/22(木) 10:53:29
もちろん不純オーケーな言語もあるし(例:OCaml)、
はじめから不純前提な言語(例:JavaScript)もある
でも、純であることにトコトンこだわった言語、
つまり純なプログラミングしか許さない言語(例:Haskell)もある
そんな純な世界だけでも、GUIプログラムは書けるんだ
0104デフォルトの名無しさん2009/10/22(木) 11:41:11
まあ、アセンブラだけでもGUIプログラムは書けるしな。
0105デフォルトの名無しさん2009/10/22(木) 11:52:03
つまりは、そういうこと
書ける事と、それがやさしい/むずかしいとは別の話
特に、はじめてGUIプログラミングに挑戦しようとする人にとって、
少なくとも現状だと、関数型言語の壁は、あまりに高すぐる
0106デフォルトの名無しさん2009/10/22(木) 15:15:52
>>92
60の訳より。

Win32++はアプリケーションを開発する為のWindows APIを直接使用するライブラリを提供しています。
Windows 95からWindows XPとVistaに到る32bit、64bitのすべてのMicrosoft OSおよびWindowsCEをサポートします。
このライブラリは、単純なウィンドウ、ダイアログ、フレーム、そしてMDIフレームをベースとしたアプリケーションを開発できます。
また直接Windows APIを扱うプログラミングにオブジェクト指向アプローチをもたらします。
Borland、Microsoft、GNUコンパイラなど　幅広いC++コンパイラをサポート。多言語サポート。
0107デフォルトの名無しさん2009/10/22(木) 19:24:39
>>103
>純なプログラミングしか許さない言語

確か破壊的に書く方法もあったよね。アクションだっけ？
Haskell が良いのは、副作用を禁止するのではなく副作用を
分けて記述出来る事だった様な気がするけど、俺の勘違いかな。
0108デフォルトの名無しさん2009/10/22(木) 20:26:43
>>105
関数型言語（文脈から考えると純粋関数型？）でのGUIプログラムは
手続き型言語でのそれより（現状）難しいと感じてるようですが、
そう感じる理由は何でしょうか。

それは単にスタンダードと呼べるGUIライブラリが整備されておらず、
それに対する入門書も無い状態だからでしょうか。
もしそうなら、それは関数型言語に対して感じる壁とは違うような気がします。
0109デフォルトの名無しさん2009/10/22(木) 20:39:06
>>108
>>105 が難しいと思ってる訳じゃないんじゃないの。
『はじめてGUIプログラミングに挑戦しようとする人にとって』、
壁が高いというのは、俺も同意見だな。
0110デフォルトの名無しさん2009/10/22(木) 20:43:31
>>109
その壁が何に対して感じる壁なのか、が訊きたいです。

また、何故その壁は高く感じられるのでしょうか。
0111デフォルトの名無しさん2009/10/22(木) 21:05:53
君は壁なんか存在しないと思ってるの？
0112デフォルトの名無しさん2009/10/22(木) 21:07:01
>>110
状態を持ちにくいからだろ。
だいたい、GUIなんて俺には副作用の塊に見える。
0113デフォルトの名無しさん2009/10/22(木) 21:13:22
>>110
横槍
たぶん入門書に載ってないからだと思われ
例えばFRPの一部であるevent（の簡易版）は、
Visual Studio 2010のF#にfirst-class composable eventsとして登場する予定
そして、それが「3日でわかる!! VisualStudio 2010」とかで紹介される事になる
そうすると、急に壁が低くなる（と多くの人は錯覚する）
要するに、技術そのものの壁じゃなくて心理的なものだと思う
0114デフォルトの名無しさん2009/10/22(木) 21:16:52
>>111
初めてGUIプログラムをする者にとっての壁はあると思いますが、
それは関数型言語に備わった、関数型言語だからこその壁では無いような気がします。

初めてGUIプログラムをする者は初めてGUIの概念や考え方、組み立て方を学ぶわけですから、
それを関数型言語をベースにして学ぼうが、手続き型言語をベースにして学ぼうが、
壁は同じくらい高く感じられると思います。
そして、それは言語ではなくGUIに対して感じる壁だと思います。

私はどちらのGUIも経験しましたが、確かに関数型言語での方が勉強に時間がかかります。
ただ、それは単に資料が少ないというだけのことで、関数型言語の言語としての壁は感じませんでした。
手続き型の方が資料が少なければ、手続き型の方の勉強に時間がかかったと思います。
0115デフォルトの名無しさん2009/10/22(木) 21:17:17
>>108,110
なにか関数型言語に対する(いい意味での)思い入れがある人みたいだから、
壁が何かを質問するよりも、率直に、関数型言語の良さをカキコしたほうがいいんじゃないかな
たとえば「関数型言語は....という特徴があるから、GUIプログラミングに適している」みたいに
0116デフォルトの名無しさん2009/10/22(木) 21:18:34
各プラットフォームのネイティブの GUI ライブラリが関数型言語で実装されてないから
ハードルは高くなるよな。格闘技の基礎が無いのに異種格闘戦に出るなんて…
0117デフォルトの名無しさん2009/10/22(木) 21:23:17
>>114
資料が少ないのが関数型の特徴だから、手続き型の方が資料が少ないという仮定は
あんまり意味が無いと思う。
0118デフォルトの名無しさん2009/10/22(木) 21:26:54
>>115
いえ、思い入れは全くないんですし、
>>105 に対して関数型はいいよとかアピールする気も全く無いんです。

ただ、>>105 以外でもよく見かけますが、
関数型言語をベースにして、その上で組み立てる物の難しさに対して、
「関数型言語の壁」と言うように言語特有の難しさに括ってしまうのは、
ちょっと違和感を感じただけです。
0119デフォルトの名無しさん2009/10/22(木) 21:29:28
俺も>>112に禿同。
0120115&1052009/10/22(木) 21:35:17
# リロードせずにカキコしちまったゼ

>>114
言いたい事は分かるし、その通りだと思うよ
でも、ここでは「プログラミング言語そのものを比較」をしてるんじゃなくて、
「GUIプログラミングのむずかしさ/やさしさを議論」しているスレなんだ
このスレでは、言語はGUIを実現するための道具、副次的なものであるという立場

>>105で書いた「関数型言語の壁」というのは、他の住人さん達が語っているように、
単純に初心者向けの情報が少ないってことを言いたかった。
0121デフォルトの名無しさん2009/10/22(木) 21:35:29
実際>>112みたいな問題って関数型だとモナドやカリー化、継続みたいな難しそうな概念を使って解決してるんだろ？
詳しくないから想像だけど。
0122デフォルトの名無しさん2009/10/22(木) 21:47:20
>>116
>格闘技の基礎が無いのに異種格闘戦に出るなんて…

面白い「たとえ」だね。ワロタよ。同感だ。

関数型言語に思い入れのある格闘家さん達は、今は己の技を磨くことに集中したほうがいいと思う
気持ちは分かるんだけど、なぜ自分達の流派が分かってもらえないんダァーと、いくら主張しても、
今の格闘センスでは、空回りに終わるか、かえって他の保守的な格闘家達からの反発をまねくだけ
0123デフォルトの名無しさん2009/10/22(木) 21:50:45
>>121
実際 >>112 みたいな問題はライブラリがやってくれるから、
それを使うだけのユーザーは、
どうやって実現しているのか意識する必要すらないです。

たとえば .NET Framework で
WFC がどうやってイベントのチェーンを実現しているのか
ユーザーは考える必要がないのと似ています。

だから、実際ライブラリを使うだけなら、
その資料とチュートリアルがあれば、
GUI 入門者でもちゃんと（使い方の）勉強はできます。
だから、「純粋にGUIプログラムを組むまでに至る難しさ」という点では
手続き型でも関数型でも同じ程度だと思います。

好奇心があってその内部処理を勉強しようとした時に、
初めて（純粋）関数型言語特有の考え方が顕著に現れてきます。
0124デフォルトの名無しさん2009/10/22(木) 21:57:08
>>123
すいません、WFC ではなく WPF です。

・・・なんか違和感あると思った
0125デフォルトの名無しさん2009/10/22(木) 21:57:17
関数型言語がむずかしすぎる(´・ω・｀)
0126デフォルトの名無しさん2009/10/22(木) 22:00:09
>>123
なるほどー。けどそうなると初学者は関数型でのGUIプログラミングは言語特性との矛盾を感じながらの実装になりそうだからストレスフルだと思う。
そこが壁なんじゃない？
0127デフォルトの名無しさん2009/10/22(木) 22:02:02
関数型言語にも、.NET Framework みたいな網羅的なライブラリがあって、
日本語のドキュメントやサンプルコードが豊富に揃っていればそうでしょうね。
ライブラリは FFI なんかで呼び出すとしても、ドキュメント類が無いから
何か詰まったら初心者にはお手上げじゃないかな。

0128デフォルトの名無しさん2009/10/22(木) 22:02:30
>>126
ん？　言語特性との矛盾とは？
0129デフォルトの名無しさん2009/10/22(木) 22:02:47
>>123
>好奇心があってその内部処理を勉強しようとした時に、

このスレの住人の好奇心はGUIプログラミングに向いているんだが....
関数型言語に好奇心があるのなら、該当するスレへ逝って、そこで大いに語れ
0130デフォルトの名無しさん2009/10/22(木) 22:03:37
>>123
>「純粋にGUIプログラムを組むまでに至る難しさ」

むしろ不純な部分として議論から省こうとしてる部分が大事だったりするんだよね。
「現実的にGUIプログラムを組むまでに至る難しさ」は大いに違う訳だし。
0131デフォルトの名無しさん2009/10/22(木) 22:04:14
なんだかんだでGUIはオブジェクト指向型言語の独壇場じゃね。
面倒なステート管理、プロパティ設定を程よく抽象化してくれる。
0132デフォルトの名無しさん2009/10/22(木) 22:07:14
>>131
俺もそう思う。イベントドリブンなプログラムとオブジェクト指向の相性は抜群。
0133デフォルトの名無しさん2009/10/22(木) 22:10:27
>>128
「基本副作用無しのはずなのになんでウインドウ出せるの？」
「ボタン押したら現在時刻をポップアップする機能って呼び出しから結果が定まらなくね？」
みたいな事だよ。
0134デフォルトの名無しさん2009/10/22(木) 22:14:02
>>130
手続き型言語で CUI を学んだ者が GUI にステップアップするのと、
関数型言語で CUI を学んだ者が GUI にステップアップするのとで、
GUI をプログラムするに至るまでの難しさは、それほど違うものでしょうか。

>>1 がどちらのタイプかは知りませんが。
0135デフォルトの名無しさん2009/10/22(木) 22:14:07
GUIの難しさって、要するに何やるにもライブラリに合わせないといけないことだとおもう。
全部自分で書くのは無謀過ぎるんでライブラリ使うことになるけど、そうするとライブラリに合わせた書き方をするしかない。
0136デフォルトの名無しさん2009/10/22(木) 22:19:36
>>134
違うと思うよ。理由は散々出てると思うけど。
0137デフォルトの名無しさん2009/10/22(木) 22:19:44
>>135
「何やるにもライブラリに合わせないといけない」ってのは、GUIに限らず、
あらゆるプログラミング(標準入出力ライブラリを含む)で共通じゃね
GUIのむずかしさとは違う希ガス
0138デフォルトの名無しさん2009/10/22(木) 22:21:33
>>131
>面倒なステート管理、プロパティ設定を程よく抽象化してくれる。
じゃぁ「むずかしすぎる」訳ではないと？
0139デフォルトの名無しさん2009/10/22(木) 22:21:38
>>137
ライブラリの規模が違うでしょ
GUI のライブラリの規模を無視して一般化しようとしてもダメなんじゃないかな
0140デフォルトの名無しさん2009/10/22(木) 22:27:59
>>133
あぁ、なるほど、それなら納得です。
確かに初学者が感じる壁はその辺りにあります。

ただ、たいていの関数型言語を学ぶ者は、CUI プログラムを学んでいる途中で、
上記のような壁をできるだけ低くするように働く概念を学びますから、
GUIでその壁に当たっても、合点がいくには至りませんが、
ストレスフルとなるまでにはいかないような気がします。
そこでストレスフルとなるなら、CUIで勉強し直した方がいいですし。
まぁ感じ方は人それぞれですが。

はい、確かにその辺りに関数型言語でのGUIの壁がありますね。
納得しました。
0141デフォルトの名無しさん2009/10/22(木) 22:29:53
>>131
細かいツッコミだけど「オブジェクト指向型言語」じゃなくて、
「オブジェクト指向手続き型言語」あるいは簡略に「オブジェクト指向言語」だろね
研究レベルだけど、オブジェクト指向分散関数型言語なんてのもあるから(例:ABCL)
0142デフォルトの名無しさん2009/10/22(木) 22:36:32
>>138
どうだろ？
「なんとか一般の人間様に制御可能なレベルになった」ってレベルじゃね？
微分とか積分とかがわからん奴には「難しすぎる」ってレベルぐらいには難しいと思う。

アップルのGUIが優れてるのは何か優れた手法をとっているとかではなくて、
それこそジョブスの鬼のようなシゴキで調整されているからなんだと思う。
0143デフォルトの名無しさん2009/10/22(木) 22:37:49
>>139
ならば、科学計算ライブラリは、ライブラリに合わせずにプログラミングできるの？
「何やるにもライブラリに合わせないといけない」というのは、
GUIプログラミングに固有のむずしさではないと思うよ

「GUIライブラリの規模(複雑度)が大きいから」むずかしい、という理由も同じだね
0144デフォルトの名無しさん2009/10/22(木) 22:42:15
GUIの理論的なモデルってあるの？
知っている人がいたら教えてプリーズ
「なんか便利そう」で対応してたんじゃ拉致があかない
0145デフォルトの名無しさん2009/10/22(木) 22:45:23
>>143
同じだと思う根拠は？
0146デフォルトの名無しさん2009/10/22(木) 22:46:09
>>144
GUIの理論的なモデルって、どういうのを期待してるんだ？
0147デフォルトの名無しさん2009/10/22(木) 22:47:16
コマンドラインやっとだったらズブの初心者だろう。
CUIもまともに出来ないんじゃないの?
0148デフォルトの名無しさん2009/10/22(木) 22:52:16
科学計算ライブラリが具体的にどのライブラリをさしているのか分からんけど、
XMLのパースとかレイトレとかは殆どフルスクラッチで書けるからライブラリの
仕様に合わせる必要は無い。GUI をフルスクラッチで書くのは規模的に難しい。
コピペとかドラッグ＆ドロップとか日本語入力変換とかベクターフォントの描画とか
一から作るのはごめんだ。
0149デフォルトの名無しさん2009/10/22(木) 22:55:21
GUIをモデル化したらCUI化するに違いない
0150デフォルトの名無しさん2009/10/22(木) 22:58:06
もう飽きたし面倒くさいから
標準入出力でいいわ。
0151デフォルトの名無しさん2009/10/22(木) 22:58:14
>>146
期待する性質としては、こんな感じ
1 その理論は描画とGUIコンポーネントとその組み合わせの世界を抽象化している
2 非同期に発生するイベントと内部状態の遷移と描画の結果と時間との関係を明らかにしている
3 抽象化された世界に必要十分な操作が導き出せる
4 必要十分な操作から便利な操作が合成でき、結果としてGUIライブラリの理想形が見えてくる
欲張りすぎか...
■ このスレッドは過去ログ倉庫に格納されています