アセンブリ言語でなく高級言語がいくつも作られるのも「単純」を捨ててでも求めるべき抽象化があるからであって

https://twitter.com/lo48576/status/1183434574744842240

> あと「高度な抽象化をさせないことにより『シンプルな表現』の幅が狭まり、低レベルな共通解に落ち着きやすい」みたいなのも私は嫌いなので、なんでも one way to do it であれば良いというものでもないなというのが最近の所感

こういうこと言うとまた怒られるんだろうけど、そもそもまともにメンテするつもりのあるプロジェクトを “最底辺” に合わせちゃ駄目なのでは。
教育で最底辺じゃなくしてから参加させてあげて

このアカウントは、notestockで公開設定になっていません。

狂プロはメンテナンス性よりも速く書くことに重きを置く印象があり、まあ Rust は避けられがちなんだろうなと。知らんけど

動的型付きである必要のない場所で Python とか使いたがる人とかがいるのと似たようなアレでは (知らんけど)

汚いコードを書くと不愉快で不愉快で仕方なくなってくるので、遊びでそんなことをできる人の気持ちは全くわからんなと思っています

むしろ「綺麗なコードを書きたい」よりも「汚いコードを読み書きして不愉快な気分になりたくない」という動機の方が強いまである

抽象化は好きだけど、それはそれとしてな……

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

あの依存計算、並列化できないのかね…… (まあ難しいのだろうけど)

コードで飯食うの確定してるので人生の格を上げるしかねえ…… (手遅れ)

べつにクソコード読んで綺麗に直すとかであればそれはそれで嫌いじゃないんですけどね、汚いコードを汚いままにしろというのは苦痛が大きすぎる

このアカウントは、notestockで公開設定になっていません。

ありがち

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

Panopticlick
https://panopticlick.eff.org/

Firefox はいいぞ

Diesel はプライマリにはクエリビルダであると自身を定義しているので、あれを ORM としてフル活用しようとすると面倒はいろいろあると思う

if is_foo1()
bar = bar1()
elif is_foo2()
bar = bar2()
else
bar = bar3()

とかどう考えてもクソ of クソでしょ、 bar = の代入を無限回書くな、式にしろ

ﾊﾟｲｿｮﾝ、テメーの話だ

Python でもワンライナーで書けるとかいうしょーもないツッコミはお断りしております

まあマトモな言語を使えということですね……

@yuntan_t .at()

Search results for "at" - cppreference.com
https://en.cppreference.com/mwiki/index.php?search=at

@yuntan_t であれば valgrind とか asan みたいなの使うしか……

素直に .at() を使おう

C++ には exception があるから型も変わらないし (まあ noexcept の中でやったりすると面倒そうだけど)

DMMの「コンプラ軽視」を法曹資格持つ社員が指摘、亀山会長に解雇されたと提訴 - 弁護士ドットコム
https://www.bengo4.com/c_5/n_10342/

このアカウントは、notestockで公開設定になっていません。

人々、キャラクターの顔面を過剰に記号化するのやめてほしいw

ずるい

このアカウントは、notestockで公開設定になっていません。

左算術シフトかもしれないのに……どうして……

このアカウントは、notestockで公開設定になっていません。

Rust はいいぞ

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

🎉

Rust 、「本当にほしかった安全な C++」です

今までの様々な言語の知見を最初から活かして作られているので、歴史的経緯を引き摺った言語で苦しんできた人なら幸せになれるよきっと

言語全体での位置付けとしては C++ にかなり近いし、 C / C++ でできることはだいたい Rust でも高効率でできる

このアカウントは、notestockで公開設定になっていません。

静的解析が強いおかげもあるけど、コンパイラのエラーメッセージがめちゃんこ親切という話はよく耳にするし実際そう

このアカウントは、notestockで公開設定になっていません。

const generics と generic associated types と higher kinded types と overload (default impl) は Rust に入ってほしいけどまだ安定化されない4大最強機能

最強というか強すぎて不安になってくるレベルの機能 (でも欲しい)

