オブジェクト指向ってクソじゃねぇかよPart3
■ このスレッドは過去ログ倉庫に格納されています
無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。 単なるマッチポンプ。 カプセル化(英語:encapsulation)とは、オブジェクト指向を構成する概念の一つで、 オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、 オブジェクトの実際の型を隠蔽したりすることをいう。 偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。 一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として 「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。 オブジェクト指向の発案者であるアラン・ケイもコーディング規約(頭文字にアンダースコアを付けるなどの命名規則)で 縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」 という概念はない。 https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 前前スレ オブジェクト指向ってクソじゃね? https://mevius.5ch.net/test/read.cgi/tech/1535085129/ 前スレ オブジェクト指向ってクソじゃねぇよ? Part2 https://mevius.5ch.net/test/read.cgi/tech/1539872441/ 何人かNG登録して前々スレ見てみなよ 日本人には答は出せなさそうだぞ 一般人はヲタや信者にに振り回されず、 言語的進化を享受すればよい もうメリデメフクメテ浸透してるし今更語る事なんてないだろ 所詮道具でしかないんだし適材適所で使っていけ OLEオートメーションサーバにしたって、サーバ側は欧米人が用意するから 日本人は黙ってVBからOLEクライアントのコードをコピペして業務要件をまっとうすればよかっただろ OOPだって同じこと ゆめゆめライブラリ提供者になったつもりになって語るなよ 身の程知らずも甚だしくて、おこがましいわ 人間の理解力や把握できる範囲の限界を認めることから出発してるから正直で現実的な考え方だったと思う で、いろいろ作っていったら複雑になっちゃった うんちく垂れ流して人を煙に巻く奴まで出て来た 継承の段数が深すぎるなら、コピーして横並びの改造版でもいいじゃん 格好つけるためにやるんなら無意味だよ 俺たちバカで忘れっぽいうっかりさんだからわかりやすくしておこう指向でいいじゃん >>143 チンポ「を」だろ はいコンパイルエラー やり直し 611 名無し三等兵 (ワッチョイ 7fe7-t9Bb) sage 2018/11/22(木) 12:46:59.97 ID:vFEoyYoC0 >>587 「ちんちん」の語源の1つの説に、 支那の娼婦が幼児語で「入れて入れて」と言った言葉を 当時の出羽守が有難がって日本に広めたという かなり眉唾物な故事がある。 その説に依るなら「チンポかシコシコする。」は 当然のように入れた側の所感とその転用じゃな。 591 名無し三等兵 (スッップ Sd1f-hEn1) sage 2018/11/22(木) 12:26:55.61 ID:9IvK1JXqd >>587 シコシコするは他動詞なので、所有者の意思とは無関係にチンポが自立行動するのであれば「イライラする」「ムラムラする」という自動詞を用いるのが正しい 644 名無し三等兵 (アウアウカー Sa87-dVyK) sage 2018/11/22(木) 13:18:34.11 ID:UNLN7beIa >>587 「胸がドキドキする」 胸は心臓の意味で、行為者として心臓が使われているので「心臓が拍動する」は日本語としておかしくない。 「チンポがシコシコする」 チンポはそのままの意味で、受け手側としてチンポが使われているので「チンポはシコシコされる」又は「チンポをシコシコする」が正しい。(50字) >>1 そのとおりじゃ! というか、おれはオブジェクト指向のC++が現れてすぐに クソだウンコだと言ってきた。 オブジェクト指向が素晴らしい?はあ?何言ってんの馬鹿なの? オブジェクト指向の特徴は、カプセル化と継承じゃ! そんなもの他の言語ではもっと簡単な方法で実現してる! それが理解できないバカはさっさと死ね! >>146 >オブジェクト指向が素晴らしい?はあ?何言ってんの馬鹿なの? 928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1 >>922 >ナンチャッテメッセージングスタイルになったのは チンポ.オシッコを出す チンポ.オシッコを止める さっきトイレでやってきた。 929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1 >>915 >単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを >ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。 × 俺.オシッコを止める 俺.オシッコを出す ○ 俺.チンポに力を入れる 俺.チンポから力を抜く 特定の言語の話なんか誰もしてないのに本当に馬鹿だな 指向とそれを言語仕様に組み込むかどうかは別の話なのに本当に馬鹿だな 無理やりOOPしなくていいと思うよ、ソフトが見やすくメンテしやすい事か重要なんだから。 無理しても余計へんちくりんなコードになるしね、ただちゃんと設計されたOOPはマジでわかりやすいので勉強はした方がいいと思う OOP否定派はどうせ手続き型でもまともに設計できない。出来るのは自分流の設計だけ、自分では気づかないけどめちゃくちゃわかりにくいコードだよ、それ オブジェクト指向で良い設計ができるのっていつ?ってことと、 もし筋の悪い設計だったとき、オブジェクト指向で作ってれば変更が楽なの?って観点が欲しい 手続き型(imperative)の対立用語は宣言型(decrative) ずーっとOOPの対立概念として手続き型を使ってる低脳クソ間抜けがいるな。 C++もJavaも今のメインストリームは大体オブジェクト指向“かつ”手続き型。 分かったかクソ間抜けwww>>150 まあ宣言するだけで、低レイヤーではしこしこ手続き書くんだけどな Javaは中途半端。プリミティブとオブジェクトを無駄に分けるし、後からジェネリクス入れたせいでダサいライブラリが残存してる 何よりもユーザーが作れるもの全てがオブジェクトになるんで「ここだけオブジェクト指向の考えを入れよう」っていうアプローチがとれない > 何よりもユーザーが作れるもの全てがオブジェクトになるんで それのどこが中途半端?原理主義だというなら分からんでもないが… 155じゃないけど 原理主義はどっちかって言うと smalltalk とかなんじゃないだろうか? javaは全部がオブシェクトじゃなくて プリミティブ型 が混じっているから 中途半端 と判断しているのではないかな? javaは所謂手続き型的に書きにくい(書けない?) クラスを作ってオブジェクト指向しないといけないのに オブジェクトじゃないプリミティブ型が混じっているから中途半端見えるのでは? javaは登場当初の時期が古い頃でもあるから 処理性能的にプリミティブ型が必要だったのかも? c++は手続き型的に書ける感じだけど javaはそういうのがし難い印象 だからstaticおじさんとかが登場したとかじゃないのかなぁ? 良く知らないけど >>158 > 何よりもユーザーが作れるもの全てがオブジェクトになるんで「ここだけオブジェクト指向の考えを入れよう」っていうアプローチがとれない と言っているのにその擁護はおかしい。 >>159 ユーザーがプリミティブ型を作れると思ってる? >>160 分かった。けど>>155 の文章力はちょっと酷すぎないか… >>153 OOPも元は宣言的を目指してるし、smalltalkや最近の関数型機能も取り込んだOOPな言語もある程度宣言的なんだよね。 じゃあ宣言的ってなんぞやってなるんだけど、HaskellもPrologも結局ループを再帰とかmapとかfoldlとかに置き換えて、if/switch文がガードやパターンマッチになっただけって言う。 (実際、Haskellのパターンマッチはcase(C言語系のswitch)の構文糖衣) OOPもそう言う制御構造をメソッドに押し込んじゃえって感じだけど(少なくともmainとかの中身は宣言的に書きやすい)、メソッドの中身は相変わらず手続き的と言う。 (この辺、最近の言語だとクロージャ(ラムダ式含む)やらLinqやらで比較的、制御構造を隠蔽し易くなってると思う。あとはif/switch文だけだ。がんばれ!) でも逆にそう言う目で見ると、関数型言語も手続き型言語も大差無い。 (関数型言語も事実上の再代入は可能だし) 強いて言えば関数型言語の方が関数に分割し易かったり、ガードやパターンマッチで分岐のネストが減る分、見やすいってだけ。 (どっちかと言えばアルゴリズムと相性が良いリストが基本か、効率重視の配列が基本かの違いの方が大きいので、リスト使う限り文法以上の違いは感じない) GoとRust入門サイト読んでみたけど、どっちもOOPじゃ無いんだね。 Go=手続き型言語に最近トレンドの機能入れました。(ただしOOPは除く) Rust=手続き型言語でも関数プログラミングな書き方出来ますが、関数型言語は言語レベルでサポートしてますー>なら、手続き型言語でも言語レベルで関数プログラミングをサポートしようじゃ無いか。 Goは依存関係に苦しんでた結果生まれたとか(dllとか基本的に作らない方針)、OOPへの問題提起な印象。 RustはOCamlとかSMLで良くね?と思ったけど、関数型言語のままだと普及しないから、手続き型言語に寄せました的な印象。 OOPのすべてを表現できるOOPLが無いから こうなるんだよ。たぶん不可能だし、その場しのぎ で作って、文法ごと捨ててしまうのが正しい。 死んだのはJavaだけやろ そらインタプリタやらサブセットやら自由な実装を認めないし フレームワークをゴミ箱に捨て続けるようでは そらうんざりだわ くそはJavaだから、限定すると Cとかと結合出来にくいから、ダメなんよ 逆に呼ぶのもメンドイし、バインディングが 最大の欠点よ。自分の殻に閉じ籠って 独自の世界観作っちゃってるのよ。 >>162 ちゃうぞ、パターンマッチはオーバーロードの機能もあるから >>170 OOPとの比較だとそうだけど、if/switchは手続き的と宣言的(OOP含む)の比較だから。 >>169 その言い方だと、他の言語はC言語と結合できやすいといってるように思えるけど、 ソースレベルで結合できるC/C++以外で、 C言語は他の言語と結合できるの? くそなのはむしろC言語では? Hello World!! ello World!! llo World!! lo World!! o World!! World!! World!! orld!! rld!! ld!! d!! !! ! を無限に繰り返すプログラムをCで宣言的?に書いてみた。 #include <stdio.h> #include <string.h> void hello(char[],int); int main() { char s[] = "Hello World!! "; int sl = strlen(s); while(1) for(int i = 0; i < sl; i++) hello(s,i); return 0; } void hello(char str[], int i) { puts(&str[i]); for(int j = 0; j < 50000; j++){} } こっちはHaskell main = do mapM_ (\_ -> hello str) [1..] hello [] = return () hello (s:ss) = do putStrLn (s:ss) mapM_ (\_ -> putStr "") [1..50000] hello ss str = "Hello World!! " こっちはシェルスクリプト #!/bin/sh while :; do s="Hello World!!" while [ "$s" ]; do echo "$s" s=${s#?} done done シェルスクリプト版改良 #!/bin/sh while [ "${s:=Hello World!!}" ]; do echo "$s" s=${s#?} done do-doneが宣言的じゃ無いぬ(´-ω-`) Cのはwhileやforが一つの文か式は{}を省略できるから宣言的であって。。。 てか、OOPどうした。 てか、手続きやOOPの本当に厄介なのはポインタとか参照とか使う場面なんで、これは良い例であってだな。。。 しかし、手続き型言語の良い点もまたそこを効率的に使える点なんだよね。。。 (安全性とトレードオフ) 正直どうせフォンノイマン型計算機なんだから手続きベースでいいじゃんっていう気もする そんなことより問題領域を表現するデータ構造(演算の定義域)をきちんと構造化してですね... いわゆる巷で言われるOOPだと、何というか分散処理の匂いがしてあまり好みではない OS上のプロセス自体を巨大なFSMとして見ることができて、そのモデルはかなり役に立つけど、どうしてその実装までそのモデルを強いられるんだ、という 別にメモリ上の構造化されたデータ群に対して演算を加えていく形式でもいいじゃんっていう そっちの方が順序回路っぽいし ミクロの視点かマクロの視点か、という違いな気もするけど > Cのはwhileやforが一つの文か式は{}を省略できるから宣言的 > Cのはwhileやforが一つの文か式は{}を省略できるから宣言的 > Cのはwhileやforが一つの文か式は{}を省略できるから宣言的 > Cのはwhileやforが一つの文か式は{}を省略できるから宣言的 なんでバカは知ったかが他人にバレないと思い込むんだろう? 浮気男が「自分がこんなに楽しんでいるのだから妻も同じようなことをしてるに違いない」と決めつけるように、 「自分がよく分からないのだから適当なこと言っても他人も分からないに違いない(からイキっておこう)」という精神なのだろうか。 👀 Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) >>173 GNU Smalltalk | str | str := 'Hello World!!'. 0 to: FloatD infinity do: [:idx | (str allButFirst: idx \\ (str size + 1)) displayNl] https://ideone.com/4QgJwe ソートしたいぜ! と宣言すればあとは誰かが宜しくやってくれる素晴らしい世界 しかし ソートが遅い ソート順が特定条件で意図しない結果に などの現実にぶち当たり自分が小人さんになったりする世界 真面目な話だけど、forとwhileは「ボクの考えた最高な制御構造だから、ブロックの中身を全部見て、どこで変数が使われてるか全部把握してね!」って書いてるようなもんだよ そこをmapにすると「シーケンスの各要素を関数で変換します」、foldだと「シーケンスの各要素を使って一つの値を出力します」って意図が最初っから込められてる だから宣言的な方が読み取りやすい >>181 いや、そいつに関してはシッタカというよりはもっとシンプルに 本人のおつむの悪さが俺らを困惑させてるケースだと思うw 周回遅れの人間が微笑んでくる感じ >>184 forは「要素を全てブロックの中で処理します」だろ? 「それではその処理を説明します」 「“まず”〜〜します」 「“次に”〜〜します」 「“それから”〜〜します」 「“最後に”〜〜します」 「そして何も返しません」 「操作していた配列は無茶苦茶にしておきました」 なるほど、つまりconstを使えば宣言的って言いたいわけだな! >>181 >>185 いあぁ。。。宣言的ってのに再代入禁止とか関数脳に侵され過ぎてもね? 実際、再代入可能な方がメモリ効率は良いのよ。 それをプログラマーが見やすいか?が重要なんだけど、現状関数プログラミングよりhs手続き型で単純な方が宣言的って言うね? まあ悪い例とでも受け取ってよ。 普通に{}で囲む処理書いてたし。 それをわざわざ?宣言的っぽく関数に括り出したわけで。 OOPならこうじゃ!なのも受け付けるし。 >>182 さすが、純粋OOPLやね。 ただ、関数型もOOPLも結局か標準関数の多さが強みじゃね?って思いがある。 (samlltalkはオブジェクト自体がコード呼び出せるって意味で文系環境だし、理系なら結局Cに行くわな。。。って意味で関数型にもOOPLにも、ライブラリの重要性しか感じないんだけど) でも>>177 が一番シンプルでわかりやすいよな? 宣言的だからって必ずしもいいとは限らない例だよな 藁人形論法と言う。 「ミカンと浣腸は違う。お前はミカンが何か全く知らないのに知ったかで論評しようとするからめちゃくちゃな文になってる」 「でもミカンが黄色いとは限らないよね」←これがお前。 誰もミカンが必ず黄色いとは言ってない。 お前のミカンの理解が間違ってる、浣腸と比べるものではないと言っている。 何事か言い負かされて、でも空って青いとは限らないよね、と言ってるのと同じだ。 お前はあれか、全く本も読まない勉強もしないでこんなところでノー知識で言葉のうわべだけから妄想したポエム書き散らしてるだけで何か得ることができるとでも思ってるのか。 池沼「ペンギンは空飛ばない空飛ばない」 池沼「カモノハシは卵産む卵産む」 低学歴知恵遅れにかぎって 継承大好きだからな >手続き型で単純な方が宣言的って言うね? 単純なら宣言的って思ってるのか >>178 で{}を省略できたから宣言的だって主張してるのはそういうことなのか 頭がくらくらする >>194 単純ならってわけでも無い。 whileやforを繰り返し構造を表す関数として解釈した。 関数が関数や値を受け取って、処理を進めているように見えるように意識した。 ドツボに嵌るついで。 >>175 のdo式の書き方をモナド式に直す。 main = mapM_ (\_ -> hello str) [1..] hello [] = return () hello (s:ss) = putStrLn (s:ss) >> mapM_ (\_ -> putStr "") [1..50000] >> hello ss str = "Hello World!! " >> は、左を実行して右を実行する演算子。 Haskellでは2項演算子を()で囲むと2引数の関数になるので main = mapM_ (\_ -> hello str) [1..] hello [] = return () hello (s:ss) = (>>) (putStrLn (s:ss)) ((>>) (mapM_ (\_ -> putStr "") [1..50000]) (hello ss)) str = "Hello World!! " (>>)を関数fに置き換える。 main = mapM_ (\_ -> hello str) [1..] hello [] = return () hello (s:ss) = f (putStrLn (s:ss)) (f (mapM_ (\_ -> putStr "") [1..50000]) (hello ss)) where f = (>>) str = "Hello World!! " とっても見やすくシンプルでバグもないシェルスクリプト版 #!/bin/sh while [ "${s:=Hello World!!}" ]; do echo "$s" s=${s#?} done クソみてえなおまじないコマンド/usr/bin/[ とか代入と値評価を一度にするクソ構文のどこがシンプルなんだ? これがシンプルでわかりやすいなら、↓のCも同じくらいシンプルでわかりやすくなっちゃうけど、普通にわかりにくいだろ。 #include<stdio.h> int main(void) { while(!NULL) { char* c = "Hello World!!"; while(printf("%s\n", c++) != 2); } return 0; } Javaならオブジェクト指向でこんなに簡単に Stream.generate(() -> "Hello World!!") .flatMap(s -> IntStream.range(0, s.length()).mapToObj(s::substring)) .forEach(System.out::println); >>202 シェルスクリプトの文法が複雑かどうかじゃなくて 書いたコードがシンプルって話をしてるんだよw >>200 iPadでちょうど良い速さにする重み付け。 CPU性能に合わせて増減して下しあ。 重み付け消すと流石にスッキリ。 main = mapM_ (\_ -> hello str) [1..] hello [] = return () hello (s:ss) = f (putStrLn (s:ss)) (hello ss) where f = (>>) str = "Hello World!! " だったらアセンブラがいいな 上記のことをやるカスタム命令 unk xxxxx xxxxxx xxxx xxxx カスタム命令に対応しているCPUを教えてください 作るしか無いのであれば、その作り方まで書く必要があります。 そこまでやって回答として認められます。 >>149 >チンの始皇帝 >略してチンシコ 2014-07-26 草間彌生の水玉は去勢されたペニス なんと若き草間彌生が無数のペニスの上に寝転がっている。この写真を見てはっとした。 現在の水玉の作品にいたるまで、草間はひとつのテーマで描き続けているのではないだろうかと直感した。 http://hpo.hatenablog.com/entry/2014/07/26/110000 低学歴知恵遅れがオブジェクト指向言語使わなければ オブジェクト指向言語はメリット満載 >>212 そしたら誰も使わないだろうに 満載もクソもあるか http://www.kh.rim.or.jp/ ~nagamura/misc/stroustrup-interview.html >>214 C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが 簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを 追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。 C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、 それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる: - うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が 安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、 もはや笑えるレベルを超えている) - 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに 効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の コードがその素晴らしいオブジェクトモデルに依存していて、直すためには アプリ全体を書き直さなきゃなんない。 言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに 限定するってことは、他の人がそれをめちゃくちゃにしないってことで、 ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい 「オブジェクト・モデル」のたわごとを持ちこまないってことだ。 Object-oriented programming is an exceptionally bad idea which could only have originated in California. — Edsger W. Dijkstra >>214 面白いおっさんだなぁw 実際素晴らしい物を作る という様な理由や そう言った事を実は言って無いんだよなぁ 寧ろ難しいから普通の人は止めておけ って言っていたらしい 実際そう思う その記事に有る 気まり事を沢山覚えておかないと大変な事になる というのはその通りで c++11やそれ以降も増え続けていて いったいこれはどうやって使えばいいんだ? なんて思う 既にオブジェクト指向言語の枠は超えて 関数型みたいな形でライブラリーを使わないといけなかったり かなり大変 オブジェクト指向は実際に効果が有る その記事に書いて有る方法だと余り活用する方法は未だに思いつかないけど それ以外なら結構効果が有る わざとらしく上手く行かない部分だけ持ち出す辺りは あのおっさんらしいと言うべきなのかw 続く 続き オブジェクト指向プログラミング問題は それを使いこなす事が難しいって事だ 結局オブジェクト指向とc++を同時にまともに使える人はそんなに居ない 逆に言うとまともなプログラマを確保するには 良いフィルター になっているとも言える そういった人たちに安定的に報酬を与えたい それに散々描いて有るけど 設計をしっかりしないといけない これが重要で 設計をしっかりやって更に作る となると時間が掛かるのは当たり前で そういう事をしないといけない そうする事を出来る人間が本来使う物 そういう面が有るのがc++とオブジェクト指向 ここを見ていれば解るとおり オブジェクト指向プログラミングだけでも難しい その上cの元々持ってる文法的な誤認性の高さを持ったままc++は更に難しくなってる c++を使いこなすのは実際至難の業だと思う osはリーナスなんかも言ってるけど 細部まで制御して作りたいし しないといけない でもc++はかなり背景で色々な事をするから邪魔 だからcの方が向いている 最適化すら余計な事をするなって言うくらいだし まぁ当たり前だわね それでもアメリカのf-35はc++で出来てるって最近聞いて驚いた つまり時間がかかるようにしてお金がかかるようにした。 C++作者が自ら言ってるように、雇用創出だね。 >>219 科学技術や文化が後退するぞ そんなこと言っていると 設計は理不尽な方法を力ずくで遂行するのではなく 科学的工学的手法を用いて合理的にすべし 普通に、Json オブジェクト程度のものとしておけばいいのにね 何人かの常駐を除いて、意外に前スレと前々スレが良スレだよな 1 C/C++ 2 その他 C/C++それ自体は使い難いが、要らないコードを減らすため、コンピューターの仕組みを知るための C/C++。 C/C++にはいらないコードを減らす能力はないよ 結局の所、何かしらのコードは、コンピュータが自動でやるか 人間がやるかのどちらかしか無い。 コンピュータにやらせれば人間の負担は減るが、実行速度が遅くなる。 C/C++は実行速度を早くするのが第一の目的になってるので 人間がやることが多い とはいえ、ある程度同じような内容なら 同じような形で最適化できてチューンせんでも良いから高級言語ってものが成り立つわけだ。 >>227 >C/C++にはいらないコードを減らす能力はないよ 気軽にコードを書き加えられないつーことでは、無駄なコードを減らすことにも繋がるのでは? C 言語にポインタがある理由は省メモリ化・高速化・開発作業の省力化です http://pg-kura.hatenablog.com/entry/20120616/1339856279 低スキルでも読めるコードは、属人的なコードになる https://mevius.5ch.net/test/read.cgi/tech/1541173295/ 1 C/C++ 2 その他 前者のほうがスキルとデバッグの苦労が多い分、コードの書き加えに慎重になるだろう? > 前者のほうがスキルとデバッグの苦労が多い分、コードの書き加えに慎重になるだろう? それはマイナス点ですよね 高級言語は簡単にプログラムを書けてかつデバッグの労力も少ないが、要らないコードが増えやすい。 パワーポイント使用を禁止する会社が増えている理由 https://news.allabout.co.jp/articles/d/88444/ 同様にパワーポイントを使えば簡単に書類作成できるが、その分無駄な書類が量産されやすくなる。 宮本 いま、若いデザイナーがゲームをつくっている時、面白くならなかったら、ついつい新しい材料を追加して 面白くしようとするんですよ。実は、いま目の前にあるのものをちゃんと使ってそれを面白くするほうが先やのに、 新しいものを持ってくるという。 https://www.nintendo.co.jp/wii/interview/r7pj/vol1/index6.html コ ー ド 書 く の は 簡 単 だ け ど 、 コ ー ド 直 す の は 難 し い ん だ よ ! 230 デフォルトの名無しさん sage 2018/12/15(土) 01:41:14.00 ID:EyhC0X8P > 前者のほうがスキルとデバッグの苦労が多い分、コードの書き加えに慎重になるだろう? それはマイナス点ですよね > 前者のほうがスキルとデバッグの苦労が多い分、コードの書き加えに慎重になるだろう? 言語の問題よりも直交性のない書き方してるかどうかのが大きいけどな。 プログラミングに限らず、環境や部品を作る技術者と その上で部品を組み立てる技術屋を分けて考えないとな どんな業種でもなんとなく住み分けできてるのに、 プログラミングだけは技術屋が背伸びするんだよな 自分がやってる事が組み立てでしかないって感じる事すら出来ずに居るからだろうな。 犬小屋程度なら日曜日のお父さんでも作れるのと同じ。 >>234 他の業種に比べるとプログラムは再現性が高いからというのがあるのかも。 それがある種の選民思想というか万能感を産んでる気はする。 うまく行き過ぎる分野でやってる人というのは他も同じようにうまくやれると思い込む可能性が 高いのではないか。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる