今、陸別より菅平の方が寒いのか・・・＞＜（4時am JSTに逆転したっぽい・・・＞＜）
菅平に行った事2回あるけど、2回とも時間の都合で通過（2回目は止まってちょっと景色だけ見た）という・・・＞＜
菅平その物の記憶よりも、菅平から長野に抜けるダウンヒルなワイディングロードをダディがミニバンで横転するんじゃないかという勢いの攻めで、スポーティーなセダンにくっついてった思い出・・・＞＜
パーツが交換可能なように互換性をもって作るのはコケないけど、『ユニットの規格を統一して、エンドユーザーがバラバラに買い替え買い増しが出来る』のは、だいたいコケる＞＜
『ユニットの規格を統一して、エンドユーザーがバラバラに買い替え買い増しが出来る』のがなぜコケるかって、だいたい、将来性を考えてがんばっても次世代製品の頃にはその規格が的外れになって、結局、微妙に互換性が無いと言う状態になって、最初に飛びついた人が「oh...」ってなる＞＜；
計算機系の場合には、『外部バスをとても汎用性な物にしてファームウェアを変えられれば何とかなる！』ってがんばると、面白合体マシンになってしまって、・・・・・PCエンジンさん＞＜
そういえば、PCエンジンというかHE-SYSTEM関連の知財って今どこが持ってるんだろう？＞＜
ゲームがエミュで動いてしまうイケナイ中華パッドはいくつもあるけど、ゲームカートリッジが刺さるコネクタがついてるAndroid端末ってないのかな？＞＜
ゲームカートリッジコネクタがあるやつがあっても自炊する時だけ使って、挿したまま使おうって人はほぼゼロだろうけど＞＜；
特殊カートリッジなら意味が・・・って使ってるチップを使った基板を新たに作ってブルートゥース経由で使うとかの方がよさそうだし・・・＞＜（どうせ音関連以外は意味無いだろうし＞＜；（音もエミュ十分だけど＞＜；））
PCエンジン公式エミュを積んで、HuCARDが刺さるようにしたLifeTouchNOTE後継機種があったら、オレンジが涙を流して喜びつつ、PCエンジンもってなかったので別にその機能は使わない＞＜（誰も得しない）
メガドラのカートリッジが刺さるAndroidゲーム機があったら、それはそれで普通にゲーム機として欲しいけど・・・＞＜
単にカートリッジコネクタがあるってだけじゃなく、外部拡張バスも専用コネクタ＆変換ケーブルで用意して、ちゃんとエミュが本格的にエミュレーションして、スーパー32XとかメガCDとかメガアダプタとか全部動くAndroid端末があったら、買う人は世界で100人くらいは居るはず＞＜
冷静に考えると実機を中古で買う方が手っ取り早いし、もって歩きたいとしても本体が小さくできてもつなぐ物が巨大すぎるから、やっぱ実機でおk＞＜；
汎用外部バスがコネクタで出てて周辺機器を合体できるマシンって、ロマンがあるよね・・・＞＜ 実際は繋ぐ人ほとんどいなくて途中で廃止されちゃうんだけど、使わなくても外部バスコネクタには無限の広がりを感じるよね・・・＞＜
USBがそのポジションになって本当に互換性と汎用性がある状態になって、とても便利になった一方、なぜか寂しさを感じる21世紀・・・＞＜
Android開発を受注したからKotlinをガッツリ使ってみたら最高だった by @omochimetaru on @Qiita qiita.com/omochimetaru/i…
Kotlin、微妙にDelphiっぽい面があるなら、どうせならPascalみたいにvarブロック方式（というかPascalは宣言部が独立してる）でも宣言できたらいいと思うんだけどそれは出来ないのかな？＞＜（サンプルコード見るとvar var var var連続しててアレ＞＜）
5日目：変数と型 - Kotlin Advent Calendar 2012 (全部俺) kotlin.hatenablog.jp/entry/2012/12/…
//Kotlin？＞＜ var hoge: Int var fuga: Boolean //Pascal var hoge: integer; fuga: Boolean; begin //実装部 end かも？＞＜
オレンジが言いたい事としては、Kotlinって例えば、 var { hoge: Int; fuga: Boolean; } とか書けないのかな？＞＜と言いたい・・・＞＜（Pascalの方が簡潔に見えるかも＞＜（ワンパスであることは別として））
ん？＞＜； Kotlinってvarが必要なのは型推論するときだけで、そうじゃない時は普通に省略できる？＞＜；（もしそうならばオレンジが書いたようなのは要らないかも・・・＞＜）
オンラインでためせるやつあった！＞＜ -- Simplest version | Try Kotlin try.kotlinlang.org/#/Examples/Hel…
//動いた fun main(args: Array<String>) { var a: Int=42 var str: String; str= a.toString(); println(str) }
//コンパイルできない fun main(args: Array<String>) { a: Int=42; str: String; str= a.toString(); println(str) }
う～ん＞＜； 微妙＞＜； これじゃvar var var var並びまくりでエレガントじゃないじゃん・・・＞＜
Kotlin、基本的に型推論を使うからPascalみたいな（ twitter.com/orange_in_spac… ）オレンジ方式（ twitter.com/orange_in_spac… ）なんて需要ほとんどないって事？＞＜；（オレンジ方式はあくまで例で、var var並ばなければいい＞＜）
//Kotlin、こう書けって事？＞＜； ※strの宣言で代入してないのは例示の為 fun main(args: Array<String>) { var a=42 var str: Any str= a.toString() println(str) }
こういう場面の型推論って、オレンジにとっては邪魔で邪悪にしか見えないから、こういう流行つらい＞＜（型推論のせいで、型がドキュメントになってない＞＜）
しかも、さっきわざとそう例示したコードは、型推論を利用するためにAny型？＞＜で宣言した（バリアント型みたいなの？＞＜ ルートな型？＞＜）けど、まさにこれほんとになんというか本末転倒感が＞＜；（そんな場面なら明示的に型指定するだろうから現実的には起きないんだろうけど＞＜）
Kotlin、var/valの連続だけ気持ち悪いだけで、あとはかなりオレンジ好みの言語っぽく見えるかも・・・＞＜
Kotlin、基本の型にunsignedな数値型がないのか・・・＞＜；（Javaにあわせたから？＞＜； JVMの仕様上どうにもならないとか？＞＜；） う～ん＞＜； う～ん＞＜；
それ（頭で宣言しようとする）はPascal脳だよという真っ当な指摘だし、その通りだしつらい＞＜；