https://twitter.com/fnya/status/1192036095820615680

三項演算子云々の文脈これか、読む価値全くないじゃん

身近にこんなこと言ってる奴いたら絶対一緒に開発するの拒否するけど

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

それはたぶん代数的データ型の入った関数型言語を使ったことがないから出る感想っぽいので、単純に新しいパラダイムに出会ったということだと思う (それならもちろん勉強は必要)

Scala とか Haskell とか使ったことのある人ならそんなに謎には見えないのだと思う

このアカウントは、notestockで公開設定になっていません。

動的型付き言語が滅びるの、動けばよしとか言っちゃうアホが滅びることが前提条件なので、人類最後の一人が死ぬまで無理だと思う (過激)

const generics とかは言語理論的になかなか爆発に近いパワがあるので、本当にヒヤヒヤしている (でも欲しい！)

Rust も数十年後には legacy C++ みたいなポジションになっているかもしれないけど、それでも C++ の1024倍マシであることは事実だし、我々が現役のうちに離脱が推奨されることはないだろうと踏んでいる

たとえば Rust 1.39 で try! マクロに deprecation warning が出るようになるとか、 Rust 1.40 で legacy (lexical) lifetime checker が削除されるとか、ちょくちょくクリーンアップを図っているので、この調子で頑張ってほしい

rfcs/2504-fix-error.md at master · rust-lang/rfcs
https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md
Tracking issue for RFC 2504, "Fix the Error trait" · Issue #53487 · rust-lang/rust
https://github.com/rust-lang/rust/issues/53487

あと最近特筆すべきものとしては、 std::error::Error trait を再設計しようという動きがあって、互換性を壊さずうまいこと機能をいい感じに入れ替えている

これマジで互換性を壊さずに API を入れ替えているの見事なバランス感覚だと思う

あと std::sync::mpsc とかを third party にしてもいいんじゃないのみたいな議論もあった気がするけど、そっちはあまりちゃんと追い掛けてないな

select! がマトモに動く気配がないとか mpmc が実装されそうにないとかいろいろあってどうにかした方がいいのではみたいな

rfcs/2017-11-09-channel.md at master · crossbeam-rs/rfcs
https://github.com/crossbeam-rs/rfcs/blob/master/text/2017-11-09-channel.md

もともと Display trait でメッセージ生成はできてたんだけど、 Display があるんだから Error::description() は誰も使ってないじゃんという話になって、要らないねとなったっぽい

Error::cause() の方はエラーを型消去して持っといて安全に downcast して使うみたいなユースケースが発覚したので、 downcast できるように + 'static 付けた方がいいよねということになり、 Error::source() で置き換えられた (cause() のデフォルト実装として内部的に source() が呼ばれている)

あとはバックトレースも std の Error でサポートすべく着々と実装が進んでいるらしい

このアカウントは、notestockで公開設定になっていません。

で、社会から C89 / C99 は駆逐されましたか？

まあ C も進化してるといえばしてるんだけど……

整数の内部表現が2の補数であることが保証されたのは C だったか C++ だったか

このアカウントは、notestockで公開設定になっていません。

Java の Second Edition はいつになったら bump されるのか問題

実際「メモリ足りないからシンボル名の識別に使われる文字数は6文字しか保証しないよ」みたいな時代とは違ってリソースに困ることはないわけで、そういう意味ではハードウェアが足枷になることは少なくなってきたのではと思う

並列コンパイルとかもやってるし

strcmp や memcpy の涙ぐましい省略をな……

このアカウントは、notestockで公開設定になっていません。

これから大きな変化が起きるとすればパラダイムとか理論とかの方面なんだろうし、その辺りはそれこそ理論が実装に降ってくるまで十年とか数十年のラグがある分野では…… (それもこれから縮まっていくのかな)

でもそうか、ハードウェアの制約がなくなれば実装に反映されるのも早くなることは期待できるか

しかしこれは罠で、もう性質の良い体系は既にだいたい研究されつくしているのであった

篩型 (refinement types とか liquid types) を標準でサポートしてコンパイラの裏で SAT や SMT ソルバが走るとかであれば、まだまだ計算リソースが欲しくなりそうですね

そもそも静的型付き言語を書くことさえままならない “プログラマ” も多いわけで、言語ばかりそう素敵になっても人間の知能が明らかに追い付いていないという悲しい現実はあるわね

このアカウントは、notestockで公開設定になっていません。

強力な型理論を使うとすぐ型推論が undecidable になったりするので、リソースがあれば良いというものでもないしなぁ

Quote: Rich Cook on Programming Idiot-Proof Programs - Neatorama
https://www.neatorama.com/2008/03/31/quote-rich-cook-on-programming-idiot-proof-programs/

> Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning.
>
> ―― Rich Cook

「今日のプログラミングは、より重大で、より上級の、馬鹿でも使えるプログラムを構築する努力をしているソフトウェアエンジニアと、より重大で、より上級の馬鹿を生み出そうとする宇宙との間の競争である。今のところ、宇宙が勝っている。」

このアカウントは、notestockで公開設定になっていません。

証明付きプログラムを書いたことがないので私は “本物のプログラマ” ではないです

このアカウントは、notestockで公開設定になっていません。

あのー……

NeruPointerException

ぽきた……

#LATECH

このアカウントは、notestockで公開設定になっていません。

markdown で十分とかいう寝言、 CommonMark でセクション ID を指定する方法が規格化されてから出直してくれという感想しかないが！？

「『スマホで十分、パソコンは不要』という人はパソコンを使うほど高度なことをしていないだけ」だし、
「『Markdown で十分、 HTML, LaTeX, etc. は不要』という人は markdown で事足りる程度の意味付けのよわよわな文書しか書いたことがないだけ」でしょ

XML の文法が煩雑という話ならまだ気持ちはわからないでもないが、 markdown で十分なんてありえない

markdown, asciidoc, latex あたりで文字のエスケープがぐちゃぐちゃになっているのを見ると、文脈に関係なく特定の記号を一貫した方法でエスケープできる XML は文法として優れているなぁと毎回感じるので、「他の形式よりもかなりマシ」という感想

私は自動的な意味付けに賛同しないのでそれでいいやという感想

まあ人間様が最後に必ず目を通すということならある程度の自動的な支援はあってもいいかもしれないけど……

まあそれ以前の問題として、そもそも文書の意味構造を表現するスキーマ自体で何が良いか合意が取れていないという深刻な問題もある

HTML でいい人もいれば DocBook や AsciiDoc がほしい人もいるし、 LaTeX みたいに滅茶苦茶にしたい人もいれば markdown 程度で満足できる人もいるし

このアカウントは、notestockで公開設定になっていません。

だいたい文脈によって2通りの意味があって、

* どれだけ多くの種類のプログラムを書けるか
* 自然に (本質的でない部分で煩雑にせずに) 事象のどれだけ多くを書けるか

なんだけど、前者はチューリング完全な言語であればすべて等価なので、後者の意味で使われるケースが多い

あーそっちの「言語」もあったわ……

完全に失念していた

このアカウントは、notestockで公開設定になっていません。

単純と簡潔と簡単はどれも微妙に違うので別概念

いわゆる「表現力の高い言語」で求めているのは「様々な問題を完結に表現できること」。
簡単にするのは言語でなくライブラリの API の仕事のことが多いし、本質的に複雑な問題はそもそも「単純」に記述できないことも多いのでそれは言語に求めるものではない

正規表現は大抵簡潔ではない……人生はつらく険しい

どうして……

単純なものは使うのが難しい、簡潔なものは用意するのが難しい

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

“本物のプログラマ” になろうな👊

証明のないプログラムなんて妄想だよな！！

このアカウントは、notestockで公開設定になっていません。

あれは参考演算子じゃなくてアホが炎上してるだけ

Coq って直観主義論理なのか……道理で直観的だと思った！！ (白目)

#直観主義論理は直観的

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ぼくはかけざんができない

かけざんが証明できた。私はかけざんがわかる。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。