@pythonconverter Thanks. But this is my joke tweet.
何に反応したのかわからないけど、Python2.xからPython3.xに変換するbotにふぁぼとリプされた。 無意味だと思うけど一応、ネタツイですって返しといた。
そもそも俺Python2.x系触ってないんだよね。Python3.xとどこが違うのかっていうのは粗方把握してるけど。
FORTRAN77と同じ理由だと思うけど、Python2ってもうサポート終了してるのにまだ使っているところがあるからな。
#アイスクリームの日 らしいのでとりあえず叫んでみた。
あれって本当はSomebody Screamって叫んでるんだけど、それに三倍アイスクリームっていう空耳を付けるのは日本人ならではだよね。
地球が滅ぶって叫んでる馬鹿いい加減に現実見たら？
@akkoden_akutoku ほとんどがガスでできていて核にたどり着くころには人間は100%の確率でﾀﾋんでいるはずなんですが、それは・・・
俺読んだことないからわからんけど、N-ArrowのTUEEEEE系がつまらないのは多分努力している描写をあまり描いていないからで、TUEEEEEになるまで血の滲むような苦労してるはずゾ、知らんけど。
@perlzemi Python自体1991年登場でそれなりに古い言語であるはずなんですけどね。
まぁ、while文使えば似たようなことは可能だけども・・・単純にパフォーマンス面で良くない。
あと、switch文って中身goto文なので、実はif文による多条件分岐よりも速いんですよね。なぜならif文は条件ごとに評価のコストがかかるから。 kotlinのwhen文とRustのmatch式はどうなのかは知らんけど。
そう言えばGo言語ではswitch文でbreakする必要がなくなって、代わりにフォールスルーする場合にfallthrough文を使うようになったと聞いた・・・switch文独自の良さを理解してらっしゃるな。俺Goまったく書いてないから知らんけど。
Kotlin環境は実はマイハウスにないのでできないが、Rust環境は構築しているから、if式とmatch式どっちのが速いのか検証してみても良いな。timeモジュールで簡単にできるだろうしな。
if : 0.00000319 match: 0.00000287 50回連続で同じ処理をやらせた平均。どうやらswitch文と同じくmatch式のほうが評価のコストがなく速いらしい。良い発見をした。
結論：Rustのmatch式はif式よりも速い。多条件分岐を高速にしたい場合はmatch式を使おう。
Rustのmatch式がif式より速いことはわかったから誰かKotlinのwhen文がif文より速いか確かめてくれー（他力本願）
if : 37ns match: 33ns Rustのif式とmatch式の比較、わかりづらいうえにバグがあったのでもう一度検証。 100回同じ処理で確認。
数十回試してもifがmatchに勝つことはなかった。そのため、match式が速いという結果自体は変わらなかった。
というか、これはCと同じだと思うのだが、キャッシュされて同じ処理を省略してるな。 初回だけだと100nsぐらい差があるのでmatch式はif式の100倍速いということになる。
間違えた、100nsぐらい差があるってことだけしかわからんな。 if式150nsに対してmatch式50nsだから3倍程度かな。
Rust By Exampleで「match式でswitch文のような書き方ができます」って書いてあったの、嘘じゃなかったんやなって・・・フォールスルーはできないけど。
別に誰もやる必要ないけど、一応RTしとこ。もしかしたらKotlinのwhen文がif文よりも速いって言うのを検証する人がいるかもしれないからな。
そういやキャッシュされているで思い出したけど、Rustってvolatileあるのかな。キャッシュさせないようにすることで処理の省略を防ぐ奴。
組込みやるならvolatileぐらいは知っておかないとね。知らないのはもはや恥レベル。
@kawamineka そこまでデータが少ないのであれば、二分挿入ソート（二分探索 + 挿入ソート）のほうがむしろクイックソートより安定して速くなるのでお勧めです。
すんません、例のアレを元ネタに呟いただけです。
@wyper_xyz @kawamineka FF外から失礼します。 配列は「型が同じ値を複数格納できる変数」であるのに対し、ポインタは「メモリアドレスを格納する変数」です。 そのためポインタはメモリアドレスを再代入できますが、配列自体にはその機能はないという点で異なります。 気になったのでリプしました。失礼いたしました。
@WebDesignerRiku 環境構築お疲れ様です。 見たところhello.exeに変換できており、ターミナルのほうでも出力できているため問題はないと思われます。 念のため、コマンドプロンプトで以下を書いて、Enterを押してだけますでしょうか。そちらも想定通り動いていれば問題ありません。 %UserProfile%Desktop\gcc\hello.exe
@WebDesignerRiku いえ、やり直さなくていいですよ。多分。結局はhello.exeがコマンドプロンプト内で実行できれば良いので。
@WebDesignerRiku 私がちゃんとhello.exeが実行できるのか不安なだけで以降はコマンドプロンプトで実行せず、テキストがあるのであればとりあえずテキスト通りに進めてください。
TIOBEのランキング、しばらく見てなかったけど、ついにObjective-CがTop20から下落してしまったのか。代わりにFortranが入ってますね。 90以降では配列が簡単に扱えるところがTop20入りしたことと関係してそう。
まぁそれだったらもっと早くにTop20入りしてるだろうと思われるかもだけど、Swiftが登場するまではObjective-CはPOTY(Programming language of the year)に輝くほどだったからそれも関係してると思う（まぁそれはMacアプリやiOSアプリ開発ができるのが主な理由だけど）。
でも、Swiftってまだ発展途上でObjective-CじゃないとできないAPIもあるんじゃなかったっけ？それはもう全部対応済みかな。
Rustでわかる英語の発音。 まずRはLと違いくっきり発音してはいけない。そのため若干巻き舌気味に発音する。 その次、ustでuの後に文字があり、その次の文字が母音じゃないのでuは口半空けで「ア」と発音、sとtは「う」の口で少し区切る感じ発音するので「ｽﾄｩ」と発音する。 これで完璧なRustや。
Rust（プログラミング言語）学習の良さそうなサイトまた見つけた。しかもMicrosoftだからかVC++ Build Toolsのインストール方法まで載っているので「WindowsでRustコーディング始めたい！」って人にお勧めかも。 docs.microsoft.com/ja-jp/learn/pa…
@perlzemi おそらくAIが講座というところに関連を見出して表示していると思われます。 自然言語処理は機械学習において最も難しい分野であり、故に偽陽性率を抑えることはできますが出すなと言うのは難しい要望なのです。 ですので、Youtubeにてフィードバックの送信を行い、改善されることを祈りましょう。
Rustはオブジェクト指向なのか、ということについてトレイトには継承という概念がある、という観点から考えてみたけど、正直オブジェクト指向と言うのはやはり難しい。 メソッドが隠蔽やオーバーライドできないと継承ではない、というのであれば、それはRustが継承と付けているのであって、->
OOPにおける継承ではないと言えるが、サブトレイトとスーパートレイトの同名のメソッドが別個のものであっても継承と呼んで良いのであれば、RustOOPにおける継承を持つということが認められると思う。 しかしながらトレイトの継承は、OOPの継承と言うよりも->
「スーパートレイトとの依存関係を作る」と言ったほうが良く、「サブトレイトはスーパートレイトの機能を受け継いでいる」とはちょっと違うと思う。なぜなら、クラスベースのOOPではサブクラスはサブクラス単体でも動かすことができるけど、Rustのトレイトはサブトレイトを実装するだけでは動かず->
スーパートレイトも実装する必要があるからだ。 以上をもとに考えると、トレイト継承はOOPにおける継承ではなく、故にOOPにおける継承を持つことがオブジェクト指向のパラダイムを持つ必要条件と言うのであれば、Rustはオブジェクト指向のパラダイムを持たないと言える。
その点を顧みて考えてみると、ちょっと凄いなと思うのが、Rustには継承がなく、また強い型付けであるのに関わらずポリモーフィズムを実現しているという点。これは他言語にはない魅力的な部分なんじゃないかと思う。
勘違いしないように補足しておくと、オーバーライドできることが継承の十分条件ではなく、そもそもオーバーライドは「動作を上書きする」ことを示すので、それが継承である必要はないと言えます。故にRustのトレイトの実装はオーバーライドが可能ですが、継承ではないと思います。
