信者「俺はこのプログラミング言語クソだと思う。ﾀﾋね」 平等に評価する人「このプログラミング言語は素晴らしいが、こういうところに問題が～」 信者「そのプログラミング言語を貶すな！ﾀﾋね！そのプログラミング言語は神！！」 信者さん、そういうところやで・・・
信者「俺はこのプログラミング言語クソだと思う。ﾀﾋね」 平等に評価する人「このプログラミング言語は素晴らしいが、こういうところに問題が～」 信者「そのプログラミング言語を貶すな！ﾀﾋね！そのプログラミング言語は神！！」 信者さん、そういうところやで・・・
某サイトでまたそういうのを見かけてしまった。というか、あのサイト自体結構過激派が多い印象。
Rustプログラミング。 トレイト境界をimplに使うことで、実装したトレイトを持つジェネリクスによって実装するメソッドを変えられるという仕組み、結構面白いと思う。
ジェネリクスを持つ構造体や列挙体に制約を課さず、実装側で制約を課すことでインスタンスを生成したときに無駄なメソッドをメモリ上に入れなくて済むということですね。
メモリ上に入れなくていいという表現は少し曖昧だな。 とりあえず、メモリリソースの節約になるってこと！
7と11の店に行くのはやめよう。 あれほど客を騙すために頑張っている店はないし、何より上層部の方々は従業員を虐めている。 家族市場や法律息子で十分ってのもあるしなぁ～
あぁ、そういえば小数点表示してないから、なぜか合計で謎の1円がプラスされてる→価格に小数点も表示みたいなことがあったなぁー。切り捨てか切り上げで良いやろそんなもん。わざわざ小数にする必要、ありますか？
まぁ小数表示にしたのは改善したとも言えるけど、そもそも価格が小数とか、普通に計算が面倒くさいだろうが。
俺もそういう方たちには申し訳ないけど1円とかそこまで細かく計算していないよ。 しかし細かい計算をして買いに来た人にとっては謎の1円プラスは詐欺じゃないか、と思うわけよ。 これが7と11クオリティ。客を騙すために必死になった店の真の姿。
Tour of Rust、Rustにおいて最低限必要な知識が大雑把だけど結構うまくまとめられていて、これこそRust初心者にお勧めかもしれん。
日本語訳版でも途中から未翻訳なので、ある程度の英語力が必要になりますが。
TRPLの日本語訳よりかは（非常に申し訳ないんだが、TRPL日本語版は少しクオリティが低すぎる気がする）間違いなく上手な翻訳だし、願わくば早く日本語訳版を完成させてほしいところだ。
別に英語が読めないわけではないので、俺は別に良いのだが、ほかにもこういう初心者向けのサイトの日本語訳を望んでいる方は多くいると思いますので。
ただ一つ残念なのが、関連関数をスタティックメソッドと解釈していたりenumをCの共用体と同様だと書いていたりしたところだろうか。enumはC共用体とは用途がまるで違うと言うことは前にも呟いたので割愛するが、確かにTRPLでも関連関数はスタティックメソッドのようなものと解釈していますが、（続く）
何も関連関数が使われるのはスタティックメソッドだけではないので・・・。
まぁ確かに間違っている情報もありはするけど、そもそもRustって覚えることが多いのでこういった情報を軽くまとめてくれるサイトがあるのはありがたい。おかげでRustに対する理解が深まったことは間違いないし訪れてみる価値はあると思う。 Tour of Rust、良きサイトでした。
Rustプログラミング。 Rustの生ポインタ、ポインタ演算する程度であればunsafeである必要はないんだね。あくまで、アクセスする場合に使われる、ということか。 なるほど、確かにアクセスできなければメモリ破壊をすることはないだろうから、きわめて合理的だね。メモリ安全である理由がわかった。
どうでもいい豆知識ですがC#にもポインタを扱うためのunsafeがあるのですが、そもそもunsafeブロック内でないとポインタ自体宣言できないのでRustでもそうなのかなと思っていた。
正直Rustのunsafeで真っ先に思い浮かんだのがC#なんだよなぁ。
Rustのunsafeに関しては、メモリ系のバグが発生していてコードを見るときに原因がパッとわかりやすくするために、極力細かく分けたほうが俺は良いと思う。すると読んだだけで「あっここが原因かぁ～」ってのがわかりやすくなるだろう。
あとRustの*const Tと*mut Tには演算子系トレイトが実装されていないから、実際にポインタ演算をする際は演算子系トレイトが実装されている型に変換して演算を行い、再度*const T、*mut Tに変換することで実現可能。 面倒だが、おそらくこの面倒さは楽にポインタ演算させないという狙いもあるだろう。
まぁこの辺りの結論はわかっていたが、シンプルに開発したい場合はC、複雑だけど保守的な開発をしたい場合はRustと言った感じだろう。 あくまでCとRustを比較した場合の話だけどね。リアルタイム性ではおそらく絶対勝てないので、リアルタイム性重視な場合はC、そこまで重視しない場合はRustかな？
保守ではなく、堅牢性が高い開発というのが正しいですね。保守性は多分Cのほうが高いと思う。シンプルなので。
正直複雑さで言えばRustに慣れてしまえばC++と同等に複雑だと思うので（今のところはね。まだRust初心者なので自信もっては言えないけど）、Cはまだ生き残れると思うけど、正直C++は地位は結構危うい気がするな。結構好きなんだけどね、あのC++独特な構文も。
最近のGoogle検索エンジン、なんか偽陽性が多い気がするね。おそらく過学習を起こしちゃっていると思うので、学習のさせ方を少し変えたほうが良いかもしれない。
偽陽性とは、検索エンジンにおける、興味ない情報なのに興味のある情報として出てきてしまうことを指します。
Google検索エンジンにはAIが使われているので、もし偽陽性が多いのであればGoogleにフィードバックを送るのもありだと思う。
Rustのunsafeブロックは極力分けたほうが良いということを呟いたけど、TRPLにも似たことが書いてあった。 doc.rust-lang.org/book/ch19-01-u…
Rustにはビットフィールドがないので、フィールドを使って1bit単位でI/O制御、というのは不可能だと思うけど、メソッドで代用できるので問題はない・・・と思う。
>RT まぁプログラミングとか言っておきながら書いてあるのはHTMLだったって例よりかはマシでしょ（そういうことではない）。
@kawamineka Pythonではforは文ではなく、式なんです。 そのため、繰り返しをする条件だけではなく、リストの[]内や辞書型の{}内（辞書型はenumerate()が必要）などでも使うことができます。 内包表記は扱い慣れると便利なので、覚えておいて損はありません。
@Glassesman10 はい、その通りです。繰り返しをする条件としても使えるので文であると混同しがちですが、forは式です。
@kawamineka Pythonのforがほかの言語と違うのはそれとは別の理由なのですが話が長くなりそうなので、Pythonにおいてはforがあの形式なのは式として扱うにはそのほうが都合が良いから、と解釈していただいて結構です。
@Glassesman10 すみません、先ほど私もPythonのforについて調べていたり検証していたりしていたのですが、forは文としても式としても使えるので（ifも同様の理由で、文も式もあります）、別々です。 申し訳ありませんでした、訂正いたします。
@kawamineka 申し訳ありません、for文と内包表記は別々と捉えてください。訂正させていただきます。 申し訳ありませんでした。 twitter.com/opaupafz2/stat…
ふむ・・・一応ディスアセンブルで見た限りでは、同じFOR_ITERなんだがな・・・ なるほど、for文が内包表記よりも遅いのはappendメソッドが呼び出されたことによるオーバーヘッドのためと考えるのが一般的か。 qiita.com/intermezzo-fr/…
だいたい、長いからforにしたんだろうけど、Pythonのforはforeachなんだから名前をforeachにしろよなまったく・・・Rustのforもそうだよ。
毎日PythonにPHPに、近頃はRustも始めて、なーにか忘れてるような・・・ そうだ、C言語だ！
なんかこのポインタ演算の書き方、面倒にしか見えないのに、魅力的に見えてきた。 let ptr = ((&var as *const i32) as usize + 4) as *const i32); やはりRustはスルメ言語。
多分関係ないと思うけど、参照では&だけなのに、生ポインタでは*constになっているのは、参照外しと区別できないからだろうか。それともCではconst T*もしくはT const*でポインタの中身の変数を書き換え可能だという名残だろうか。T *constがポインタ変数の再代入不可を指すのでややこしいけど。
const T*もしくはT const*でポインタの中身の変数を書き換え可能 ↓ const T*もしくはT const*でポインタの中身の変数を書き換え不可能 不可能って書いたつもりだったのに。F***
Fのポインタのポインタのポインタではない。何なのか、ご想像にお任せします。
そうか、Pythonのfor文の場合はリストのappend以外もありえるけど、内包表記はリストのappendに限定されるから高速になれるのか。 つまり、一応a = [i for i in range(n)]はa = []; for i in range(n): a.append(i)の糖衣構文ってことになるのか？
今現在のAIの定義が機械学習であるとするならば、生産性が上がるというのは（場合にもよりますが）ビジネス的観点から見ても事実であります。 機械学習は分析と組み合わせることでより客観的な判断が可能となり、結果として生産性が向上するからです。
「場合にもよりますが」と書いたのは、「すべてにAIが適用できるわけではない」「時には経験や勘も大事になってくる」場合もあると言うことです。ですので、AIを使うべきか？ということを考えたときに、使うべきではないという結論に至ることもあると言うことです。
申し訳ないけど、もう限界だ、解除。 フォロー数1人だったからそういう体制にしたのかなーと思いきや、フォロワー減り始めてから唐突に再開するし、安定してきたらまた解除し始めてさ。 そんなフォロワー弄ぶような人間とは価値観が合う気がしません。 というわけで、さいなら。
初心者と勘違いされるような文面にしてるのがいけないのかな。使っているプログラミング言語見たら歴が長いことぐらいわかりそうなもんだが。
もしかしたら、初心を忘れないようにしたいと書いたことで勘違いする人もいるかもしれないしな。変更した。 あれだな、本当にマジでプログラミングについて左も右もわからないような人に混ざって全然初心者じゃないような人が「初心者です！」みたいなことはしないようにしていきたいね。
@kawamineka copy.copyはシャロ―コピー、copy.deepcopyはディープコピーを意味します。 たとえばコピー元の変数a、コピー先の変数bがあったとして、シャロ―コピーはaを変更するとbも変更されますが、ディープコピーの場合はされません。
@kawamineka もう少しわかりやすく説明すると、 シャロ―コピーはaとbを同じ変数として扱ったコピーを行います。 ディープコピーはaとbを別の変数として扱ったコピーを行います。
@kawamineka すみません・・・また、間違えました。 1次元リストの場合copy.copyはディープコピーと同等になりますが、多次元リストをディープコピーする場合はcopy.deepcopyにしなければなりません。 つまりまったく別のオブジェクトとして扱いたい場合はcopy.deepcopyを使っておくのが無難です。
Python設計者はもう少し言葉の定義を厳格にしたほうが良い。 シャロ―コピーは本来変数のメモリアドレスのコピーを示し、ディープコピーは変数そのもののコピーを指す。 なのにPythonではディープコピーは本来と同じであるもののシャロ―コピーは別物だ。 ややこしすぎるんだよなぁ・・・。
まぁ、シャロ―コピーって聞いたから真っ先にメモリアドレスのコピーだと思ってしまった俺も悪いんだけどさ・・・。
結構よくわからずに設計してる人が多いのかな。プログラミング言語においてはすべての用語が言語ごとに別々であると考えたほうが良いと思えて来たぞ・・・。 Rustのトレイト、PHPのオーバーロード、そしてPythonのシャロ―コピー・・・どれも別物だ。
とりあえず、まとめると、 Pythonでは代入が本来の意味でのシャロ―コピーで、copy.copyが1次元までのディープコピー（Pythonにおけるシャロ―コピー）、copy.deepcopyが完全なディープコピーという感じか。
というか、Pythonでの代入がシャロ―コピーってのは知らんかったよ。まさかメモリアドレス（というかオブジェクトID）をコピーしていたとは。
普通代入ってディープコピーのほうを採用するもんなんだけど、Pythonだけなのかな、シャロ―コピーは。まぁそもそもPythonの変数って変わってるからなぁ・・・。
Pythonを対抗したからか、Rubyも同じくシャロ―コピーだな。Perl、PHPはディープコピーか。
いやRubyがシャロ―コピーなのはまったく偶然だと思うけどね。ただ、RubyってPythonと競合してたはずなので・・・。
動的型付け言語による代入の動作まとめ シャロ―コピー： Python, JavaScript, Ruby, Julia ディープコピー： Perl, PHP 多分俺が静的型付け言語に触れていることが多いのが理由だろう・・・動的型付け言語は意外とシャロ―コピーが多かった。
JavaScriptはCの恩恵を受けているのでシャロ―コピーなのは意外だった、というのが正直な感想。 Julia、知ってた。
そもそも、1次元配列のみディープコピーするcopy.copy、いる？俺的には代入（シャロ―コピー）とディープコピーだけあれば十分だと思うんですけどね。
Pythonの代入がシャロ―コピーだということが判明し、そのとき「関数の引数に代入するとそれはシャロ―コピーだから、リストの変更も可能なのか」と思い、そのとき、ふと「あれ、Fortranもそうだったような？」ということに気づき、確かめてみたら、（続く）
変数に代入する場合はディープコピー、引数に代入する場合はシャロ―コピーという、ちょっと変わった仕様だった（多分ほかにもそういう仕様のプログラミング言語もあるかもしれないが）。
まぁそしたらFortran90以降では特にポインタがあるからその意味がなくなるわな。 引数にディープコピーさせるにはどうすればいいのかと言う問題も、別の変数にディープコピーさせればいいわけだし。 今だから気づいたけど、ここは原始的だが実に合理的でわかりやすい。面白い。
@kawamineka 基本的にはIntel製やAMD製がリトルエンディアンでモトローラ製がビッグエンディアンですが、今はモトローラ製は見なくなりましたね・・・。 ARMアーキテクチャやPowerPCはビッグエンディアンも可能なのでエンディアンはまだ気にしたほうが良いですが・・・。
@perlzemi 確かそのときに活動をしばらく休止すると言っていたのにすぐに復帰したことでまた良くも悪くも話題になりましたね。
Twitterたまに通知来ないバグ何とかして。
クオリティフィルターがアカンのかな。特にFF外から通知来ないように設定してるわけでもないので。
Rustプログラミング。 今さらながらDisplayトレイトがわかった。println!やformat!などのマクロでの動作をカスタマイズできるのね。
なんかTwitterにスパチャみたいな機能が追加されたみたい。俺は金を搾取するようなマネはしたくない（スパチャがダメと言っているわけではない）のでやらんけど。
金をもらう価値のある人は別に良いけど、俺は趣味で金をもらう価値はないのでやらないということです。そもそもお金あまり興味ないしなー。生活できればそれでいいって感じで。休みが大量に欲しいわけでもないけど。
ずっと夢ぇ～を見てぇ～ｗｗｗ（←最近7と11が金にがめつすぎて夢を見れていない人の願望）
Rustはオブジェクト指向のパラダイムは持っていないというのは意外と周知の事実だったりするのかな。割とオブジェクト指向じゃないという意見は結構多いと思う。
前にも言ったけど、RustはCやFortran90などのOOPに向いていないことが自明なプログラミング言語よりかはオブジェクト指向的であり、実際オブジェクト指向性は高い、でもオブジェクト指向としてのパラダイムは持っていない、というのが俺の主張です。
パワハラはもちろんいけないということ前提で話すけど、なぜ指摘されるのもダメな奴がいるのか・・・指摘もダメなら放置しかできない。 もう良い歳した大人なんだから、指摘ぐらい受けても耐えられるように（普通自分のために指摘しているわけだから耐えるという表現はおかしいと思うが）なろーね。
まったく的外れな、理不尽な指摘であれば、それは怒るのも仕方ない。でも、それが真っ当な意見であるならばそれは自分のダメなところであるし当然受け止めるべきだ。
指摘されるのもダメな人は、きっと「それは自分のためになる」「ためになった」という認識が足りないのですよ。 もしかしたらごく一部に「社会人になったら勉強しなくていい」という人もいるかもしれないけど、勉強は永遠に続くものです。ﾀﾋぬ間際まで学ぶことがあるかもしれません。
そのため、「勉強したい！」という認識を常に持っておくことは、人生においてとても大切なことだと俺は思いますね。
@kawamineka 確かにポインタは一つの関門だと思います。 ポインタはプログラミングの中でも特にコンピュータ目線で物事を考えなければなりません。 かくいう私もポインタで挫折しかけました。 しかし理解できるようになると、本当に（冗談抜きで）なんでもできるようになるので便利です。
ふと思い出したので、Linus氏の罵言の件について少しだけ話すけど、俺がLinus氏の罵言で一番印象深かったのはC++への罵言だったなぁ。多分アンチC++の中でも極めて力強い罵倒だったと思う。 C++がCと違うのは事実なんだけど、意外とその件でC++を罵倒する人はLinus氏以外でもいるからな。
何度でも言いますが、俺はC++のあの独特な構文が好きですね。
Python→Python2(dos)→Python3(tri-) Pythonの経緯はこうでしょうか？わかりません（大嘘）。
このほかにもPythonFrontier（2019年終了）、PythonPortable、PythonPortable2nd(G)、PythonPortable3rdとかもあるらしいです。 （大嘘）
PythonFrontierとPythonPortable（Portable Python）はあったけど、2nd、2ndG、3rdはなかった。
@kawamineka 代入（=）と等価（==）は違うのと、==はTrueかFalseを返すため文法としても問題ありませんので、仕様変更も警告を出すのも言語仕様上難しいのです・・・。 よくあるミスですが、こればかりは仕方ないです・・・。
Rustプログラミング。 パスについて。 self:: -> "./", ".\" super:: -> "../", "..\" crate:: -> "/", "C:\" ::<dir>:: -> "<dir>/", "<dir>\" ::<dir>::{<fileA>, <fileB>} -> ["<dir>/<fileA>", "<dir>/<fileB>"], ["<dir>\<fileA>", "<dir>\<fileB>"] ::<dir>::* -> "<dir>/*", "<dir>\*"
多分crate::は厳密にはモジュールのルートだと思うけど、OS風に書くならこうだよな、っていう感じで。
そういえばRustのRc構造体のcloneはメソッドとしてではなく関連関数として使ったほうが良いって書いてる資料があった。確かCloneトレイトのcloneと間違えるからって。
Rust（プログラミング言語）って結構update多いんだな・・・1ヶ月ちょっとで1.52.0か。
俺もかもしれないが、Rustをよくわからずとりあえず過剰に褒めている人ってなんかよくわからんところとか、それ良いところなのか？というところを褒めている人が多い印象・・・もっと褒めるべきところあるだろ。
TwitterKon-Katsuかなんか知らないけど、主にアラサーの人たちに願望が強い人が多いのかな。今の20前半はそこまで強くないイメージがあるから。