使わざるを得なかった最悪のフレームワーク

おまえらが今までに止むを得なく使わざるを得なかった
最悪なフレームワークについて語ってください。

頼むから俺に設計させろ！　とか
コレ使わない方が絶対実装はえーよ！　など

使いたくも無いものを周りに強制されて
泣く泣く苦労した経験がおまえらにもあるはず。

プロジェクト単位のイヤンな強制という点で、
ツールキット・コンポーネント集も、まとめて取り扱わせて戴きます。

さあ、お前ら、語ってください。

せっかくなので真・コンピュータ用語辞典より
http://www.geocities.co.jp/SiliconValley/5634/t82D3_0009.html#855
> フレームワーク
> 【プログラミング】
> ・野蛮で汚くて人様には見せられない土台部分を隠すためかどうかは知らないが、
> 何処の誰かが作り「便利でしょ?　使いなさい」と押しつけられる、重くてバグ
> だらけの余計なコードの集合体。

Zopeというなんだか分からない変なアプリケーションサーバもどき。
最悪だったYO!

>>3
もう少し詳しく聞きたい。

>>3
今、Zope Japanとかいうページを見つけたので見てみようとしたら
落ちてやんの・・・。

2ch的、グッドタイミング・・・なのか？

ちなみにURL
ttp://www.zope.ne.jp

Ruby >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Python
Walrus >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Zope

Pythonは糞言語。使ってるバカは死ね

1=3だろ？
自作自演したいなら書き込み時間をあけないと駄目だよ（w

6 == (●´へ｀●)

もうここには来ません。

立て逃げかよ。

MFC

>>7

残念はずれ

1=5でした。

俺の苦労話は、あとでこっそり語ってやるYO！

ちなみに>>9もおいらじゃないずら

１の苦労話次第でこのまま朽ち果てるか決まるな

>>11
ツルッ禿しく同意〜。
あと、HP Widget Set (Motif が出来る前の Xt のサブクラスライブラリ)。

>>11

MFCの最悪な点は、糞なOSを切り離せない事。

MFC単体のバグとか糞設計だけならともかく、セットで強制的に糞OSの
バグバグな点がついてくる

MFC どころか Windows そのものが最悪のフレームワークだ罠

んじゃ、ｲｲ!と思ったフレームワークも語って欲しいぞなもし

Ruby!

>>18
言語の話じゃなくてフレームワークの話をスレ

ＳＴＬはフレームワークですか？

とりあえず、STL は何の略だい？と言ってみる。

スタンダードテンプレートライブラリ
なんで？

AWTはフレームワークですか？

だからフレームワークってなんだよ。聞いてんだろ
誰か早く答えろよボケ
話が進まねーだろ。

>>24
フレームワークってなんだよ、だと？
>>2 読めや、カス。

>>25
それはネタでしょ
正確な定義を教えてちょ。
STLやAWTはフレームワークじゃ無いですか？
DWHはフレームワークですか？
.NETはフレームワークですか？

フレームワークとは英語で「枠組み」という意味で、文字どおりソフトウェア全体の
枠組みを提供するものを指して一般にこう呼ばれている。コンポーネントはそれ自体
完結した1つの完成したソフトウェア部品として提供されるが、フレームワークの場合、
それをベースとして開発者が個別の目的に応じた拡張を施すことで最終的な完成品を
効率良く作ることを意図しており、いわば半完成品として提供される。

通例、互いに関係を持つクラスを集めたクラスライブラリとして提供され、
開発者はそれらを継承するなどして独自のクラスを作成し、フレームワーク
が用意した枠組みに沿ったアプリケーションを作成する。
このような使い方を考えると、フレームワークで再利用の対象になっている
ものは、コードやライブラリといったソフトウェアそのものというよりも、
そこに込められた知的産物としての設計アイデアの方だということがわかる。
つまり、アプリケーションの肝となる「しかけ」の部分だけをそっくりいただき、
それ以外の部分は好きなように作ることができるという、まさにオブジェクト指向
の特徴を生かした魅力的な開発スタイルになるのだ。

ところが、実はここに1つ大きな問題がある。
フレームワークを使いこなすには、そこに込められた設計アイデアを理解
しなければならない。オブジェクト指向の基本的な概念を知っているだけ
ではなく、それらを使ってどのような「しかけ」が作りこまれているのかを
正確に把握してからでなければ、フレームワークを使いこなすことは難しい
のである。

以上、
ttp://www.oracle-master.org/study/yomi/yomi15_dsnp1.html
より抜粋

http://www.e-owl.net/course/trial/demoVC++/course/cont/page/00004T20-01-03-L.html

まあ、こんなのもありか。

誤解を恐れずばっさり言うと

フレームワーク：設計思想、ライブラリの活用方法までを定義した半パッケージみたいなもん
ツールキット：特定の機能を実現したライブラリ集。
コンポーネント：RAD開発で用いられるソフトウェア部品。

って感じだ。

>>29
ぜんぜんオブジェクト指向じゃないフレームワーク使わされてます・・・。

オリジナルはCOBOLだってよ・・・。

そんなもんJavaに持ってくるなよ。

>>26
＞DWHはフレームワークですか？

まさかデータウェアハウスの事じゃないよね？

厨房ﾊｯｹｿか？

単純に我々が書くアプリケーションのコールバックルーチンを呼ぶ奴らが
フレームワークなんじゃないのか？
ついでにウイザードみたいなジェネレーターがソースコードの雛型吐き出
してくれて、ライブラリーが雛型の関数を呼んでくれるのがフレームワーク
プログラミングなんじゃねーか。

