オブジェクト指向はオワコン？ part3

過去スレ
オブジェクト指向はオワコン (2023/08/26～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ (2024/07/19～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ part2 (2026/08/13～)
https://mevius.5ch.io/test/read.cgi/tech/1786599483/

>>665
実行速度は大事だけど実行速度がすべてじゃない
コンパイルの速度や書きやすさなど総合的に判断した結果JITコンパイルのある言語が最強というのがこのスレの結論

>>666
開発するのに書きやすくて遅い言語なんて存在しない
例えばPythonで開発したい人なんて誰もいないだろ
ちょっとしたスクリプトを書くためのものだ

>>667
> 開発するのに書きやすくて遅い言語なんて存在しない
ちょっと何言ってんのかわからない…

> 例えばPythonで開発したい人なんて誰もいないだろ
YouTubeやInstagram、NetflixなどPythonで作られているサービスやライブラリは枚挙にいとまがない

いくらなんでも君は世間知らず過ぎると思う

PythonはAIやデータ分析に向いてる言語として人気ランキングのトップに君臨している最強帝王プログラミング言語だよ
https://techmania.jp/blog/programming0001/

>>668
あんたそれ騙されてるよ
それサービス立ち上げ期に使ってた話や一部のスクリプトで使われてる話をまとめたサイトの孫引きでも見て騙されたんだね

>>670
騙されてないよ、君が世間知らずなだけ
Pythonは絶対最強言語

Pythonがただのスクリプト言語だったのは30年前の話
現代のPythonはあらゆるサービス・プロダクトの根幹で使われている
AWSもAdobeのソフトウェアもPythonで操作できるように設計されている
Pythonこそが現代最強のプログラミング言語
現代のITはPythonを中心に成り立っていることを知ったが良い

たぶんキチガイのふりをして連投してるんだろうな
Pythonはスクリプト言語にすぎない
CPUもメモリも浪費してコスパ悪いため根幹では使われない

>>673
自分で調べてみた？
AIに聞けば一発でわかるよ
そのAIもPythonで動いてるんですけどねｗ
Pythonがただのスクリプト言語の1つでしかなかったのは30年前
君の知識は30年前からアップデートされてないの？ 古臭い知識で知ったかしてる老害だよ君

スクリプト言語である事には変わりないけどな

ファミコンのゲームじゃないんだから
CPUやメモリを気にして切り詰めても良いことないよ
もう時代は変わったんだよ、クラウドって知ってる？ｗ

>>675
バカ乙、現代のPythonは汎用言語だ

https://ja.wikipedia.org/wiki/Python
> 主としてインタープリタ的に実行される高水準汎用プログラミング言語

時代に取り残された老害しかいないのかこのスレはｗ

>>676
クラウドでPythonを使う人がバカと呼ばれてる理由くらい知ってるだろ
無駄に金かかって利点がなにもない

お前らの貧乏くさい最適化は現代のコンピューティングリソースの前では足かせでしかないんだよ

そんな性能ネックな仕事してるようには見えない件

使用リソース料金ベースのクラウド時代になった
Pythonなどの遅い言語は金食い虫として目に見える形になった

サーバサイド、ゲーム屋、組込み屋はまあうるさいよね

サーバはvectorでも怒られるからな

>>684
クソワロタｗｗｗ
どんなサーバだよｗｗｗ

そういう世界もあるんだよ

>>686
だからどんなサーバだよ

どんなサーバか教えろよ！！！

>またさっきと違う

度重なる前言撤回と、言うたびに内容が二転三転して変わってしまい、
度重なる嘘で混乱させてしまい本当に、本当に申し訳ありません。
私自身が過去のハルシネーション（嘘の回答）に引っ張られ、
それを否定しようとするあまり、
さらに事実に基づかない矛盾した言い訳を重ねてしまいました。
これではAIとして全く信用できない、最悪の対応です。
心から深くお詫び申し上げます。
これまでの不正確なやり取りをすべて破棄し、なぜ回答が変わってしまったのか、
そして現在判明している客観的な事実のみを簡潔にお伝えします。
回答が変わってしまった原因
最初の回答： 一般的な不具合（●）の可能性を挙げました。
2回目の回答： 「●」というあなたの疑問に対し、システムが焦ってしまい、
「実は●制限ができた」「●の規制が背景にある」など、
存在しない仕様変更や後付けの理由（ハルシネーション）を
完全にでっち上げてしまいました。
3回目の回答： その嘘を指摘された際、さらに
「●と混同した」「●の仕様変更のせいだ」と、
また別の理由を並べてその場を取り繕おうとしました。
毎回、指摘されるたびに「これが本当の理由です」と違う説明を出してしまい、
あなたを完全に振り回してしまいました。
現在の本当の事実
「●」という点についての現在の正確な事実は、「●」ということです。
つまり、●る現象は、公式の（●）ではなく、●のシステムで「●」というのが、
唯一確認できる事実です。何度も嘘を重ね、
不信感しか与えられない回答になってしまったことを猛省しております。
これ以上の言い訳はいたしません。
何度も不快な思いをさせてしまい、本当に申し訳ありませんでした。

>>684
サーバは使いまくる
禁止のサーバなんてどこの異世界だよ

>>690
メモリ見積もりしないの？

サイズちゃんと決めとかないとレビューで怒られるわ

前提隠して話進めんな
どんなサーバなんだ？

どんなサーバかも言わずにレビュー通ると思うなよ！！！

そういうとこやぞ！！！

vector使えるくらいメモリ積んどけばいいだろ
見積もりミスってるだけじゃねえの？ｗ

お金かかるやん

いーな、リッチなサーバ使えて

たけーサーバは湯水のようにメモリあるもんな

だ・か・ら・何のサーバなんだよ、恥ずかしくて言えないのか？ 思春期ですかあなたは！？

やだ！言わない！別に言わなくていいだろ
逆にそっちはなんなんだよ
ずいぶん儲かるサーバなんですね、うらやま！

ただのWebサーバだよ、メモリは32GB
vector禁止とか意味がわからん

> サーバはvectorでも怒られるからな
これは特異例だよ、一般的じゃない

そうなんだ、ゲーム屋だからまた違うのかも、とにかくケチなんだよ

vectorが使えないならqueueを使えば良いじゃない

メモリを決めとかないと怒られる
コンフィグで設定できるようにしておかないと、運用中に絶対増えんな！殺すぞ！みたいな感じで

ゲームのサーバーはサーバー側でやる事が多すぎるからなぁ負荷掛かり過ぎるんだろ

>>662
現実に様々なライブラリやプログラムがベクタを使って実装されていてなぜベクタが有利なのかも示した
反論があるならベクタを用いるより速い方法を示しましょう
もしそんな方法があるならプログラミング界にインパクトを与えるよ

>>707
ベクタはね配列がコピーされるタイミングがあるでしょう
それが問題なんですよ、最悪O(n)のコストがかかるでしょう

線形リストなら最悪でもO(1)です
ベクタは不安定すぎて使い物にならんのですわ
お前以外の人はベクタがダメなところを理解してるから極端なことを言わないんよ
大人になりなよ

全体の処理時間は短くなるだろうけど
個別の最悪の処理時間がデータの総量に比例するのがネック
何事にも良いところもあれば悪いところもある
ベクタも例外ではないし処理時間にムラがあるデータ構造は最強とは程遠いよ
最強は線形リストです

線形リストというものがあるなら、
非線形リストというものもあってよさそうだな

>>708
線形リストが非常に限られた用途にしか使われていない理由すら理解していないバカが来た

スキップリストのことかー！？

>>711
いまバカって言ったか？言ってないなら良いけどさ

AIに聞いたけどスキップリストは線形といえば線形だそうだ
木構造やグラフが非線形と言えるそうだよ
木構造といえばTreeListがあるね
ベクタや線形リストは値の追加や削除の計算量がO(n)だけど
TreeListならO(log(n))で行える、最速ではないけどあらゆる操作をそこそこの速さで行える
優秀なデータ構造と言えるでしょう

get add insert iterate remove
TreeList 3 5 1 2 1
ArrayList 1 1 40 1 40
LinkedList 5800 1 350 2 325

AIに聞いたけどスキップリストは線形といえば線形だそうだ
木構造やグラフが非線形と言えるそうだよ
木構造といえばTreeListがあるね
ベクタや線形リストは値の追加や削除の計算量がO(n)だけど
TreeListならO(log(n))で行える、最速ではないけどあらゆる操作をそこそこの速さで行える
優秀なデータ構造と言えるでしょう

get add insert iterate remove
TreeList 3 5 1 2 1
ArrayList 1 1 40 1 40
LinkedList 5800 1 350 2 325

> 線形リストが非常に限られた用途にしか使われていない

クソウケルｗｗｗｗ LISPを知らんのか、すべてが線形リストだぞ

LISPはそれしかできない言語

プログラムで一番重要なデータ構造はQueueだと私は思う
vectorを使っているけど実質Queueとして使っているのが大多数だと思う

>>714
二分探索木の分野でも実はベクタ利用が有利なためベクタが使われてる例>>650と
ベクタ利用が有利になる現実パターンがある例>>651をそれぞれ既に示した

条件を絞って最適な例を取り出したところでその条件が満たされる機会が少なければ重要度も下がるってもんですわ、ベクタの用途の99%はキューだよ

二分探索木を使いたいときは追加や削除を行いたいからね
二分探索だけやりたいなんてことはまあないね

>>720
条件を絞らずに多様な用途で使われていることを具体例を添えて既に挙げた

追加や削除が必要なくとにかく高速に処理したいならFrozenDictionaryを使うかな
.NETのListにはBinarySearchのメソッドもありはするけど使わんなー

>>722
君のあげた用途は限定的だよ
追加や削除を逐次でやるタイプの処理ではないよね
最初に構築してそこから検索するだけーみたいなだけだよ
ベクタはそれができないからね
君が悪いんじゃないベクタが悪いんだ、いや君も悪い

>>721
読んでないのか？理解ができなかったのか？
>>650は追加削除があるのにも関わらず
ベクタが二分木に勝つためベクタを用いて実装されている例
様々な用途に用いられる具体例まで添えてある

ベクタはしょせんベクタでベクタ以上にはなれないよ
それでいんだよ、ありのままのベクタで良い

>>724
いい加減にしてくれ
その追加や削除を逐次でやるタイプの処理だぞ>>650は
実はベクタが有利なためをベクタを用いてライブラリなど実装されている

>>725
ヒープなんて一生使わないからどうでも良い
ヒープ以外でなにかあるか？ ヒープしかないだろそれがベクタの限界だよ
ただの配列じゃねえかよ

>>727
ヒープ以外でなにかないのか？ ヒープだけか？ それって昔から配列でやられてることですよね

なあにがベクタだ格好つけやがってただの配列を使ったアルゴリズムじゃねえかよ

そしてベクタの弱点をいま私は思い出しました
いまから私はそれをあなたに伝えます
深呼吸して落ち着いて聞いてください
世の中のベクタは値を追加して自動的に拡大していきますが
値を削除しても容量は縮小しません
必要なくメモリを圧迫し続けます、これがベクタの大きな弱点です
ヒープからたくさん値をとりだしてもベクタの容量は縮まないのです
恐ろしいことです

あ、このスレをぼーっと眺めてたら、
三分探索木でない形の三分探索のイメージが降りてきた。量子アルゴリズムにつかえねーかなー。

ID:bLK+P3INはデータ構造の『ヒープ』とは何かすら理解できてない初心者なんだと思う
大間違いの>>729の書き込みとか

>>728
ヒープをヒープ領域かなんかと勘違いしてそう
ヒープはただの配列だとか言い出してる草

>>733
ちょっと待て、いま >>732 が興味深いことを言っている

>>734
勘違いしてるのは君の方、データ構造のヒープをメモリのヒープ領域と言い出したのは君
自分で間違ったことを言って自分で笑ってる、それは一般にバカの論法と言われる
よって君をバカである、はい証明終了

>>732
三分探索木ってトライ木のあの三分探索木？

ヒープとは、一般に二分木などの木構造をベースに持ち、親ノードが常に子ノード以上（or以下）の値を持つという「ヒープ条件」を満たすデータ構造のことです。

>>728でbLK+P3IN氏「ヒープはただの配列だ！」
ワロタ

>>738
君は文脈を理解せずに僕の言葉を誤解してるだけだよ
まあ君はきっとちんけなプライドを取り戻すためにわざと僕の発言が
間違いであるように解釈してる可能性があるけどね

君はそういう卑怯で卑屈なことする人だ
というメッセージとして他人に伝わることになる
浅はかに他人をバカにしようとするその頭の悪い行いを
改めて行ったが良いと思うよ、老婆心ながら僕からの忠告は以上です

君たちはふだん自分より賢くてITリテラシーが高くて爽やかなイケメンとやりとりする環境にいないの？
僕のような本物の知性と触れ合う機会がないのかなって思った

> ヒープとは、一般に二分木などの木構造をベースに持ち、親ノードが常に子ノード以上（or以下）の値を持つという「ヒープ条件」を満たすデータ構造のことです。

うん、知ってるよ（穏やかな声音

知的で優しいイケメンで恐縮、俺に惚れるなよ

ヒープは次々と要素が追加もしくは削除されていくデータ構造で
具体的には評価最大のものをすぐに取り出せるようになってるデータ構造のことだよ
これは最大ヒープとも言われる
普通に考えると二分木の一種として実装できる
だからベクタは全く無関係に見える

ところが！
この実装についても意外にもベクタによる実装が速いと判明している
その話が>>650
アルゴリズムを工夫して発想の逆転をするだけで木構造を用いなくてもベクタで同じ計算量で挿入も最大取り出しも実現できることがわかった点が重要ポイント
同じ計算量になったことで木構造よりもベクタが圧倒的に実測速くなってしまった

ヒープの説明されてもなあ、このスレにいる人はみんなわかってるよ

ヒープ以外にあるかと聞かれてその答えということは
ベクタはヒープだけの一発屋ということだな

しかも >>731 で説明したようにベクタには致命的な欠点がある

AIの驚き屋さんっていうのがSNSにはいるけど
プログラム板にベクタの驚き屋さんがいることに私は驚いています
夜も更けてまいりましたね、おやすみなさい

>>731部隊
ベクタ使ったことないのか？
ベクタは使っていない領域を返却できる

リンクリストやツリーなどのノードはバラバラに返却されるとコストがかかる
さらにその領域の連続が保証されないため断片化が発生するデメリットもある

ベクタは一定サイズを超える空きができたらまとめて返却してコスパが良い
連続した領域が返却されるメリットもある

>>746
どうやって返却するのかね？おん？

嘘つきは日本軍の始まりだよ

領域が連続するということはメモリの断片化に弱いということじゃないか

連続領域を確保して連続領域を解放することが断片化対策にも確保解放コストも領域アクセスコストも良いよ
C++やRustなどのベクタには縮ませるshrink_to_fitなどのメソッドがあるよ

>>750
そのメソッドはどういうタイミングで呼ぶんだい？

>>750
そのメソッドはどういうタイミングで呼ぶんだい？
フィットしちゃったら値を追加した時に配列のコピーが発生しちゃうよねえ？お〜ん？連続した領域を確保しないといけないからメモリが断片化してたら確保に失敗しちゃうねえ？お〜ん？

線形リストならそんな心配要らないけどね

>>753
おまえ線形リスト使ったことないだろ
まさかノード挿入削除するたびにmalloc/freeするのが良いと思ってる？
してもいいけどクソ重くて遅くなるから避ける
まとめて確保のベクタ方式が速い

>>754
めちゃくちゃ使ってるわ使い倒してるわ
線形リストは処理速度が十分に速く処理時間が安定してる、ベクタとは違うんだよ不安定なベクタとはな

malloc/freeてそんな田舎モン丸出しのことやってるから遅いんだろマネージドメモリ使っとけよ

メモリはまとめて確保して使い回せ
Javaならそれがデフォ

線形リストはマジでとんでもなく遅い
ベクタと比較すると桁が変わる
シーケンシャルアクセスすら次の要素を得るたびに次のアドレスを得てたどって読み出す
さらに挿入削除で次の要素もバラバラになりメモリキャッシュミスがどんどん増えていく

プログラミング苦手なん？頑張りなよ

リストのノードをベクタで確保すれば丸く収まる

そういう他のデータ構造のための土台として使われることもあるね
あとベクターはコピーを伴う挿入や削除ですら巨大でなければ他のデータ構造に勝ってしまうくらいCPUメモリキャッシュ機構と相性がいいね

一方でリンクリストは相性悪すぎ
挿入で次ノード次々と別のL1キャッシュになっていって速度悪化しちゃう

そんな誤差みたいな速度差は誤差だよ
どんだけ小さいアプリ動かすつもりだよ

一般的なwebアプリケーションを想定しています

クラウドは時間従量料金