アカウント名:
パスワード:
>プレゼンしたらソフトウェア完成っていう身分になるのはいつのことやら
では、「将来しなければならなくなるプレゼンテクニック」をタレコミしてくれ。
パッケージ済みを右から左に流したら終わりっていう身分になるのはいつのことやら
# それは違う話だ
>パッケージ済みを右から左に流したら終わりっていう身分になるのはいつのことやら
募集地域： 首都圏/関東/甲信越/北海道/東北/北陸/東海/近畿/中国/四国/九州/全国職 種： 店頭販売スタッフ仕事内容： *************【 急 募！！ 】*************時々、レジを打ったり接客対応で気分転換をしながら、パッケージ済みを右から左に流すだけの簡単なお仕事です。
時 間： ６時間 休暇は応相談勤務地 ： 日本全国のアレゲ電機店舗給 与： 時給７５０円～（データ管理費として１２０円天引きさせていただきます）福利厚生： 社販価格でソニーのRollyが買えます採用条件：・１８歳以上 ※未経験でも大歓迎！・小銭とお札の金額を認識可能な方・Oliverとディナーを楽しめる方・頑張れば頑張っただけ昇給・残業代あり！・サークル感覚で楽しく働くことが出来ますよ！申込み先： 採用担当Oliver
>> オブジェクトをお絵かきソフトのように組み合わせればもうソフトウェアの完成
IntelligentPadhttp://www.pads.or.jp/ [pads.or.jp]
その後進化していない様子ですね。
制御システム向けには、RTI 社の Constellation があります。
Constellation では、画面上で用意されたブロック (コンポーネント) を繋げるだけで制御プログラムが開発できます。もっとも、実アプリには用意されているコンポーネントだけでは不足で、デバイス制御等でカスタム・コンポーネント (C++ で作成) を用意する必要もありますが。
実績もあり、例えば、NASA ではこの Constellation (当時は ControlShell という名前) を使ってケネディ宇宙センターの Shuttle Checkout and Launch Control System (2億円の予算のシステム!) に使用しました。その他、無人機の開発や研究等で使用されております。
しかし高価なので、それなりのシステムでしか採用するのは難しいと思います。
お絵かきソフトのように組み合わせ
TechEdに来てる「絶対プログラムとか組まなさそう」な年配の方などが、そういう風に勘違いしそうなデモや説明なら、マイクロソフトさんが毎年披露されてるんですけどね...。
LabVIEWは既にそれを実用の域に迄してますね。
＞UMLで書いた設計から、コードを生成するなんてのはもういろいろやられてるので、案外そう遠くない未来かも。
まあたしかに、歴史はありますね。黒歴史が。
「モデル駆動型アーキテクチャ(MDA)は、ソフトウェア開発において、アセンブラから初期の高レベル言語への転換以来の大きな転換となるだろう、という人がいます。一方で、単なる『ナイト・オブ・ザ・リビング・CASEツール／ゾンビの誕生*1』に過ぎないという人もいます。私は後者の立場ですが、こういったうまい言い回し以上の何かが必要だと感じています。 [capsctrl.que.jp]」
少なくともUMLはそういう方向の役に立つ度合いは少ないですね。
まず図言語の悲しい宿命として、スケーラビリティが無いです。紙や画面に多くを詰め込めないから。そしてそのせいで、UMLで十分に複雑な情報を伝えることを諦めないとならない。
また、普通の言語でいう予約語みたいな概念を絵柄にマッピングするのは、絵柄の種類が少ないときはいいんですが、(UMLのように)多数になってくると覚えきるのが困難になります。UMLが「一部の図法だけ」使われがちなのはそのせい。覚えきれるところまでしか使ってもらえないんですね。アプリ全体を記述できるぶんに必
>ブジェクトをお絵かきソフトのように組み合わせればもうソフトウェアの完成
再帰を表現するときは、合わせ鏡を使うんだよね～。
>オブジェクトをお絵かきソフトのように組み合わせればもうソフトウェアの完成
このようなものですか?子供向けのオープンソース・プログラミング言語 [osdn.jp]
「N次元 超多包体の幾何学とその扱い方」とかがプログラマーの必修科目になったりして。
グルー言語なんて概念も出てきているからね。コンポーネントの持つインターフェースの標準化とかができれば、用途を特定して必要な機能を推定しやすくなれば、積み木を重ねるだけでコーディングというのも不可能じゃない。LabViewとか、REGOとか、特定分野に限ってなら実現できているわけですし。
squeakじたいは古典的な意味でのプログラム言語＋実行環境でしかなく、ただ、いろいろ気が利いているために、今回のお題のような物をその中で実現するために便利であろう選択肢の最右翼の一つだ、というだけです。
>サイバーフレームワーク
OOエンジニアの輪！ ～ 第 24 回 加藤 康之 さんの巻 ～ [ogis-ri.co.jp]ですね。主張(とそれを反映してるはずである製品)は極めて興味深いと思う。
これで、このアーキテクチャの苦手ポイントについてももっと掘り下げてくれたら、「神」認定してもいいところなんだが。
他の枝で出てる、LabView、Max、YahooPipeなどと同じ系統なわけだけども、こいつらの味噌は「オブジェクト」が所謂OOPでいう「オブジェクト」とはちょっと違うという点だ。OOPでは「オブジェクト」はおよそありとあらゆる部分がソレで出来てるってこと
ワークフロー記述言語というのかな。Automatorなんてのもありました。http://support.apple.com/kb/HT2488?viewlocale=ja_JP [apple.com]
Max/MSPとかYahoo Pipeみたいな方向性はどうですか？
(てきとうにぐぐったYahoo Pipeの絵→ http://chikura.fprog.com/PIX/1208233725_blogsearch.png [fprog.com] )
これが便利かどうかは、モンダイの形態に依存します。上記はUNIX PIPEの延長みたいなものでして、つまり入力→処理→出力を数珠繋ぎ「すれば解決できる」ような形態のモンダイに特化しています。そういう問題なら解けます、そうでないならまたヨソを当たってください、と。
入れ子、つまり複数の部品とその配線の組み合わせを新たな部品として登録する仕組み、があれば、それなりに大規模化もできますし。
UNIX PIPEとの違いは、
オブジェクトをお絵かきソフトのように組み合わせればもうソフトウェアの完成・・・って時代が来るのかと思ってたけど，先は遠いのかなぁ。
思わぬ伏兵、メイドイン俺 [nintendo.co.jp]。 まあ、むしろ限られたリソースをトリッキーに使い倒すのが楽しかったりするのですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
codingそのものが無くなるんじゃないの？ (スコア:1)
# アセンブラのようなANSI C codingから未だ離れられないロートルより
Re:codingそのものが無くなるんじゃないの？ (スコア:3, おもしろおかしい)
Re:codingそのものが無くなるんじゃないの？ (スコア:1, すばらしい洞察)
>プレゼンしたらソフトウェア完成っていう身分になるのはいつのことやら
では、「将来しなければならなくなるプレゼンテクニック」をタレコミしてくれ。
Re:codingそのものが無くなるんじゃないの？ (スコア:1)
というシステムでOKじゃないか。
そうしたらプレゼンのテクニックも必要ない。
Re: (スコア:0)
パッケージ済みを右から左に流したら終わりっていう身分になるのはいつのことやら
# それは違う話だ
Re: (スコア:0)
>パッケージ済みを右から左に流したら終わりっていう身分になるのはいつのことやら
募集地域： 首都圏/関東/甲信越/北海道/東北/北陸/東海/近畿/中国/四国/九州/全国
職 種： 店頭販売スタッフ
仕事内容：
*************【 急 募！！ 】*************
時々、レジを打ったり接客対応で気分転換をしながら、パッケージ済みを右から左に流すだけの簡単なお仕事です。
時 間： ６時間 休暇は応相談
勤務地 ： 日本全国のアレゲ電機店舗
給 与： 時給７５０円～（データ管理費として１２０円天引きさせていただきます）
福利厚生： 社販価格でソニーのRollyが買えます
採用条件：
・１８歳以上 ※未経験でも大歓迎！
・小銭とお札の金額を認識可能な方
・Oliverとディナーを楽しめる方
・頑張れば頑張っただけ昇給・残業代あり！
・サークル感覚で楽しく働くことが出来ますよ！
申込み先： 採用担当Oliver
Re:codingそのものが無くなるんじゃないの？ (スコア:2)
>> オブジェクトをお絵かきソフトのように組み合わせればもうソフトウェアの完成
IntelligentPad
http://www.pads.or.jp/ [pads.or.jp]
その後進化していない様子ですね。
Re:codingそのものが無くなるんじゃないの？ (スコア:2, 参考になる)
制御システム向けには、RTI 社の Constellation があります。
Constellation では、画面上で用意されたブロック (コンポーネント) を繋げるだけで制御プログラムが開発できます。
もっとも、実アプリには用意されているコンポーネントだけでは不足で、デバイス制御等でカスタム・コンポーネント (C++ で作成) を用意する必要もありますが。
実績もあり、例えば、NASA ではこの Constellation (当時は ControlShell という名前) を使ってケネディ宇宙センターの Shuttle Checkout and Launch Control System (2億円の予算のシステム!) に使用しました。その他、無人機の開発や研究等で使用されております。
しかし高価なので、それなりのシステムでしか採用するのは難しいと思います。
Re:codingそのものが無くなるんじゃないの？ (スコア:1)
お絵かきソフトのように組み合わせ
TechEdに来てる「絶対プログラムとか組まなさそう」な年配の方などが、そういう風に
勘違いしそうなデモや説明なら、マイクロソフトさんが毎年披露されてるんですけどね...。
Re:codingそのものが無くなるんじゃないの？ (スコア:1, すばらしい洞察)
LabVIEWは既にそれを実用の域に迄してますね。
Re:codingそのものが無くなるんじゃないの？ (スコア:1)
Re: (スコア:0)
＞UMLで書いた設計から、コードを生成するなんてのはもういろいろやられてるので、案外そう遠くない未来かも。
まあたしかに、歴史はありますね。黒歴史が。
「モデル駆動型アーキテクチャ(MDA)は、ソフトウェア開発において、アセンブラから初期の高レベル言語への転換以来の大きな転換となるだろう、という人がいます。一方で、単なる『ナイト・オブ・ザ・リビング・CASEツール／ゾンビの誕生*1』に過ぎないという人もいます。私は後者の立場ですが、こういったうまい言い回し以上の何かが必要だと感じています。 [capsctrl.que.jp]」
Re: (スコア:0)
少なくともUMLはそういう方向の役に立つ度合いは少ないですね。
まず図言語の悲しい宿命として、スケーラビリティが無いです。紙や画面に多くを詰め込めないから。
そしてそのせいで、UMLで十分に複雑な情報を伝えることを諦めないとならない。
また、普通の言語でいう予約語みたいな概念を絵柄にマッピングするのは、絵柄の種類が少ないときはいいんですが、(UMLのように)多数になってくると覚えきるのが困難になります。UMLが「一部の図法だけ」使われがちなのはそのせい。覚えきれるところまでしか使ってもらえないんですね。アプリ全体を記述できるぶんに必
MADO (スコア:1)
見た事もさわったことも無いけど、
ちょうど親コメントに書いてあるような趣旨のツールだった覚えがある。
SOFMAPのパンフレットでいつも読んでたな。
--------------------
/* SHADOWFIRE */
Re:codingそのものが無くなるんじゃないの？ (スコア:1, おもしろおかしい)
>ブジェクトをお絵かきソフトのように組み合わせればもうソフトウェアの完成
再帰を表現するときは、合わせ鏡を使うんだよね～。
Re: (スコア:0)
Re: (スコア:0)
>オブジェクトをお絵かきソフトのように組み合わせればもうソフトウェアの完成
このようなものですか?
子供向けのオープンソース・プログラミング言語 [osdn.jp]
Re: (スコア:0)
学習用によくある単機能ブロックを組み合わせる様なものをイメージしてるんだろうけど、
コードが膨大になり、かえって煩雑になるとは思わない？
低級言語ほどシンプルに書けるでしょ？
Re:codingそのものが無くなるんじゃないの？ (スコア:1)
「N次元 超多包体の幾何学とその扱い方」
とかがプログラマーの必修科目になったりして。
Re: (スコア:0)
複数のブロックをまとめる機能（マクロとか言ったりする）があればそうでもないよ。
特定に業務に対象を絞ったものだといろいろ使われてるな。LabViewとか、ゲームエンジンだとか。
ただやっぱり抽象化は制限されるから汎用的な言語ではあまり流行らないみたい。
悪いイメージがあり過ぎるのも流行らない理由だと思うけど。
Re:codingそのものが無くなるんじゃないの？ (スコア:1)
グルー言語なんて概念も出てきているからね。
コンポーネントの持つインターフェースの標準化とかができれば、用途を特定して必要な機能を推定しやすくなれば、積み木を重ねるだけでコーディングというのも不可能じゃない。LabViewとか、REGOとか、特定分野に限ってなら実現できているわけですし。
Re: (スコア:0)
Re: (スコア:0)
つsqueak
Re: (スコア:0)
squeakじたいは古典的な意味でのプログラム言語＋実行環境でしかなく、
ただ、いろいろ気が利いているために、
今回のお題のような物をその中で実現するために便利であろう選択肢の最右翼の一つだ、
というだけです。
Re: (スコア:0)
仕様書だけ用意すれば一切VBAは書かなくても大抵の業務は回せるよ？
アレがいやだこうじゃなきゃ嫌だって細かい注文をして駄々をこねる奴さえいなければ。
まぁ、EUCならともかく、顧客と請負の関係ではそんな事言えないけどさ。
＃細かい特例実装をしないといけないような場合って、そもそも業務そのものが最適化されていない。
Re: (スコア:0)
名言だと思う。
で、業務だの法律だのは、いわゆるソフトウェアよりもずっと重い、つまり変化してくれにくいものだって点がネック。
業務だの法律だのを反映しないとならない(業務)ソフトウェアでは
ソコが開発/修正のボトルネックだし、
仕様が判りにくくなり易いという意味ではテストとデバッグのボトルネックもソコになる。
Re: (スコア:0)
Re: (スコア:0)
>サイバーフレームワーク
OOエンジニアの輪！ ～ 第 24 回 加藤 康之 さんの巻 ～ [ogis-ri.co.jp]ですね。
主張(とそれを反映してるはずである製品)は極めて興味深いと思う。
これで、このアーキテクチャの苦手ポイントについてももっと掘り下げてくれたら、「神」認定してもいいところなんだが。
他の枝で出てる、LabView、Max、YahooPipeなどと同じ系統なわけだけども、
こいつらの味噌は「オブジェクト」が所謂OOPでいう「オブジェクト」とはちょっと違うという点だ。
OOPでは「オブジェクト」はおよそありとあらゆる部分がソレで出来てるってこと
Re: (スコア:0)
ワークフロー記述言語というのかな。Automatorなんてのもありました。
http://support.apple.com/kb/HT2488?viewlocale=ja_JP [apple.com]
Re: (スコア:0)
ついでに、僭越ながら。
この手のものは抽象度が非常に高く、人間がフローを明確に意識しているものには強いですが、そうでないものには弱いです。
たとえば、MLの型推論のようにローカルな規則の集合のようなものは、宣言的に書くほうがずっと楽でしょう。
特に、prologのようにバックトラックを持つものやhaskellのように遅延評価ベースのものとは対極的だと思います。
Re: (スコア:0)
Max/MSPとかYahoo Pipeみたいな方向性はどうですか？
(てきとうにぐぐったYahoo Pipeの絵→ http://chikura.fprog.com/PIX/1208233725_blogsearch.png [fprog.com] )
これが便利かどうかは、モンダイの形態に依存します。
上記はUNIX PIPEの延長みたいなものでして、
つまり入力→処理→出力を数珠繋ぎ「すれば解決できる」ような形態のモンダイに特化しています。
そういう問題なら解けます、そうでないならまたヨソを当たってください、と。
入れ子、つまり複数の部品とその配線の組み合わせを新たな部品として登録する仕組み、があれば、
それなりに大規模化もできますし。
UNIX PIPEとの違いは、
Re: (スコア:0)
「画面イメージと帳票イメージを定義すると完成」というのが有りましたが、
その後はみなさんご存じの通り、すたれています。
コーディングが不要になる方面もあるでしょうが、
必要性が高まる部分もあり、バランスがとれていくのではないでしょうか。
#将来、codingが「技術」とみなされるかどうかは知りません。
Re: (スコア:0)
Re:codingそのものが無くなるんじゃないの？ (スコア:1, すばらしい洞察)
ノ ‐─┬ /
,イ 囗. | / ＿ 丿丿
| __| —ナ′
/ ‐'￣
,‐ /
ナ'￣ / ､＿__
/ ノ`‐、＿
/ ＿ 丿丿 ＿メ | ＿/
—ナ′ 〈＿＿ Ｘ /￣＼
/ ‐'￣ / Ｖ /
/ ＼ ｌ レ ' `‐ ノ
/ ､＿__ Χ￣￣〉
＼ 丿 /
＼ / ＿
—ナ′＿_
| ＿/ ￣￣〉 / ,
Ｘ /￣＼ ノ / ＿|
/ Ｖ / / く＿/`ヽ
レ ' `‐ ノ ———'フ
/￣ ┼┐┬┐
み | 〈 / Ｖ
つ `− 乂 人
を
┼‐ | —┼‐
┼‐ | |
｛＿_） | ＿|
| く＿/`ヽ
Re: (スコア:0)
オブジェクトをお絵かきソフトのように組み合わせればもうソフトウェアの完成・・・って時代が来るのかと思ってたけど，先は遠いのかなぁ。
思わぬ伏兵、メイドイン俺 [nintendo.co.jp]。
まあ、むしろ限られたリソースをトリッキーに使い倒すのが楽しかったりするのですが。