「イテレータ」を含む日記 RSS

はてなキーワード: イテレータとは

2019-01-08

プログラミング課題楽しい

面白半分でやってるけど知恵の輪みたいで楽しい時間泥棒

使ったことないイテレータ関数使って挙動確認したり

好きになる人の気持ちちょっとわかった

2018-07-29

for文アレルギー

イテレータ関数が便利すぎてfor文見るとえぇー…って気分になる

iとかforから脱出するための条件式定義するのが馬鹿らしく感じられる

でもきっとfor文でしか書きたくない人もいるだろうからfor文も使わないとなあ

2017-01-22

ownership とシステムプログラミングその他に関する怪文書

この会話ログフィクションであり、実在人物地名団体とは一切関係ありません。

坂木

わろた

Rust vs. Go に対する @tanakh さんの発言まとめ

https://togetter.com/li/1072495

坂木

自分理解できないもの意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。

安原

NTPsec が,ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした(こなみかん

宮森

今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。

宮森

……が、理解できないものに対して、理解を試みず~すべきだ~と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。

安原

いや,私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います. ownership に理解を示さなコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です.

宮森

いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている(思い込んでいる)人たちですんで……こわちかは同意

安原

いや,私は C で開発してきた人たちの多くは,そもそも ownership の概念を獲得していないのではないか危惧しています.元々,私はもっと楽観的で,多くの C プログラマは ownership の概念を獲得していると思っていました.

宮森

あ、それはそうだと思います概念を獲得していない

リソース人間管理をすれば適切に管理できる、という思想の下に皆さん書いていらっしゃるので……。

安原

OpenSSL騒動の時,関数の途中で return したことによるリソース漏れ揶揄したことがありますOpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ, ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました.

安原

ああ,はい人間を信頼しすぎているというのはいかにもありそうですね.

藤堂

C++er の方がその辺もっときちんとしているように見える

安原

しろ C++ によって ownership という概念が明確になり,その重要性が認知されるようになったのではないでしょうか? これについては,私は歴史的なことが分からないので真偽のほどは何とも言えませんが.

宮森

シニア開発者しかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。

宮森

OSとかシステム系のプログラマの人々、基本的リソース人間が適切に管理するし管理できると考えている人が多い印象([検閲削除]社時経験)。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。

坂木

[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。

今井

自分が知っている C 「しか」書けない職業プログラマ基本的地雷だなぁ...。

今井

リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)

安原

うーん,数値計算系のチームやコミュニティも ownership の概念の獲得,重要性の理解,その管理自動化することへの理解,これらを期待するのは難しいだろうなあ…….そもそも高度なリソース管理必要になる場面少ないし…….

坂木

コード品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。

安原

OS 実装とかシステムプログラミングって,クライアントに直接接しないだけで,その上にクライアントサイドソフトウェアが載るわけで,コード品質が強く求められると思うのですがそれは…….まあ, API とかで切り離されているので,そこだけしっかりしていれば,という話はあるか.

宮森

そこはコードレビューテスト等でカバーっちゅう。まぁ確かにコードには実際assertが入りまくったりするわけですが。

坂木

品質が強く求められるからといって品質が高いわけではないのが問題ですね

今井

あとは、デモが作れればいい、的なのも同じかなぁ。

宮森

メモリ管理、freeせずに終了してOSに全て回収させれば管理しなくて良い。

宮森

メモリ管理コンパイル時に全て静的なサイズで確保すれば管理しなくて良い。(FORTRAN77並の感想)

安原

OSGC してくれる論, TPO をわきまえているならば普通にありですよね(TPO をわきまえているならば!).

今井

まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。

坂木

私は基本その文化で過ごしてきたので現在進行形でわりかし困ってますね……

今井

あれ、そうなんです? 私がかかわった人のなかでは、コード見ててもむしろカッチリしてるほうだと思ってたのですが...。

(つまり、ここから坂木さんのハードルめっちゃ高いという帰結が...)

宮森

いろいろ言っていますがワタクシ、そういう管理必要プログラムは全く書けなくなりましたので今書くと死にますプログラム顧客大事データが)

安原

しかし,システムプログラミング界隈に「人間リソースを適切に管理できる」という悪しき信仰がはびこっているの,何か構造的な原因があったりするのかなあ?

宮森

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

宮森

実際、Linuxカーネルとか、規模からすれば驚異的に少ない数のバグで動いているので、信仰心が生まれ気持ちも分かる。

宮森

他の言語OS書くっていうのも研究レベルではあるけど、実用になっているのは見たこと無いですねぇ……。

