惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

C
Check Point Blog
AI
AI
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
U
Unit 42
Vercel News
Vercel News
Stack Overflow Blog
Stack Overflow Blog
P
Proofpoint News Feed
Microsoft Security Blog
Microsoft Security Blog
The GitHub Blog
The GitHub Blog
WordPress大学
WordPress大学
Martin Fowler
Martin Fowler
博客园 - 【当耐特】
B
Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Apple Machine Learning Research
Apple Machine Learning Research
博客园_首页
F
Full Disclosure
Google DeepMind News
Google DeepMind News
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
H
Help Net Security
Recorded Future
Recorded Future
N
News and Events Feed by Topic
雷峰网
雷峰网
V
Vulnerabilities – Threatpost
Schneier on Security
Schneier on Security
aimingoo的专栏
aimingoo的专栏
S
Schneier on Security
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
O
OpenAI News
Project Zero
Project Zero
罗磊的独立博客
G
GRAHAM CLULEY
腾讯CDC
P
Privacy International News Feed
V
V2EX
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Hugging Face - Blog
Hugging Face - Blog
爱范儿
爱范儿
H
Heimdal Security Blog
L
LINUX DO - 热门话题
Forbes - Security
Forbes - Security
美团技术团队
MongoDB | Blog
MongoDB | Blog
Security Latest
Security Latest
M
MIT News - Artificial intelligence
T
Tor Project blog
Cisco Talos Blog
Cisco Talos Blog
宝玉的分享
宝玉的分享
T
Threat Research - Cisco Blogs
TaoSecurity Blog
TaoSecurity Blog

hayato

Chromium's DOM Deep Dive: Understanding Shadow DOM and Tree Structures - hayato Introducing the Task Scheduler in Chromium's Network Stack: A 0.3% Improvement in Loading Speed - hayato 出版のお知らせ 「普通の人が資産運用で99点をとる方法とその考え方」 - hayato Resource loading with Content Addressable Bundles - hayato 普通の人が資産運用で99点をとる方法とその考え方 - hayato Imperative Shadow DOM Distribution API - hayato Google にソフトウェアエンジニアとして入社して 10 年と 10 日がたちました - hayato Web のつくりかた: ソフトウェアエンジニアリングと雰囲気で理解する Web 標準とブラウザのつくりかた - hayato ブラウザのしくみ: データ構造とアルゴリズムと雰囲気で理解する DOM と Shadow DOM - hayato 六本木ではたらくソフトウェアエンジニアへのよくある質問とその答え (FAQ) (2015 - 2017) - hayato What's New in Shadow DOM v1 (by examples) - hayato Simple timer application for the pomodoro technique - hayato Google の面接試験で出る (はずがない)「海賊と金貨」問題を空気を読まないでプログラムで解いてみる - hayato hayato.io (4topcoder) - hayato SRM432 - hayato SRM405 - hayato SRM386 - hayato SRM385 - hayato SRM384 - ゲーム - hayato SRM369 - hayato SRM368 - hayato SRM366 - typo 2 連発 - hayato Python - generator で素数生成 - hayato New Launguage - 新言語追加の予定? - hayato lxml で HTML スクレーピング - hayato SRM358 - Today is a Bad Day (-50). - hayato SRM349 FizzBuzz 問題が簡単すぎるそんなあなたへ。「赤いマーブル問題」。 - hayato Suffix Array - hayato google-code-prettify を導入してみる - hayato Subset の生成 - hayato 2006 年のまとめ - SRM332 - hayato Google Code Jam 2006 - Championship Round - hayato Blogger Beta に移行 - hayato Google Code Jam 2006 - Round1 に挑戦 - Generics と AutoBoxing - hayato Google Code Jam 2006 - Qualification Round 通過 - hayato Google Code Jam 2006 - Qualification Round に挑戦 - hayato Google Code Jam 2006 - Practice1 - hayato Google Code Jam 2006 - 開催決定 - hayato Stay tuned... Global Google Code Jam 2006 - 秋に開催? - hayato SRM308 - Hard DP - hayato SRM304 - 条件付確率 - hayato JavaWorld に寄稿しました - hayato 2006 TopCoder Open Final Round - hayato IBM Rational Software Development Forum Tokyo で講演します - hayato SRM298 - ひとふで書き - hayato SRM293 - ビンゴ - hayato 2006 TopCoder Open - Round1 撃墜 - hayato 2006 TopCoder Open - Odds 発表 - hayato 2006 TopCoder Open Qualification Round - hayato SRM291 - OutOfMemory - hayato デブサミ 2006 で講演します - hayato SRM287 - 気分は中学生?連立2元方程式 - hayato SRM281 - 2006 年はポイントゼロスタート - hayato SRM280 - Challenge 祭り - hayato SRM277 - 初賞金げっと - hayato マラソン・マッチ - hayato reStructuredText で blogger - hayato 2006 TopCoder Open - NSA がスポンサーに - hayato SRM276 - お買い物は楽しく DP で - hayato SRM273 - bit 演算は int で行われるのね - hayato SRM272 - Division1 - 4 度目の正直 - hayato JavaOne Tokyo で講演します - hayato SRM270 - Integer == Integer - hayato SRM268 - Division2 脱出 - hayato SRM266 - NASA, we have a problem... - hayato SRM265 - Division2 落ち... - hayato SRM262 - 初 Division1 は Typo に終わる - hayato SRM260 - TopCoder への挑戦のはじまり - hayato
Rust が最強のプログラミング言語である証明 - hayato
2017-08-30 · via hayato