フレームワークの定義で時間を取るより、ライブラリその他全般にまで話を広げたほうが良いんでないの？

>>36
禿同
そのほうが有意義だしね。1でもコンポーネント集とかも含めて・・・ってなてるし
既存のライブラリに対する不満なんぞ、ム板なら腐るほど出てきそうな気もする。
とりあえず俺はJavaのThredをなんとかして欲しかった。

>>37
もうすこし具体的に書いてくれるとうれしい。

Servlet Works
WACS
Web 基盤

MFC

VB使い。

>>41
フレームワークじゃない。

>>38
基本的にThredクラスを継承したクラスのみスレッド化できるってところ。
Runnableをインプリメンツするような方法を基本にしてほしかった。
利点は解るんだけど、冗長になる局面のほうが多いような気がするのよね。

Thred あたりからﾄﾞｷｭｿの香りが…

Threadじゃないの? (ぼそ)

>>44-45
よく間違えるんです・・・。コンパイルエラーとか。
鬱出汁脳

MFC

MFCってやたら票のばすな・・・。

震えるぞMFC
燃え尽きるまでMFC

基幹システムを全部CGIで

>>50
Parlかよ！
Servletとかならまだしも。

>>51 さらしage

>>51 さらしage

MFC

いやー、MFCをいつかやろうと、
本まで買ったが機会が無かった。
良かった、良かった。

VCL

WTLとか言ってみるテスト

MFC

ruby

MFCで決定〜

============== 終了 ============

MFC は４年前から使ってないなー。
と言うわけでオレは
<<PowerBuilder>>

>>2
真・コンピュータ用語辞典じたいが
「おもしろいでしょ？さぁ笑いなさい」と押し付けている
いやらしさを感じるんだけど。あれ書いたやつ、童貞っぽい

>>62
確か、娘が二人いたと記憶している。

>>62
禿同。

で、WACs

保全。

WACs と Servlet Works

.NET

なにっ!!
俺も WACs

<<WACs>>に一票。
当方ADSL

人気だなー、WACs(ﾜﾗ

>>65
Servlet Worksもひどいの？
うちのリーダーが使わせたいみたいなんだけどさ。

>>69
ひどいというか、単体じゃ箸にも棒にもかからんタダの WAS ラッパー。
まともなものを作るなら更なる膨大なライブラリの作りこみが必要。
(まだ突き止めてないけど) バグおよび挙動不審も少々ある模様。

COBOL/VB 使い向きだが、もともとオープンシステムや Web 開発
専門でやってきた部隊、特に精鋭部隊には作りづらくてしょうが
ないという罠。むしろ社内政治で使われるだけのコマ、とどこか
のスレにあった。

(WACsってなんだろう
眠くて調べる気力が湧かないや。
誰かｺｿｰﾘ教えてくれるといいなあ・・・)

WebSphere Application Component (s って何だっけ?)
これも WAS ラッパー。Java 言語を強引に手続き型設計に持って逝った
WAS 専用品、かつ、国際業務機器内輪ネタ。ServletWorks から派生して
いるため似たような構成だが、WACs の方が少々使えるライブラリが多く
そしてバグも多い。

WACs も Servlet Works も 1 リクエストで上がってきた「キー」だか ID
だかを元にアプリクラスのインスタンスを生成し、呼び出し、捨てる。
このためアプリクラスの中は (COBOL や VB にありがちな) 「巨大なフロー」
を記述することになる。特に WACs はデータ型が基本文字列なので、trim()
やら substring() やら多様することになり、ヒープに細かいオブジェクトが
出来まくってやたら GC に時間がかかる (4〜8秒規模)。

リモートユーザごとにログの出力先を分ける等の芸当が出来ないため、
1 台のサーバで十数人が平行テストすると、自分のログがアッと言う
間に流れてしまう (下手すりゃ他人に消される)。

>>72
ＧＣに４〜８秒って、その間アプリケーションサーバ全体が止まる
んだろ？すごいな。金融関係だと一定時間で客がＯＫしなきゃ無効
になる取引もあるんだがどうするんだ？

今日 ServletWorks な連中と打ち合わせしてきた。奴ら得意そうに
”クロスサイト・スクリプティング”って繰り返してた。思わず屁が出た。

50 ：デフォルトの名無しさん ：02/03/20 00:33
      基幹システムを全部CGIで


51 ：デフォルトの名無しさん ：02/03/20 02:31
      >>50
      Parlかよ！
      Servletとかならまだしも。

解析不明なエラーをはき出すWin。。。
フレームワークうんぬん言う前にOSが糞だ。

Unixの方がシンプルで安定してる。

富士通の。

>>73
Javaって使ったこと無いけどGCは別スレッドで動いているから
メインスレッドの処理はそれほど影響受けないんじゃなかったっけ？
lispのGCは結構いらつくが。

>>78
LISP の GC がマークアンドスイープしか無いと思ってる知ったか
ハケーン。

処理系により全然違うだろ

OSPとLTCS　通信系は最悪なフレームワークが多い

>>78
メインフレームのWASのGCは笑えるくらい全部とまるぞ。

現在開発中の某社基幹システム用のフレームワーク
心当たりある人はグチれ

ほしゅ

Swing(プログラマとしてではなくユーザとして)

…Swingね…あれで軽ければなぁ…。Java全般に言えることだけど。

>>86
(´･ω･`) そうだなあ…　JavaはAWTもSwingも使わなければ
決して重くないのに、GUIを使った瞬間、重くて使い物にならなく
なるんだよなあ…

そろそろ SWT マンセーなやつの出番ですか？

SWTマンセー!!