坂木

Linux カーネル、一体どうやったらあの規模のコードクオリティコントロール出来るのか本当に不思議

安原

Linux カーネルのアレは,属人性依拠しすぎていて全然スケールしないのでは…….

坂木

Linux カーネル属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバいレビュアーごろごろしているのかな

宮森

属人性依拠しさえすればできるので十分な数の開発者がいれば問題になりません(キリッ

安原

私も [検閲削除] のコミュニティを見てましたから,各々必要ドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡アンサンブルを奏でうる場合がありうるのは理解しているんですが,本当にただの奇跡しかないと思っています

宮森

つーても機械エンジニアリング町工場職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。

宮森

なおその対極がみずh(省略されました

安原

Linux カーネルにおけるスケール云々は, Linux カーネルコミュニティ自体におけるスケーラビティではなくて,(システムプログラミングコミュニティ全体(他のプロジェクト)へスケールするかどうかを言ったつもりでした.

坂木

まあ人外を集めるという手法一般にはスケールしないですからね……

宮森

C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。

安原

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

これが原因だとすると,やはり Rust だ……Rust しかない…….ツール周りとか,まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば…….

坂木

Rust は 1.0 が出る直前くらいにちょっと触ってイテレータが作れなくて敗北したっきりだな。

坂木

イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……

藤堂

1.0 以前のことは忘れましょう (本当に unstable)

安原

Rust,型でエラーを弾くだけではなくて質の低いプログラマまでも弾く印象.

坂木

一般に型の強い言語は質の低いプログラマを弾きますね(Haskell などを思い浮かべながら)

安原

「Rust 経験者」という条件でプログラマ募集して,それで入ってきた人材に C を書かせればよいのでは!(ピコーン!

藤堂

犯罪ですよそれは

安原

はい

藤堂

haskell 経験者を集めて php 書かせようとした会社がどこかにあったような (ヘイトけがたまる)

安原

まさにそれをイメージしていました.

宮森

どういう顛末になったか詳しく知りたいw

藤堂

うーん、それ以降の話は知らず

今井

Rust そして誰もいなくなった、にならないかが一番心配だったりする

安原

それな

宮森

もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコード生産しているからなのでは、という気がしてきた……。

(この辺で一同寝落ち

2009-08-11

http://anond.hatelabo.jp/20090810221943

こういったカウンタのようなプリミティブな値だと正直どう最適化されるかわからんのもあって、前置だろうが後置だろうがどうでもいいと思うのですが、イテレータとかではそれなりのオーバーヘッドが見込まれるので普段から使い分けを意識しておくほうがよいかなと思う

2008-08-29

http://anond.hatelabo.jp/20080829081459

なにやらもっと単に論理学的な解答があるらしいよ?

俺にはわからんが。

分かりやすさで言えばインデックスループの方が分かりやすいんじゃないかと思う。

イテレータはもうちょっと汎用性を重視してる。

http://anond.hatelabo.jp/20080824080254

イテレータって概念はすごい判り易いから、じゃ駄目なの?

イテレータはすごく使いやすいから、C++開発とかでもわざわざイテレータ実装する事あるよ。

インデックスループとか終了条件ループよりも判り易いじゃん。

2008-08-25

http://anond.hatelabo.jp/20080825233641

教科書的には、その回答で合ってると思う。Java屋じゃないんで詳しいことはしらないが。

教科書レベルではなく、現場レベルでは、違うと思うので、ようはポインタしかとらえていない。

そもそもなぜVector,List,Map などの複数のデータ保存形式があるか?

といえば、データの種別や、それの検索方法、取り扱い方法により、保存方法を変えた方が効率的だ。

という側面から来ている。

そういった、異なるデータには、異なる方式のデータ構造という構造を取っておきながら、

アルゴリズムは共通です。というのにどれだけ意義があろうか?という事。

たとえば、Vectorであれば、コピーならばmemcpyなどの専用命令でDMA転送を期待するが

Listやmapであれば、一つ一つforを回してコピーする必要性がある。

たとえば、1KB単位ブロックVectorソートする場合、スワップの手間がバカにならないので、スワップをなるべくさせないアルゴリズムソートする。

逆にListであれば、個別の要素が、以下に大きくても、スワップの手間は高々ポインタ1つ分なので、スワップを気にせず最適なアルゴリズムソートする。

データ構造が違うと言う段階で、同じアルゴリズムを使うことは少ない。だから、そもそもイテレータアルゴリズムの吸収を期待しない。

つーこと。

もっとも、一般的には、簡単なプログラムであればアルゴリズムを使った方が簡単にできるので、使った方がよいが・・・。

それこそ、DB使った方が早くない?とか、Perlでよくね?とかいろいろな議論が出てくるのだが

今回はあくまでもプロレベルでどうのこうのという話しだったので

普段からチューニングを念頭にプロとして話すとそうなるんじゃね?という話し。

2008-08-07

rubyダメな2つの理由

1. イテレータの |x| のセンス。縦棒!?

2. begin ... end のセンス。

2008-07-31

[][][][]無題

百万回繰り返された例の件について書いてみるよ。あ、タイトルは必要ないよね?このタグだけ見ればわかるものw

Perl

  • sigil 汚い、my our local 汚い。
  • ->が汚い、ドットにしてよ。Perl6ではドットになるんだって?やったぁ。
  • とにかくコードを見るだけでげんなりする。
  • クラス機構が後付けなのがめんどくせー。Exporter使うのだるい
  • とにかく文法がアレすぎる。あ、でも後置修飾子はおきにいり。
  • でもはえー、ちょうはえー。
  • ライブラリ超使える。もうなんでもできる。

総評:肉は腐りかけがうまい

PHP

  • 名前がださい。
  • ライブラリがださい。関数名がださい。
  • もうとにかください、見るのも嫌。

総評:作った人間はドS、使ってる人間はドM。

Python

総評:とにかく微妙というか、中途半端につかいにくい。いまだにPerlが生きていたり、Rubyキャッチアップされてるのも納得の出来。これがLL界を制覇したらPerlよりうっとうしい。

Ruby

  • 基本的な機能には文句ない。メソッドチェインとかブロック構文とかもうさいこう。
  • なんで定数に代入可なんだろう。警告出るからいいけど。
  • なんでも式だから乱用したら解読しにくそう。
  • ボキャブラリや慣習が他の言語からの流用が多いから覚えやすい。
  • ライブラリが貧弱。
  • バイト文字処理が貧弱。
  • require 'rubygems' が汚いしめんどくさい。RUBYOPTつかえ?そういう問題じゃない。
  • いちばんおそい。でもPythonとどっこいどっこいだからあんまりきにしない。
  • 日本でしか人気ないから結構あっという間にすたれそう。
  • よくまとまってて使いやすいけど、特に目新しい点はないよね。人気があんまりないから変な要望がなくてごちゃごちゃしてないって部分はあるかも。

総評Perlライブラリが流用できたら最高。できなかったらNIH症候群にかかる。

いじょう、ストレスたまったドヘタプログラマが真夏の暑いときに油をぶちまけてみたよ☆

2008-05-19

[]Ruby学校の朝の風景

「お早うクソッタレ共!ところでMatz訓練生、

貴様は昨夜ケンカ騒ぎを起こしたそうだな?言い訳を聞こうか?」

「ハッ!報告致します!スーツ臭いJAVA使い共がブロックを指して

無名クラスと抜かしやがったため、yieldパンチを叩きこんだ次第であります!!」

「よろしい。貴様の度胸は褒めておこう。

いいか、Agileで殴りあうには1にも2にもクソ度胸だ。

仕様書を便所紙程度に感じなければ一人前とは言えん。

今回のMatz訓練生の件は不問に処そう。

だがブロックを知らないオカマJAVA使いでもSESEだ。

訓練生の貴様はそこを忘れないように。

ではRuby訓、詠唱始めッ!!!!」

何のために生まれた!?

――Rubyで書くためだ!!

何のためにRubyで書くんだ!?

――静的型付を吹っ飛ばすためだ!!

メソッドを何故定義するんだ!?

――ブロックを書くためだ!!

お前がソースに書くべき事は何だ!?

――Procとブロック付きメソッド!!!

ブロックは何故内部イテレータなんだ!?

――JAVAオカマ野郎が外部イテレータだからだ!!

ブロックとは何だ!?

――慣れるまで避けられ、慣れた後は避けられない!!

Rubyとは何だ!?

――Perlより早く! Pythonより早く! JAVAより早く! どれよりも楽しい!!

Ruby書きが食うものは!?

――ステーキウィスキー!!

ロブスターワインを食うのは誰だ!?

――早漏スーツJAVA使い!! 仕様が変わればおケツをまくるッ!!

お前の親父は誰だ!?

――OO元祖のSmalltalk!!ポッと出のJAVAとは気合いが違うッ!!

我等Rubyプログラマ! レビュー上等! ペアプロ上等! 仕様変更が怖くてプログラムが書けるか!!(×3回)

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん