ラベル プログラミング の投稿を表示しています。 すべての投稿を表示
ラベル プログラミング の投稿を表示しています。 すべての投稿を表示

をしようと思ったのですの。

前に書いたように、ラムダというか匿名関数自体は使えるし、それを投げることも出来るのですの。なのでいけるかなと思ったのですの。

でも、クラスメソッドとして書いた関数は、匿名関数のように投げ回すことが出来ないようなのですの。ふべん。

代わりにこう↓かけたらいいなと、

class Foo{
 $bar = function (){
  return ~~~;
 };
}

思ったのですけどダメで、、

PHP:プロパティ
http://php.net/manual/ja/language.oop5.properties.php
宣言時に初期値を設定することもできますが、初期値は定数値でなければなりません。
ということで、
こう↓するしかないみたいですの。

class Foo{
 public $bar;
 function __construct(){
  $bar =  function (){
   return ~~~;
  };
 }
}

でもこの方法だと、関数をたくさん並べたときに宣言と定義の位置が離れて見づらくなるので嫌なのですの、、

なんとか良い感じに書ける方法があればいいのですけど、、


--2018/12/24 追記
メンバ変数の宣言時に関数を代入出来ないのなら、メンバ変数の宣言をコンストラクタ内に持ってくればいいじゃないですの!

class Foo{
 function __construct(){
  $this->bar = function (){
   return ~~~;
  };
 }
}

一応これは成功しましたの。さすがPHPですの。
ただ、ここでもう一つ問題がわかって。メンバ変数に関数を入れた場合、それを呼び出すときに普通のクラスメソッドのようには呼び出せないそうなのですの。

【PHP】プロパティに格納されたクロージャを呼び出す方法まとめ
https://qiita.com/rhap/items/1701247844772c3c92f0

なぜそんな意地悪を。。

ということで、ここで心が折れましたの。
自由に投げられるクラスメソッドが欲しくて調べはじめたので、普通のクラスメソッドとして扱えなくなってしまうようだと厳しいですの。

しかも、一番簡単そうな「括弧でくくる」方法は、PHP5.4では使えないようですの。いったんローカル変数に入れて呼び出す方法なら出来たのですけど、これはちょっと嫌ですの。

↓これはNGで
    /*
     * @dataProvider forNantoka
     */

↓これだと動くみたいですの
    /**
     * @dataProvider forNantoka
     */

上段のアスタリスクに注目ですの。

/*~*/は通常のブロックコメントで、
/**~*/はドキュメンテーションブロックという、アノテーションを書くための特殊なブロックだそうですの。

@dataProvider もアノテーションの一つなので、ドキュメンテーションブロックで書かないと動かないということですの。


PHPUnit data provider error
https://stackoverflow.com/questions/14426208/phpunit-data-provider-error

2. アノテーション
https://phpunit.readthedocs.io/ja/latest/annotations.html

2日ほど頭を抱えていたのがやっと動いたのでメモですの。

Windows環境
NetBeans8.2(PHP用)
XAMPP1.8.2(PHP5.4.31)

・ツール>オプション>一般 の設定
 PHP5インタプリタ
  xampp/php/php.exe

・ツール>オプション>フレームワークおよびツール>PHPUnit の設定
 PHPUnitスクリプト
  xampp/php/phpunit.bat

 スケルトン・ジェネレータ・スクリプト
  DLしたpharファイルをおいた場所を指定(たぶんどこでも良い)

・プロジェクト・プロパティ(プロジェクトを右クリック>プロパティ) の設定
 テスト>PHPUnit
  ブートストラップの使用 にチェックを入れ、「生成」ボタンを押す

・xDebugの設定(コードカバレッジを取るのに必要)
 xamppのphp.iniの最後のほうの[XDebug]の欄のコメントアウトをすべて外して、xamppのapacheを再起動する

持っている本のタイトル(ピンク)、著者名、著者紹介 ですの。

とくに流れを感じられるようなリストにはなっていないのですけど、ソフトウェア見積もりとCodeCompleteの著者が同じだったのは驚きましたの。どちらも良書で、とくにCodeCompleteは最高の一冊なので、さすがという感じですの。 


Clean Architecture 達人に学ぶソフトウェアの構造と設計
Robert C. Martin/ロバート・セシル・マーティン(1952~)
コンサルティング会社を経営(Uncle Bob Consulting LLC. と、Clean Coders)
アジャイルソフトウェア開発宣言の共著者、FitNesseの作者
愛称:ボブおじさん 
SOLID原則をまとめた。Clean Architectureの提唱者

ソフトウェア見積り 人月の暗黙知を解き明かす
Code Complete 第2版 完全なプログラミングを目指して
Steve McConnell/スティーブ マコネル(1962~)
ソフトウェア工学教科書の著者
ソフトウェアエンジニアリングとプロジェクト管理の専門家
他に有名らしい本:ラピッドデベロップメント―効率的な開発を目指して

熊とワルツを リスクを愉しむプロジェクト管理
Tom DeMarco/トム デマルコ(1940~)
70年代の構造化分析と構造化された設計の開発における主要人物の1人
有名な本:構造化分析とシステム仕様

ソフトウェアテスト293の鉄則
Cem Kaner/セム ケイナー
フロリダ工科大学のソフトウェア工学教授
ソフトウェアテスティング協会(AST)を設立
消費者保護擁護者としての立法業務(統一コンピュータ情報取引法、統一電子取引法の草案への参加など)を行った。

ユースケース駆動開発実践ガイド
Doug Rosenberg/ダグ・ローゼンバーグ
Iconixプロセスの提唱者。XPの最も激しい反対者の1人
(↑の本もIconixの本らしい)

レガシーコード改善ガイド
Michael C. Feathers/マイケル・C・フェザーズ
Object Mentor社勤務(コンサルティング系の会社?)
CppUnit、FitCPPのオリジナル開発者 


レガシーソフトウェア改善ガイド
Chris Birchall/クリス・バーチャル
広範なプロジェクトを経験後、ロンドンのガーディアン紙で、
シニアデベロッパとしてWebサイトのバックエンドサービスを担当

最近読んでいるClean Architectureの著者のRobert C. Martinさんが、Wikiを使ったテストツール FitNesseの作者さんでしたの。びっくり。FitNesseは以前、テストについて調べていたときに見つけて面白いなーと思ったツールだったのですの。

ソフトウェアの世界の有名人なのだから、なにかすごいソフトを作っていても驚くことではないはずなのですけど、いざ遭遇すると破壊力が高いですの。

そういえば、Winnyで有名な(?)金子勇さんを初めて知ったのは、NekoFightの作者さんとしてでしたの。

NekoFight
http://kaneko-isamu.la.coocan.jp/nfight.htm 

あんまり話題になった記憶のないソフトなのですけど、実際、とんでもない作品で。初めてみたとき、世間知らずなわらわは「ネットの世の中にはこんなものを作れる人がごろごろいるのかー」と、ショックを受けた作品でもありますの。

10年くらい前、AIを作ろうとして、3層ニューラルネット+バックプロパゲーションを勉強していて、難しすぎてぜんぜんわからなくて困っていたわらわの目に飛び込んできたのが、この文章でしたの。
 AIの方式は単なる3層ニューラルネットで、学習アルゴリズムは私独自のED法(誤差拡散法)です。
ED法は、バックプロパゲーションが実際の神経系のメカニズムとしてはありえないというのが気になって私の方で考え出した学習アルゴリズムですが、 学習速度が非常に速いのと、中間層を増やせば無制限に性能が上がるのが特徴のアルゴリズムです。私の方では、おそらく本物の脳みそ(前頭前野大脳皮質)も こんな学習アルゴリズムなんじゃないかと思ってますがもちろん確証は無し(笑)
ものすごく苦労しても理解できないものを、あっさり(?)超えていってしまう。こんな人がその辺にいるなら、わらわがやってもしょうがないのでは?と思ったものですの。

あとで経歴を知ってびっくり。ぜんぜんその辺にいないレベルの人でしたの。(原子力研究所で働いて、未踏ソフトウェアに参加して、東大大学院で教えてた人)

NekoFightは、そのうち注目されて解説でも出回らないかなと思ってずっと見ていたので、まさかの訃報に別の意味でもショックを受け。。

なんだかうまくまとまらない文章になってしまったのですけど、話を戻すと、技術書の内容自体ではなく、”人”について調べてみるのも面白いかなと思ったのですの。

それまで自動テストを導入していない状態から、いきなりフルセットのテスト項目を想定してテスト駆動開発をはじめるのは大変で当然だと思いますの。

そこで思ったのは、次のようなステップで進めていけば始めやすいのでは?ということですの。
  1. 要求を実現するための、シンプルなテスト項目だけで開発を進める
  2. たいてい訪れる「実装中にうまくいかなくなって動作を検証したくなるとき」が来たら、その内容をテスト項目として追加していく
  3. あらかた形が出来てきたら、テスト項目を増やしてフルセットに近づけていく
