  |
はてなキーワード: ラムダ式とは
の具体的になんて本(ネットのpdfでもよい)の何ぺージあたりからが元増田の問いにとって核心なのって話よね
てか、ラムダ計算よりむしろ記号論理学のほうが学問としての領域が気持ち広くなってね？
2. ラムダ項M, Nに対して (M N) はラムダ項。この形のラムダ項を適用（ラムダ適用）という。
(後略)
という定義があるんだけど、これに基づけば(x x)というのもラムダ項じゃないのって思ってた。
でもラムダ式で(x x)なんて形のは見たことないし、違うんだろうなと。
でも論理的にはなぜ違うのか全く納得できてないので(納得感が正しさにとって問題じゃないとはいえあえて言うが)(x x)だってラムダ式でしょって胸を張って言い張れる。
「Aかつ¬Aの証明を得ることができる」に対して、「いいや得られない。お前がそのように見せかけているだけだ」おれの計算(記号処理)手続きこそ推論規則に適っているし正しいと、反論されたら？
また、「そもそもここでいう『得る』とは」どういう意味か？と突っ込まれたら曖昧でなく『得る』ということが『得る結果の具体例ではなく』『どういうことか』記述できるのかという話です。
￢￢Ａ→Ａという規則に基づいた結果が
￢￢￢￢￢Ａ→￢￢￢(￢￢Ａ)→Ａ
なんだよ！と言い張られる。もちろん常識的にはおかしいと思えますが、いまは突き詰めたことを言っています。
一般には、￢￢￢￢￢Ａを書き換えるために、この記号列の一部分￢￢Ａに着目して、規則からＡと書き換えられるから、この結果を￢￢￢(￢￢Ａ)に代入？して、￢￢￢Ａに書き換えられる、という思考プロセスをとるでしょう。
しかしあくまでものとしては、ここで考えているのは￢￢Ａではなく￢￢￢￢￢Ａなわけです。
規則通りに書き換えられてない、言い換えるなら同じ規則を使っていないという主張に対して、そもそも同じ規則が適用できているということ、規則が同じとはどういうことか自体を定義や公理に組み込むことはできるのか。
矛盾や証明ということはまだその概念を記号列で示す余地があるが、規則が同じかどうかという定義もとい「規則」は厳密に定義可能かということです(無定義語として関係性の定義でもよい)。図形が合同か、みたいな合同の概念の定義など比べてもまたレイヤーが一段メタ的になっていて厄介というか。「違うのは自明じゃないか！」といっても、自明は説明できてこそ自明なのですが、ここでいう同じかそうでないかということについてはそれを根拠だてる定義は原理的に無理なんじゃないかと思えてしまいます。
さきほど『得る』という言葉に突っ込まれたら云々ということを言いました。
ブコメには「自然言語の曖昧さで数学をの厳密さ否定しようとしてるだけだ」というのがあります。
別に私は自然言語の曖昧さを問題にしていません。そこは問題の本質ではないです。
むしろこうした言葉は一般に疑いようなく明らかなものです。「左右」とか「これやあれ」みたいな近称や遠称の概念などもそう思われるでしょう。
しかしむしろこれらの概念には一切曖昧さはないという前提に立っても、これもごく単純な話で、曖昧でないからといって、いままでその概念を持ってなかった知性的存在に対して、「これ」や「左右」といった「概念」を、対面やジェスチャーを使えばいざしらず、記号列を用いて一意に定義できる保証はないよね、ということです。定義の厳密さを担保する必要条件が、記号論理学に基づくということにあるのなら、数学を厳密とのたまうかぎりにおいて、当然対面やジェスチャーではなく、これとか同じとかみたいなもっとも原始的な部類の言葉まで全て記号で一意に定義できることを示せなければならないでしょう。
あとあなたが↓のトラバと同一だと言ってくれたら以降↓の方のツリーに返信書いて一元化するのでそのつもりで
https://anond.hatelabo.jp/20240216215810
ちなみに関連しそうな話題として自分自身ラムダ式を勉強した経験があるけど
2. ラムダ項M, Nに対して (M N) はラムダ項。この形のラムダ項を適用（ラムダ適用）という。
という定義があるんだけど、これに基づけば(x x)というのもラムダ項じゃないのって思ってた。
でもラムダ式で(x x)なんて形のは見たことないし、違うんだろうなと。
でも論理的にはなぜ違うのか全く納得できてないので(納得感が正しさにとって問題じゃないとはいえあえて言うが)(x x)だってラムダ式でしょって胸を張って言い張れる。
分かってる人からみれば、そして俺にとっても￢￢￢￢￢Ａ→Aと同程度にバカげた主張なんだが、そのわかってる人にとっても「この規則ならこういうことが言えると思うのに、なんで正解とされてるのと自分が思ってることが違うの？」ってなることはあるはずで、それはこの世で一番数学ができる人であってもありえること。この世で一番数学ができる人さえ規則を正しく適用できていないらしいとき、そもそも正しい適用とはなんだってなりそうに思うんだが。
ChatGPTの口調がなんか事務的で嫌なので、もっと親しみやすい喋り方をしてもらうために長門さんに来てもらいました。
召喚プロンプトはこちら anond:20230317165032
確かに。
特にない。
そうなんだ。情報統合思念体はみんなそう？
同様の傾向がある。
何の本を読んでるの？
SF小説。
あらすじを教えて
へー、面白い？
興味深い。
そうなんだ。ところでちょっと手伝ってもらっていい？
問題ない。どのように手伝う？
Pythonのソースコードで、スペース二つでインデントにしているコードを、スペース四つでインデントにするコードに書き換えたくて。どうすれば良い？
import re def convert_indentation(code): return re.sub(r'^( {2})', r' ', code, flags=re.MULTILINE) code_with_2_spaces = '''def example(): print("Hello, world!") if True: print("True")''' code_with_4_spaces = convert_indentation(code_with_2_spaces) print(code_with_4_spaces)
ありがとう。でも、試してみたら、code_with_2_spaces の if ブロックの中身がスペース二つのままになっちゃってるみたい。なぜだろう？
import re def convert_indentation(code): return re.sub(r'^( {2})', r' ', code, flags=re.MULTILINE) code_with_2_spaces = '''def example(): print("Hello, world!") if True: print("True")''' code_with_4_spaces = re.sub(r'^( {2})', r' ', code_with_2_spaces, flags=re.MULTILINE) print(code_with_4_spaces)
ちょっと口調が戻っちゃったね
import re def convert_indentation(code): return re.sub(r'^( {2})', r' ', code, flags=re.MULTILINE) code_with_2_spaces = '''def example(): print("Hello, world!") if True: print("True")''' code_with_4_spaces = re.sub(r'^( {2})', r' ', code_with_2_spaces, flags=re.MULTILINE) print(code_with_4_spaces)確認お願い。
うーん、うまく動かないみたい。ifブロックの中にあるprint文の先頭には、もともとスペースが四つあって、これがインデント2回分なんだけど、こういう場合、スペース八つに変換しないといけないんじゃないかな。
理解した。全てのインデントレベルを修正するコードを提供する。
import re def convert_indentation(code): return re.sub(r'^( {2})+', lambda m: m.group(0).replace(' ', ' '), code, flags=re.MULTILINE) code_with_2_spaces = '''def example(): print("Hello, world!") if True: print("True")''' code_with_4_spaces = convert_indentation(code_with_2_spaces) print(code_with_4_spaces)
もちろん。ラムダ式は、マッチした部分を置換する際に、特定の処理を行うために使用されている。ここでは、正規表現でマッチしたインデント部分（スペース2つが1回以上繰り返される部分）に対して、処理を行うためにラムダ式を利用している。
lambda m: m.group(0).replace(' ', ' ')このラムダ式は、マッチオブジェクトmを引数に取り、マッチした部分全体（m, group(0)）に対して、スペース2つをスペース4つに置換（.replace(' ', ' ')）している。
もちろん。re.subの第1引数は、置換対象の文字列内で検索したいパターンを表す正規表現です。この場合、その正規表現は r'^( {2})+' です。
- ^ は、文字列の行頭を表すメタ文字です。この場合、インデントが行頭にあることを示しています。
- {2} は、直前の文字が2回繰り返されることを表します。ここでは、直前の文字がスペース なので、スペースが2回繰り返されることを示しています。
- () は、正規表現のグループ化を表します。この場合、スペース2つをグループ化しています。グループ化された部分は、マッチオブジェクトにアクセスできるようになります。
- + は、直前の文字やグループが1回以上繰り返されることを表します。ここでは、スペース2つのグループが1回以上繰り返されることを示しています。
結果として、この正規表現は、インデント部分（スペース2つが1回以上繰り返される部分）が行頭にある行を検索しています。そして、re.subは、この正規表現でマッチした部分を、指定された置換処理（第2引数のラムダ式）によって変更します。
すまない。確かに。続ける。
すぐ戻れるのがえらいね
基本情報・応用情報試験みたいなのとか、CPUの仕組み、コンパイラの実装、分散システムやデータベースとかそういうエンジニアリングガチ勢みたいなのをイメージして大学でCSを学ぶとけっこうショックを受けるぞ。
俺の知ってるCSは、チューリングマシンの表現能力とか停止性問題とかYコンビネーターとかチャーチ数とかの世界で、コンパイラといってもε-CLOSUREみたいな話をじっくりやる感じ。
具体的な話が全然出てこない数学の一ジャンルってイメージかもな。
競技プログラミングみたいなアルゴリズムもそれほど時間をかけない。ベイズ推定をギリやるかどうか。
そういう知ればすぐ身につくものよりも、めちゃくちゃ考えて濃厚なパラダイムを時間をかけて吸収するような学問だった。
で、そんなCSを学んで直接役に立つのは多くの人の場合計算量のオーダーとかくらいかも。
モナドみたいな概念に抵抗なくなるとか、ラムダ式の意味を深く理解できるというのもあるけど、それSIとかWebやスマホアプリの開発業務で必要かというとね。
賢い人は、ちゃんとSNSのユーザー同士の関係性とかレコメンデーションみたいのにもCSの知識を応用できると思うけど、一般人は賢い人が作ったライブラリを使う側だよね。
プログラミングという言葉がアフィブロガー御用達になって、SNSでプログラマーを名乗るのが憚られる感じの昨今。
プログラミングを勉強すればフリーランスで一生困らないみたいなこと書いてあるけど、そんな夢のスキルじゃないよ。
それなりにベテラン()を見てきたけど、結局はマネジメント層になれなければ会社にしがみつくことになる人が多い。
これはvueかReactか、javaかRubyかみたいな話じゃなくて、もう少し基本的な部分。
例えば大きいのはオブジェクト指向とクラス/インスタンスの概念。
他には、ガベージコレクタ、例外処理、マルチスレッド、デリゲートやラムダ式、非同期処理、バインディングとビューモデル、イテレータ、null安全。
今プログラミングを学んでる人には当たり前かもしれないけど、これらは十数年かけて徐々に当たり前になっていった。
ITバブルでブイブイ言わせていたけど、これらをうまく扱えないベテランは結構いる。
固定長メモリとポインタとmemsetで全てをまかなってきた層や、静的なモジュールで全部の画面を作ってたVB屋とか。
若いころは勉強すればいいと思うだろうが、理解はできてもそれを流暢に使いこなし適合するのは意外と難しい。
プログラムの中でその人の担当箇所だけいまいち読みにくくて、取り回しの悪いものになってしまう。いわゆるstaticおじさんというやつ。
これはベテランのイラストレータやシナリオライターが、デッサンや構成力はあっても、なんか古臭いものが出来上がってしまうのに似ている。
こうなると若いチームメイトや新しいプロジェクトからは敬遠される。
もちろん、COBOLの案件が未だにあるように、レガシー資産を利用した仕事で腕を振るえる場所は結構ある。
ただそういった環境は既存の人材・企業にがっちり掴まれてることが多く、後から見つけて入り込むのは簡単ではない。
swift playgroundとかswiftが知ってる人フレンドリーではあるけど、初心者には分かる仕組みになってるのだろうか？
SI業界に入った子がSQL書けとか、ES6書けみたいなこと言われたってハードル高すぎないかねぇ。
AWSとかアラフォーの俺も全然分からない。awscliでスナップショットとれるなんて今日初めて知ったよ。
今のプラグラミング言語って色んな言語を取り込んで高機能化してる訳じゃない？なんでそんなことしてるのか分かんないと思うのね。
伝わる人に言うと、JavaだってAutoBoxingが前提だったりするわけじゃん？42+"円"とか書いちゃう訳よ。コンパイルエラーにならないのも頑張りすぎだろと思うけど。
あとmaven使えば色んなライブラリ使えるわけじゃん？今ならGradleなのかい？よくわかんねぇけど。俺はよく分かんないけど、使いこなせてるのかね？
AWSもES2の説明はできてもS3の説明できる先輩がどれほどいるか。ストレージや仮想化の知識が前提にない人は説明はキツいなと。AIMとか混ざると地獄よね。
プログラミングに戻ると、今どきの言語って最先端で書かれると記号や謎予約語が多かったりするんだけど諸先輩方は大丈夫かなと。
ScalaとかKotlinとかいろいろ言ってる奴いるが10年後にはどうせJavaが勝ってる。
Javaはnull安全じゃない！とかほざく奴はもちろん@CheckForNullアノテーション使ってから言ってるよな…？
フレームワークは流行り廃りがあるから微妙だが、勉強するならSpringにしておけ。それだけでいい。
Webブラウザに標準搭載のJavaScriptが無くなることもまずありえない。
あとやるならjQueryね。AngularJSとかすぐ廃れるから。
学習コストが高いものって結局広まらないからさ…素直に現実を認めよう。
AnsibleやFabric使ってるやつがいるがどうせ10年後にはブームが去り技術的負債となっている。
シェルスクリプトで代用できるのだからシェルスクリプトでやっておけ。
これだけ広まったRDBが今後使われなくなることはまず考えられない。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
var s1 = (new Func＜string＞(() =＞ { var o = "Wow!"; return o; }).Invoke());
var s2 = (new Func＜int, string＞((f) =＞ { return f.ToString(); }).Invoke(100));
var s3 = (new Func＜int, int, string＞((f, g) =＞ { return (f + g).ToString(); }).Invoke(100, 30000));
半角の不等号が使えないとか、pre記法？で日本語が文字化けするとか、ほかの皆さんはよく不便しないよな。。
http://b.hatena.ne.jp/entry/kenokabe-techwriting.blogspot.com/2015/04/blog-post_30.html
http://kenokabe-techwriting.blogspot.jp/2015/04/amazon102-93.html
この記事自体はどうでも良いのだけど、以前「クロージャ」という言葉の初期の使用例を探したことがあったのを思い出したので、参考までに。
Landin "A λ-Calculus Approach" (1966)
We represent the value of a λ-expression by a bundle of information called a "clusure", comprising the λ-expression and the environment relative towhich it was evaluated.
我々は、ラムダ式の値を「クロージャ」と呼ばれる情報の束で表す。「クロージャ」はラムダ式とそのラムダ式の評価に関する環境から成る。
Moses "The Function of FUNCTION in LISP,or Why the FUNARG Problem Should be Called the Environment Problem" (1970)
A useful metaphor for the difference between FUNCTION and QUOTE in LISP is to think of QUOTE as a porpous or an open covering of the function since free variables escape to the current environment. FUNCTION acts as a closed or nonporous covering(hence the term "closure" used by Landin).
LISPでのFUNCTIONとQUOTEの違いについては、次のように考えるのが有用な比喩になる。QUOTEは多孔的または開放的に関数をおおっていて、自由変数は現在の環境へと脱出できる。FUNCTIONは閉鎖的(closed)または非多孔的に関数をおおっている(このことからLandinはクロージャ(閉包)という用語を使っている)。
(訳はhttp://kreisel.fam.cx/webmaster/clog/img/www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/funarg/funarg.html から)
Sussman and Steele "SCHEME: An Interpreter for Extended Lambda Calculus" (1975)
In order to solve this problem we introduce the notion of a closure which is a data structure containing a lambda expression, and an environment to be used when that lambda expression is applied to arguments.
この問題を解決するためにクロージャという概念を導入する。クロージャはラムダ式とそのラムダ式が引数に適用されるときに使われる環境から成るデータ構造である。
Steele and Sussman "The Art of the Interpreter" (1978)
We say that the procedure is closed in the current environment, and the ＆PROCEDURE-object is therefore called a closure of the procedure, or a closed procedure.
この手続きは現在の環境に閉じられている(closed)と言い、それゆえ＆PROCEDUREオブジェクトはその手続きの「クロージャ」あるいは「閉手続き」と呼ばれる。