2017 年現在、Rust が最強のプログラミング言語である証明を以下に示します。

ICFP プログラミングコンテスト

ICFP プログラミングコンテストの説明については以下をご覧ください。

ICFP Programming Contest は「なんでもあり」が特徴の,他とは一線を画す特徴的な プログラミングコンテストです.ACM の関数型プログラミング言語の学会 ICFP (International Conference on Functional Programming) に伴って毎年開催されてい まして (1) プログラミング言語自由 (2) 計算資源自由 (2) チーム人数制限なし (3) 72 時間勝負 (4) 問題の形式も毎年大きく変化,等の特徴があります.優勝者は「その 年のプログラミング言語」を決めることとなっており「その年はその言語の文句は言え ない」とか.

引用元: http://iwiwi.hatenablog.com/entry/20130927/1380255924

コンテスト優勝チームが使用した言語は「優秀なハッカーに選ばれたプログラミング言語」として正式に認定されます。さらに優勝チームには「使用したプログラミング言語を一年間無制限に自慢してよい」という名誉ある権利が与えられます。

そのため ICFP プログラミングコンテストは「最強のプログラミング言語を決める大会」という側面があります1

最近は以下のような風潮もあるようなのですが:

実は最近のICFPContestに対する参加者の態度にやや疑問を持っているんだ…
最強言語認定を自分の好きな言語に与えるために勝利を目指すんだと思ってたんだけど、まず勝つこと先行でそのためには混成言語編成チームでもかまわないみたいなのは風情に欠けるんじゃないかって

— Noriyuki OHKAWA (@notogawa) August 4, 2017

それでも「自分の好きな言語に優勝させてやる!」という熱い思いをもった参加者が今年も大勢参加しました。

2017 年、今年のコンテストを主催したのはオックスフォード大学です。

私は昨年に引き続き Rust で参加しました。8 月 4 日から 8 月 7 日にかけての 72 時間です。

今年の問題

今年の問題を簡単にいうと「鉱山(λ)に道をつなげてより多くの都市(λ から遠ければ遠いほど高得点)に到達しましょう。」という問題でした。実際のルールはもっと複雑です。興味がある方は、実際の問題仕様を見てください。

「百聞は一見にしかず」、以下の実際に行われた戦いの様子をご覧ください。私はチーム hayatox です。

(Link, その他の大きなマップでの戦い: Map: junction, Map: nara)

結果

参加者から提出されたプログラムをもとにした、コンテストの1st ラウンドの結果が今週発表されました。それによると参加チームは 146 チーム。そのうち 26 チームは提出したプログラムが仕様を満たしていないことが判明し参加不可能。残りの 120 チームの間で戦いが行われました。