おそらく、いきなり網羅的なテストとか、異常テストとかを盛り込んで始めるのは、慣れた人でないと難しいのではと思うのですの。

というか、実装前にクラス/メソッドレベルで完璧に設計が出来ているというのは非現実的なので、実装しながら問題点に気づいてあれこれ変えて形を作っていくことを考えると、こういう感じでないとロスが大きいと思うのですの。

ただ、試してみたわけではないので、いまのところ空論ですの。
これまでの議論から必然的に導けるのは、コンポーネントの構造をトップダウンで設計するのは不可能だということだ。コンポーネントの構造は、システム 設計の際に検討するだけのものではなく、その後もどんどん変わっていく。
Clean Architecture 達人に学ぶソフトウェアの構造と設計
第14章>トップダウンの設計 より

アジャイルで開発する場合、テストその他の自動化は推奨ではなく必須だそうですの。
であれば、どんな言語を使うか選ぶ際も、その言語に対応した自動化ツールがどのくらいあって、どういう使い勝手なのか、うまく連携は出来るのか、といったことが、言語そのものの良し悪しと同じくらい大切になってくるのかなと思いましたの。

書こうとして数日、手が止まってしまいましたの。
PHPという言語への興味の惹かれなさが浮き彫りに…という感じですの。

使うシーンは多いので、一度、改めて整理してみることに価値はあると思うのですけど、手が動かないですの。

関数型発祥らしく、計算や判定の類は書きやすく、逆に、副作用が中心になる、手続き型を強制されるような部分は(単体では)書きにくいか書けないという感じだと思いますの。

基本的に大抵のことは出来て、別関数でお膳立てしてあげれば何でも出来る、という印象ですの。(お膳立てしすぎると、最悪、ラムダ式の部分がただのラッパーになるというのはあるにしろ、、)


また、C#7からは、式中で変数の宣言が出来るようになったそうで、逆に言えば、C#6ではそれが出来ないですの。

でも、単に変数を加工していく感じを真似るだけなら、selectでメソッドチェーンしていく構造にする手も。あまり意味はないかも知れないけれど。

例えば、引数で数値をもらって、それを要素1つのIEnumerableに変換してselectを繰り返して、最後に数値に戻して返す。

public int getPiyo(int x) => Enumerable.Repeat(x, 1).Select(c => c * 2).Select(c => c / 2).First();

意味があるかはともかく、一応出来るようですの。

ちなみに、この例のような数値計算なら
public int getPiyo(int x) => x * 2 / 2;
と書くのが圧倒的に素直ですの。

+ 日本語コーディングしようぜ
http://www.flat7th.org/~keizo/wiki/code2/KyDml6XmnKzoqp7jgrPjg7zjg4fjgqPjg7PjgrDjgZfjgojjgYbjgZw

日本語コーディング、そういうのもあるのかですの。

大会かなにかで賞金が成績によって決まるものがあったとして、
参加者が10人未満なら成績の合計、10人以上なら成績の平均の10倍が賞金になるとき、それを求めるクラスメソッド、

public int getBonus(IEnumerable scores)
{
 if (scores.Count() < 10)
 {
  return scores.Sum();
 }
 else
 {
  return (int)scores.Average() * 10;
 }
}

これを、ラムダ式と日本語コーディングにおまけで三項演算を加えて書くと以下ですの。

(一行版)
public int get賞金(IEnumerable 成績s) => 成績s.Count() < 10 ? 成績s.Sum() : (int)成績s.Average() * 10;

(改行を入れた版)
public int get賞金(IEnumerable 成績s) => 
成績s.Count() < 10
? 成績s.Sum()
: (int)成績s.Average() * 10;

量的に少ないせいか、思ったより迫力がないですの。むしろ最初のコードより短くて見やすい気もしますの。
ただ、わらわがC#の標準の中括弧の付け方(BSD/オールマン・スタイル)が嫌いなこともあって、そもそも中括弧を使わないで済むというのはとても爽快ですの。

使いそうなLinq関数

Select(式)(シーケンスを加工する)
Where(式)(条件を満たす要素を取得)
First()(先頭の要素を取得)
All(式)(すべての要素が条件を満たすか)
Any(式)(条件を満たす要素が1つでもあるか)
ToArray()(配列に変換)
Constains(値)(条件に一致する要素があるか)
ElementAt(値)(指定番目の要素を取得)

