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

推荐订阅源

Spread Privacy
Spread Privacy
K
Kaspersky official blog
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Forbes - Security
Forbes - Security
Hacker News - Newest:
Hacker News - Newest: "LLM"
The Last Watchdog
The Last Watchdog
SecWiki News
SecWiki News
Attack and Defense Labs
Attack and Defense Labs
Google DeepMind News
Google DeepMind News
Security Archives - TechRepublic
Security Archives - TechRepublic
S
Secure Thoughts
WordPress大学
WordPress大学
Microsoft Security Blog
Microsoft Security Blog
P
Proofpoint News Feed
云风的 BLOG
云风的 BLOG
V
Visual Studio Blog
Security Latest
Security Latest
TaoSecurity Blog
TaoSecurity Blog
Cyberwarzone
Cyberwarzone
S
SegmentFault 最新的问题
Cloudbric
Cloudbric
aimingoo的专栏
aimingoo的专栏
S
Schneier on Security
N
Netflix TechBlog - Medium
MyScale Blog
MyScale Blog
T
The Blog of Author Tim Ferriss
H
Hacker News: Front Page
C
Cybersecurity and Infrastructure Security Agency CISA
小众软件
小众软件
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
AWS News Blog
AWS News Blog
AI
AI
G
GRAHAM CLULEY
IT之家
IT之家
P
Privacy & Cybersecurity Law Blog
L
Lohrmann on Cybersecurity
Last Week in AI
Last Week in AI
D
Docker
Recent Announcements
Recent Announcements
O
OpenAI News
T
Threat Research - Cisco Blogs
GbyAI
GbyAI
S
Security @ Cisco Blogs
T
Troy Hunt's Blog
C
Check Point Blog
博客园 - 三生石上(FineUI控件)
A
About on SuperTechFans
The Cloudflare Blog
阮一峰的网络日志
阮一峰的网络日志
N
News and Events Feed by Topic

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: