1 :
デフォルトの名無しさん:
もうコーディングは嫌だ
もっと新しいグラフィカル志向なプログラミング言語が欲しい
2 :
デフォルトの名無しさん:2014/01/26(日) 02:50:13.55
Age
そうか?
じゃあ、1+1をグラフィカルに表現してみてくれ。
そっちのほうがもっと嫌になるぞ。
1+1はそのままでいいんじゃね?
アルゴリズムとかオブジェクト指向なデザインパターンをグラフィカルに表現できないものかと
>>1 15年位前にPrographCPXという線を結んでいくだけでプログラミング出来るのがあったよ
6 :
デフォルトの名無しさん:2014/01/26(日) 08:32:29.85
バナッコペ「ロンーwwwwwwwwwwww」
LabViewだろ
唯一まともに成功したグラフィカルプログラミング言語だぞ
>>7 調べて見たけどこれ電子回路の制御限定じゃん
もっと汎用性のあるものがいいよ
DSLとGUIでRADをENJOYするスレだろ
マインクラフト
教育用以外で汎用的なグラフィカルプログラミング言語が成功した事例は聞かないな。
結局のところ、アプリを作るのにグラフィカルな方が分かりにくく面倒な部分が多いからだろうな。
プログラミングは大きく分けて何かを宣言する部分と、何かを制御(操作)する部分がある。
前者は静的な部分、後者は動的な部分とも言える。
宣言する部分というのは例えば OR マッピングとかシェーダーツリーなど。
こちらは確かにグラフィカル(図)で表現できる。
必要な情報を狭い空間に一度に表現できるから、その方が分かりやすい。
しかし、制御する部分はそうもいかないことの方が多いだろうな。
こちらは例えばアルゴリズムがそうだ。
アルゴリズムの入門書で擬似コードと一対一に対応した図が描かれたものは皆無だろ。
アプリの種類にも依るだろうが、たいていは宣言部分より制御部分の方が
大きな割合を占めるはずだ(今まで作ってきたアプリのソースを見なおしてみるといい)。
そういう意味では、純粋関数型言語のグラフィカル表現の方がまだ可能性が無くもないと思う。
12 :
デフォルトの名無しさん:2014/01/26(日) 11:09:43.06
関数型のグラフィカル表現ってどんなんだろう。フラクタルみたいになるのかな?
LabViewは手続きや時間経過も表現できるけど
文字通り壮絶なスパゲッティになる
3分間考えてみた
・関数は外から見る時はできるだけマスキングして内容を表示しない
・関数には値の入出力の箇所をもたせる
・関数への引数や戻り値の受け渡しは入出力ポートからのコネクタ(線)で表現
こんな感じ?
>>14 もう1分考えてみろ
コネクタ(線)だらけになるぞ
表示する際はマスキングして見やすくできるかもしれんが、
プログラミングする際はコネクタ(線)を繋ぐ操作が面倒になる
それは仕方ないだろ
関数定義の間を線で繋ぐということをしないで
別個に作れるようにしちゃうと、もうグラフィカルとは言えん
この図はブルートゥース技術によりワイヤレス接続されています
テキストだけで情報と情報のリンクを記述する画期的な技術を思いついた
ユニバーサルリソースロケーティングとマークアップ言語を用いたハイパーリンク技術と名づける
ワープロソフトで書けばいいのに
markdownを使うのはなぜ?
>>16 テキストよりも分かりやすく、プログラミングしやすく、という目的でグラフィカルにするのに、
コネクタ(線)を繋ぐ操作が面倒になるのを仕方ないで済ませたらいかんような気がする
グラフィカルにする目的が他にあれば、繋ぐ操作を犠牲にしてもいいかもしれんが
視覚化するのであれば、ソースコードからUML図でもなんでも生成すればいい。
グラフィカルなコネクタによる接続の問題は、
接続を簡単なコネクタでは表現できないんだよ。
プロトコルがどうであるとか型がどうであるとかインターフェースがどうであるとか。
ブラウザとウェブサーバーは一本の線で繋げられるだろうが、その中で行ってる処理は膨大。
そういった処理や情報をコネクタに加えないと単なる概要図にしかならず動く図にはならない。
動作可能な処理や・情報をコネクタに加えたら、すごく見づらくまた作るのに手間がかかるものになる。
実行可能なソースコード → 簡略化した図
は生成可能だが、
簡略化した図 → 実行可能なソースコード
ということ。
簡略化した図 → 実行可能なソースコード
は、無理ということ。
関数は呼び出す都度に別個で設置するということでいいよ
どうせ関数の外からはマスキングされて見えないんだから複雑になることはない
それよりも基本的なアルゴリズムをグラフィカルにいかに実現するかが難しいな
For文一つとってもコーディングより簡単に表現する方法があればいいんだけど
>>23 >関数は呼び出す都度に別個で設置するということでいいよ
グラフィカルというよりIDEのソースコードの色分けみたいなもんでしょそれ
普通の関数型言語になっちゃう
>>23 > それよりも基本的なアルゴリズムをグラフィカルにいかに実現するかが難しいな
はい、それがフローチャートやPADと呼ばれるものです。
明らかに情報密度が低くく、面積あたりに記述できる
量が少ないので、書くのが大変になります。
グラフィカル言語はエディタを含めて考えないとな
他の関数呼ぶときにいちいち広大なキャンバスをスクロールしなくても
簡単に目的の関数にコネクタを接続できるようにエディタがサポートすればいい
トポロジーを全部表示するモードと特定の関数に注目するモードの切り替えも必要だな
そしてそのうち、全部テキストで書いて
グラフィカルに変換すればいいんじゃね?ってて
発想になる。
それがDOT言語などである。
>>26 Scratch だって本質的にはフローチャートを描いているのと何ら変わらんが、
あれで本格的なアプリを作ろうとは思わんだろ
計算手順を図式化するのにフローチャート以外の方法があるか?
俺は思いつかん。
もちろん、その図からちゃんとマシン語なり中間言語なりにコンパイルするか、
他言語に変換できなければならない。
>>29 典型的な日本人的発想だな
これだから日本からGoogleグラスやiPhoneは生まれないんだ
>>30 そりゃ俺は典型的な日本人だから、こんな発想しかできんのは仕方ないだろ
じゃあ聞くが発想を転換すればいいアイデアが出るのか?
今まではどういう発想だったからダメで、どういう発想に切り替えればいいんだ?
この流れwwww
Q. 永久機関は作れないのか?
↓
A. 無理
↓
>>30 典型的な日本人的発想だな
これだから日本からGoogleグラスやiPhoneは生まれないんだ
とりあえず文句だけ言っとけばいい。
何も言えないならば、文句を言えば、
自分が何も言えないことをごまかせる。上から目線になれる。
>>31 自分で考えろ
ここはお前の自己啓発スレじゃない
ところで
アルゴリズムをグラフィカルに実現するためには、基本的な制御文であるif、for、while、switchなんかはなるべく一種類のグラフィカルユニット?的な何かで表現できるべきだと思う
あとはそれらをつなげて行く形で組んで行けたらいいと思うんだけどどう?
>>34 これお前だワロタw
とりあえず文句だけ言っとけばいい。
何も言えないならば、文句を言えば、
自分が何も言えないことをごまかせる。上から目線になれる。
>>34 Scratchはそれができる
よかったな、理想のグラフィカルプログラミング言語だよ
新しく考える必要はない
>>34 > if、for、while、switchなんかはなるべく一種類のグラフィカルユニット?的な何かで表現できるべきだと思う
だからそれがPADだって言ってるだろ。
お前、過去に語り尽くされたことを知らないで、
調べもしないで語るなよ。
お前、既存のものを何も知らんだろ?
そして既存のものを出したら文句言ってるだけだろ。
ifとか、一行を一グラフィカルユニットにした所で
場所をとるだけだろうな。
実際の所、グラフィカルユニットにしなくても
代わりにインデントと空行を使えば、十分視覚的になる。
40 :
デフォルトの名無しさん:2014/01/26(日) 14:30:37.98
グラフィカルにしたところで、グラフィカルなコーディングはついて回るんだから
>>1 の望みは永遠に叶いそうにないな
41 :
デフォルトの名無しさん:2014/01/26(日) 14:33:52.73
ところで、グラフィカルプログラミング言語で高階関数は作れるんかな
>>42 作れる。
┌──────┐
│任意の文 │
└──────┘
基本的にこの罫線の形を変えればいいだけ。
あとはどんな関数であれ処理であれ
その説明をグラフィカルな図の中に書けば良い。
>>41 視覚化ではなく、その図を書けば完成。
動作可能にならないとダメなんだってさ。
コーディング書きたくないわけだからそういうこと。
>>41 でも大規模な開発には向いてなさそうだけどどうなんだろ
>>44 コーディングを一切排除するのは難しいならあってもいいと思う
でもなくせるなら無くしてほしいって話
あと変数名もめんどうなので無くしてほしい
いちいち新しい変数作るたびに名前なんて考えてられんわ
どうにかならんもんかな
>>46 コーディングというものを二つに分けて考えよう。
文字入力部分と処理部分。
処理部分は処理をなくせない以上どうあってもなくせない。
文字入力部分は代わりに、絵にしようが音声にしようが置き換え可能。
ただし面倒くさい。
嘘だと思うのなら、バラエティ番組を思い出せばいい。
一人が問題の答え(文字)を絵でかいて、もう一人がなんて文字か当てるというやつ。
48 :
デフォルトの名無しさん:2014/01/26(日) 15:44:38.58
>>46 全部アドレスで指定するってこと?
それの管理が面倒だから変数名って概念があるんだが…
>>46 お前の言ってるのは、「面倒くさい」んじゃなくて、
「出来ない」なんだよ。
コーディングすることが「できない」
適切な変数名をつけることが「できない」
単なる能力不足。
簡単な例えで申し訳ないけど
例えば1から100までの合計を求める処理を
Excelを使って求めようとした場合殆どコーディングを必要としないし変数名も使わない
あれは広い意味でいうとある種のグラフィカルなプログラミングと言えると思う
ただ応用範囲は狭いから汎用性はないってだけで
ExcelといってもVBAのはなしじゃないぞ
>>50 だからそれ、めんどくさいよね?
基本的に素人用の道具って
「プロ用の道具+技術」に比べたら
面倒くさくて遅くて柔軟性がないんだよ。
たとえばプロの料理人だったら包丁でかつらむきを
高速にできるだろうね。でも素人だったら無理だし、
包丁渡されても技術がなければ遅い。
つまり君はまだ「プロ用の道具」しか渡されてなく
技術がないからそういう話をしてるんだよ。
>>50 計算式を使わないで、1から100までの合計を出すコードを
愚直に書くならこんな感じか
var sum = 0;
for(var i = 1; i <= 100; i++) {
sum += i
}
これをエクセルで書くとしたら、1入力して、2入力して
1、2を選択してずずーっと引っ張ると3, 4, 5・・・と埋まっていくから
100の所で止めて、そしてセルを選択して、sumボタンを押す。
こんな感じかい? 面倒くさすぎw
たぶんこの説明でわからない人もいるだろうね。
コーディングを必要としないが、面倒くさくなってるよね?
>>52 プロ用の技術がめんどくさくて遅くて柔軟性がないならみんなC言語なんて使わないでアセンブリ使ってんじゃないか?
>>53 確かにExcelだとその操作がネックになるよな
なんとか新しいグラフィカル言語作ってできないものかな
まあ無理ならいいけど
55 :
デフォルトの名無しさん:2014/01/26(日) 16:32:11.55
あげ
>>54 言語の違いは、ふさわしい適用範囲が違うだけ。
どれもプロ用。
yahoo pipes がそれっぽいなと思った記憶があるな
もう何年も前だけど
新しいグラフィカルプログラミングに求める要件
・開発期間を大幅に短縮できる
・可読性が半端ない
・処理速度は遅くても気にしない
誰か作って
>>56 どれもプロ用ってことはないでしょ
たとえばbrainfuckのプロとしてふさわしい適用範囲って何?
>>59 批判するしか脳のないバカなんだから相手するなよ
OSもCLIしか認めないんだろうか
グラフィカルなツールが出てからプログラマの
レベルが下がった事は考慮にいれないの?
63 :
デフォルトの名無しさん:2014/01/26(日) 17:06:26.75
MacOSXにAutomaterっていうのはある
比較的グラフィカルではあるけど…ちょっと混みいった話になると
やっぱりシェルスクリプトやAppleScriptに頼ることになるんだよなぁ
つ カルネージハート
DSLとして割りきるなら、グラフィカルなプログラミングも現実的だと思うよ。
複雑な処理は専用モジュールとしてあらかじめ作り込んでおけばいい。
けどなんか結局複雑なパズルみたいになりそうな予感
結局操作方法が変わるだけで、コーディングには違いないだろうしな
>>1 がそういうDSLで我慢できるなら、これで完了だね
JP1/Scriptじゃダメなの?
>>62 本来の意味でのプログラマじゃないよな
事務屋さんがコンピュータ使ってるだけ
グラフィックは文字よりも書くのに手間がかかる。
ただしコードのグラフィック化(可視化)は意味がある。
だけど、それはコードの情報を減らして重要な部分のみを可視化するというもの
だから可視化されているものから、動くコードを作るのは不可能。
実際に動くレベルの情報をグラフィックにすると手間がかかる。
よってグラフィカルなプログラミング言語というのは
開発可能だが、効率が悪い。
まあこういう結論。
>>69 そう思います。
自分は学生時代はBASIC・FORTRAN・Cを、就職した後は
汎用機を任されたので10年程COBOLをやりました。
特に、就職してからは色々なプログラマと仕事しましたが、
最近プログラマになった人は(キツイ言い方すれば)本来
プログラマになるべきでない様なプログラマに向いてない
人がプログラマになった感じの人が多い気がします。
色々理由はあるんでしょうが、長い不況でとりあえず職を
探したらそれしかなかったとか、流行でなったとか。
そもそも前提から間違っている
隅から隅までグラフィカルじゃなくて
要点を絞ってここをグラフィカルに出来れば大幅に効率アップ!
ってのを探るのでなければ先に進みようが無い
GUIアプリのポトペタとか
ツクール系ゲーム開発のマップエディタとか
> 要点を絞ってここをグラフィカルに出来れば大幅に効率アップ!
だからそれがないんだよ。
グラフィカルってのは理解しやすくなるが、
文字に比べて情報量は減ってる。
見るときや理解するのにはいいけど
書くと効率は下がる。
だからコードを可視化するツールがあればいいのさ。
おまえらツールたくさんあるのに知らないだけじゃねーの?
CADで書いてた回路図はほとんどが言語で記述されるようになった
>>75 そしてたくさん知ってる君が答えるわけだね。
>>1 によると、求められてるのは新しいグラフィカル志向だから、古いのじゃだめなんだよ
マジレスするとこの分野で最も成功しているのは普及率・完成度ともにFile Makerだと思うんだわ
プログラミングのぷの字も知らないような、おっさんが自分でかなり使いやすいツールを作ってたりする
ファイルメーカー社の仕事は、もっと評価されていい。自分じゃ使わないけど。
いや、そのFile Makerを作るプログラム言語を
グラフィカルにしたいって話でしょ?
Cに相当する部分をグラフィカルにしたいのか
そりゃ需要ないから無理じゃね
これこれこういう理由でこういうものが必要なんだという要件を明確にしてもらわんとね。
ドラえもん全部できるもの出してよって発想からは何も生まれない。
Javaはかなりグラフィカルなツールでてるじゃん?部分的とはいえね
そういうの組み合わせていったら、コード書く部分は相当減るんじゃね
100%コードをなくしてしまうのは効率が悪くなると思う
>>82 > これこれこういう理由でこういうものが必要なんだという要件を明確にしてもらわんとね。
だから、何かがしたいんじゃなくて、
俺、コーディング書けない。書く技術力がない。
→ 書かなくていい方法ない?
って話なんだよ。
本質的には、技術力不足が原因なので
コードを他の何かに変えても、出来ないものは出来ないだろうね。
グラフィカルに表すことができる処理のコーディングなんて最近の言語使えば楽勝だろ
構文解析とは違う何か新しい革命が起こらない限り無理だな
全部できるもの出せって言われたらドラえもんはしょうがなく覚醒剤を出すかもしれない。
グラフィカルの意味を教えてくれ
そういえば子供の頃夢想したなあ
レゴブロックに小さな機能をつけたようなパーツをいくつか用意しておいて
PCの画面でゲーム感覚でそれを組み立てるとどんな複雑なプログラムもかけるという空想
理屈の上で可能なのか不可能なのかよくわからんまま忘れてたらおっさんになってしまったな
まあ今思い出したから今でもよくわからん
>>90 似たようなのはあるよ
マインドストームで検索だ
>>91 おお、サンクス
名前は知ってるがあれってブロック組み合わせてロジック作成できるのだろうか?
PC上でコード書いてマイコンに送り込んで制御するものだと思っていた
出きるなら面白そうだな
ちょっと検索してみよう
>>88 それ前から思ってたんだが、テキストで書くのとの本質的な違いってどこにあるんだろ
単にアルファベットや単語の形がブロック状に変わって色がついただけのような気がする
やってることは「なでしこ」なんかと同じじゃないかな
むしろ文字だけの方が分かりやすい
本質的に同じでも、なんか楽しけりゃいいと思うよ。
>>92 ああ、ごめん
そういうのはできない
中心となるプロセッサとメモリと電気制御をするデカイパーツがあって、そこからケーブルを伸ばしてモーターやセンサーを使うってやつだ
>>96 ありがとう
今見てるんだがこれはこれでワクワクする感じだなあ
子供が出来たら買ってやろう
その前にパートナーを検索しないとだが・・・
98 :
デフォルトの名無しさん:2014/01/26(日) 22:31:32.38
例えばWin32APIでSendMessage(HWND,MSG,WPARAM,LPARAM)ってのがあるけど、
HWNDにウインドウハンドル書かずに矢印で対象ウインドウに線引っ張ったら分かりやすいし、
ウインドウハンドルとかいちいち書くかなくていいよね。
MSGもアイコンだと視認性が上がるよね。
WPARAMとLPARAMもどうせ何かの変数だよね。
そしたら、SendMessageって四角形にMSGのアイコン付けて、SendMessageって四角形の中のWPARAMとLPARAMには変数から矢印を引っ張って、
SendMessageって四角形から対象のウインドウに矢印引っ張るといいよね。
グラフィカルなプログラミングは
できるできないでいえば出来る。
ただし効率が悪いので使わない。
>>95 ごめん、Scratch はまさに「なんか楽しい」というのが第一の目的だからいいんだが、
たぶん
>>1 の目的には合わないだろうなぁと思った。
>>98 そのレベルで矢印を引くとなると、文字通りスパゲッティコードになるのが目に見える
デバッグやテストも描きにくいだろうし
103 :
デフォルトの名無しさん:2014/01/26(日) 22:38:31.26
unix派はコマンドラインに固執してコマンドラインの方がGUIより効率が良いという信念は今も変わらないじゃないのかい?
Flashなんかはタイムライン間にグィッとオブジェクトを動かせばスクリプト組まなくてもトゥイーンできたけど
条件によって動く方向やスピードを変えるというのになると途端に複雑なタイムラインを作る必要が発生して
結局ASで制御した方が楽でメンテナンス性も良かったりしたな
だから使い分けだろ
今は選択肢すら無いって話をしてるんだろ
使い分けもなにも結局複雑になるんだから
そもそも用途が無い
どこで使うんだよ
選択肢がないのはそれが使い物にならないからよ
選択肢が無いなら新しく作ればいいじゃない
今になっても出てこないってことは作る価値がないと判断されてるんだろ
111 :
デフォルトの名無しさん:2014/01/26(日) 22:52:46.34
>>110がこれから世に出回る全ての製品と全ての概念と全ての技術を否定しました。
馬鹿が楽してプログラミングしようとしても無理ってこったw
>>101 > ソースはOSの操作
今はOSの操作の話をしてるんじゃないよ。
プログラミングの話。
くんくん、権威主義に凝り固まった老害のニオイがする
まぁやっぱり
「馬鹿には無理」
ちょっと手続き型の概念から離れたら
GUIエディタもあるし
Flash、HTMLエディタ、
データベースエディタもある
UMLからコード生成したりもできる
プログラミングの役割はGUI付きツールに確実に侵食されている
>>105 プログラミングで一番多く実行する
関数の実行をどうグラフィックにするんだ?
たとえば、hoge(1234)を
グラフィックにするって話だよな?
今俺は、キーをたったの10回タイプして、
hoge(1234)って書いたわけだが、
これをグラフィックにして、手間を減らせると思う?
>>116 それって、一番重要な処理は
なにも作ってないんじゃね?
それで作ってるのはインターフェース部分だけでしょ?
本格的に3D空間にものを自在に表示できるようになったら、プログラミングの技法も若干変わるだろうよ
それまでは今と一緒だな
機能を可視化する方法は一通りではなく、より機能を正確かつ直感的に伝える可視化方法が求められる
コンピュータプログラミングは誕生してから時々刻々と新しいパラダイムが誕生しては消えを繰り替えし
未だ進化の途中にある
古くはシングルタスクのストレートフォワードなコードから始まり、関数や構造体による構造化、オブジェクト指向の台頭
GUIの一般化によるイベントドリブン型プログラミング、インターネットの普及によるウェブプログラミング
複数コアのCPUを効率的に使うためのコードの並列化、そのうちくるであろう量子コンピューティングなどなど
(適当に思いついたのを並べただけでグラフィカルプログラミングとの相性やそれぞれの概念の大小については何も考えてない)
おそらくどこかの時点でグラフィカルな言語を開発したとしても次の概念が来た際には大幅な修正や設計のし直しが求められる
PCの進歩、プログラミングの進歩が止まるまでは教育目的の簡単なものが出るに留まるんじゃあないか?
グラフィカルになったとしても、複雑な電子回路みたいな表示になりそう
複雑な電子回路は言語によるプログラミングで作られてるよ
>>50にあるような
Excelのアイデアを利用できないかな
改良を加えれば操作性はいくらでも改善できると思うし
基本的なアルゴリズムの構文なら再現できそうだよ
>>123 1から100までの合計をExcelで出そうとすると
面倒くさいんだけど、これじゃ使いものにならないでしょ?
実行中のプログラムのメモリ配置をてグラフィカルに描画するツールないの?
insightあたりはUIがウンコだから論外
>>126 > 実行中のプログラムのメモリ配置をてグラフィカルに描画するツールないの?
デバッガ
>>125 Excelをつかうんじゃなくて
新しいコーディング手法に応用できないかと言ってるんだよ
>>128 デバッガの描画と操作性でイケてるものって?
Excelは関数型言語だぞ
>>129 だからなんで、面倒な方法を使おうとするんだよ?
文字のほうが少ない労力でできるだろうが。
視覚化が便利なのは、全体の概略、設計を把握するときだけだよ。
>>132 表計算に関してはプログラミングするよりExcel使った方が効率いいんだが
>>133 俺も写真にフィルター処理をする際にはプログラミングするよりもフォトショップ使った方が効率いいと思うぜ
書くときだけを考えるから面倒なんだ。
実行時のフローを追ったり、排他制御や並行プログラミング、
リファクタリングまでグラフィカルにできると考えたら、ずっと効率が良い
>>134 > 俺も写真にフィルター処理をする際には
そのフィルター処理を作る場合の話でしょ?
あんたが言ってるのは単に画像に作ったフィルタを適用してるだけじゃん。
効率求めてマクロにするのはプログラミングだよね
>>135 訂正しておくね。
×リファクタリングまでグラフィカルにできると考えたら、ずっと効率が良い
○リファクタリングまでグラフィカルにできると考えたら、ずっと効率が良いと思っているが、根拠も無いし証明もできない。悔しい!
学研の電子ブロックでグラフィカルプログラミング!
>>136 横レスするが、
Excel(もしくは相当する表計算ソフト)が存在しない世界を想像してごらん
表計算ソフトが無かった1970年代、誰もが表計算が必要になるたび、
BASIC、PASCAL、COBOLなどでいちいちプログラムを組んでいた
143 :
デフォルトの名無しさん:2014/01/26(日) 23:53:01.53
カプセル化した内部をグラフィカルには難しそうだな
結局ここは文字で組むしかなさそう
145 :
デフォルトの名無しさん:2014/01/26(日) 23:54:16.89
>>137 表計算ソフトにはセル同士の値を計算する処理があらかじめ作られてるんでしょ?
あんたが言ってるのは単に打ち込んだ数字にその処理を適用してるだけじゃん。
>>145 見せる見せないじゃなく、プログラミングするのに必要な部品をどう作るかということ
これが無いと完成しない場合はどうなる?
グラフィカルが無理な箇所だから組むしかねぇだろ
なんかずっとずれた回答してるよなお前
148 :
デフォルトの名無しさん:2014/01/26(日) 23:57:16.15
>>147 おまえ、Smalltalkとかしらない入門者だろ
>>142 なんの話してるんだ?
ExcelがExcelで作られてるというのならわかるが、
処理の部分はグラフィックに作る理由がないんだよ。
開発効率が悪いから。
>>141 それ意外に面白いかもな。組上がったロジックをPCにセーブできると。
いや〜楽しそうです。
プログラミングでもエクセルでもどっちでもできることを
エクセルでやる人ってのは、
単にプログラミング技術がないからだよ。
文字で書いたほうが早いが
そもそもそれが出来ない人は
ツールを使うしかあるまい。
ようするに
>>1は自分の技術力がないから
それ以外の方法を探しているだけ。
それが非効率なものであっても、
プログラミングが出来ないから、どうしようもあるまい。
>>149 じゃあ開発効率のいいグラフィカルプログラミング言語を作ればいいじゃん
処理の部品が膨大にないと出来るものが限られるんじゃね?
シンプルな処理の組み合わせをするなら結局はコード書くのと同じ位グチャグチャなグラフィックになるだろうし
>>149 それって、単純な処理だけエディタから書けるようにして、
グラフィカルなUI部分では隠蔽しとけば良いだけちゃうん?
そもそもラピュタだってブロックから出来てたんだぜ。宮崎駿の先見性と直観力は信じられる。
157 :
デフォルトの名無しさん:2014/01/27(月) 00:06:51.56
>>152 1だけど正直コーディング歴は20年のベテランです
Webアプリでもゲームでも何から何までなんでも作れます
処理の順番を文字で書くのも、絵で描くのも本質的には変わらないと思うんだが…
キーボードを打つよりもマウスを動かす方が手間が多いというだけで
ただの老眼だろ
>>158 Smalltalkライクな環境を作り、公開してはじめて、そのレスは意味を持つ
emacsなんかと比べるとVSはかなりグラフィカルだ
SmalltalkといえばSqueakなんてものもあったな
これをベースに拡張していけばいいもの出来んじゃね?
素人レベルの作業だと、どう考えてもemacsの方がはやい
UMLから派生させるのは無理?
167 :
デフォルトの名無しさん:2014/01/27(月) 00:44:34.02
>>166 ありだと思う
あとはもう少し細かいアルゴリズムの表現力をつけたいが
169 :
デフォルトの名無しさん:2014/01/27(月) 01:09:34.32
スレチで申し訳ないんだけど、
グラフィカルな開発環境より、全ての言語の中間のような言語が欲しいかな。
それそのものは実行もコンパイルもできなくていいから、好きな言語にエクスポートできるやつ。
言語間の相互変換は試みられてるけど、完全ではないし、できないものもある。
だから最初から変換する前提で設計された、仮に「XXX言語」とでも呼ぼうか、があるといい。
言語が違うってだけで一度書いたアルゴリズムをまた書くのはうんざりだ。
XXX言語は好きな言語にエクスポートしてから使うが、開発者はXXXの文法を学ばなければならない以外は今まで通り開発できる。
C言語でコンパイルしたいのなら、コンパイラのパスを通しておけばエクスポートからコンパイルまで自動でやってくれる。
JavaScriptへだろうがJavaへだろうがボタン一発でエクスポート。
haxe
>>153 > じゃあ開発効率のいいグラフィカルプログラミング言語を作ればいいじゃん
ないよ。っていうかグラフィカルプログラミングの定義上、
グラフィカルでなければならないよね?
文字も絵と考えれば、グラフィックなんだ。あとはそこに載せられる情報量の話。
緻密で複雑なグラフィックである文字の方が情報量が多いのは言うまでもない。
まあドット単位で正確に絵を書くというのならば、文字よりも多くの
情報量を入れられるだろうさ。大変すぎる作業になるのは明らかだけど。
それで「あ」という文字をキーで入力するのとこれを絵として
マウスでもペンでもいいけど書くのはどっちが時間がかかるかい?
結局のところ、こういう話。文字のほうが早く入力できるんだよ。
>169
前に同じアイデア、2ちゃんねるに書いたな。
スレ立てた気もする。
.netもparrotも失敗したよ
この世界では規格なんてものは大嘘で、実際に手に入る実装こそが真実
デファクトな中間言語のようなものがjavascriptだとしたら、
javascriptで書いた方がはやいって考えるような世界
>>171 死ねゴミクズ。おまえなんて、この世界に生まれてくるべきじゃなかった
>>171 グラフィカルだからってキーボードを一切使わないという訳ではないだろ
百歩譲って効率が少し劣ったとしても
視認性や再利用のしやすさの面で優ってたら利用する価値はあると思うけどな
>>173 JavaScriptいいよね。なんて言ったらいいかよくわからないけど、
JavaScriptはとても外部の環境に影響されない言語なんだ。
例を出すとC言語。実はC言語にはディレクトリという概念がない。
それはディレクトリがないOSもあるわけで、C言語標準には含めなかった。
他の言語には標準的に搭載されているスレッドとかネットワークアクセスとかも。
JavaScriptはそれよりも更に進んで、ファイルアクセスというものすら存在しない。
CPUだけで処理できるような計算処理だけに制限された言語なんだ。
もちろん外部ライブラリを使うことで計算以外もできるけどね。
>>175 > 視認性や再利用のしやすさの面で優ってたら利用する価値はあると思うけどな
視認性ならコードを視覚化すれば良い。
再利用のしやすさは、コードで書いても同じ。
178 :
デフォルトの名無しさん:2014/01/27(月) 01:31:07.67
ブラウザ上ですら互換性ないのにバカじゃねーの
>>178 今は普通にコンソールで実行できる。
>>179 互換性問題は複数の実装があれば
どの言語にも存在する問題。
何に反論にもなってない。
>>181 コードをそのまま視覚化するんじゃなくて
コードの構造を視覚化するんだよ。
どこがどう繋がっているとか。
でもそれは元のコードのつながりだけを抽出したもの
到底動くレベルにはならない。
ここまでMELなし
LabViewと並んで一度使ってみたい言語だった
>>72 一時期、職安ではプログラマを勧めていたし
そういう職業訓練を受けると特典をもらえた時期があった
185 :
デフォルトの名無しさん:2014/01/27(月) 02:57:53.08
関数型言語限定の話になるけど、構造というか、効率化と可視化はもうちょっとしたいね。
プログラミングつったら関数をいっぱい書いていくけど、自分で書いた関数一覧がIEのお気に入りみたいに右側にアルファベット順に自動で表示されて、
クリックするとキャレットのところに自動で挿入される感じとか。
あとはコードの特定の部分を関数化しようとおもってコピペしたら、自動でその部分の変数が宣言されて関数名の入力ポップアップが出るとか。
宣言したクラスや構造体変数を書いたらすぐ横にメンバ一覧が出るとか。
お気に入り一覧以外に履歴一覧もあって、他のコードで使ったコードの関数もそこに出てすぐ使えるとか。
それがさらにオンライン対応になって、企業や特定のコミュニティ内で再利用できるとか。
もちろんヘッダまで遡って自動インクルード、自作のヘッダでもインクルードする。
関数型言語限定の話っていうからなにかと思ったら、
関数型言語でできる話じゃなくて、
静的型付け言語なら普通にできることが
できてないから、関数型言語限定の話って言ったのか。
187 :
デフォルトの名無しさん:2014/01/27(月) 03:07:00.37
え?
頭の中にはC言語があった。
C言語使うことが多いからC言語でそうやって組めたらいいなという妄想だ。
ちゃんとしたIDE使いなよ。
関数のリストは表示されるし、
クラス・構造体は、.や->を書いたらリストが表示されるし、
コードの特定の範囲を関数にするって、
それIDEに備わっているリファクタリングツールの機能の一つじゃないか。
>>180 node.jsなんて今日日じゃ常識レベルなのに、
javascriptにはファイルハンドラがとか、おまえバカだろ
>>189 JavaScriptにファイルハンドラないよ。
nodeはJavaScriptという言語仕様の一部じゃないからね。
>>171 ペンで書いた「あ」が一文字で何種類の情報を表現出来ると思う?
上の方の関数を線で繋ぐ話がすごく興味ある。
線がゴチャゴチャするだろとか批判あったけど、ネスト・階層(gui風に言うならレイヤー)があれば良いだけの話で
それが上階層に行けば最終的にはフローチャートになる、なってなきゃおかしい
で、ギターのコンパクトエフェクター繋ぐ感じとか、DTMのミックスダウンソフトみたいにデータの流れと関数(エフェクター)をgui管理出来たらメチャ楽だと思うんだよね
アイディアのある人は是非作ってくれ。
どれも使いにくい
それよりuml描くだけでコードに変換してくれるツールの方が良い
>>191 言語仕様にファイルハンドラって意味が分かりません
例えばJavaやC#の言語仕様にファイルハンドラってものはあるんですか?
>>193 関数を呼び出すたびに関数を定義している場所までコネクタを引っ張るなんて発想は
なにかしら図面をみたことがあるなら出てこないはずだよな。
ICや機能ブロックを組み合わせた回路図で、図面の端っこにICの定義が書いてあって
そのICを使うたびにそこまで線を引くとか、そんなことはありえない。そこは名前参照するだろ
グラフィカルのいいところは一次元の文字列ではなく二次元に自由に並べられるところだとおもう。
条件分岐が複雑になったときや、関数に渡す引数の前処理が多段になったときに
どこからきた値がどの分岐、あるいはどの関数のどの引数に影響するのかということを
単なるインデントではなく二次元に配置すると見通しやすくならないか?
ワイドモニタ向きだともおもうんだけどな
あつかうデータ型が描画要素とか音形とか限られていると比較的作りやすいんだよね
多様なデータ型があって、処理も多様だと、とたんに処理系を作るのが面倒になる
気がする
一度作ろうとしたことはあるけど面倒になったw
なにが面倒って使えるライブラリをそろえるのが面倒くさい
Win/Macの標準GUIやDBアダプタが標準化されてるLLがあれば核にするんだけど
・・・と妄想してもう10年近く放置してたりするww
ここに書いとくと誰か作ってくれそうだから昔考えたアイデアを書いとく。
グラフィカルにするとレイヤーを扱えるようになる。もちろんテキストでもできるんだけど。
たとえばデバッグコードやトレースポイント(プローブ)を通常のレイヤーに重ねて垂直に結線する
処理前後の値の相関図をデバッグレイヤーにグラフィカルに表示したり、ログを取ったあと、
不要になればデバッグレイヤーを切り離せば通常動作する回路になる
元のコードを読むときははデバッグレイヤーを不可視にすると本来のコードを読みやすい
中間データをシグナルインジェクター的に流し込んでもいいとおもう
デバッグじゃなくてもちょっと試しに改変したりパッチを当てるときにも
元のコードがまるまるそのまま下のレイヤーに残っているというのが便利
どんなプログラム言語で書いても
最適化の前にはデータ構造としての「グラフ」に分解されて実行されるんだから
最初からグラフィカルに書けばいいとおもうのん。
頭のいい人には関係ないことだけどコネクタを使うと中間変数を省略できるから
数字の逆唱を5個とか7個しかできない凡人にはグラフィカルにするメリットがある
かもね
vimやSublime Textなどの高機能エディタが
IDEより生産性が高くなってしまったので、
IDE復権のためにグラフィカルな言語の登場が待ち望まれるね
いきなり大規模なもんはできないだろうから
とりあえず小規模な基本的なアルゴリズムが組めるものを考えてみよう
>>193 線をつなぐのはいいんだが、それをグラフィックでやる意味が無いだろ。
関数A → 関数B
ほら、関数を線でつなぐことが出来た。
ループはどう書く?
>>205 for(i in data) {
hoge(i)
}
これを絵で書いたら分かりやすくなる書い?
あたりまえだけど、iとかdataとかhoge(i)といった
情報を捨ててはいけない。
値を全部リストにする
>>206 i→data→hoge
はいできた
解釈は各自好きなようにやってくれ
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
J言語をグラフィカルにしてください
>>206 だと
→ for
しか書けないよね。線の中身がdataで、後はforの下のレイヤーになる。
入り口と出口があってそれぞれに意味を付けられるようなのじゃないとあんま使いではないのかも
file1 →↓
file2 → [ diff ] → stdout
こんなのだったら使いやすそう。ファイルの結線を変えて比較したり[diff]にツマミが付いてて、それを回すと出力形式変えられたり。出力線を足して差分取ったり。それをまた[diff]に結線したり。
csv
↓
[ awk ]
↓→ column1
↓→ column2
↓→ column3 → [ sed ] → ‥
こういうのとかも
コードを図で書くのって難しいな。
図ってのは、頭のなかに描く分には自由だが、
PC上で扱うとなると、位置と大きさがあるせいで
意外と抽象化の役に立たない気がするよ。
つーか邪魔になるレベル。有り難みがない。
むしろ抽象化度が低くて凡人にもわかやすい
現代人が世界共通で使っている数式はオイラーからニュートンまでのそうそうたる天才達が一般化したもんだから
凡人の浅知恵じゃ超えられないよ。
ライプニッツによって定義された関数を初めてy=f(x)の形で表したのもオイラーである。
wikipediaより
既存の構文をいかにグラフィカルにするかという考え方だと新しいもんはできないな
要は問題をいかに解決するかが重要なんだから
例えば簡単なアルゴリズムの問題集なんかから問題を見つけてきてそれをいかにグラフィカルな手法で解決するかを模索してみた方がよっぽど発展性あるかも
簡単な数式や小さな構文は文字で書いてあったほうが理解しやすいけど
関係する要素が増えてくるとグラフィカルにしたくなる
構造が簡単で入出力いずれかの数が多い
>>211-212あたりがグラフィカルに向いているとおもう
並列に並ぶ要素が増えるくらいなら束ねることで閲覧性を保てるけど
構造が網目状に入り組んできたら数式でも図形でもどちらでも難読になるね
自分は汎用機のプログラマ(コボラー)なんで、
便利な開発ツールなんて殆どありません。
汎用機からCOBOLのソースをftpで取り込んで
テキストファイルにして秀丸などで修正とか。
だから、汎用機以外で使われているPC系の
ツールを見ると結構羨ましい。
edit画面で、ifと打ち込んだらすぐ下にend-ifと
表示されるたりするツールを見た時はびびりました。
>>219 > 関係する要素が増えてくるとグラフィカルにしたくなる
正確に言うと、グラフィカルに ”見たくなる” でしょ?
グラフィカルなプログラミング言語は
書いたものがそのまま実行可能にならなきゃいけないけど、
実行可能なレベルまで書き込むと、画像では場所とりすぎで逆にわからなくなるよ。
>>222 わかりにくくなる、で済ますのではなく
いかにすれば使いやすくなるか考えるのが真の開発者だ
>>224 > いかにすれば使いやすくなるか考えるのが真の開発者だ
じゃあお前が考えろよw
文字というのは特定の形のグラフィックを
使いやすいように定めたもの。
象形文字という絵から文字が生まれた。
そもそもグラフィックをいかにすれば使いやすくなるかを
考えた結果、文字になったわけで、話がおかしいんだよ。
「リンゴ」って三文字書くのと
リンゴの絵を書くのと、
どちらがわかりやすいかという問題だな。
色つきでないとリンゴと梨の区別がつかないな
「赤いリンゴ」を表現するために
何秒で出来るか競争してみようぜ?
おーっと、ここで青リンゴの登場だー
文字って凄いよな。
たったの数回キーを叩くだけで
表現できてしまう。
これを図で書く?
アホだろw
233 :
デフォルトの名無しさん:2014/01/28(火) 23:00:30.51
class ringo{
iro=COLOR_RED;//色(赤)
omosa=300;//重さ(グラム)
suibun=95;//水分(パーセント)
amasa=15;//糖度(度)
}
ね、文字だと簡単でしょ?
リンゴみたいに具体的な形があるやつなら
まだグラフィックにするメリットがわかるんだが。
ソート処理をグラフィックにするとして
どんな形になるんだ?
バブルソート、クイックソート、シェルソート
この違いをどうやってグラフィックにするんだろうか。
文字の周りを罫線で囲むだけじゃなんの意味も無いよ。
そう、コードっていうのはグラフィックにできないんだ。
>>232 3文字だと文字でも困らないな
でも小説と漫画を比較すると断然漫画の方が視認性高い
>>234 大学の教授は大体絵に書いて説明してるぞ
色は良いよね。アイコンに近いのかも。
ディレクトリが用途とかで色分け出来たら良いのになあと思った事が何度もある。
それとディレクトリだったら、単に時系列でソート出来るだけじゃなくて、例えば使用頻度の高いファイルやディレクトリは大きく、そうじゃないのは小さく表示するとか便利だと思う。
あと平面のウィンドウが実は立方体で、ディレクトリ一覧をグルっと横に回すと中身が見れたり、タグ付けされた奥行きの情報が見れたりとか、一杯やりたい事ある。
技術が追いつけばねぇ…
>>235 > でも小説と漫画を比較すると断然漫画の方が視認性高い
だが書くのに時間がかかるだろ?
コードを視覚化するのには意味があるんだよ。
だけどその視覚化されたものには、コードの全ては含まれていない。
もしコードの全てを含ませようとすると、それは巨大になり
そして作るのにもかなりの時間がかかる。
だから視覚化されたコードは、コードの一部の特徴を表したに過ぎない。
それは実際に動くプログラミングにはなりえない。
(不可能ではないが時間がかかりすぎるため、教育用として小さいコードを書くのが精一杯)
ぶっちゃけていえば、
絵っていうのは、馬鹿に説明するためにある。
小説とマンガの関係も同じ。
>もしコードの全てを含ませようとすると、それは巨大になり
>そして作るのにもかなりの時間がかかる
そのためにコンピュータがあるんだろ
人間は指示をするだけ
コンピュータは指示を受けてルールを構築していくだけ
出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
ただ文字だと見にくく、絵だと見やすいというだけの話
>>234 『大人のピタゴラスイッチ』でクイックソートを動画にしてたぜ
プログラムの視覚的全体像をみたい余り文字を通常の1/10に小さくしている人居たけど
文字の形がほとんど判別できないのなw
視力に頼りすぎているそいつはプログラマとしての寿命は短いだろうなと思った。
目が悪くなったら画面を大きくすればいい
>>242 ドコが見やすいのか、
バブルソートを絵にして説明してくれ。
もちろん、動かないとダメだぞ?
247 :
デフォルトの名無しさん:2014/01/28(火) 23:57:53.16
━━━━━━━
in →┃バブルソート┃→ out
━━━━━━━
>>247 バブルソートって
文字でかいてるなw
結局、文字が一番適切に説明できるんだよw
バブルスライムの画像を使えばどうだろう。著作権違反かな。
>>248 勝手に文字禁止なルールにするなw
グラフィカルなOSにも文字は使われてるんだぞ
バブルスライムの画像で
バブルソートが実装できるのか?
>>250 いや、だって
>>247って別に罫線いらないじゃんw
文字だけで十分なのに、
それを絵にする意味ってなんだよ?w
253 :
デフォルトの名無しさん:2014/01/29(水) 00:07:10.36
いやバブルスライムをクリックすると胃袋が2つに分かれて再帰的に反芻してソートして排泄するのがわかるとか。
グラフィカルに表現する利点は複数の要素の関係性が表現しやすいという点だろうな
でも関係性が増えると線が多すぎて逆に見にくくなってしまうというジレンマが・・
構造化プログラミングのせいだな
文字はグラフィックの一部だ、グラフィカル言語は文字を使ってもいい
むし抽象度や粒度を適切に制御するために文字の混在は推奨されるだろう
現実の問題で関係性が複雑すぎてグラフにするとわからなくなるようなものはあるのだろうか
コードの複雑性を隠すために条件分岐文を折りたたむという方法があるけど
あれって全体の構造をみて必要なところだけ折りたたまない実装はあるのだろうか
現実的にはファイルを分割するという形でプログラマのコントロール下に置くことになるのかな
グラフで表現するときはこういった折り畳みはその図面の中で行われるのだろうか
ダブルクリックすると機能ブロックが開いて詳細実装をみることができるとか
ズームするとグーグル地図のように詳細図に切り替わるとか
259 :
デフォルトの名無しさん:2014/01/29(水) 16:46:31.19
>>7 LabViewでプログラム書いてみ。
あっという間に使う気が失せるから。
>>193 データの流れをGUIでプログラムできる環境はたくさんある。
261 :
デフォルトの名無しさん:2014/01/29(水) 21:27:14.72
このスレがなんか一番ソフト工学してるな
グラフなら、コードの中のある変数や引数に注目して
その祖先や子孫をあぶり出し表示するのは簡単だな
テキストで同じことをするにはどうするんだろう?
>>262 何か勘違いしてそうだから言っておくけど、
コード(文字)をグラフィックに視覚化するのはいいんだよ。
これが見やすい(場合がある)ことは否定していない。
ただしコード(文字)を書かずに、最初からペンかマウスかで
画像を書いてプログラミングするのは効率が悪いという話
コードの一部(例:変数に着目して視覚化)をグラフ化するのは
何も問題がないが、最初からグラフを書くことでプログラミングなんかしたら
大変きわまりないだろ?
流れは矢印で書くほうがわかりやすくてはやいよ
詳細はコーディング
JP1/Script形式が最強だろ
もうちょい言語側がパワフルになってほしいけどな
アルゴリズムもグラフィカルにしたほうが効率いいだろ
今のままでも十分視覚化されてると思うが
比較する対象がないからだろ
ガラパゴス携帯しかない時代の人間がガラパゴス携帯が一番使いやすいと考えてるようなもんだ
だれか僕にもできるの作ってどらえもんってこと?
>>268 もっと作業効率あげれる未来の道具出してよドラえもんってことだよ
ま、タブレットとかスマホでプログラム作れる環境は欲しい。
AndroidもiOSもCのコンパイラとかPythonとかあるだろ
キーボードを見捨てた時点からあなたは無能である。
落書き見たいにプログラミングできたら楽しいだろうな
>>269 効率を上げるために絵から文字が生まれたのに、
絵に効率を求めるなんて愚かだな。
絵は見るのにはいいが描くのは大変だ。
>>274 なんでそんなに文字だけにこだわるんだ?
文字自体もグラフィカルな表現の一種なんだが
何か不都合でもあるのか?
見る側からすれば、文字だけの文より図や絵が入ったほうが
見やすいのは明らか
その図や絵を自分で書くという発想さえ抜かせば
文字よりも図や絵でまとめあげたほうが楽という感じだろうな
まぁ、出来るもんなら作ってみろって感じ
そのためにコンピュータがあるんだろ
人間は指示をするだけ
コンピュータは指示を受けてルールを構築していくだけ
出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
ただ文字だと見にくく、絵だと見やすいというだけの話
>>275 なにか不都合がって、
最初からプログラミングを
画像でやるのは不都合だって言ってるじゃん。
100種類のオブジェクトがあるとして、
文字なら100種類の識別子をつけられるけど
100種類の絵で識別するのは困難。
絵だと見やすいのは幼稚なオモチャに限られる。
>>277 > 出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
> ただ文字だと見にくく、絵だと見やすいというだけの話
いやいやw 支持を絵でやるのが難しい(時間的に)って話だろw
紙芝居で作業指示書を書いてみ?
なんなら、競争でもするか?
三回まわってワンと言う。
これを絵で指示してみ?
労力はどれくらい違うよ?
>>279 絵だと100種類のアイコンですむな
ドラッグアンドドロップで使用できるから楽だ
282 :
デフォルトの名無しさん:2014/01/31(金) 01:10:29.88
100種類作るのがめんどくさくて微妙な違いがわからないって言ってるんだが。
>>280 ボタンをポチポチクリックしていくのと命令をひたすら書いてく作業はどっちが楽だろな
確実に前者だろ?
後者だというならお前は一生グラフィカルインターフェイスに触れるな
たった100種類で足りるわけ無いだろw
100種類っていったら、日本語に使われる文字より
はるかにするないぞ?
まあ、英語よりは文字数多いかもしれないけどな。
それでどうするんだ?アイコンを複数つなげて言葉を作るのか?
そりゃそうだ。アイコン一つで表せることは100種類しかないからな。
>>283 よし、じゃあ競争だ。
お前はボタンをポチポチ、スクリーンキーボードで
入力してくれ。俺はキーボードで入力する。
>>285 そしてアイコンの代わりにラベル(文字)を見るのか?
もう文字だけでいいじゃねーかw
>>284 論破されすぎて混乱してきてるな
冷静になれ
論破っていうのはこういうことを言うんだよ。
絵で指示するのまだできないの?
>>277 > 出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
> ただ文字だと見にくく、絵だと見やすいというだけの話
いやいやw 支持を絵でやるのが難しい(時間的に)って話だろw
紙芝居で作業指示書を書いてみ?
なんなら、競争でもするか?
三回まわってワンと言う。
これを絵で指示してみ?
労力はどれくらい違うよ?
>>285 それだとグラフィカルにする必然性が薄くなる。
残るのは関連を線でつなげることとグリグリ動かすことくらいだな。
線でつなげるのは100x100=10000本の線でスパゲッティになる可能性すらある。
動画はさらにめんどう。
>>286 表計算の作業で競おうぜ
俺はエクセルつかうからお前はコーディングな
まさかエクセルは文字があるからグラフィカルじゃないとか言わないよな?
292 :
デフォルトの名無しさん:2014/01/31(金) 01:20:28.08
じゃあエクセル対プログラムでエラストテネスの篩のプログラムで競争してくれ。
>>290 グラフィカルユーザインターフェイスってそんなに不便だったのか
でもOSの世界ではシェアが圧倒的に多いんだがな
そんな不便なものがこんなに普及しちゃつてんだから不思議だよな
>>293 都合悪くなったら日本語読めない振りwwwwwwww
わろた
296 :
デフォルトの名無しさん:2014/01/31(金) 01:22:28.51
>>294 2ちゃんねる見て、googleしてエロ動画見てるだけだろ。
そんな簡単なことができたくらいで偉そうに。
>>295 エクセルで何をグラフィカルにプログラミングするの?
棒グラフ出すってこと?
>>296 そんな低俗な使い方してるのは中卒のお前だけだよ
世の中じゃデスクワークや研究でも普通に使われてんだよ
もっとそとにでて現実をしれ
>>297 グラフィカルのいみ調べてこいよ
表でもグラフでも、広義の意味では文字でさえもグラフィカルなんだよ
グラフィカルの反対語が文字だとでも思ってんだろな
>>299 じゃあ素数100万個出す競争でもする?
一行にカンマ区切りで2000個ずつ
これでいい?
ドラえもん「未来のアイテムが幾らするか知ってるかい? 現代価格で100億。」
>>299 何をしたいのかさっぱり分からんのだが?
>>294 お前何か勘違いしているよ。
グラフィックっていうのは見やすいが
書きにくいんだよ。描くのに時間がかかる。
だからコード→グラフィックの変換はいいが、
最初からグラフィックを使ってプログラミングするのは
馬鹿なアイデアだって話。
いい忘れたけど過去転送の送料が99億なんだけどね。
>>299 > 表でもグラフでも、広義の意味では文字でさえもグラフィカルなんだよ
じゃあ、スレタイの
「グラフィカルなプログラミング言語ない?」って
いうのはどういう意味?
> もうコーディングは嫌だ
らしいよ。
>>301 それはエクセルのまけだわ
じゃあ次は売上データを元に
月別で棒グラフを作成するって課題でやろうせ
データはCSVで用意しとくよ
まぁ命令はクリックだけでできた方が楽だろな
>>307 CSVで用意したデータをコーディングしないで、
グラフィカルなプログラミング言語(?)で
やるってこと?
普通にコーディングしたほうが早いと思うが?
エクセルは横方向だと
A〜Z AA〜ZZ までだっけ?
>>307 もちろん、ただツールを使うだけじゃダメなんだよね?
プログラミングして作らないといけないんだよね?
いや、ツールを使うなら。グラフ作成ツールに流し込めば終わりだからさ。
>>307 コーディング派はグラフの作成もコーディングでやった方が速いと考えてるらしいな
仕事が早くて羨ましい
>>312 おいおい、「プログラミング言語」前提の話だろ?
日本語でおk
>>311 既存のシステムを使うんでは比較にならないだろ
ずるはダメだぞずるは
結論:エクセルやりたいならエクセルやってろ
グラフィカルなプログラミング言語だから
ツールで用意された機能を使うんじゃなくて、
実際にプログラミングする時間で比べなきゃ意味が無いでしょ?
>>309 エクセルだと簡単に表計算できるよ
グラフも一発だ
>>309 それ、プログラミングじゃないじゃん?
>>1をみればわかるけど、
最初からプログラミング言語の話をしてるんだけど。
ちょっと話、皆についてこようよw
320 :
デフォルトの名無しさん:2014/01/31(金) 01:45:19.51
救済処置:エクセルで満足できないやつはアクセスへ移行しろ。
アクセスで満足できないやつはブイビィーでもやってろ。
命令は絵でやるより
コーディングしたほうが早いというからエクセルの例えを出したんだよ
やっぱ表計算ではエクセルに勝てないとさとったか
グラフィカルの勝利!
>>317 ツールで用意された機能使うにしても
キーボードでツール呼び出すよりアイコンクリックした方が断然早いけどな
エクセルで不満がないならエクセルやってればいいのに。
何か不満があるんだろ?その不満はプログラマブルに解消可能かもしれないのに、
いきなりグラフィカルになんでもやりてぇ〜〜〜〜〜!とか言っても無理な相談なんだよ。
で、グラフィカルなプログラミング言語がコーディングよりも効率悪いと言う根拠はなんだ?
>>312 エクセルVBAやVBなんて
コーディング量ほとんどなくなったよな
そう思えば時代は間違いなくグラフィカル!
>>323 不満といえばエクセルには汎用性がないことかな
もっと操作効率を落とさず作業範囲を広げたいんだわ
なんだ?このスレ
結論:マイクロソフトに相談しろ。莫大な投資をすればマイクロソフトは動いてくれるはず。
勝手に自分で作れよ
そして勝手に儲けろ
それだけのスキルと知能はここの住人にはない
>>324 > で、グラフィカルなプログラミング言語がコーディングよりも効率悪いと言う根拠はなんだ?
世の中に効率がいい「グラフィカルなプログラミング言語」というものが存在しない。
ちなみに、「グラフィカルなプログラミング言語」の定義は
普通のプログラミング言語と同じことが出来るもの。
たとえば、ifやloop、オブジェクト指向ができて、
それがそのまま実行可能であるというもの
もしかしたら効率がいい「グラフィカルなプログラミング言語」ができるかもしれないが
そもそもコーディングを上回る速さで絵を描くというのが不可能ということから、
効率が悪いというのは明らかである。
まああれだ、
「三回まわってワン」という命令を
文字で書く以上のスピードで書いてくれという話。
世の中にはグラフィカルなプログラミングがあふれているよ
これ以上何が必要なの?
>>333 開発効率。開発スピード
「三回まわってワン」という命令を
文字で書く以上のスピードで書いてくれ
>>332 それはさすがにグラフィカル系の圧勝だわw
ループチップに3回って設定して
表示チップに「ワン」と設定するだけ
ドラッグ2回とクリック2回、それと「ワン」とタイピングするだけ
具体的な問題が提示されないのに解決方法なんて提示されるわけがない
>>331 なんで命令する→絵を書くになるんだ?
せいぜいアイコンをクリックとかコネクタ引っ張ったり要素を配置したり変形させたりとかだろ
一つ命令するために絵を書くなんてそれはプログラミングとは言わないだろう
たしか洋物のブラウザゲームであったな
ロボットを目的地まで移動させるのに
ブロック?(命令)を並べていくの
条件分岐とループはあった
関数はあったかどうか覚えてない
それで、「三回まわってワン」はまだ?
>>336 これだから日本でiPhoneやGoogleグラスが生まれないんだよ
具体的な問題がないなら自分で作れよ
人任せ
>>339 3回まわってワン実行プログラムのアイコンをクリックするだけ
お前は文字しか使えないんだったよな
俺の勝ちだ
>>340 具体的な問題がないことが
証明している。
これが最終結論でいいじゃないか?
俺はこの結論でいいと思っている。
その反論を俺がやるワケがないw
> 3回まわってワン実行プログラムのアイコンをクリックするだけ
ということは
1回まわってワン、2回まわってワン、
4回まわってワン、5回まわってワン、
一兆個以上もアイコンが必要じゃねーかwwww
347 :
デフォルトの名無しさん:2014/01/31(金) 02:21:16.77
>>346 彼が一番出来るプログラマかもしれないのにそりゃないだろ。
>>344 これまさに(効率の悪い)
グラフィカルなプログラミング言語だね。
>>345 コンフィグでテキストボックスに回数が設定出来るんだよ馬鹿が
>>347 プログラミングできても考える脳がなきゃ意味は無い
所詮かれは支持されたものしか作れないのさ
考える脳がある人「じゃぁ相応の金くれ」
>>331 効率がいいプログラミング言語ってのはデバッグと検証の時間も含めての効率だ
短時間でカスコードを書いてデバッグは人任せなんてのは速いとはいえない
他人がみたときに問題点の有無をすぐに指摘できて改造しやすいのが効率のいいコード
アイコンだけで表現するなんて妄言はいてるヤツは
小学校の地図の勉強と中学校の電気回路の勉強をやり直せ
ワンワンキャンキャンしつけえな
より直感的に出来るようにするにはどうしたらいいかってことだろ
浮かばない奴は黙っとけ
夢を語らせておけばいいんだよ
まず、ユーザに1以上30以下の整数をひとつ、入力してもらう。これをnとする。
1〜nの整数を並べる。これをLとする。
※Lをシャッフルする。
Lが偶然にも大きいものから小さいものへの順に並んでいたら、何回シャッフルしたかをユーザに伝え、終了する。
順に並んでいなければ※に戻り、成功するまで何度でも繰り返す。
これをグラフィカルにプログラミングすると、どうなるん?
> 典型的な日本人的発想だな
> これだから日本からGoogleグラスやiPhoneは生まれないんだ
これは使える
ドラえもん!たいへんだ大変だ!とにかく大変なんだ!なんでもいいから早く出してよ!
ドピュ
基本UMLやRADベースじゃないの?
文字ベースのほうが検索とか差分とか把握しやすいからコード部分はテキストだけでも編集可能で
グラフィカルなビュー・エディタを改善していく
でだんだん面倒になってリソースもUMLもテキスト指定・・・
363 :
デフォルトの名無しさん:2014/01/31(金) 15:25:18.49
五線譜に落とせないかな
364 :
デフォルトの名無しさん:2014/01/31(金) 18:20:34.97
「今日の22時に
>>1にレスしなさい。」
これを図形で表現するところから始めて、日常会話まで図形で網羅していく。
生活に困らない程度まで図形で会話が成り立つようになったら、プログラミング言語に
取り組む。
こういう順番のほうが良くない?
何いってんの?
366 :
デフォルトの名無しさん:2014/01/31(金) 18:32:14.40
図形でプログラミングするんじゃないの?
367 :
デフォルトの名無しさん:2014/01/31(金) 18:38:18.65
姉貴が高校くらいの時から美顔ローラって言うのを始めたんだよね。
ゲルマニウムとかいうやつ。
もともと結構不細工だったんだけど、やり始めてからだんだん肌がきれいになったんだよ。
数年経ったらなんか顔がすっきりしてきて、今や美人と認めざるを得ない感じになってきた。
ゲルマニウムってすごいなーって感心するわ。
こんなに変わるもんなんだ。
キャラクタは図形に含まれますか?
369 :
デフォルトの名無しさん:2014/01/31(金) 18:41:39.12
象形文字ならいいよ。
ゆるキャラは図形ですか?
371 :
デフォルトの名無しさん:2014/01/31(金) 18:55:09.23
図形化したらいいよ。
写真はダメだよ。
紙に穴開けてプログラミングするのはどうだい?
文字なんてもう見るのが嫌なんだろう?
頑張れ低能共
低能にしか浮かばないアイディアを活かし、
低能でも優秀な人を超えるプログラムを作れるようにするんだ
期待しているよ うふふ
>>374 それ、日本語プログラミング言語の
コードを一行一行、色付き枠線でくくっただけじゃね?
377 :
デフォルトの名無しさん:2014/02/01(土) 13:27:19.29
確かに有能な人が作ると有能な人にしか使えない難しい言語が出来上がる傾向にある
Haskellとか
言語作者の設計思想のなかに無能な人に使ってもらいたくないというのがあったのだろう。
俺が理解されないのはみんな無能だからだ
無能な人に使ってもらいたくないまでは思ってないだろうけど
バカに迎合してやるつもりはない位には思ってそう
>>378 まあ、無能な人が使うツールは
有能な人が作ったツールだしね。
有能な人が使ってるツールを使わなければ、
有能な人になれないのは当然なわけで。
>>377 Haskellは、言語の見かけの難易度/解決出来る問題の難易度、で言えば易しい方。
スキルもコーディング慣習も異なる集団の共同作業を考慮して作っていない
というのが正しい
あるシステムを改良するとして、無能な人のための改良が
有能な人の足かせになるのであれば
そんなのは改良とはよべない。
無能な人でも有能な人でも、両方便利になるならそれはいいこと。
で、有能な人にとって便利になるのであれば、
無能な人は切り捨てるよ。当然だろ?
無能な人は有能な人の頑張ってなればいいだけの話だけど
その逆は不可能なんだから。
有能な人を切り捨ててでも、無能な人が便利になることを
目指しているツールもある。ようするに馬鹿向けツール。
そういう馬鹿向けツールを使ってる人は、
いつまでも成長できない。
386 :
デフォルトの名無しさん:2014/02/01(土) 14:43:51.71
html作るのに有能なブログラマは必要ない。有能>無能ではなく有能<無能なこともある。
387 :
デフォルトの名無しさん:2014/02/01(土) 14:44:23.15
一気に広がった言語って言うと、VB、PHP、Java、Javascriptとかなんだけど、
これらって、天才向け言語じゃないよね。
言語学者自身が成功するためには、ささやかな庶民向け言語が良いんじゃないのかな。
>>386 おい、今はプログラマの話をしてるんだぜ?
そりゃソフトウェアではないものを
作る人は関係ないだろw
389 :
デフォルトの名無しさん:2014/02/01(土) 14:50:04.71
PHPなんてダメ言語とか言われてるけど、すぐに欲しいものを自分で作れるんだから、
ダメ言語と言われても使っちゃうよね。
他の言語だと、必要なライブラリの学習から始めないといけないし。
下手したら完成する前に諦めるかも。
PHPならとりあえず動かすとこまでは行ける。
使いやすいライブラリの充実も言語にとって重要なんだろね。
PHPが良かったのは、(Windowsで運用するわけじゃないのに)Windowsで
単純に開発できること、(ありものを加工して添付してるだけなんだけど)
使いやすいライブラリの充実あたりなのかな。
>>387 天才向け言語と
普通の人向け言語と
馬鹿向け言語があるんだよ。
それらの言語は普通のプログラマ向けの言語。
広がった言語っていうのは全部そう。RubyとかPythonとかもね。
普通のプログラマ向け。
馬鹿向けっていうのは、日本語プログラミング言語とか
マウスでぽちぽちつくれますー。みたいなやつ。
>>388 html書くのが遅くて無能プログラマだと直接言われたことがある。
田町のあの糞システム会社早く潰れないかな。
392 :
デフォルトの名無しさん:2014/02/01(土) 14:56:12.95
(利用者が最先端技術の研究のために使っていると主張することが多いので)
Pythonは天才向けでしょ。
Rubyはそうでもないけど、一気に広まった言語じゃないよね。
ていうか、広まったともいえないかも。
>>391 うん、プログラマかどうかはともかく、
お前はHTML書くのが遅かったんだろう?
つまり、その会社で必要とされる仕事が遅かったんだろう?
394 :
デフォルトの名無しさん:2014/02/01(土) 15:01:10.70
たとえば、連絡帳みたいな簡単なアプリ。
Pythonで作ったとかだと、ボケ、カス、Pythonを汚すなって言われるでしょ。
他の言語だとあまり反響が無い。
PHPだと、俺にも使わせてってなる。
この辺り使ってる人の層が違うんだよきっと。
>>392 天才が使っているのと天才向けは違います。
天才は、普通のプログラム言語も使えます。
天才が使っているかどうかではなく、
普通のプログラマが使っているかどうかで、
普通のプログラム言語かどうかが決まります。
つまり、最先端技術や研究をしてないお前が使ってるのは
全部、普通のプログラム言語(もしくは馬鹿向け?w)ってことだよ。
>>394 > Pythonで作ったとかだと、ボケ、カス、Pythonを汚すなって言われるでしょ。
聞いたこと無いな。ググって探してきて。
でもそれは無能プログラマとは意味が違うよね
プログラマの間で、広く使われている
プログラム言語を使えないのは無能。
当たり前だな。
いや、397は
>>393へのレスな
それとももしかしてHTMLがプログラミング言語だと思ってるのか
>>395 ほほう、では最先端技術や研究をしていない俺が趣味で勉強がてら使ってる
Haskellはバカ向け言語?
天才向け言語があるなら教えてよ
俺が使ってあげるからw
HTMLはプログラム言語ではなく
マークアップ言語。
プログラム言語ではないが、
ウェブ系の会社においてHTMLを
かけるのは必須技術
たとえばタイピング技術はプログラムとは関係ないが
プログラマにとって必須技術なのと同じこと。
>>400 > ほほう、では最先端技術や研究をしていない俺が趣味で勉強がてら使ってる
> Haskellはバカ向け言語?
普通向け言語だろ?
天才向け言語なんて無いと思うよ。
誰が天才向け言語なんて言い出したんだか?w
>>387だね。
>>401 タイピングが遅い立派なプログラマはいくらでもいる
>>403 具体的に誰?
そしてどれくらいの遅さ?
キーボードを見ながら打つレベル?
405 :
デフォルトの名無しさん:2014/02/01(土) 15:34:39.51
呼んだ?
406 :
デフォルトの名無しさん:2014/02/01(土) 15:36:28.65
馬鹿には無理ってよく見かけるからさ。
PythonやJS使ってる人は、自分のことを天才だと思ってるんだと、
まあそんな風に見てたんだよ。
そうでもないの??
>>404 有名人がタイプしてるところは見たことないんで、具体的に誰とは言えないだが、
回り見りゃ分かるじゃん
タイピングゲームやらせたら250打/分くらいの、タイピングが普通よりちょっと遅いかな
くらいで、平均以上のプログラマーはいくらでもいるし、
タイピングの速い無能プログラマーもいる
相関関係もあまりないんじゃないかな
>>407 周りってそれお前の周り見た結果だろ?
HTML書くのが遅いお前のレベルが基準で、
周り見て遅いとか立派なプログラマって言ってるわけでしょ?
お前基準じゃなにも参考にならないな。
だから、有名人の名前を聞いたのに。
>>406 いや、だからさ、
天才と普通と馬鹿がいるんだよ。
お前短絡すぎ。馬鹿じゃないなら
天才と言ってるように思えるんだろう?
お前ごときが知っている有名なプログラマって誰よ?
411 :
デフォルトの名無しさん:2014/02/01(土) 15:46:32.49
無理って言われてる人って馬鹿には見えないというか、まあ傍目には
割と賢そうに見えるので。
少なくとも対象ドメインについての知識は豊富そうな感じの時が多い。
でも、結構バカとかカスとか言われてるのを見かけるんだよね。
賢そうな人に対して、馬鹿には無理とか言ってるってことは、
俺って天才!だってPython使えるから!って思ってそうな予感がしてくるんだよー。
>>408 とりあえず、HTML書くのが遅いと言ってるのは俺じゃねえけどw
反論してる奴は全部同一人物だと思うのやめた方がいいぞw
まあ、HTMLなんてたいてい既存のやつをコピペするよなw
emmet使いこなせば早いけど、そんなのは経験が少なくて蓄積コードがない
やつくらいだろ
なんにせよ、javascript書いてる時間の方が圧倒的になげーよw
413 :
デフォルトの名無しさん:2014/02/01(土) 15:49:17.10
それに対してPHPは、PHPでゴメンナサイって感じが伝わってくるんだけど、
動くから良いじゃん、便利だよありがとって素直に思えるんだよー。
Pythonの場合、天才の俺は庶民が使うものなど作らん!!って感じなんだよー。
だって動くものってほとんどPHPで出来てて、Python製って見かけない。
>>412 コピペするから何なんだ?
コピペするなら速いだろう?
まさかコピペ出来ないから遅いって言う訳じゃあるまいし。
415 :
デフォルトの名無しさん:2014/02/01(土) 15:55:11.13
そろそろ結論が出たようですね。
最強のグラフィカル言語は、マクロの記録だったようです。
まだ二月になったばかりですが、本年の最優秀グラフィカル言語処理系の栄誉を
Excelに贈りたいと思います。
ご清聴ありでした。
>>413 【俺がそう思ってるんだ」って
熱弁されても困るw
お前がそう思っているからって
それが世界の常識というわけじゃない。
>>414 だから、HTMLが遅いって言ってる奴はコピペが使えない事情があったんだろ
でも無能プログラマかどうかは判断できないよね
だって関係ないんだから
418 :
デフォルトの名無しさん:2014/02/01(土) 15:56:46.61
そろそろ世界の常識になりつつある。
419 :
デフォルトの名無しさん:2014/02/01(土) 15:58:41.92
天才用言語で書けるのはコードの断片まで。
完成された商品にはならない。
まあ、この板で一人のPython信者がPythonは天才だとか素晴らしいとか主張してるのは知ってるよ
確かこいつはJavascriptが嫌いだと思う
でも、そいつ一人がそう言ってるだけじゃないかな?
それ以外の世界ではPythonは有名なLLの一つ程度の認識でしょ
>>417 コピペが使えない事情が合ったというのなら、
そもそもお前が言った「まあ、HTMLなんてたいてい既存のやつをコピペするよなw 」が
使えないってことだろ?
つまりは、HTMLを一から書くのが遅いってことだろ?
それウェブ系プログラマにとって致命的な技術力不足だよ。
>>421 つまり、以降が違うね
その事情のもとにおいて遅いだけなんだから
致命的な技術力不足とやらは全く違うと思うよ
423 :
デフォルトの名無しさん:2014/02/01(土) 16:02:19.82
弘法筆を選ばずというけれども、弘法大師の残した筆コレクションを見れば
どれだけツールにこだわっていたかわかるというものです。
大体さ、HTMLが遅くたって、30分が一時間になるとかその程度だろ?
一方、Javascriptが遅かったら、4時間が8時間になるぞ
致命的かどうかで言ったら前者なんて誤差の範囲だと思わんか?
425 :
デフォルトの名無しさん:2014/02/01(土) 16:03:51.85
思いませんね。
いや、全然思わない。
へー、俺は4時間損する方が30分損するよりよっぽど致命的だと思うけど
そう思わない人もいるんだ
へーw
>>422 その事情っていうのは、
「一からHTMLを書くこと」なわけ?
つまり、既存のものを修正することは出来ますが、
一から作ることは出来ません。
っていいたいの?
>>424 JavaScriptとHTMLの両方に優れている人は、
JavaScriptだけしか出来ない人に比べて
30分も速いですね。
一日30分が1ヶ月20日あれば10時間です。
>>427 さあ、本人じゃないからどんな事情なのか分からんけど、
HTMLが遅いとかなんとか言ってるんだから、当然
コピペで終わるような状況じゃなかったってことは想像つくってぐらいかな
まあ、既存と全然違うデザインだったとかで一から作る必要があったんだろうね
で、タグの詳細仕様とかあやふやで調べながらやったとか、そんな感じだろ
430 :
デフォルトの名無しさん:2014/02/01(土) 16:08:56.02
虚しく往きて実ちて帰るという弘法大師の言葉を振り返ってなお4時間に
こだわりを持てますか?
>>428 そうですね。でもJavaScriptが得意な人はもっと速いですね。
無能プログラマかどうかを判断するなら総合的に見ないとね
432 :
デフォルトの名無しさん:2014/02/01(土) 16:10:42.45
総合的な判断にはチャートグラフが便利です。
ここでもまたExcelの実力が証明されるわけです。
ウェブプログラマならHTMLをかけるのは当然。
たった100個程度しかないタグぐらい覚えてるだろ。
それが遅いならやっぱり技術力ないってことだな。
あとなあえて今まで言ってなかったけど、
ソースコードと違ってHTMLは使いまわすものじゃないぞ。
たいてい一から書くものだ。使いまわすのはmetaタグぐらいなもんだろ。
434 :
デフォルトの名無しさん:2014/02/01(土) 16:13:32.83
100ページのサイトを手書きで作るなら、90ページは使いまわす。
普通はそこでテンプレートを使う。
HTMLを書くのが遅いというのは
テンプレート1枚を書くのが遅いという意味だろう。
>>433 いや、使い回すもんでしょ
Webフレームワークは大体テンプレート機能もってて、たいていテンプレートは使い回しだし
HTML5boilerplateとか知らないの?
まあ、こいつはコピペどころか、オート生成だけどさ
>>435 その場合、もっとインパクトは少なくなるよな
>>436 おい、意味が違ってるぞ。
お前が言ってるのは、テンプレートをコピペするって話じゃないだろ。
テンプレートは一つで、それを使ってHTMLを生成するって話だろ。
>>437 インパクトの大小は関係ないでしょ?
ウェブプログラマに必須の技術が
遅いって言われてるんだから。
>>438 まあでも本質は同じだよ
揚げ足取りの類い
まあしかし、テンプレートもテンプレートのコピペが多いかなw
441 :
デフォルトの名無しさん:2014/02/01(土) 16:17:47.39
サンプル数が100点を超えたのでそろそろ判定結果を発表します。
総合評価
☆★★★★E
講評
あなたがそう考えるのは心の弱さです、自分を見つめなおしましょう。
>>439 関係あるだろ
インパクトが少ないなら必須でも
遅くていいんじゃない?
出来ない訳じゃないんだし
>>440 前提が間違ってる。
そのテンプレートがコピペ出来ないって状況、
つまり一からテンプレートを書くのが遅いって話だろ。
テンプレートはコピペしないぞ。
同じものをそのまま使うものだ。
>>443 テンプレートだって、部分部分はコピペだったりするでしょ
まあ、理想的にコンポーネント化されてたらそうはならないだろうけどさ
>>442 それ技術力が低い奴がよく言ういいわけだよ。
できなくてもいいじゃない。別に対して時間かかってないんだから。
そういって、鍵も使わずにSSHログインで
毎回パスワード入力している人がいるぞ。
446 :
デフォルトの名無しさん:2014/02/01(土) 16:20:12.93
テンプレートを修正して保存すると、自動的にサイトへ反映されます。
しかしこの重さ、どうにかならないものだろうか。
>>445 もし、それでも総合的に時間かかってないなら、有能なんじゃないの
時間かかってないとかが問題じゃなくて
基礎的なことを理解していないっていうのが問題なんだよ。
できないのに、理解しているってことはまず無い。
理解があやふやだから、間違ったことをする。
HTMLを書くのが遅いっていうのは、HTMLを理解していないわけで、
HTML5どころか、未だにCSSを使わないテーブルタグによる
レイアウトをしていると思われる。
449 :
デフォルトの名無しさん:2014/02/01(土) 16:22:30.33
二チャンネルでビジュアル言語を開発したら、ビジュアル・インパクト・A(エース)と
名前を付けましょう!
絶対つけましょう!
>>447 いやw
鍵を使ってないだけではなく、
SSHそのものを理解していない。
だからSSHに関すること全てができない。
こういう奴が更に応用技術出来ると思う?
当然できませんでした。
面倒だったよ。AWSの認証周りを理解させるのに。
(たぶん今でも完全に理解していない)
451 :
デフォルトの名無しさん:2014/02/01(土) 16:24:10.82
453 :
デフォルトの名無しさん:2014/02/01(土) 16:25:14.31
お察しいたします。
チーソ
>>448 俺は正直問題だと思わないなあ
例えば、最近までバックエンドのJavaプログラマはJavascriptを知らない人多かったけど
別に無能とまでは思わないしね
HTML理解してるけど、タイピングが遅くてEmmet知らないから遅いだけって可能性もあるな
ちなみにIE7以前ならテーブルタグによるレイアウトは普通に有効だと思うけど
たいてい、「遅くてもいいいじゃん、そんなに時間かかってないんだし」とか言い訳してる奴は
だいたい時間かかっていて遅くて迷惑かけてるんだよね。
>>450 SSHの認証周りに関しては無能なんだろうなとしか思わんけど
そいつがJavascriptはバリバリに出来るなら、フロントエンドプログラマとして有能だと思う
>>454 そりゃ、仕事でやる必要がないことが
できなくても問題じゃないでしょw
だが仕事でやる必要がある以上出来ないとだめだ。
それがいやなら「それは俺の仕事じゃない」と
拒否することだね。
>>455 パレートの法則やボトルネックを理解してる有能なプログラマかも知れんよ
lodash.jsの作者も、部分部分の些細な最適化していないことに関して同じこと言ってたわ
>>457 でも今の話は、「無能プログラマ」かどうかだろ?
お前が言ってるのは「無能そのチームの一員」だろ
>>456 だからそういうことだよ。
JavaScriptを使う仕事であれば、JavaScriptができなければ
有能にはならない。
それと同じでHTMLをやるような仕事である以上、
HTMLができなければ、有能ではない。
ついでに行っておくと、今のフロントエンドプログラマは
JavaScriptの圧縮結合でnode使って
CSSを効率化するためにLESSやSASSを使ったりしている。
その為にLinuxも使うからSSHも普通に使っていたりする。
だからJavaScriptがバリバリに出来るだけでは、
JavaScriptプログラマとしいて有能であっても
フロントエンドプログラマとしては有能にはならない。
461 :
デフォルトの名無しさん:2014/02/01(土) 16:36:27.27
ウェブなんて馬鹿でもできるから広まったんだろ。
ウェブやってるやつがバカとか賢いとか言っててむなしくない?
単純労働に知恵なんか必要ない。
ほんとバカ!なんて馬鹿!
なるほど、馬鹿だからウェブなんかやってるのか!
>>459 だから最初から言ってるだろ?
「ウェブ系プログラマ」としてって。
ウェブ系プログラマなら当然HTMLも使うんだよ。
>>460 だから、それも「無能その仕事をする人」であって、
「無能プログラマー」ではないってこと
お前は配管工の仕事が要求される職場で配管作るのが苦手だったら
「無能プログラマー」だと思うのか?
俺は、HTMLはプログラミング言語じゃないと思うし、
多少それが苦手でも無能プログラマーじゃない奴はたくさんいると思う。
あと、LESSやSASS使ってるようなワークフローなら、Yoeman使って
Scafoldして、ReactみたいなフレームワークでHTML隠蔽してるかも知れんぞ
>>462 使うけど、割合的にはjavaScriptに比べてずっと少ない
重要性が少ないと言ってるわけ
>>464 重要性は高いぞ?
HTMLとCSSのデザイン分離の考え方を理解していなければ、
JavaScriptから直接色を変えたりとかアホか事をする。
>>465 デザイン分離のコンセプトを知らないかどうかと
HTML書くのが遅いかどうかはまた別だと思うぞ
むしろ、そういうのを知ってる奴はclass属性みてるだけで
タグの詳細に疎い傾向にあるかも知れんな
HTMLを理解して慣れてないと
HTMLとCSSで出来るようなことを
JavaScriptでやったりするんだよな。
そもそもさ、HTML書くのが遅いとか叱られる職場って
どうせ、むちゃくちゃ低レベルな職場だろ?
で、CSSもJSもへったくれもない状況で本当に低レベルなHTMLを一から書かされて、
無能だと言われたんだろ
本人じゃねえから、事情知らねーけどさw
469 :
デフォルトの名無しさん:2014/02/01(土) 16:57:26.22
>>468 本人だけどそんなところだ。月収6万。そこを辞めて次の職場では月収55万だった。
>>469 お、おう
そうなのかw
まさに地獄から天国って感じだな。おめでとうw
月収6万って手取り?さすがに手取りだよな
てことは、55万も手取りか?すげえw
472 :
デフォルトの名無しさん:2014/02/01(土) 17:38:18.33
ごめん、点をうち忘れた。
>>413 WindowsでもBlender, Inkscape, TortoiseHg辺りはPython使ってるみたいだが
ちなみに手元のUbuntuで削除しようとしたら、大量のパッケージに削除マークが付けられたんだが?
gdm, gnome-shell, compiz, gksu, ibus, software-center, unity...
もしPython削除したら、環境まるごと入れ替えが必要になりそうだなあ
ああ、別に高尚なもんだけじゃないぞ?伺かクライアントとかあったし
電子回路がプログラミングっていうのはおもしろい視点だな
ソフトウェアで実現可能なことはハードウェアでも実現可能だからな
たぶん
普通
再帰呼び出しするハードウェアとかめちゃくちゃ難しそうだな
呼び出される回数分だけ物理的にハードウェアを用意するかw
そうだね
ズームアウトしたらグラフィカル、ズームインしたらテキスト、なIDEが有ればいいと思うんだ。
つまり、書く時はテキスト、眺める時はグラフィカル。
>>481 それだったらリスト化されてた方がいいな
ズームアウトしていくと括弧の深いレベルからどんどん非表示になっていく
ようなものってあるのかな。
そんなんPythonならインデントレベルの深さに合わせて
折り畳むだけで出来るな
>>484 インデントレベルは意味的な深さとイコールではないから
その実装は簡単だけど意図に沿っているとはいいにくいな
>>481 アセンブラでそんな感じに紙に書いたことはある
近づいたらテキスト、離れたらグラフィカルw
消しゴムで書きかえながらレジスタチューニングしていたが
カレンダー一枚の裏からはみ出たら途端にわかりにくくなったww
とにかくどの言語もコメントが書きにくい
どこからどこまでが何の処理なのかわかるようにして欲しい
四角で囲ったり色分けできたり
>>487 それは関数やメソッドを切り分けるべきなんじゃないのか
>>485 >>483が言う括弧の深さとは等しいだろ
意味的な深さなんて恣意的に決まるモノはともかくな
20年前にBTRONで実現できてた話だが、ソースコードがハイパーテキストで、
文字を装飾したり、説明文書にリンクしたり、絵を混ぜたり出来た。
今実装するなら、Wordの*.docxファイルをソースコードとして使えるようにするとかかな。
>>490 NEXTSTEPではシェルスクリプトでマークアップ出来てた気がする
それビューワーの問題だろ
NeXTのはWindowsのワードパッドに相当するText.appで書いたリッチテキスト
形式のファイルをシェルスクリプトがプレーンテキストと同じように解釈して
実行できた、とおもう。ワードで書いてそのまま実行できるようなもの。
エディタから実行できるわけじゃない。
ターミナルアプリでcatしたときにリッチテキスト表示されたかまでは覚えてない
群衆プログラミングというのはどうだろう
それぞれ自律して動くエージェントを大量に用意して、それぞれのエージェント達に簡単な命令を与えて行く
そうすることで群衆が命令に対する目的に応じて組織的に最適解を求めていく
そんなプログラミング手法どう?
495 :
デフォルトの名無しさん:2014/02/04(火) 00:44:40.17
あげ
そして互いに矛盾する命令を与えられた集団同士が
それぞれの正義を掲げて○しあう悲劇
つまりそれこそが種としての最適解
凶暴な種は滅びる
定めじゃ(ご冥福を)
人間がコードをひたすら書いていく作業はもう古い
人間の命令に対して自律して判断し目的を達成するエージェントシステムが理想に近い
500だもん
プログラマも人間ですよね?
学習用だったかで、カルネージハートみたいな命令チップを並べる様なのはあったな
1つのチップは命令チップの集合体で、その中のチップ1つも命令チップの集合体で…
ってな感じでメタ的な構造にするとか
503 :
デフォルトの名無しさん:2014/02/07(金) 20:59:18.13
504 :
デフォルトの名無しさん:2014/02/08(土) 11:57:27.62
3Dグラフィックスの世界ではもはやプログラミングは不要みたいだな。
マジで?何を使って作ってるの?
いやLightWave使いの人になにかエフェクト作りますと言ったら、イラネと言われたから。
3DCGデザイナーからしたらいらんわそりゃwCGソフトでやれるんだしwww
フォトショとかイラレ使いの2Dデザイナーに同じような事言ってもイラネって言われるよwww
どんだけ時代に取り残されてるんだよwww
3DCGで言えば、ノード繋いでプロシージャルテクスチャを設定していくのなんて、グラフィカルプログラミングってものに近い気がするな。
ちょっと
>>507 クンこんなことで遊んでないで早くイラネ作ってよ 待ってるんだから
ここまでPiet無し
俺が作ってやるよ
いや俺が作ってやるよ
じゃあ俺がつくる
517 :
514:2014/02/14(金) 20:50:28.45
>>515 おねしゃす! 作りながらうp頼んます!
絵よりも文字のほうが後に発明された。
情報を記録する上で高度な道具は文字の方。
絵の方が遥かに労力かかるしな
パソコンならクリック一つだけどな
RPGツクールみたいな用途を限定したものなら、出来ると思うけど
限定しないと難しいよな。
>>515 に期待するのみだわ
逆に難しい部分ってどこよ
基本的な文法はカルネージハート方式でも十分じゃん?
軽ネジ♥法師貴ってなんですか?
>>523 ディティール部分、細かくなるほど難しくなると思うよ。
RPGツクールは、パラメーターからグラフィックまで全部フォーマット用意して
それを組み立てていくでしょ。この方式は細かい部分はモジュールになっていて、単に組み立て方をオリジナルに出来てその要素だけ自由でしょ。
プログラムはその制約が無い分、わからない人にはわけがわからない。
簡単にするということは、制約を作ることじゃないの?
HTMLエディターも同じような感じじゃん。
HPビルダーとかプレビューだけで作るとソースが無茶苦茶でディティールまで制御出来ない。でも簡単みたいな。
ソースだけで作れると、不自由に感じる部分で素人からしたら、簡単になる。
どこをトレードオフするかってなると、そこしかないハズ。
HTMLエディタがおかしくなるのはブラウザのせいであって
ホームページビルダーのせいにするのはかわいそう・・・
出力先が紙であるソフト(Quarkなど)はかなり細かく作りこめるしな
>>526 ブラウザ関係なくね?吐くソースがおかしいんだから。
ソースが見苦しいってだけの話だろ
だからDSLとグルーと汎用プログラミングをごっちゃにするのはやめろと
ソースの構造ではなくてむしろ処理の流れがわかりやすくなるようなもの作ってほしいな
デバッグしやすそうなやつ
もしくはバグが起こりにくそうなやつ
関数型言語でいいじゃん
いままでの流れをドラえもんでたとえると。
「ドラえも〜んしずかちゃんとやりたいよう〜」
「とりあえず告白すれば?」
「やだよ」
533 :
514:2014/02/17(月) 06:43:51.98
535 :
514:2014/02/18(火) 06:11:55.53
俺は本当に浮かんでるんだが
他に浮かんでる奴がいれば、いくらあれば作る?
俺なら200万円は最低でも欲しい
つきあわなくても、やれればいいな
アイディアなんか誰でも持ってる。それを矛盾なく実現するのが遥かに難しい。
ドカタの妄想
>>538 非ドカタの驕り
非ドカタのおまえは浮かんでるだけだが、ドカタのこっちは完成寸前だ。この差は天と地ほどもある。
これはもはや天地逆転だな。
誰も思いつくもの作ってるのね、乙
心の安静を得るためにそう思いたいんだろ。
非ドカタにできるのはせいぜいドカタの頭を叩くこと。他は何も成せない。
俺もアイデアを持っているんだが、
>>514よ。俺に出資してくれ。
出資?なぜ開発に金がいるんだ?
休日か仕事終わりに作業すればいいんでないの?
会社やめて開発に専念したいから生活費くれってことか?
何をするにも金が要る
そのくらい子供でも分かる
546 :
514:2014/02/19(水) 16:24:54.08
543とか544は低能っぽい
ネットで出資金募れるサイトあるよね
>>548 だから出資って何に金がかかるの?
開発を委託すんの?
絵空事いうプログラマ
551 :
514:2014/02/20(木) 00:28:00.56
質問厨って煩わしいな
自分で考えろって話
答えられないから逃げちゃった
見積りも出来ない
554 :
514:2014/02/20(木) 06:34:31.95
低能共はもっと生産的な頭を働かせろよ
生きる道が無くなってしまうぜ
生産財は無料が原則だろ
ブルジョワのブタども
>>555 と、絶対王政時代で頭の進化が止まってるエセ左翼は、今日も喚くのだあった。
558 :
514:2014/02/22(土) 00:33:04.70
>>555みたいな奴って大概もらう権利だけ主張して
自分は何もしないという まさに圧倒的クズタイプが多いよな
まあそういう人間でいたいならそうしたらいいんじゃない
559 :
514:2014/02/28(金) 18:30:36.23
もうちょっとスレ伸ばし頑張れよ
残ってるプロジェクトが全部終わって万が一時間余れば作ってやるからよ
>>560 フリーフォーマットだとこういう風にごちゃごちゃするから
やっぱ碁盤上にしたほうがいいと思うんだよ
563 :
514:2014/03/02(日) 18:48:24.79
フリーフォーマットもやり方しだいだろうな
文字と図形
代数と幾何
コマンドラインとGUI
とういう構図がプログラミングにもあっていいよな
まだGUIはCUIの完全な代替にはなってないんだよなあ
アプリ同士の連携やバッチが弱い
Visual Studioにでもそういうの搭載されれば
Prographは最初Mac用のフリーソフトで商用版がPrographCPXとして販売開始
ちょうどWindowsが広まった頃にWindows版を作った辺りで会社が消えた。
だもんで権利がどうなってるのかよくわからないので消えっぱなし。
MartenはPrographCPXのクローンみたいなの。
内容としてはオブジェクト指向でオブジェクトをアイコンで管理
アイコンのコード部を開くとパーツを置くGUIが開いて
上からの引数が流れてきて処理パーツに入り処理を済ませて下に流れてゆくデータフロー形式。
正直、あの「クラスのアイコン管理」は他の言語も取り入れて欲しいなぁ…
言語じゃなくてエディタでいいだろ
グラフィカルなエディタない?
572 :
514:2014/03/05(水) 10:05:18.01
俺の発想もそれだが
見つからないならお前が作れよ
573 :
デフォルトの名無しさん:2014/03/05(水) 14:50:02.37
vvvvがまだ出て無いとか
思うんだが、これは注目するレベルに応じてビューを切り替えた方がいい。
マクロレベルではオブジェクトグラフ、オブジェクト内部はコールグラフ、そして各メソッドの実装と。
つまり3つのレイヤーでプログラムを表現できればいい。
つーことは、既存のIDEになんかのプラグインでも入れればできるんでないの?
577 :
デフォルトの名無しさん:2014/03/13(木) 12:46:32.09 ID:ZlFTo0ST
>>576 VSのUltimateとかではそう言うのやろうとしてるが。使い物にならないけど
>>577 それどの機能の話?
使いものにならないんじゃなくて
使ったことなくて知らないだけじゃ?
ID出るようになったんだな。
つか、俺のいったのは表示に関してで、編集とはちょっと違うよな。
例えばコールグラフをGUIで編集できるようにするとしたら、
各メソッドの引数、戻り値が統一されてなきゃなんなくね?
それもできなくはないけど...
GUIで編集する理由なんてあんの?
いや、それはこのスレの主旨的な話さ。
だが、電子ブロックみたいな子供向けのプログラミング環境としてはありかもな。
582 :
デフォルトの名無しさん:2014/03/14(金) 00:47:27.83 ID:bbGk2WDX
>>578 CodeMapがその方向に向いてる機能じゃねーの。
上手く使うと使えるのかもしれんけど試した限りではこれじゃない感。
使える使い方あるなら教えて欲しい
電子回路図とかは GUI でやってたし、意味はあると思う。
ただ数十〜数千程度の素子並べる時代ならなんとかなってたけど数万から下手すると億に到達するような時代だとやってられない。
ソフトでも UML とかのグラフィカルなアプローチやってるが、現場ではほぼ使い物にならないと言うのが現実。
アナライズとしては意味アルよ、特にコードグラフは。
585 :
デフォルトの名無しさん:2014/03/14(金) 08:50:03.98 ID:bbGk2WDX
なんかアナルライフに空目した(´・_・`)
>>583 プログラムもフローチャート図とかGUIでやってたよ。
同じく数(行数)が大きくなると成り立たないけど。
やれないことはないが、無駄な時間がかかり過ぎなんだよ。
それを省くと、絵ではなくて文字で書きましょうか?ってなる。
"フローチャートは現場では使い物にならない"
合ってはいるが、それはチマチマフローチャートなんて
(プログラム本体と別に)書いてるヒマねーよ!じゃね?とは思う。
フローチャートじゃ表現力がなさすぎるんだよな。
コードで書けることしか描けねえなんて無意味。
>>586 > プログラムもフローチャート図とかGUIでやってたよ。
ほんとにやってたか?
うちの会社その手のツール作ってたけど、作ってるやつらですらまともに使ってなかった、て言うか使い物にならなかったぞ。
普通にコーディングしたソースをフローチャートとかに変換してレビューに使うとか、クロスリファレンス出力させるとかぐらいしか使いでがなかった。
590 :
デフォルトの名無しさん:2014/03/14(金) 23:33:45.53 ID:bbGk2WDX
フローチャートは書かないけどクラス図とインタラクション図足して2で割ったような図は自分用によく書く。
そう言うのとエディタがシームレスに連携してくれると一番いいんだけどな
UML1.0っぽい図は便利なんでホワイトボードに描きながらクラス考えるなぁ
線がグチャグチャになったとき、巡回セールス問題を遺伝的アルゴリズムで解いて
できるだけ短くなるプログラムを作るんだ。
次に線がクロスするときはできるだけ直角に交わるように回り道するアルゴリズムを考えるんだ。
ある一定分野なら非常に有効なんじゃないかな
ネットワークのプロトコル記述とか、独立したシステムが協調動作するアクター指向のシステムとか。
VSとか部品でUI組み立てる部分をコードでも出来ればいいんだよな
教育用とかライトなのが一番思いつく用途だけど
MindStorms...
まあカルネジーハート・・
>>590 クラス図書くとコード生成してくれるってのはあるけど
それを動的にするってこと?
598 :
デフォルトの名無しさん:2014/03/27(木) 12:43:03.18 ID:LV/+/NZy
んー、今のファイル内で縦に固定化されてるクラスとか関数が自由にダイアグラム上に配置出来て、呼び出しなど関係あるものは近くに配置出来るとかかなー コードとして開いてるのを閉じてクラスの矩形にするとかでコード間の関係をうまいこと視覚化出来るといいんだが。
上手くやらんと使えるものにはならないのは認識してる。
599 :
デフォルトの名無しさん:2014/03/27(木) 12:44:17.17 ID:LV/+/NZy
>>597 コード生成のためというより今のテキストで書かれてるコード間の関係をコードエディタとシームレスに見れるといいなという
グラフィカルに確認できるほうが需要あったりして
昔のMacで作業ごとにデスクトップのこの辺があれ、この辺はこれみたいに
作業フォルダ分けてたみたいにクラスはもうGUIで
クラスのアイコンとインターフェイスだけすぐ観れる状態で
ばらばらと空間に置いてあって、ダブルクリックで開くと
中身参照できてそれをコードエディタで弄る。みたいにして欲しいわ。
Smalltalkが一番そういう環境に近いのかもね
コードを読めない人・・・グラフィカルがいいと思っている
コードを読める人・・・テキストがいいことをわかっている。
コードを読めない人が成長すると、
コードを読める人になる。
ようするにグラフィカルがいいと思ってるのは
たんにコードが読めないから。
読めないからグラフィカルになれば俺にもわかるはずと
夢を抱いているが、それはありえないので。
Visual ASMがあれば欲しいぞ
アセンブラのビジュアル化ってLEDやスイッチなどのハード化が主だな
printfデバッグならぬLEDデバッグ
ハードウェアエミュレータの話でもしているの?
ハードウェアをどうにかするって話で
言語じゃないじゃんw
図示できるとこに着目したいけどGUIとコマンドプロンプトのようにはいかないだろうか
例えば【IF】部品を引っ張ってきて
【IF(){}】のカッコ内のパラメーターを入力する
そうすると部品単位の扱いになって入力ミス等が減ると思うから
やっぱ始めに初心者向けが想定されるんじゃないだろうか
関数なら=【HOGE】ーみたいに入力とリターンがあるとかなのかな?
>>606 そうやって長々と説明しているけど、
文字で書けば一行だからねw
そう、効率の問題。
むしろ、効率の問題的にわざわざコードでタイプしないでも
オブジェクト指向なんだから基底クラスの"フォルダ"に
使うクラスをポイポイぶち込んで、プルダウンで
その新クラスが使えるメソッド選んでオーバーライドコードを
チョロっと打てば、はい新しいクラス完成でいいじゃん。って思ってるだけだけどね。
>>608 それ、クラスのインターフェースしか
作れて無いぞw
そんなインターフェース定義よりも、
量が多いのは、インターフェースの中身だろう?
>>610 >オーバーライドコードをチョロっと打てば
学習、実用、文章派
向いてる方がそれぞれ違うな
613 :
514:2014/03/28(金) 14:27:22.81 ID:TjE6hC/t
下手に知識を持った低能はマイナスに作用するな
無知でも地頭が良いやつの発想こそ縛られて無くて良い
地頭がいいやつって評価されるけどさ、
地頭がいいだけじゃだめだろ。
学歴の話か
地頭いいやつって、無理に知ったかする必要ないから
中卒高卒の発想は爆笑もので下手な芸人より面白い。
お前はその芸人よりつまらんけどな
620 :
514:2014/04/05(土) 00:40:28.92 ID:m2nwt+w+
「青は藍より出でて藍より青し」
な
なんでや、D関係ないやろ