コンピューターサイエンスや競技プログラミングに懐疑的な人たちは決まってソートのアルゴリズムがどうとか言う傾向にあるけど、たしかに増田の言う通り、ソートなんて自力実装するような時代ではないからその辺は無視してもらって構わないとは思う。
でもソートについて「ソートだけをして終わり」なんて実装をすることはなくて他の処理と組み合わせて存在しているものじゃない?
たとえば「配列をソートしてからサーチする」「ソートしていない配列に対して都度サーチする」「配列をハッシュマップに変換してからサーチする」要求に対してどれが効率的かみたいな判断は要る場面はあるでしょう。
「今書いているコードが呼び出す機能の一つ一つがどういうふうに書かれているかがわかったとして、一体何が嬉しいんだ?」
たとえば配列に対する.find() 的な関数があると思うが、これは「配列を先頭から順にチェックして、指定のものを見つける」ような実装であることが多い。内部的には配列長に比例する時間がかかるループが書かれている、O(N)の関数。
これを自分が実装するコードのループ内で使うと、自分が書いたコード自体は一重のループにしか見えないが、実は二重ループになっているということがあり得る。
その処理がやけに遅いと思ったとき、「find()は標準の関数だから無罪!中身を見る必要なし!」って感じでスルーしてたらコードの全体像は永遠に見えないことになる。
とはいえ、勉強したくないものを無理に勉強する必要もないとは思うよ。
サンプルで実装してあげたものの一部改変などをしてもらうぶんには知識もスキルもいらないだろうし。
https://gigazine.net/news/20210302-hacker-reduces-gta-online-load-times/
JSONをパースする処理や、配列から重複を探す処理など、増田が言う通りラップされたものを使うだけでできることではあるけど、求められる出力を満たせる部品をただ並べただけではこういうダサいことが起こりうる事は知っていてほしい。
知ってたら色々便利だけど、知らんかったら知らんかったで大半の業務はどうにでもなる以外に言うことないよな 車を運転する時に整備もできたら問題起きても便利だが、運転さえでき...
上の方の仕事をしているプログラマーたちにとってのCSの知識の位置づけがその比喩で表せているとは到底思えないんだが、、
そんなのは本当に職務のレベルによるとしか言えないわ そりゃそういうのが要る職場はたくさんあるけど、要らんとこも相応にあるやろってだけ