クラスメソッドとして書く場合は、
public int a(int n) => n + 1;
のような短文形式のみ可能で、
public int a(int n) => {(略); return n};
のようなブロックで囲う複文形式は許可されないですの。

同様に、if文は使えない…けれど、三項演算子は使えるようですの。
public int a(int n) => n == 1 ? 1 : 0;


式形式のメンバー (C# プログラミング ガイド)
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members
式本体の定義のサポートは、メソッドとプロパティの get アクセサーのために C# 6 で導入され、C# 7.0 で拡張されました。 
とあるように、基本的には簡単な(?)getアクセサ用にあるようですの。

ろくなプログラムを書いていないせいか、
ろくにプログラムを書いていないせいか、
最近、プログラミング能力が上がるどころか地に落ちている気がしますの。

関数型言語の美しさに触れてからというもの、オブジェクト指向の醜い部分が気になってしかたがなく。オブジェクト指向を捨てたはいいものの、関数型を実用できるほどの力も環境もなく。

いっとき、C#のLinqに賭けたものの、期待したほどの力はLinqには無く。

今はただ、PHPあたりでゴミクズのようなコードを書くばかり。

プログラミング自体もまあ好きだったけれど、やっぱりその前に、プログラミングで好きなものを作るのが好きだったのかな、と、素朴に思うのですの。いまごろになって。

どうでもいいものを、どうでもいい感じで作りすぎたせいなのか、好きなものをプログラミングすることさえちょっと抵抗感を感じてしまう今日このごろですの。

新しいことを学ぶこと自体が嫌になったわけではないのですけど、IT関係で新しいことを学ぶ意欲は激減していますの。いろんな技術書を見ても、わくわくするどころか、ふーんそれで?ってなってしまいますの。

よくIT辞めた人が農業にいくのわかるきがしますの。食べ物にはわかりやすく価値があるけれど、ITはわかりやすい価値からもっとも遠い。わらわは頭が悪いので、その価値がわからなくなってきましたの。

わくわくが欲しい。さもなければ、お金が欲しいものですの。

FireFoxのソース画面では、<!要素>という書き方は怒られてしまいますの。
タコって。

タコなコメントとは言うものの、コメントとしては機能していないようですの。たぶん無効なタグ扱いですの。

ソースはこの辺のようですの。(FireFoxの開発or翻訳リポジトリっぽい)
https://hg.mozilla.org/l10n-central/ja/file/default/dom/chrome/layout/htmlparser.properties

ここによれば、他にも「タコな文書型宣言が見つかりました」もあるようですの。

↓遭遇した方のブログ

タコな文書型宣言(爆笑)
https://blogs.yahoo.co.jp/katsutoshi_maita/31904592.html

UnityのSceneManagerを使おうとしたら、LoadSceneとかとか、必要なメソッドがどうしても使えなかったのですの。

もちろんusing UnityEngine.SceneManagement;は書いてるのですの、それじゃないんですの。なんなんですのいらいら。

2時間くらい悩んでコーヒー飲んで戻ってきて、ふと英語で検索してみようって思ったのですの。

http://answers.unity3d.com/questions/1224144/scenemanager-does-not-contain-a-definition-for-loa-1.html
そしたらこれを見つけて、思い出したのですの。

SceneManagerって名前の自作クラスが、アセット内にあったことに。。
どうりでいくら調べてもわからないわけですの。


たしかに、Unityのデフォルトのクラス群?の中には、SceneManagerを使っているものもあって。その記述をコピペして来ても動かないから変だなとは思ったのですの。

同名のクラスがアセット内にある場合、いくらusing UnityEngine.SceneManagement;していても、アセット内のクラスの方が読まれてしまうので、もし書くならUnityEngine.SceneManagement.SceneManagerとでもしないといけなかったのですの。

これって、トラブルになったもので検索しても出てこないから、忘れた頃に定期的にはまりそうでおそろしいですの。 。ぶるぶる。

あまりのことに、Unityの再インストールまでしてしまったですの。

変数に値を再代入する方法をしらない人が書いたコードの中では、変数とは定数のことである。

ゆるい言語、きびしい言語、いろいろあるけれど、使う人が常にすべての機能を正しく知っているとは限らないですの。むしろ、大小の違いこそあれ、全ての人は自分なりのサブセットだけを使ってコードを書いている、と言っても過言ではありませんの。(*)

さて、一見して無駄が多く、構造的に弱そうなコードであっても、良かれと思って書きなおしてしまうと問題が起こることがありますの。

それは直接的には、既存部分と書き換えた部分の不整合のせいだったり、書き換え方がそもそもまずかったせいだったりするわけですけど、、根っこには、書いた人と書き直した人の、お互いのサブセットの衝突があると思いますの。

よく勉強して、フルセットに近いサブセットを持っているほうが常に正しいか、というとそうでもなく、不完全な学習によって作られたサブセットが、ある種のドメイン固有言語となっている可能性もありますの。

オール天然素材でつくった、ロハスでおしゃれで、だけど頑丈で安全!と噂の橋をトラックで渡るのなら、その前に、それが歩行者と自転車しか知らない人が作った橋じゃないことを確認してからのほうがロハスですの。

郷に入れば郷に従え、という通り、
既存のコードを分析するときは、言語のフルセットの機能から考えるだけでなく、書いた人のサブセットの姿も考えないと、本当の意味は見えてこないのかもしれないと思ったのですの。


*) アセンブラや、Brainf*ckみたいな小さな言語もあるので実は過言ですの。

それ系で、まさか泣かされるとは思わなかったですの。

Java、C++、Python…プログラミング言語擬人化計画!
http://next.rikunabi.com/tech_souken/entry/ct_s03600p002412
(Web魚拓)

C++お姉さんが多彩とか、C#が成長著しい幼女とか…
と書くと、よくある擬人化みたいだけど、PHPだけ人間じゃないみたいなのをはじめ、言語の雰囲気や歴史、使ってる人のタイプまで鋭く表現されてて凄いですの。

特にRubyは衝撃的で、あの言語の妙な愛でられ方に感じてた違和感が、一気にすーっと消えましたの。もう…パパはRubyに甘いんだから的な優しい世界。こんなにも理解を助けるイラストは偉大だと思ったのですの。


読んでもないのに比較に出すのはひどいけど、
本探しの最中、「擬人化でまなぼ!ネットワークのしくみ」のレビューで、
また、擬人化キャラがMPEGやJPEGとしての特別な特徴があるわけでなく、ネクタイに誰が何を表しているかだけなので、正直擬人化しているメリットがわからない
こういう指摘があったのを見てたので、やっぱり理解を助けるほどの擬人化って簡単じゃ無いんだろうなって思いますの。


で、結局なにに泣かされたのかと言うと、もちろんJavaScriptですの。

言われてみればたしかに、JavaScriptほど戦火に翻弄されてきた言語も無いですの。ほかの言語は競争こそあれ、いちど自分が設置された家は安全地帯でしたの。でも、JavaScriptの実行環境はブラウザ。

そのブラウザっていうのはまさに、代を変え、相手を変えながら、延々と戦争してる紛争地域。そのせいで特に昔のJavaScriptは、基本的な命令すらブラウザ同士で互換性が無いような悲惨な状態だったそうですの。

もちろんプログラマにも恨まれるし、それはちょっと変わった子になるのもしょうがないですの。

なんかこだわりの強いオブジェクト指向だったり、関数型言語みたいだったりするのもしょうがないですの。とか思ったら、泣いていましたの。


実際のところ、そういう仕様は別にブラウザ戦争に巻き込まれたからではなくて、最初からそういう言語だったのですけど、イメージがはまり過ぎてるので、もうそれでいいですの。

それにしても、ブラウザ戦争が凄惨化した8割くらいはマイクロソフトの横暴のせいだと思ってるのですけど、そんなマイクロソフトが「パパがRubyを愛でるように」育てたC#と、JavaScriptの関係に妄想が膨らんでしまいますの。

後発の強みでオブジェクト指向+関数型言語してるC#と、古いのに昔から近い機能を持ってるJavaScript。なんとなく対照的でもありますの。そういえば、Node.jsの登場で今では仲良くサーバサイドで殴りあってるそうですの。

JavaScript「来ちゃった」
C#「ゆだんした!」
JavaScript「ならキミがブラウザへ来る? あそこは地獄だよフゥハハハ」
C#「こわい!たすけてパパ!」
マイクロソフト「まってて!いまTypeScriptつくってるから!」

きっとこんなかんじですの。

SQLについて調べていたら、すごく詳しい記事を書いてる方がいたのですの。
生島勘富さん、という方ですの。

「艦これ」についてのまとめ #艦これ
http://d.hatena.ne.jp/Sikushima/20131230/1388375483

初級シスアドはユーザ向けの試験で、プロはできて当然!
http://el.jibun.atmarkit.co.jp/g1sys/2009/07/csql-bbbb.html

どうも、キワな方が多いことで個人的に有名な@ITのエンジニアライフで、コメント欄を炎上させて執筆陣から除名になった方だそうですの。
あそこのコメント欄、過疎か炎上の二択しかないきがしますの。

さておき、SQLと、それを中心とした開発についての愛と知識は本物だと思うのですの。

いくつか記事を読んだ限り、この方が一番よく主張しているのは、
「SQLは、APサーバ側の言語(Java、C#など)からDBアクセスのために呼び出される添え物、ではない」ということのようですの。

DBMSを使う以上は、なるべくSQLで処理をするのが(ほとんどの場合)良い、と。

なぜかというと、そもそもDBMSを使う以上は、そこにデータを集めていくことになるので、データを扱う処理はすべてDBを通すことになるわけですの。
そういう状態で、処理の主体をAPサーバに置こうとすると、DB・APサーバの間で処理がぐるぐる行ったり来たりする非効率な構造が生まれやすいということですの。たぶん。

また、SQLは、それさえちゃんと書ければ、設計から開発までぜんぶ出来ると言ってもいいくらいの言語なのに、その割に教育がすごく手薄で残念、もっとみんなSQLを勉強するべき、、ということもよく書かれていますの。

わらわもSQL苦手なのですけど、そうやって丁寧に「むしろSQLこそがメイン」と言われると、そうかも、と思ってしまいましたの。


ほかにも、C#とか使ってて、DBとやり取りする部分のコードが綺麗に書けなくて、、っていうのは、けっこうみんな悩みどころだと思うのですけど、この方いわく「ストアドでDB側に置いてしまえば、そういう汚い混合コードを書かなくても済む」といわれていて、これもなんだか納得ですの。

ストアドを多用すると、処理の在り処が散らばってわかりにくくなる…と思っていたのですけど、主体がAP側っていう先入観を捨てれば、かえって全てDB側にまとまって見やすいかもですの。

それに上でも少し書いたように、構造上、AP側はDBを無視して完結することは出来ないけれど、DB側はそれ自体で完結することが出来るはずですの。それなら、処理をどちらかにまとめたい場合、DB側にまとめるのは悪くない筋だと思うのですの。たぶん。

5年以上前の話に今さら感はあるのですけど、
C#の型推論について調べていて、へぇーと思ったのでメモですの。

2010-09-29 C#のvarとtry~catchが糞すぎる
http://d.hatena.ne.jp/yaneurao/20100929 

ものすごく大雑把に言うと、↓のようなコードをvarを使って書くとコンパイル通らない、という問題ですの。
HogeClass hoge = null;
try {
    hoge = new HogeClass();
    hoge.XXX();
} catch {
    if (hoge!=null)
        hoge.YYY();
}
直接的な問題は、ここで、
var hoge = null;
とすると、コンパイルが通らないことですの。
var hoge; 
でも同じく。

そこでC#の型推論が甘い、という話になるのですけど、

ただ、この書き方を許すということは、
コンパイル時に↓のようなコードを弾かなければいけなくなるということで、

var hoge = null;
if(てきとうな式){
 hoge = 1;
}else{
 hoge = "文字";
}

それって、すごく大変じゃない? と思ってこれを書き始めたわけなのですけど、元の記事からリンク貼ってあったページを見ると、

[C#][Nemerle]C#の型推論は怠けすぎ
http://d.hatena.ne.jp/akiramei/20100929/1285759272

関数型、あるいは関数型寄りの言語なんかでは、普通に実現できていることのようで、なんか型推論ってすごいんだなぁって、5年以上前の記事を読んで思ったのですの。

この辺りは、よくも悪くも、「よその言語のおいしいところを、つまみ食い」してるに過ぎないC#の限界なのかもしれないですの(ドヤ顔)


ちなみに、一行でこう書いても↓ダメでしたの。当たり前だけど。
var hoge = (true == false) ? 1 : "文字";

Scala IDE for Eclipseが2.0.0になってたですの。
 ばーじょんあっぷしたら、インデントがズレまくる現象が治りましたの。ひゃふー

 やー。。いちど崩れたインデントを治すのに、手動でスペースキーを連打するのは超大変でしたの。

 ScalaIDE.orgさんありがとうですの!