The evolution of c#

The Evolution of C#
C#の秘めるポテンシャルとソーシャルゲーム

gloops Holdings Pte. Ltd.
Engineer
Microsoft MVP for Visual C#
Yoshifumi Kawai

Self Introduction
株式会社gloops (グループス)
ソーシャルアプリケーションプロバイダ
大戦乱!!三国志バトル, 大召喚!!マジゲート, etc…
Windows Server(IIS) + SQL Server + ASP.NET + C# で構築

個人活動
Web : http://neue.cc/
Twitter : @neuecc
Microsoft MVP for Visual C# (2011/04 – 2013/04)

The Evolution of C# Async

2010 C# 4.0
LINQ 2012 C# 5.0

Dynamic
2005 C# 2.0
Java/Delphi 2008 C# 3.0

Generics
2002 C# 1.0

最適な言語を選択する
領域が変われば言語は変わる
Cは基本！C最速！Cで全て書ける！
……わけはない。
Cの生産性でウェブアプリケーションを作るのは大変だし利点もない
書けないわけではないけど、実質書けない

ウェブアプリケーションで大事なのは？
パフォーマンスは勿論大事、だけど全てにおける優先事項ではない
比較対象がC++とか、そういうお話
CPUよりもDBアクセスとかがネックになりがちなので
速いリリース速度に対応するための軽量さが何よりも大事

軽量とは
Lightweight Laguage...
軽量プログラミング言語（けいりょうプログラミングげんご、和製英
語:Lightweight Language,LL）とは、日本においてスクリプト言語を指す
ジャングリッシュで、取り回しに優れ、コードの作成や修正が容易と見な
されるプログラミング言語のことを指す。
出展:ウィキペディア「軽量プログラミング言語」

つまるところ
コードの作成や修正が容易であること
それは、リリース後も高速に更新をし続ける、ソーシャルゲームで何より
も大事なこと

C#は軽量か？
軽量です！
Rubyなどと比較しても？
Visual Studioという翼があれば！

今時の言語は単独で評価できない
IDE・フレームワーク・言語、これらは三位一体

Visual Studioはロケットブースター
C#単体の走る速度はLLには敵わないかもしれない
しかしロケットブースターがついた時、その速さには誰も敵わない

自動生成 vs 言語機能
どちらも大事
自動生成があれば全て事足りる、などということはない
いくらIDEがロケットブースターでも、重さは、重さ

例えば型推論
C# 3.0から入った機能
型は非常に大事だけど、手で書くのは面倒なので推論してくれる
言語機能にそれがない場合、IDEを使って右側の型から自動生成で宣言す
る型を作ることもできる(e.g. Eclipse)
でも、頻繁に行う部分でそれって、凄く手間だし、コード上の視覚的にも
良くない

静的型付け vs 動的型付け
コンパイルでの検出ってやっぱ大事
ユニットテストがあるからなくても大丈夫、ではない
コンパイルエラーならIDEが「リアルタイム」に検出する
リアルタイムなのは、速さであり軽さ

強力な入力支援
甘美なるIntelliSense！もうこれなしで生きていけない！

強力なリファクタリング支援
ソーシャルゲームの頻繁な更新のもとでは、設計は不変、ではない
むしろころころ変わる
強固なリファクタリング支援は型付けあってのもの

足を止めたらお終い
要求が変わっていくのは当たり前
10年前に現代のようなプログラミングは想像できたか？

言語も進化し続けなければならない
要求が変われば、追随していかなければならない
ただたんに書ければいい、というだけではダメ
より軽量に！より高速に！

→C#ははどのように進化していったか

C# 3.0 - LINQ
LINQの存在はC#の大きな強み
あらゆるデータを統一的に扱う仕組み
特にコレクションに対する操作(LINQ to Objects)が強力
LINQ != SQLです:)

コレクション？
データベースから取得したデータもそう
"select * from hogehoge"の結果は行のコレクション
ウェブアプリケーションの中心はやはり、それ！
DB上で整形済みだから、特に必要ない……？

JOINを避ける
DBへの負荷削減
大量のデータを扱う関係上、JOINは極力避けるようにしている
代わりにメモリにキャッシュ可能なデータは積極的にメモリへ

NoSQL
高速なデータ取得、かわりにDB上での柔軟な結合はない
gloopsではMemcachedとRedisを利用中

LINQ to Objectsによるインメモリ結合
データはC#上で結合するが、普通にやると生産性落ちるしバグの元
そこで、LINQ to Objectsを使う
SQLよりも強力なパワーを持つので、むしろ書きやすい

例えばこんなインメモリ結合
パーティー装備アイテム皮の鎧、とか……

勇者
色が一致するのがそのキャラ
クターの装備してるアイテム
剣士

魔法使い
パーティーテーブルと装備アイテ
僧侶ムテーブルを結合したい！

こういう風に結合されればいい
勇者

剣士

魔法使い
それGroupJoinで一撃
僧侶

party.GroupJoin(equipItems,
x => x.CharacterId, x => x.CharacterId,
(character, items) => new { character, items });

GroupJoin != OuterJoin
勇者

剣士

魔法使いオブジェクトの集合をバラさ
ずそのままで結合
僧侶

(character, items) => new { character, items });

LINQ > SQL
SQLの外部結合と同じようにも出来る
SelectManyでバラすだけ
// SelectManyでバラす & DefaultIfEmptyで存在しない場合のnull化
(character, items) => new { character, items })
.SelectMany(x => x.items.DefaultIfEmpty(), (chara, ....

でも、わざわざバラす必要はない
むしろバラした形でしか問い合わせできないのはSQLが問題
自由なクエリはSQL的なしがらみに囚われなくていい

C# 4.0 - Dynamic
世界の全てが型付けできはしない
外の世界とのやり取りの境界線が必ずある
そこで基本は静的に、部分的に動的にするのがdynamic

例えば？
SignalRというWebSocketなどを透過的に扱うライブラリがある
WebSocketという最新フィーチャーにも.NETは追随してます！
（擬似的に）ブラウザ上のメソッドを呼び出すことが出来
ここでの境界はブラウザ上で動くJavaScriptであり、動的な存在

C# 5.0 - Async
高まる非同期処理の重要性
Node.js（流行ってますね！）に代表されるノンブロッキングI/O
I/Oを待っている間のスレッド消費がなくなる

が、しかしコールバック地獄
ネストする関数
例外処理は？リトライ処理は？
気の利いたライブラリでカバーしようにも限界

C# 5.0は言語構文として用意した
非同期処理が重要だ、という時代の要請への素早い対応

C# 6.0? - Compiler as a Service
C#はIDEとの相性が考えられている
C# + Visual Studioの良さは、言語設計からして考慮されているから
例えばC#の型推論は非力な側面もあるけれど、IDEでの入力補完などを考
えると、ギリギリのラインになっている

Visual Studioを拡張する
ただのエディタマクロ以上の拡張を実装するには、構文解析が必要
そこでC#自体のParserを提供、更にVisual Studio拡張との融合も
これにより個々のアプリケーション開発に特化した拡張機能を、簡単に作
ることができ、生産性が爆発的に高まる

まとめ
進化する言語 C#
大事なことなので三度言いました！
業界の最前線、高い要求に対して、応え続けてくれる
C# + Visual Studio + .NET Frameworkと、三位一体で進化し続けている

言語が思考を規定する
言語が進化するのは、決して複雑怪奇にしたいからではない
むしろ楽させるために進化している
常により良いを目指して、しがらみに囚われず変わり続けよう

The evolution of c#

More Related Content

What's hot

Viewers also liked

Similar to The evolution of c#

More from leverages_event

The evolution of c#