果たしてどの言語が今年は最強の名を手にするのでしょうか?

各チームの使用した言語は現在のところコンテストのサイトでは明らかになっていません。そのため以下の条件で各言語を代表するチームを適当に選びました。

  1. GitHub を"icfp 2017"で検索
  2. メインで使用した言語がほぼひとつであることをチェック(そうでなければスキップ)
  3. チーム名が README 等に記載されている
  4. 1st ラウンドの結果にチーム名が載っている -> 採用

各プログラミング言語とそれを使用したチーム 2 とその人数 3 、そしてチームの獲得ポイント 4 です 。

使用言語チーム名人数獲得ポイント
Rusthayatox1109 109
C++GennAI8106 106
HaskellSampou7108 108
Common Lispcvnm169 69
Clojuredrop table teams;238 38
JavaA Storm Of Minds2109 109
KotlinLambada Calculus986 86
Scalacodingteam448 48
C#kontur.ru1670 70
F#lambda-llama50 0
ElixirThe Mikinators842 42
PythonLambding Snakes vs Coding Monkeys494 94
GoMIPT Lambda364 64
  • Rust 十分強い。しかし最強という感じはまだ受けません。
  • ほとんどのチームは複数人で参加していることがわかりました。ひとりで参加している「ぼっちチーム」は Rust 以外は Common Lisp だけです。さすが Lisp。孤高の存在。
  • 特に C++を用いたチーム GennAI は 8 人中 7(?)人が Google のソフトウェアエンジニアです。
  • さらに特筆すべきは C#を用いたチーム kontur.ru。なんと 16 人チーム!もはや数の暴力です。

正規化

数の暴力にはこちらも理不尽な理論で対抗するしかありません。「獲得ポイント」を「チームの人数」で割ってやりましょう 5。正規化した結果は以下のようになります。

使用言語正規化
Rust109.0 109.0
C++13.2 13.2
Haskell15.4 15.4
Common Lisp69.0 69.0
Clojure19.0 19.0
Java54.5 54.5
Kotlin9.6 9.6
Scala12.0 12.0
C#4.4 4.4
F#0.0 0.0
Elixir5.2 5.2
Python23.5 23.5
Go21.3 21.3

以上により Rust が最強であることが示されました 6。証明終わり。

おまけ

RustでICFPCに参加した同僚「コンパイラがチームメイトみたいなもんでしたよ」

— いもす (@imos) August 8, 2017

そういえばコンテストの翌日にオフィスで会った時そんなこといった気がします。:)

実際、私は大したことはしていません。今回は合計で 12 時間くらいしか参加しておらず、仕様もすべては実装していません 7 。それにもかかわらず最低限動くプログラムを完成・提出できたのは、すべては Rust という素晴らしい言語を作成したコアチームと、crates.io という素晴らしいパッケージ ・エコシステムのおかげです。今回のコンテストではじめて使用したライブラリがいくつかありますが、すべて苦労することなく使用することができました。私は巨人の肩に乗っ かっただけです。

来年に向けて

  • 「私の愛する JavaScript が Rust ごときに負けるはずがない。」
  • 「はっはっはっ。自称最強 Ruby 使いであるこの私が出場していない大会で良い成績をとることに何の意味があるというのか?かわいいやつらめ。」
  • 「その証明には致命的な誤りがあります。どこが間違っているかというと....」

もっともなご意見でございます。しかしながら、参加しない人に反論する権利はまったく与えられないのがこの ICFP プログラミングコンテストです。

唯一の正しい反論の方法は「机上の空論を展開」することではなく、実際に「愛する XXX 言語を勝たせてやる」ことです 8。ぜひ来年の ICFP プログラミングコ ンテスト 2018 に参加してみてください。

興味をもった方は雰囲気をつかむため過去の問題に挑戦してみるとよいかもしれません。特に 2006 年カーネギーメロン大学が主催した「古代文明が作ったコンピュータの仕様とその上で動くプログラムを記した古文書」を巡るコンテストは「神回」として伝説になっています 9。ぜひ挑戦してみてくださいね。


footnotes: