[過去ログ] Git 18 (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
740:  (ワッチョイ 497b-vCJ4) 2022/11/01(火)08:51 ID:Jzc3CN/20(6/8) AAS
 補足。 
  
 分からなければ「OOP 抽象化」でググって色々読んでみてくれ。 
 死ぬほどでてくるはず。マジで基本中の基本だから。 
 ハッシュを交換することに手こずるようなら、その『コード』は間違いなく糞だ。(Git自体が糞と言っているわけではない) 
 ただ、修正すればいいだけ、要は漏れなく上記のようにしてしまえばいいだけではあるが。 
  
 正しく構成すれば、Hash変更なんて簡単に出来るし、 
 そもそもそうなってないコードなんてOOPでは存在を許されてない。 
 (そうとは書けないように構成されてる。 
 それを強制的にやらせるシステムの一つがprivateだが、これはこれで間違った使われ方も多いが) 
741(1):  (ワッチョイ d9e4-Xmag) 2022/11/01(火)09:16 ID:kz7RaJ2H0(3/5) AAS
 長々とご苦労さんだがお前SHA-256対応の意味が理解できてないよ 
742(1):  (ワッチョイ 497b-vCJ4) 2022/11/01(火)09:26 ID:Jzc3CN/20(7/8) AAS
 >>741 
 俺は以下記事の理解書いてる。 
 俺が書いた事の意味が分からないのは君の問題。 
 外部リンク:www.infoq.com 
 ただ、初めてOOPを示されていきなり意義を理解出来る奴はほぼ居ないのも事実。 
 でも、君は確実に老害扱いされてると思うよ。 
743:  (ワッチョイ f15f-iYvO) 2022/11/01(火)09:32 ID:WFTKMpG40(1) AAS
 なんだか知らんけど5chでうだうだ言ってて何になるの 
744(1):  (ワッチョイ d9e4-Xmag) 2022/11/01(火)09:36 ID:kz7RaJ2H0(4/5) AAS
 >>742 
 君はその記事の意味することを理解できてないね 
 コミットオブジェクトの構造とか役目を理解出来てないと難しいかもしれない 
745(2):  (ワッチョイ 497b-vCJ4) 2022/11/01(火)09:57 ID:Jzc3CN/20(8/8) AAS
 >>744 
 そう思いたいんだろうけど、残念ながらそうじゃない。 
  
 少なくとも君はソフトウェア階層やOOPの基本事項について全く理解出来てない。 
 だから今、老害と言われ続けるか、再び学び直して熟練者と言われるかの分水嶺にいるだけ。 
 俺は君に何も強制することは出来ないが。 
  
 確かに俺はGit初心者なので、記事の理解は間違ってるかもしれない。 
 でも、ハッシュの中身や長さが変わったり混在したところで、 
 正しく構成されてるソフトウェアなら数行の変更で対応可能なのは事実だよ。 
 そして君と同様の人達によってGitが作られているのであれば、 
 そりゃそうなってなくて苦労するんだろうさ。 
まあいいけどね。もう水掛け論だから終わりにしようぜ。これ以上やってもお互い得る物もないし。 
746:  (ワッチョイ 8b8f-5UCg) 2022/11/01(火)10:12 ID:ju8ytuSJ0(2/2) AAS
 > GITは、すべてのファイルオブジェクトとコミットの識別と整合性チェックをSHA-1に強く依存しています 
 こう書いてあるのになんで無視するんだろう 
747(1):  (ワッチョイ d9e4-Xmag) 2022/11/01(火)10:29 ID:kz7RaJ2H0(5/5) AAS
 >>745 
 数行で対応w 
 それが出来ないgithubは無能集団なんですねw 
 糞MSに買われちゃうぐらいだから仕方ないか 
748:  (オッペケ Src5-8VyY) 2022/11/01(火)12:34 ID:lDKItQe4r(1) AAS
 Git初心者に語らせると頓珍漢な文章が生まれるという好例 
749(1):  (ワッチョイ 8bbb-VzUj) 2022/11/01(火)12:39 ID:QdibabTL0(2/2) AAS
 >>745 
 お前日本語読めなさそうだな 
 ましてやリンク先にある英語とかかけらも理解できてないだろ 
 混在とかじゃないぞ。二つを同時につけて「安全」に相互変換するということだぞ 
 安全にすることが目的でSHA-256を使えば解決みたいな話じゃない 
 お前みたいなのが目的と手段を取り違えるタイプの典型 
 OOPとかアホなプログラマでも理解できる単純なことなわけないだろ 
 そんなんで済むならとっくに終わってる 
 まずは常識で考えろ 
 できないなら黙って勉強しろ 
750:  (ワッチョイ 699f-1Eu/) 2022/11/01(火)18:29 ID:/+vO/8+o0(1) AAS
 長文すげー 
751:  (ワッチョイ 497b-vCJ4) 2022/11/02(水)05:40 ID:n+gr/3CY0(1/2) AAS
 >>749 
 どうであれ同じだよ。 
  
 複数付けようが、何をどう組み合わせようが、 
 抽象化の向こうの実体については知らないし、取り扱うコードも存在してないから、 
 同じバイナリで動作するんだよ。それが抽象化と隠蔽で、これはOOPの基本中の基本。 
752:  (ワッチョイ 497b-vCJ4) 2022/11/02(水)05:41 ID:n+gr/3CY0(2/2) AAS
 んー、お前ら完全に化石だわ。若い奴からは確実に馬鹿にされてるよ。 
 というか、現在において有名OSSにこんな化石居住区が存在してたことにびっくりだわ。 
  
 >>747 
 数行ってのは誇張ではなく、実際にそんなもんなんだよ。 
 例えばMMDは3DVision対応に20-30行と言ってるが、 
 > そのため、樋口氏がMMDの3D Vision対応に要したのは、20~30行程度の簡単なコーディングのみだった。 
 > 外部リンク[html]:pc.watch.impress.co.jp 
 この樋口氏はVer5->7でDirectX対応してて、その時もインタビュー受けてて(ググッても出てこないが) 
 確か「よくよく確認して、実際に変更する必要があるのは2-3行だったのでほっとしました」 
 とか言ってたはず。 
  
 これは特殊ケースではなく、こうなるように設計するんだよ。 
 これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。 
 だから糞なソースも「頑張って」修正して何とかするんだ、のノリだ。 
  
 ソフトウェア工学はそんなのは20年前にクリアしてて、今は、 
 A. どうすれば変更に対して強くなるか(仕様変更があってもソースコードを変更せずに済むか) 
 B. どうすればそもそもソースコードを記述する必要すらなく出来るのか(全ての状況に対し同じバイナリで対応する) 
 C. どうすれば出来るだけ早い段階でバグを検出出来るか 
 とか移ってて、大体馬鹿がCに対して悪ノリしてるからLinusがこき下ろす事態になるのだが、 
 ABはちゃんとやらないと話にならないよ。 
  
 だからまあ、次のGitは「勉強をがんばらなくてすむGit」で、 
 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。 
 でも君らは「頑張らなくちゃいけない」「頑張るべきものだ」と思っちゃってるみたいだから、 
 今のGitプロジェクトからはこれは出てこないだろう。 
 となると、上記のようにして簡単に実装したNext-Gitに成果をかっさらわれ続ける事態になると思うよ。 
 ちょうどGNU/Linuxの形に似てるが。 
 あれはLinusが悪いわけではないし、ストールマンも別になんとも思ってないようだけど。 
753:  (ワッチョイ c114-Tk+f) 2022/11/02(水)06:01 ID:z+vraLDY0(1/2) AAS
 > これは特殊ケースではなく、こうなるように設計するんだよ。 
 > これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。 
  
 それあなたの感想ですよね? 
 gitはソースコード1行程度で変更終わりですよ 
754:  (ワッチョイ c114-Tk+f) 2022/11/02(水)06:03 ID:z+vraLDY0(2/2) AAS
 > 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。 
  
 シェルスクリプトは移植性低いって分かってる? 
 シェルスクリプトでラップしようものなら 
 Linuxでは動くがFreeBSDでは動かないってことが 
 しょっちゅう発生する 
  
 シェルスクリプトで頑張るものじゃない 
755(1):  (ワッチョイ d9e4-Xmag) 2022/11/02(水)07:01 ID:S2ENS6Jw0(1) AAS
 git の一部機能は git コマンドを使ったスクリプトで実装されていたんだけど、多くのユーザーの要望に応える形でそれらのC言語化進めてる 
756:  (JP 0H8d-8VyY) 2022/11/02(水)09:34 ID:33j+wJW8H(1) AAS
 シェルでラップw 
 USPから悪い影響でも受けたか? 
757:  (ワッチョイ 8bbb-VzUj) 2022/11/02(水)10:35 ID:sFE/M4aa0(1) AAS
 OOPなんて初心者プログラマ訓練ギブスってことを理解できなくてアホ理論展開しているやつがいてw 
758(1):  (ワッチョイ fb66-Q7eZ) 2022/11/02(水)14:42 ID:LlnSL/r70(1) AAS
 OOPなんか、そん辺のサンデープログラマでもかなり深い所までメリットデメリット含め浸透してるがな。 
 関数指向やクロージャがある言語も同様で 
 もはや当たり前のようにハイブリッドになってて一部の原理主義者以外いい塩梅で使ってるから話題にはならん。 
759:  (オッペケ Src5-5UCg) 2022/11/02(水)15:33 ID:4T0OIw/dr(1) AAS
 OOPそれほど語るなら、お前の大好きなシェルスクリプトはみんなOOP意識して作られてるのかって感じだな 
760:  (ブーイモ MMdd-ntN1) 2022/11/02(水)18:08 ID:mw55lzgRM(1) AAS
 リーナスを中心としたOSSコミュニティの起源にタネンバウムとのモノリシックカーネル・マイクロカーネル論争があることを知らないのかな? 
 結果として無駄な抽象階層を積み重ねることの無意味さをLinuxカーネルの成功が証明してしまった 
 もちろんLinuxカーネルもファイルシステムとか必要なとこは抽象化されてるけどね 
761:  (ガックシ 06dd-uk66) 2022/11/02(水)18:41 ID:1AIcQZnX6(1) AAS
 今どきの若い奴(というか最新の風潮)ってなんでもかんでもオブジェクト指向を徹底するって感じじゃないと思うけどなあ 
 それこそオブジェクト指向主義みたいなのが滅茶苦茶強かったのって20年前ぐらいじゃない? 
 WindowsもNTでマイクロカーネルにしたけどオーバーヘッドデカすぎて一部はカーネル空間に戻したりしたでしょ。 
 SIerの階層が深い開発なんかだとオブジェクト指向を徹底しないと事故が起こりそうだけど、そういうとこしか知らない人間なのか? 
762:  (オッペケ Src5-8VyY) 2022/11/02(水)22:26 ID:KtYxSAYnr(1) AAS
 何でもかんでもシェルでやろうとするやつは病気 
 名前を呼んではいけないあの開発手法とか推してそう 
763(2):  (ワッチョイ 497b-vCJ4) 2022/11/03(木)05:47 ID:AHw2USmo0(1/17) AAS
 >>755 
 それはどのプラットフォームで問題になったの? 
 賢い選択とは思えないけどね。 
 具体的なデメリットは既に666で挙げたとおり。 
  
 俺はシェルの互換性問題なんて有ったとは思えないけど、 
 (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。 
 ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ) 
 それが問題なら、GitのC化ではなく、直接シェルの互換性を上げるのが常策だよ。 
 互換性がC化で達成出来るのなら、 
 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、 
 gsh(=gitsh)だ!これを使え!と強弁すれば済んだろ。 
  
 なんかやっぱり無能の働き者を地で行ってる気はする。 
 仕事を減らす努力をしてないよね。 
764:  (ワッチョイ 497b-vCJ4) 2022/11/03(木)05:49 ID:AHw2USmo0(2/17) AAS
 >>758 
 その通りだ。だからアマチュアの樋口Pも正しく対応出来てた。 
 だからこそ、このスレのこれまでのやりとりに驚いている。 
 今時初心者でも、他言語スレでもあり得ない流れだ。 
で、パッチ出てきたけど、あれでは駄目だね。 
 彼等はC流のメモリ管理の方法を知らず、Gitは完全に糞コードで出来てる。 
 あれでは他にもメモリリークだらけだよ。 
 (ただこれも想定内っぽいし、 
 リークしたところでアプリとしては大した問題でもないのも事実だが) 
  
 彼等は、バグを直す努力はしているが、 
 バグが出にくいコードにする努力は全くしてない。 
 OOPもやりすぎると問題だが、何故彼等はそうするのかを学んで、 
 美味しいところだけ貰えばいいのにとは思うよ。 
 OOP原理主義者も、Gitプロジェクトやこのスレ民みたいなOOP排除原理主義者も、同様に問題だよ。 
765:  (ワッチョイ 497b-vCJ4) 2022/11/03(木)06:07 ID:AHw2USmo0(3/17) AAS
 ただ見る限りGit界隈は密結合主義のようだ。 
 つまり、Gitと知識的に密結合した、Gitに詳しい奴だけがGitを使うべきであり、 
 tutorial1が基本コマンドなら普通はtutorial2は応用コマンドのところ、 
 なんと内部データ構造の紹介になってるし、 
 (ただこれは俺には極めて有効に作用したが、普通はブーイングの嵐だろう) 
766:  (ワッチョイ 497b-vCJ4) 2022/11/03(木)06:07 ID:AHw2USmo0(4/17) AAS
 ソースコードも密結合、これは馬鹿除けだ!と言い放つ。 
 糞コードでもパッチの手数で勝負だ!カリスマLinusならモグラ叩き志願者は無限に募れる! 
 とまあ、他の誰も出来ないアプローチだね。 
 ただまあ、ソースコードを清潔に保つ目的は長期的メンテの為であり、 
 それは実際出来てるしいいだろ、と言われれば、はーそうですねー(棒)だが。 
767:  (ワッチョイ 497b-vCJ4) 2022/11/03(木)06:07 ID:AHw2USmo0(5/17) AAS
 これ見てたら、buggyな糞コードでもとりあえず動けば受け入れてどんどん改訂し、バグもパッチの手数で勝負するのと、 
 普通のプロジェクトがやってる、レビューして駄目なコードは最初からrejectするのと、 
 (つまり手間をかけてもrejectされる可能性があるからコードを投げるのを躊躇される) 
 どっちが良いのだろう?とは考えさせられるよ。 
 リソースが無限にあるOSSでは、前者の方がいいのだろうか? 
 LinusはBillJoyに対して「オープンソースを理解してない」と思ったらしいが、こういう事なのだろうか? 
 (この発言はLinus著作本にあるらしいが、俺は読めてない) 
  
 しかしこのアプローチでは、絶対に浄化はしない。 
 自分の糞を片づけるのは仕方ないとして、 
 他人の糞を片づけたがる奴はいないし、そもそもその界隈が掃除に価値を置いてない。 
 しかし糞コードならどんどん投げてもらえるし、それらを受け入れる限り、進化が止まることもない。 
 はーなんだかねー。なるほど研究者と色々衝突するのも分かる気はする。 
 そういや大昔「伽藍とバザール」読んだなーと思って今読み返してみたが、これがバザールなのか? 
  
 (NGにかかったので分割した) 
768(1):  (ワッチョイ d9e4-Ojdt) 2022/11/03(木)10:41 ID:NhDXzDSd0(1/3) AAS
 それだけ文句あるなら本家MLで言うか自分で作り直してみろよ軍師様 
 これだけ大口叩いておいて英語のMLでコミュニケーションとれないとかだったら笑うが 
 Git は世界中のプログラマが使ってる最重要プロジェクトで、これが改良されるとなれば世界中から絶賛される 
769:  (ワッチョイ 699f-1Eu/) 2022/11/03(木)10:46 ID:odT0DHDr0(1) AAS
 まだやってのか 
 暇そうだな 
上下前次1-新書関写板覧索設栞歴
あと 233 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ
ぬこの手 ぬこTOP 0.023s