  |
はてなキーワード: イテレータとは
プログラミングという言葉がアフィブロガー御用達になって、SNSでプログラマーを名乗るのが憚られる感じの昨今。
プログラミングを勉強すればフリーランスで一生困らないみたいなこと書いてあるけど、そんな夢のスキルじゃないよ。
それなりにベテラン()を見てきたけど、結局はマネジメント層になれなければ会社にしがみつくことになる人が多い。
これはvueかReactか、javaかRubyかみたいな話じゃなくて、もう少し基本的な部分。
例えば大きいのはオブジェクト指向とクラス/インスタンスの概念。
他には、ガベージコレクタ、例外処理、マルチスレッド、デリゲートやラムダ式、非同期処理、バインディングとビューモデル、イテレータ、null安全。
今プログラミングを学んでる人には当たり前かもしれないけど、これらは十数年かけて徐々に当たり前になっていった。
ITバブルでブイブイ言わせていたけど、これらをうまく扱えないベテランは結構いる。
固定長メモリとポインタとmemsetで全てをまかなってきた層や、静的なモジュールで全部の画面を作ってたVB屋とか。
若いころは勉強すればいいと思うだろうが、理解はできてもそれを流暢に使いこなし適合するのは意外と難しい。
プログラムの中でその人の担当箇所だけいまいち読みにくくて、取り回しの悪いものになってしまう。いわゆるstaticおじさんというやつ。
これはベテランのイラストレータやシナリオライターが、デッサンや構成力はあっても、なんか古臭いものが出来上がってしまうのに似ている。
こうなると若いチームメイトや新しいプロジェクトからは敬遠される。
もちろん、COBOLの案件が未だにあるように、レガシー資産を利用した仕事で腕を振るえる場所は結構ある。
ただそういった環境は既存の人材・企業にがっちり掴まれてることが多く、後から見つけて入り込むのは簡単ではない。
今更、こんな本を読む必要はないです。いや、出版された当時でも実質的な価値はなかったと思います。
また、挙げられている23個のパターンには特に根拠はなく、著者が思いついたものを挙げただけです。
Code Completeにも書かれているように、GoFのデザインパターンは使える状況で使えば保守性が上がるというものでありません。たいていの場合は無駄に複雑になるだけです。必要のない場面では使うべきではなく、使って良さそうに見える場面でも、ドメインモデルを再検討した方が良いです。優れたソフトウェア開発者であれば必ずそうします。
GoFを推薦している人というのは、以下の特徴があるように見えます。
実際は、GoFのデザインパターンはほとんど有用ではなく、またまともなプログラマなら仕事の片手間にぺらぺらと読んでいれば、内容も底の浅さも理解できる程度のものでしかないのですが。
これと非常に似たものに、麻雀の点数計算があります。麻雀の点数計算は、普通の知能のある人からは無意味に複雑なものに見えますが、麻雀プレイヤーの多くは合理的なものだと思っているようです。この理由は単純で、大多数の麻雀プレイヤーは頭が悪いからです。だから、点数計算が無意味に複雑なシステムであることが理解できず、また普通の人なら1日で覚えられる点数計算を苦労して覚えたから価値あるものだと思いたがるわけです。
誤解しないでいただきたいのは、「デザインパターン」という概念自体は重要であるということです。しかし、GoFは別に「デザインパターン」の原点とか典型とかでは全くないのです。理解力が低いとそういう勘違いをしてしまうようですが。
この会話ログはフィクションであり、実在の人物・地名・団体とは一切関係ありません。
坂木
わろた
坂木
自分が理解できないものを意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。
安原
NTPsec が，ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした（こなみかん
宮森
今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。
宮森
……が、理解できないものに対して、理解を試みず～すべきだ～と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。
安原
いや，私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います． ownership に理解を示さないコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です．
宮森
いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている（思い込んでいる）人たちですんで……こわちかは同意。
安原
いや，私は C で開発してきた人たちの多くは，そもそも ownership の概念を獲得していないのではないかと危惧しています．元々，私はもっと楽観的で，多くの C プログラマは ownership の概念を獲得していると思っていました．
宮森
安原
OpenSSL の騒動の時，関数の途中で return したことによるリソース漏れを揶揄したことがあります． OpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ， ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました．
安原
藤堂
安原
むしろ C++ によって ownership という概念が明確になり，その重要性が認知されるようになったのではないでしょうか？ これについては，私は歴史的なことが分からないので真偽のほどは何とも言えませんが．
宮森
シニアな開発者にしかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。
宮森
OSとかシステム系のプログラマの人々、基本的にリソースは人間が適切に管理するし管理できると考えている人が多い印象（[検閲削除]社時経験）。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。
坂木
[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。
今井
今井
リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)
安原
うーん，数値計算系のチームやコミュニティも ownership の概念の獲得，重要性の理解，その管理を自動化することへの理解，これらを期待するのは難しいだろうなあ……．そもそも高度なリソース管理が必要になる場面少ないし……．
坂木
コードの品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。
安原
OS 実装とかシステムプログラミングって，クライアントに直接接しないだけで，その上にクライアントサイドソフトウェアが載るわけで，コードの品質が強く求められると思うのですがそれは……．まあ， API とかで切り離されているので，そこだけしっかりしていれば，という話はあるか．
宮森
坂木
今井
あとは、デモが作れればいい、的なのも同じかなぁ。
宮森
宮森
安原
今井
まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。
坂木
今井
宮森
いろいろ言っていますがワタクシ、そういう管理が必要なプログラムは全く書けなくなりましたので今書くと死にます（プログラムと顧客の大事なデータが）
安原
しかし，システムプログラミング界隈に「人間はリソースを適切に管理できる」という悪しき信仰がはびこっているの，何か構造的な原因があったりするのかなあ？
宮森
システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
宮森
宮森
坂木
Linux カーネル、一体どうやったらあの規模のコードをクオリティコントロール出来るのか本当に不思議
安原
坂木
Linux カーネル、属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバい系レビュアーがごろごろしているのかな
宮森
安原
私も [検閲削除] のコミュニティを見てましたから，各々必要なドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡のアンサンブルを奏でうる場合がありうるのは理解しているんですが，本当にただの奇跡でしかないと思っています．
宮森
つーても機械エンジニアリングで町工場の職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。
宮森
なおその対極がみずh（省略されました
安原
Linux カーネルにおけるスケール云々は， Linux カーネルのコミュニティ自体におけるスケーラビリティではなくて，（システム）プログラミングコミュニティ全体（他のプロジェクト）へスケールするかどうかを言ったつもりでした．
坂木
宮森
C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。
安原
＞ システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
これが原因だとすると，やはり Rust だ……Rust しかない……．ツール周りとか，まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば……．
坂木
坂木
イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……
藤堂
1.0 以前のことは忘れましょう (本当に unstable)
安原
坂木
安原
「Rust 経験者」という条件でプログラマを募集して，それで入ってきた人材に C を書かせればよいのでは！(ﾋﾟｺｰﾝ!
藤堂
犯罪ですよそれは
安原
はい．
藤堂
安原
まさにそれをイメージしていました．
宮森
藤堂
うーん、それ以降の話は知らず
今井
Rust そして誰もいなくなった、にならないかが一番心配だったりする
安原
それな
宮森
もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコードを生産しているからなのでは、という気がしてきた……。
（この辺で一同寝落ち）
教科書的には、その回答で合ってると思う。Java屋じゃないんで詳しいことはしらないが。
教科書レベルではなく、現場レベルでは、違うと思うので、ようはポインタとしかとらえていない。
そもそもなぜVector,List,Map などの複数のデータ保存形式があるか？
といえば、データの種別や、それの検索方法、取り扱い方法により、保存方法を変えた方が効率的だ。
という側面から来ている。
そういった、異なるデータには、異なる方式のデータ構造という構造を取っておきながら、
アルゴリズムは共通です。というのにどれだけ意義があろうか？という事。
たとえば、Vectorであれば、コピーならばmemcpyなどの専用命令でDMA転送を期待するが
Listやmapであれば、一つ一つforを回してコピーする必要性がある。
たとえば、1KB単位のブロックのVectorをソートする場合、スワップの手間がバカにならないので、スワップをなるべくさせないアルゴリズムでソートする。
逆にListであれば、個別の要素が、以下に大きくても、スワップの手間は高々ポインタ１つ分なので、スワップを気にせず最適なアルゴリズムでソートする。
データ構造が違うと言う段階で、同じアルゴリズムを使うことは少ない。だから、そもそもイテレータにアルゴリズムの吸収を期待しない。
つーこと。
もっとも、一般的には、簡単なプログラムであればアルゴリズムを使った方が簡単にできるので、使った方がよいが・・・。
それこそ、DB使った方が早くない？とか、Perlでよくね？とかいろいろな議論が出てくるのだが
今回はあくまでもプロレベルでどうのこうのという話しだったので
百万回繰り返された例の件について書いてみるよ。あ、タイトルは必要ないよね？このタグだけ見ればわかるものｗ
総評：とにかく微妙というか、中途半端につかいにくい。いまだにPerlが生きていたり、Rubyにキャッチアップされてるのも納得の出来。これがＬＬ界を制覇したらPerlよりうっとうしい。
総評：Perlのライブラリが流用できたら最高。できなかったらNIH症候群にかかる。
