  |
はてなキーワード: retinaとは
ローソン受け取りのバーコードをfireタブレットのfire7で軽い気持ちで提示したら読み取れなかった。安い端末なのであきらめもつくが何が原因か？もともとバーコードリーダーというのは液晶は読み取ることはできず、あたりまえにできたわけではないらしい、しかもできるとしてもretinaやIGZOみたいな高級ディスプレイを想定していて解像度が低い安い液晶ではできないのかも。よくある読み取れないときの対策に明るさを最大にというのがあるがfire7は明るくしても反射が強いので明るさまだ足りてない気がする。つまりもっと明るくするか反射をもっとおさえられたらどうか。ノングレアの反射防止の保護フィルムというのがあるのだが保護フィルム貼るとバーコードを読みとれなくなるかもしれないという注意はよく見かけるが、認識率が上がったという話はない。安い液晶では無理なのか、明るさや角度の検証など店の端末で小一時間位テストしたいんだが
気持ち悪い信者共が常軌を逸した持ち上げ方をするので冷静に比較
Surface Laptop3 15inch
\308,880
Macbook Pro 15inch
\302,800
優位を太字で表記する
| 名前 | Surface | Macbook Pro |
|---|---|---|
| 価格 | \308,880 | \302,800 |
| ディスプレイ | 2496x1664 | 2880x1800 Retina Display With TrueTone Technology |
| プロセッサ | Core i7 4-Core | Core i9 8-Core |
| メモリ | 16GB | 16GB |
| ストレージ | 512GB | PCIe ベース 512GB |
| dGPU | 無し | Radeon Pro 560X |
| Thunderbolt | 無し | 4 |
| セキュリティ | 無し | Apple T2 Processor |
| 指紋認証 | 無し | Touch ID |
| Touch Bar | 無し | 搭載 |
| カメラ | 720p | 720p FaceTime HD |
| バッテリ | 最大 11.5 時間(真偽不明) | 最大 10 時間 |
| オペレーティングシステム | windows10 | macOS |
| オフィススイート | 別売り | 付属 |
| 開発環境 | Windows ベース | Unix ベース + Xcode |
センセーショナルなスペックで華々しいデビューを遂げた iPhone 11
主に映像を中心としたコストパフォーマンスの凄まじさをここに書いておく.
13mm F2.4
24mm F1.8
52mm F2.0
iPhone 11 は 4K/60fps の動画が撮影可能, 4K 対応のレンズとなると写真用レンズでは解像力不足.
要件を満たせる近しいレンズは CarlZeiss の Compact Prime CP.3 になると思われる
https://www.system5.jp/products/detail93889.html
ただし, 広角側は Zeiss より 2mm も広角なので 13mm のシネプライムレンズとなるとそれだけで数百万オーダーである.
これで iPhone 11 のレンズの凄さが伝わっただろうか.
スチル用では Zeiss の Otus シリーズがギリギリ要件を満たせそうだが, 広角は 28mm しかラインナップされていないので除外した.
4K/60fps
1080p/120fps
上記のレンズに交換可能で上記要件の動画を撮影できるカメラを探してみた.
13mm (上記レンズでは 15mm) の画角で撮影するには "フルフレーム" もしくは "ラージフォーマット" のカメラが必要になる.
クロップされて画角が狭くなる Super35 や マイクロフォーサーズは論外という事をあらかじめ言っておく.
https://www.pronews.jp/news/20190913165025.html
CANON C500 Mark II (未発売, 170 万円前後)
https://www.pronews.jp/news/20190906130311.html
他にも探してみたが, 要件を満たせるカメラは上記 2 機種しか見当たらなかった.
4K/60p がどれだけ敷居の高い物だったのかをおわかり頂けると思う.
Super Retina XDR
https://www.apple.com/jp/iphone-11-pro/
6 月の WWDC で MacPro と同時に発表された前代未聞の高性能ディスプレイと同じ "XDR" を冠するモニタを搭載している点も見逃せない.
"XDR" モニタは 400 万円のプライスタグが付く SONY のマスタモニタ級であることは皆さんもご存じだろう.
https://japan.cnet.com/article/35138580/
これだけのモニタを搭載したスマートフォンが今まであっただろうか ?
答えは "No" だ.
https://japanese.engadget.com/2019/09/11/iphone-a13-bionic/
見ての通り Galaxy の 2 倍, Pixel に至っては 3 倍のプロセッサ性能性能を叩き出している.
これらに相当するプロセッサは何だろうか.
それは Mac 上位機種にのみ許された Core i9 や Xeon プロセッサだ.
これら Intel フラグシッププロセッサを搭載したコンピュータが 15 万円で買える話しなど聞いたことがない.
さらに A13 プロセッサ内蔵の GPU は Metal のアクセラレーションが可能だ.
もはやスマートフォンというよりはクリエイティブワークステーションである.
iPhone 11 のカメラ機能だけを見ても数 100 万円相当の価値がある事がわかっただろうか.
高い高いと言うがよく考えて欲しい.
170 万円相当のカメラに 200 万円相当のレンズ, 400 万円相当のモニタ, それを Apple のエコシステムに裏打ちされた唯一無二で孤高のユーザエクスペリエンスが包括するオールインワンクリエイティブワークステーションである.
これでも 15 万円のプライスタグを "高い" と揶揄できるだろうか ?
揶揄出来るとしたら貴方の頭はどうかしているか Apple より優れた企業のある別時間軸の住人なのだろう.
つまり iPhone 11 は "写真が撮れるスマホ" を突き放し, シネマティックスマートフォンという新たな次元へ進化した新世代のマシンである.
タピオカなどと揶揄する人達は, iPhone 11 で撮影された映画やフォトグラフィを見て自分の浅はかさを恥じる事になるだろう.
そして何も買わずに帰ってきた。
paypayの20%還元のニュース自体は一週間ほど前に聞いていたが忘れていた。
昨日になって「あ、明日からだ、これ結構早く終わっちゃいそうだよなぁ」と思い
キャッシュバックの上限は5万円、つまり購入金額としては25万円分ある。
Twitterなどをぼーっと見ているとビックカメラでApple製品を購入するのがとてもお得らしいことはわかったが
数年前に購入した親用のRetina iPadはまだ十分すぎるほど使えるし、
1年半前に購入したMacbook proはCTOでかなりいいスペックにしただけあって何ら不満はなく買い換える必要もない。
そこで、ようやく思いついたのがデスクトップのWindowsPCを新調してはどうか、というものだった。
当時最新だったi7-860 2.66GHz、メモリ8GB、SSD 80GB、HD5850で組んで、SSDのあまりの速さに感動した覚えがある。
途中、メモリは16GB、SSDは250GB、GPUはGTX570に換装したが、このPC自体はもう9年も使っていることになる。
このPCに買い換える前は、確か2～3年おきにPCを買い替えていた気がする。
Pentium 100MHz、メモリ64MB、HDD 850MBで14型インチのモニタと一体型のPCで、TVチューナーもついていた。
TVチューナーではTVを録画することも出来たが、avi形式の無圧縮で録画されるため
1分そこらでHDDの空き容量が無くなりかけて焦った思い出がある。
次のPCはK6 300MHzで、次がAthlon TB 1.4GHzで、その次がCore2Duo E6600 2.4GHzだった。（うろ覚えなので数値は間違ってるかも）
これらのPCに買い替えた理由は、単純に遅さに耐えられくなったからだ。
ゲームが重すぎる、ブラウザがすごいもっさりしている、VisualStudioの起動や動作が遅すぎてイライラする等々、
どれも切実に、今よりも速いPCが欲しい！！、という思いがあって買い換えていたのだと思う。
そう、今回CPUに関しては9年も買い換えずに来てしまった理由はまさにそれで、現状あまり困ってないのである。
SkyrimやWitcher3は普通に遊べたし、VisualStudioは普通に快適だし（VisualStudio自体がバージョンあがるごとに速くなってるのもある）、
Chromeもメモリは潤沢に使うものの相変わらず速いままだ。
とはいえ、不便なこともないわけではない。
USB3.0に対応していないのでスマホやUSBメモリにデータを転送する（この機会自体以前に比べてめっきり減ったが）のは若干時間がかかるし、
Windows10にアップデートしてからスリープ出来なくなってしまったので毎回PCを起動/シャットダウンしなければいけなくなった。
そういうわけで、デスクトップのWindowsPCを9年ぶりに買い換えることにした。
昼休みのうちに最近の自作事情を調べて、よし今回はRyzen5 2600にして久しぶりにAMDで組むぞ！とワクワクしていた。
そして退社後に意気揚々とソフマップに向かい、その他のパーツもあらかた決めたんだけど、結局買わずに帰ってきた。
買えなかったのだ。
どうしてもこのPCは必要なんだ！という強い気持ちを維持できなかった。
そういう強い気持ちを持てないと、私はモノが買えなくなっているのだ。
それも何故か収入が増えるに従ってその傾向は強くなっているように思える。
どうしても、
本当にこれは必要なのか、
別に現状そこまで困ってないのに何故買うのか、
もし買ったとして今持っているものとそこまで違いがあるのか、
と考えてしまう。
iPadは親のため、Macbookは移動中等のスキマ時間を有効活用してスキルアップを図る、
という大義名分があって初めて購入できた。
#
泥酔しながら書いた。
20XX年、スティーブジョブスシアターから中継される光景に、日本人は狂喜乱舞した。
ジョナサン・アイブが更迭されて間も無い中の発表会を、一部の信者は心配そうに見守り、残る大多数の一般人は期待を持って目の当たりにしていたのだ。
そこで発表された新製品は、大多数の一般人が求めていたまさにそれであった。
2018年のRetina 13インチは、皆が求めていたものだったが、今年のMacBook Airはさらに一味違った。
「OK、分かった。MacBook Airはスペックは平凡、その割には値段が高く、MacOSとデザイン以外、魅力のないラップトップだった。」
「それも今日で終わりだ。MacBook Airは、世界の第一線で戦える最強のラップトップに仕上げた。それは値段にも反映している」
「899ドル。世界で尤も安く買えるハイスペックUnixシステムの一つだ」（1アップルドルは105円とする）
特盛にしても2500ドルのMacBook Airは飛ぶように売れた。
なお、無印MacBookはCPUをArm 64bitとして、物好きどころか割とヘビーユーザーにもそこそこ売れた。こちらは599ドルから。
USB Type-Cも2つ付いたのは嬉しい悲鳴。重い処理はできないが、Armに最適化されたバイナリのAdobeもまあまあ動くし、Logicも動く。ピンク色の筐体が、オルチャンメイクで丸眼鏡な女子大生にウケた。
「Mac Mini買えばいいじゃん」
違う、そうじゃない、デカくて早くて（排熱が）燃えるように熱いMac Proが欲しいんだよ。GPUとかいっぱい積んじゃってさ、CPUもサーバのいいやつがよう。
「OK、小僧。用意してやったさ。これで好きなだけFacebookとTwitterをやるがいい。」
「おいちょっと待てよ、Thunderboltディスプレイ、Thunderboltディスプレイじゃないか。お前ちょっと痩せたか。ベゼルがないじゃないか」
Mac Proのお披露目の影に隠れるように、こっそりと。そうThunderboltディスプレイが帰ってきたのだ。
幾年ぶりかの再開に、マカーたちはサムスンとLGロゴの入ったディスプレイを窓から放り投げた。
CPUが新しくなった。価格は1099ドルから。なんか新しいRadeonが乗ってる。
CPUが新しくなった。価格は1299ドルから。こっちもなんか新しいRadeonが乗ってる。
訓練された貧乏信者たちは、涙を流しながら、メインボードを傷付けないようにそーっとメモリを増設した。もちろん保証は効かない。
iPhone XSとXRの登場はAppleの企業価値を大きく傾けさせた。あまりにも売れなかったのだ。
しかしそれも今日までだ。そうiPhone SE2、皆が待っていた小さいあいつがパワーアップして帰ってきたのだ！
既に世界の半分以上はLenovoを使ってるし、残りのシェアの大半をDELLが占拠していた。安価かつハイスペックなWindowsは、僅かなMacBookのシェアをさらに削っていった。
そして、中国のAndoroidのシェアが100%になった瞬間、iPhoneは既に過去のモノとなってしまったのだ。
どうしてアニメの浮世絵とかがだいたいクズかの理由を述べていく。
いくつかパターンはあるけれど、一番多いパターンは、単純に見れたものじゃないというレベルのものだ。
そんなものが売れるのは
っていう前書きがあるからだ。
手で作ったからといって、伝統技術で作ったからといって、機械が印刷したほうが綺麗なら、そんなものに価値はない。
おそらく、ここ数十年まではカラー印刷技術の中で最強の座を誇ってたと思う。
2枚の版木、赤、青で摺るとする。
1枚目で摺る。
1枚目の赤の版木が当たる部分、当たった部分は赤になり、当たらない部分は紙の地の白のまま、つまり2色の世界。
2枚目の青の版木が当たる部分、一枚目の版木も二枚目の版木も当たった部分は赤と青が重なり紫に、二枚目の版木だけ当たった部分は青に、一枚目の版木だけ当たった部分は赤になり、当たらない部分は紙の地の白のまま、4色の世界。
3枚の版を使えば、8色、4枚の版を使えば16色、理屈の上では指数関数的に色数が増える。
雑誌なんかで、表紙のすぐ下や、誌面の中頃に、一枚だけカラーページでグラビアやイラストのカラーページがあったりするのはわかるだろうか？
昭和の初期までは、あれを木版でやっていた。
しかも、浮世絵の時代と遜色ないどころか、それ以上に15度20度と摺って色を重ねて印刷していた。板を彫って。ばれんで摺って。
中でも、最もキチガイじみた雑誌はというと、毎号50度摺以上の手間暇をかけて、日本画の複製を誌面に挟んでいたある美術雑誌だ。
号によっては100度近い摺りを重ねたらしい。
色数の問題だけではない。
ほとんどの印刷技術は、オフセット印刷もシルクスクリーンもレーザープリントもインクジェットプリントも、色の濃淡を色の粒の"密度"で表現している。
木版で使うグラデーションをつける技法は、粒ではなく無段階のグラデーションをつけることが可能である。
人間が視認できる限界を超えたRetina Displayがでるまでは、真のグラデーションは木版の中にしかなかった。
そして発色である。
浮世絵の技術で摺られた絵は、直後に触っても、手に絵の具は移らない。表面には絵の具は残ってない。
紙の繊維の奥から、輝くのだ。
いつものように、能書きが長くなったが、
っていうことを強く打ち出した売り方だと、極端な話、出来のいい悪いに関係なく売れる。
普通の印刷よりも汚くても、「それが木版の味です」として売れる。
たぶん、下絵もどんな絵なら工数をケチっても綺麗に仕上がるかなんてことも考えていないし、職方に高いレベルは要求しないし、職方もそれを見抜いてそれなりの手間しかかけない。
企画元「安く版権が手に入ったから、斜陽産業の職人を安く買いたたいて作らせて、オタクに高く売ろう」
職人「どうせわかりゃしないから、材料と手間をケチろう。どうせ工賃も半額に値切ってくるんだろう」
っていう思惑が誰でもわかる。
みれたもんじゃない0点の浮世絵、これがアニメの浮世絵の約8割。
実は、丁寧過ぎるのも嫌いなので、それについてもややこしいんだが、それについてはまた後日。
ぼく「やった！念願のMacbook Pro Early 2011だ！すごい速い！デザインカッコいい！Appleサイコー！」
MBP「せやろ」
ぼく「２年ぐらい使ったらなんか画面が突然フリーズするようになったんだけど。。きっとパッチが来るから大丈夫！Appleは優秀だから！」
ぼく「そうなんだ！Apple Careが切れてたから4万出して換えたよ！でもまだ直らないんだけど。。」
MBP「そうなんか？なんかRadeonのGPUがおかしいとか言ってる奴がおるようやけど、わしゃ知らんで。リコールもせんぞ」
ぼく「３年使ったからね！そろそろ寿命かな、今までありがとう！新しいRetina 15inch Late 2013買うよ！」
MBP「よっしゃ27万もろたで」
ぼく「すごいSSD速い！筐体も薄いし、Retina見やすい！Appleサイコー！」
MBP「せやろ」
ぼく「なんか突然キーボードとトラックパッドが反応しなくなって再起動しないといけない時があるんだけど。。」
ぼく「上げたよ！でもHDMIのセカンドモニタ繋ぐとまた画面がフリーズするんだけど。。」
MBP「ロジックボード換えたら直るんやないかな（鼻ホジー）」
ぼく「よろしい、ならば戦争だ」
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
1.処理能力が高い!
「Qualcomm Snapdragon 800, 2.26GHz」と「Adreno 330, 450MHz」を積んでいます。
どう見てもオーバースペックです。本当にありがとうございました。
2. 画面が綺麗で大きい!
解像度は445ppi
それに大きくて見やすい!
4.95インチの画面は、片手でホールド・操作できる限界のサイズかと思われ。
3. 安い!
コスパ最強。
Nexus5 ならGoogle Playで4万、オクだと3.5万、芋場NMPなら0円で手に入ります。
メモリすっきり! 動作快適!
広めのソフトウェアキーボード、秀逸なIME(Google日本語入力)。
押下するとヴァイブレーションで「押したよ」と教えてくれます。
6. 拡張が高い!
林檎の「ほら、こうすればいいんだよ。これがアフォーダンスさ」といった鼻持ちならない感じがありません。
7. 可哀想!
モトローラ売却か〜ら～の Google Play Edition 一本化で、Nexus シリーズが消えるとの噂があります。
