Rust Part6
■ このスレッドは過去ログ倉庫に格納されています
どなたかが間違えてわっチョイ付きで立ててしまつたようなので立て直しました >>9
いや、だからあらし以外でっていってるじゃん IDあるしワッチョイまったく要らないでしょ
どうせ自演するやつは環境変えられるわけだし、根本的に荒らしを警戒するほどの書き込みも無いし
ワッチョイの必要性を感じたこと無いし、ワッチョイがあってよかったと思ったこともない と言って必死にワッチョイなしへ持って行こうとする荒らしww 必要性ないってのは分からなくもないんだが、
だからってアリのスレを使わない理由にはなってないんだけど。 >>7
>>13
そう思うんならお前がそっちにカキコめばよし
それだけのこと
俺はこっちにカキコむ いや、その通りであっちのスレに書き込む人いなんいんだよ。
あんたが多数派なの。それは事実なんだけど、2ちゃんてそういう感じなんだね。 ワッチョイあると書き込み減るんですよ、事情は人それぞれでしょうけど
使わない理由になりませんか? ワッチョイは運営がサボるための口実。入れると荒らしレス以上に書き込みが減る 2ちゃんてのはそういうとこなんだね。
まあこの板だけかもだけど。 いまさら書籍なんぞに何を期待するんだろう?
APIの最新情報は公式に揃ってるし (日本語で)体系的に学びたいって事じゃないの?
APIリファレンス読んだだけじゃその言語特有のイディオムみたいなものは学べないし そーなん
rustに限らず本なんてここ10年手に取ったことすらないわ
ネットが未発達な時代は本で読んでたけど… これは俺の持論だけど、
ネットは確かに情報量は多いけど断片的な情報しか手に入らないし
間違った情報(書いた本人が勘違いしてるだけの場合も含む)も多い
そんなのを自分で精査していく手間を考えると、
お金払ってでも本を買ったほうが効率的に有用な情報を手に入れられるよ 誤解を招く前にいちおう補足しとくと
>>29で本って言ってるのは「プログラミング言語の本」て意味
そんでもってネットで十分て言ってるのは
「ネットでAPIリファレンス見るだけで十分」て意味
>>28
人生で最初の言語は体系的に学んだほうがいいかもしれない(のかな?)
二個目以降は真顔でAPIリファレンス引くだけのことと感じてる
>>30
まぁそれはあるね
・ニワカなやつほど語りたがる
・ノイズのっけた二次情報を発信したがる
・意味も無く薄めた二次情報を発信したがる
・独自解釈で歪めた二次情報を発信したがる
という点では注意が必要だ
Qiitaみたいなもんはほんと公害 将棋でも棋書読まずに定跡そっちのけだけど滅茶苦茶力戦になったら強い人っているよね 俺はプログラミング言語の本を買うのはやさしいC以来15年ぶりだ
あと一週間だね 日本人は目的より手段を優先する人が多いからしょうがない
少:××をしたいから勉強する
多:勉強をしてから出来る事を探す 紙の本じゃないと脳に染みてこない体質
絵的なものなら電子媒体でも全然いいんだけど >>37
怖くて外に出られないから武器を延々と収集するマニアみたいなものだな。 いやマジで「××を勉強したい」などと言う人に「それ勉強して何をしたいの?」と
質問しても明確な答えが返ってこないケースはかなり多い
日本の教育制度がそういう風潮だから当然っちゃ当然なんだが能率は良くないよね >>43
ま、勉強する事そのものが目的の場合もあるとは思うけどな。
その場合はパズル解きたくなるのと同じようなものね。
遊びであり趣味であり好きでやってるだけ。
だから上達する必要がないんだけど何かに迫られてやってるわけじゃないので結果的にかなり上達する。
野球が好きで毎日野球ばっかりやってて結果的にプロ並みに上達してしまうみたいなのと同じ。
本人は主観的には遊んでただけで一切努力していない。 自分のささやかな経験を拡大解釈して知ったかぶるケースはかなり多いよね
海外では興味があっても使い道がないなら手を出すなと教育してるわけ? 『プログラミングRust』って、電子書籍版出ないの? >>44
趣味ならそれでも良いかもしれないけど実践的じゃないよね
日本は大規模なプロジェクトが苦手だしな。宇宙・航空なんか最たる例
>>45
日本は手段偏重。技術偏重とも言える。逆に目的や結果は軽視される 原発ダム高速鉄道高層ビルに大規模なプロジェクトは枚挙に暇ないがないけどなあ
本を買うって話でそんな脈絡ないことを言い出すあたり、遺伝子にも環境にも恵まれなかった失敗作なんでしょうなあ 別に好きでやってるのはいいと思うよ。
実践することとの区別のついてないバカが実際にいて困るってだけ。 好きなの使わなきゃ楽しくないじゃん
なんでそれがバカなんだ? 日本人は大規模なの下手だと思うよ
鉄道やなんやらは一見大きく見えるが小規模理論でスケールできる例なんだろう
実用OSなどの大規模なソフトウェアは本当に苦手で
日本からは決して生まれて来ないと思う
(TRONが実用になってたらこの案は引っ込める)
あとオーケストラとかサッカーとか
動的に複雑に協調していくようなもんは全て下手だと思う
というより、欧米の連中がなぜかそこをうまくこなしてると思う 鉄道を持論で小規模扱いするんか
ソフトウエアの世界で弱いのは英語ができないからだよ
オーケストラは知らんがスポーツは個人競技だって欧米が強い、フィジカルの違いだから
プログラマなのになんでそんな無茶苦茶なこと言うんだよ 原発は大事故を起こしたばかりじゃないか
自分が言う大規模というのは一人の人間が全体を把握できないという意味
日本は個人で全体を把握できる物は強いが、それが出来ない物は弱い
鉄道だって構成要素は使い回しが多く種類は以外と多くない
プログラム関係なら汎用OSなんかが該当するかな
この話を突き詰めていくとアメリカで言うシステムエンジニアリングに行き着くんだよね
日本人には理解されない事が多いけど >>55
おおむね同意
日本人がすぐれてるのは職人芸の延長だと思う
コケシ作ったりするような、ああいうサイズ感は得意
個人の勤勉さがうまく働く例だと思う
「一人の人間が全体を把握できない」という表現もなるほどなぁと思う
俺はもっと単純に「複雑さがあるレベルに達すると」くらいに考えてた >>56
白状すると元ネタはこれ
マツドサイエンティスト・研究日誌 保存版 システムエンジニアリング(その4) 超人にならなくていい
ttp://anoda.web.fc2.com/weblog/20050424.html
そっち系の本職の人の記事だが本来の意味のシステムエンジニアリングについて解説している
この業界ですらみんな判っているわけではなく打ち上げて間もない衛星を管理不十分でお釈迦にしたばかりだし 語れば語るほど薄っぺらいが、たいていの人はこういう時期があったので、生暖かく見守っているのだよ 最近は義務教育や高校で近似解や数値計算も教えるのかな?
今のご時世コンピュータを使用してはいけないとかナンセンスだよね >>55
まあわからんでもないかな。ある種の細かい部分の差異を捨てられない感覚がある。
大規模な場合にそういう差異が生じることを前提に組まなきゃならんって場面で
うまく切り捨てられない印象。 日本は島国だから、争わない遺伝子が多い
他国では戦争が多いから、逆らう人 : 従順な人 = 7 : 3
などだが、日本人だけは逆
日本では、体制を変えたり、乱を起こすような、乱世向きの人は嫌われる。
従順な治世向きの人が好まれる
日本人は、命令・洗脳・支配されると喜ぶ。
人の上に立ちたくない。
反発力がない。
だから同じ事を、飽きずにずっとやれる ステロタイプの日本人像ばかりで飽きれる
持論ですらないし
持論じやないから反論に対して反論できず言い張るだけ
こんな奴らがプログラマやってるなんて信じられない
IT土方なんて揶揄されるのも仕方ないな >>57
(´・∀・`)ヘー
俺も白状すると指揮者の小澤さんって人が書いた本に(タイトル忘れた)
オーケストラとかやると日本人はからっきしダメ
欧米人はなぜか不思議と音楽になっていくが
日本人はなぜかうまく行かない不思議がある
みたいなのを昔読んでひっかかってたのが元ネタ
あの本では合奏そのものに対する歴史とか
個人レベルでの音に対する感覚とかを原因と考えてたような記憶
>>61
切捨てかぁ…それあるな!!
これは俺が個人的にみっけた法則なんだけど
日本人の動画は長い!つべでも三分くらいある!
要点以外の前後関係を大事にすると言えなくも無い
海外の事故動画なんて数秒、一分未満だけど
日本人が上げてるどうがは五分とかある印象
>>65
もうやめるから許して… 自分自身大して能力が高いわけでもないし、日本的な方法でやっていたら中々成果物が出来上がらない
>>61
細部にこだわりたくなる気持ちはわかる。でもそれをやっていると全体が進まなくなるので
なるべく俯瞰的に、客観的に見るように心がけているな
>>66
もう一人挙げると川口淳一郎氏も優秀なシステムエンジニアだな。初代はやぶさの総指揮官をやった人
中古で良ければ著書がブックオフ等で100円位なので読んでみるといろいろ考えさせられると思う
>動画
手間を掛けたシーンから捨てろ!的な話を聞いた事がある。客観的に見て冗長になっていないか注意せよ
って事なんだが細部にこだわりすぎていると中々難しい プログラミングRust、どっかのイベントで早売りしてたのね 英語版パラパラと見てみたけどrustが日本語で錆だからとunicodeキャラクターの例に錆持ち出してみたり文字列の例で顔文字ಠ_ಠ使ってみたり日本フレンドリーな著者だなと思った。 本に書いてあることは時代遅れって聞いたことがある。大体あっている気はする 本を買うのは最新が知りたいんじゃなくて基礎が知りたいからでしょ The Rust Programming Languageの第二版はだいぶわかりやすいドキュメントになってるな。
rust使わなくてc++だけの人でも読む価値あるわ。 安西先生。自動テストがしたいです。
>>73
2018でその基礎が変わるんだよ。
NLLとかモジュールとかマクロとかraw identとか。
あとedition導入されると新しい機能は
その都度追加される様になるから紙じゃ追いつけなくなる。
>>74
rustのdoc全部いちいち細かいところ間違えてて
ミスリードしまくりだったのが異常だったんだよ。
今マシになってきてる。 rust2018なる風呂敷についてよく知らんけど、基礎を覆すほどのもんじゃないと思うけど
アップデートあったら差分だけ把握すれはいいでしょ 全部いちいち細かいところ間違えるはどう考えても不正確な物言い >>77
Python2と3くらい変わるから別物だよ >>82
単純にキーワード増えるから過去のコードが動かなくなる
今まで Trait と書いていたところを dyn Trait と書かないとコンパイルエラーになる >>83がPython2と3がどれ程違うかを知らないってことは分かった いやそれくらいgrepでよゆうっすよ100万行ファイル置換しましょうオッケー大丈夫! dyn traitはオプションなんですけども
既に追加されているけど元気にコンパイルてるよ
async/awaitについてはどんな理屈で動かなくなるのか想像すらできない キーワード増えるってあらかじめ予約してた奴でしょ? >>86
勿論「いる」
同じ「過去のコードが動かなくなる」でも程度次第で修正の手間が全然違う pythonの場合2to3でも動かないやつあったけどcargo fixで直らないやつあるん?
動かなくなるコードよりNLLで動くようになる放置コードの方が多そう 異なるeditionのcrateを混ぜて使えるんで、簡単な所からcargo fixしていけばいいんでないの? 過去のコードが動くことは保証されてるぞ
ちゃんとeditionの説明読んで 何もしなければそのまま動く
Cargo.toml に edition="2018" と書くと新しい構文やキーワードが有効になる
crateごとにeditionは混在可能
なので破壊的変更はない >>94
保証されているとドキュメントに書いてある
(コンパイラやcargoがそう作られてるとは言っていない) えっ!? 試せるの?
まだ予告されただけなんじゃ… 今だ!100ゲットォォォォ!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ (´´
∧∧ ) (´⌒(´
⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
 ̄ ̄ (´⌒(´⌒;;
ズザーーーーーッ ■ このスレッドは過去ログ倉庫に格納されています