  |
はてなキーワード: 構文解析とは
いやぁ〜、テキストエディタの世界、めっちゃディープでんねん！聞いてくださいよ〜。
まず、テキストエディタの心臓部、バッファ管理システムについてや。これ、単なるテキスト保持やないんですわ。例えば、Emacsのガベージコレクション機構。マーク＆スイープ方式採用してて、バッファ内のLispオブジェクトを効率的に管理してんねん。これがあるから、長時間の編集作業でもメモリリークせーへんのや。
次に、レンダリングエンジン。これが曲者でんねん。Unicode標準のUAX #9に準拠した双方向アルゴリズム実装せなアカン。さらに、合字処理のためにOpenTypeのGSUB/GPOSテーブル解析も必要や。Harfbuzzライブラリ使うんやけど、カスタムシェーピングエンジン組み込んで、特殊な文字体系にも対応せなアカンのや。
構文解析エンジンも侮れまへんで。LR(1)パーサーじゃ複雑な言語構文に対応でけへんから、GLR（Generalized LR）パーサー実装するんや。これで曖昧な文法も扱えるようになるんですわ。Treesitterライブラリ使うと、インクリメンタルな構文解析ができて、巨大ファイルでもリアルタイムにハイライティングできるんや。
差分アルゴリズムも奥が深いんですわ。Myers差分アルゴリズムだけやなくて、Histogram差分アルゴリズムも実装せなアカン。大規模リファクタリングの差分表示に効くねん。さらに、セマンティック差分アルゴリズムも組み込んで、構造的な変更も検出できるようにするんや。
非同期処理システムもめっちゃ重要や。単なるPromiseやasync/awaitやのうて、Reactive Extensionsベースのストリーム処理実装するんや。これで、複雑なイベントシーケンスも扱えるようになるんですわ。さらに、アクターモデルベースの並行処理システム組み込んで、マルチコア活用した並列処理も可能にするんや。
最新トレンドもめっちゃアツいんですわ。例えば、Language Server Protocolの拡張や。単なる静的解析やのうて、シンボリックAI使うた意味解析まで可能にしてるんや。これで、コードの意図を理解して、より高度なリファクタリング提案ができるようになるんですわ。
WebAssembly統合も進化してるんや。Single Instruction, Multiple Data (SIMD)命令セットサポートで、テキスト処理のパフォーマンスが爆上がりしてんねん。さらに、WebAssembly System Interface (WASI)採用で、ファイルシステムアクセスも可能になってるんや。
AI支援機能も侮れまへんで。単なる補完やのうて、プログラム合成（Program Synthesis）技術導入してるんや。部分的な仕様から完全なコードを生成できるようになってんねん。さらに、説明生成AI組み込んで、生成されたコードの詳細な解説までしてくれるんですわ。
リアルタイムコラボレーションも進化してるんや。Conflict-free Replicated Data Type (CRDT)のカスタム実装で、ネットワーク遅延があっても一貫性保てるようになってんねん。さらに、意図ベースの競合解決アルゴリズム導入して、複雑な編集操作の衝突も自動解決できるようになってるんや。
拡張性アーキテクチャもすごいんですわ。WebAssemblyベースのプラグインシステム採用して、言語に依存せんプラグイン開発可能になってんねん。さらに、サンドボックス化されたランタイム環境提供して、セキュアなプラグイン実行も実現してるんや。
性能評価も厳しくなってるんですわ。起動時間は、コールドスタートだけやのうて、ホットスタートも測定せなアカン。メモリ使用量も、物理メモリだけやなくて、仮想メモリの使用状況も追跡するんや。CPU使用率は、マイクロアーキテクチャレベルの最適化まで求められるようになってんねん。レンダリング性能は、GPUアクセラレーションの効率も評価せなアカンのや。応答性は、入力レイテンシだけやのうて、知覚的な応答性（Perceived Responsiveness）も測定するんですわ。
いや〜、テキストエディタの世界、マジでディープすぎて、もう頭おかしなるで〜！こんな感じで、テキストエディタの最深部まで潜ってみましたけど、いかがでしたか？テキストエディタ、侮れまへんで〜。ホンマに。
javascriptの結合性について
a=b=1;のような場合、この文に使われている演算子はどちらも同じ=という種類であり、優先順位に差が無いので、左側から解析し、もう一つ同じ演算子があるので演算子の実行を保留し、右側の=を見つけて、右から代入するというのはわかります。
では()すなわちグループ化のような場合はどうなのでしょうか？さいわいこれには結合性はないようですが、あったとしたらどう考えればいいのでしょうか？
=のように右と左をオペランドに挟まれた形ではないので、左側とか右側とかいってもよくわかりませんし、(...)+2の)+のように演算子同士が隣接する場合も考えるとますますどういうアルゴリズムなのかよくわかりません。
それともだからこそ、()には結合性を設けないとしたのでしょうか？
dot dot dotさん
2024/2/25 15:38
a = b = 1
は
a = (b = 1)
調べましょうでもいいんですが、知ってるならそのあなたが同じ疑問にあたったときに調べて解決につながった情報だけを一通り書いてくれるのが一番ありがたいのですが。
論旨
無断で数千人の声優を学習したというのは、恐らくMoeGoeのことを指していると思われますが、アクセントも不安定で「演技泥棒」には程遠いです。
最新のモデルをもってしてもアニメの演技のような抑揚の大きい音声を学習させることは難しいことであって、実用レベルに押し上げるようなブレイクスルーもまだ起きていないのが現状です。
音声合成の学習には、データセットとして音声とそれに対応する文章を合わせた音声コーパスと呼ばれるものを用います。
演技というものは台本でいうところのト書きであって、文章に直接的に含まれている情報ではないことからも、文章から生成する音声に演技を付与させることの難しさが理解できると思います。
文章と音声があれば、即座にデータセットとして使えるかと言えばそうではありません。
文章で想定している（文章を構文解析することによって得られる）読み方と、音声における実際の発音が異なる場合があります。
音声合成は結局のところ文章の音素と音声を対応付けているだけなので、音声コーパスの文章と実際の音声に乖離がある場合には学習の精度が下がる恐れがあります。
加えて、現在の音声合成ではアクセントなどの情報を用いることが多いですが、アクセント辞書から得られた情報と実際のアクセントが異なる場合も演技音声では散見されるでしょう。
上に述べた抑揚の問題や、音声にBGMなどのノイズが混ざっている場合など、音声自体がデータに適さない場合もあるため、それらの選別も必要です。
音声合成用に収録された音声コーパスであれば、読み方やアクセント、ノイズ等に細心の注意を払って録音されていますが、一般の音声は必ずしもそうではないのです。
このような読み方やアクセント等の修正は、残念ながら人力に頼らざるを得ません。そもそも台本がない場合は一から書き起こす必要があります。
AIイラストの成功には、イラストへの人力でのタグ付けが寄与していることはよく知られていますが、果たしてAI音声という分野において人力による音声コーパスの整備が進むでしょうか？
AI音声合成ソフトの代表例とも言えるVOICEVOXはいまや多くの人気を集めており、多くのキャラクターが参加しています。
また、COEIROINKのように音声コーパスを用意することで自らの声を学習させた機械学習モデルを共有できるような音声合成ソフトも登場しています。
AIイラスト界隈における絵師との軋轢が援用されていますが、音声合成の分野においては多くの場合、データの提供者たる声優と相互理解のある関係を保ちつつ発展してきたことを強調しておきます。
もともとナレーションの分野においては、既に十分な品質の音声合成ソフトが存在します。
AIイラストと異なり、倫理的問題のある音声合成に手を出す動機付けが乏しいことが現時点において関心が集まらない要因となっています。
そもそもASMRには、バイノーラルという特色があるわけで、AIが生成したモノラル音声がAIイラストほどの脚光を浴びるとは考えづらいです。
いわゆる”後で読む”系のサービスでPocketを愛用してたんだけど、
Instapaperに本格的に切り替えることにした。
①いちいちウェブ画面に切り替えがいらない
PocketではデイリーポータルZとか某2chまとめブログとかはいちいち、
ウェブ画面にして読まないといけなくて、圏外中結構ストレスになってたけど、
Instapaperだと構文解析があってるらしく全ページ記事ビューで読めるのがいい。
これで圏外中でも読めないストレスがかなり減った。
IFTTTを使って、pocketでFAVしたの→Tumblrでポストして記録をしてたんだけど、
タイトルとリンクとれてなくて、せっかくのがともやもやしてたんだけど、
Instapaperを使ってみたら、アプリ上でお気に入り→Tumblr でできようになって、
記事内容がそのまま飛ぶようになっている。
ーーー
いまのところpocket でできて Instapaperが不便な所は見当たらないので、そのまま本格移行するつもり。
弊学では、2年生の時に必修のプログラミングの授業でC言語を習う。
中学生の頃からパソコン大先生でスクリプト言語を軽く触ってた自分としては、わざわざ面倒な書き方で面倒なコンパイルをして動かす事に疑問を感じていた。
ちなみに、試験は紙ベースで、手書きでプログラミングをさせられる。つらい。
スクリプト言語で良いと思ってた自分は、C言語を覚えることに疑問を感じていた。
結局、授業以外で全く勉強せずに試験結果は散々だったが、なんとか単位が取れたので良しとしよう。
プログラミング初学者である人は苦労して書き方を覚えていたように思う。
脱落していった人を何人も見たが、人間やれば出来ないと思っていたことが出来るのである。
今学期、PHPを書く授業とPythonを書く授業を履修してみた。
PHPは、某テキストをもくもくと写経して動かしてみる授業で、独学でテキストのコードを動かす気力のない自分にとっては最高の授業だ。
Pythonは、MeCabなどで形態素解析や構文解析をする授業で、サンプルコードを自分で考えてカスタマイズして毎回レポートで提出する。
Pythonの書き方に慣れないからか、かなりハードであるが、やりがいがあっていい感じだ。
書いたらすぐに目に見える成果が出るところが大きい。
自分は、プログラミングを授業で教えるのならスクリプト言語に限るはずだと思う。
そう思っていた矢先に事件が起こった。
最近、研究室に入ったところ先生が手当たり次第Javaを教え始めたのである。
せめてJavaScriptでいいからスクリプト言語を教えてほしいところなのに、なんでJavaなんだと発狂した。
それでも、30億のデバイスで動くハイブリッドさとオブジェクト指向を理解する上での分かりやすさという面ではJavaが手軽なのかもしれない。
ところで、最近になってプログラミング教育義務化とか叫ばれてるが、Scratchでパーツを並べてプログラミングをするなんてただの積み木に過ぎないと思う。
絶対にツマラナイだろう。
自分は、プログラミングの授業で数字を足し算して黒い画面に表示させるとかツマラナイと感じてしまった。
こんな複雑なことをしても、これしか成果が出ないならやってられないと思うのは自分だけなのだろうか。
お願いだから、プログラミングを教えるのならツマラナイ授業をしないで欲しい。
生徒に分かるように、生徒は楽しんでプログラミングをするべきだ。
別にどんな言語でもいいと思うが、プログラミング言語は人それぞれ好き嫌いが激しいだろう。
自分は、分かりやすくて直感的なRubyというプログラミング言語が学校の授業で採用されるべき言語に間違いないと思う。
別にRubyにこだわる必要はなくて、スクリプト言語であればなんでも良いと思う。
CやJavaなどのコンパイル言語は複雑で分かりにくいし、教えにくいはずだ。
スクリプト言語を教えた後に、コンパイル言語、オブジェクト指向の概念を教えていくのがいいのではないだろうか。
みんなの意見を知りたい。
現在大学の中でOrarioのアクセスがどうこうという問題が起きているようだが、
ひとまずこの記事については、下記URLにある、京都大学の専門家であらせられる記事について、一人歩きしてる感があるので、
もう少し彼のような上流側（という表現で良いかどうかは不明だが）の専門家ではなく、
下流でプログラムをガッツリ書いているほうの専門家として私(匿名で失礼)が纏めたいと思う。
https://srad.jp/~yasuoka/journal/611343/
Orarioの芳本大樹が書いた『時間割アプリの「Orario」の特性と安全性について』(2017年4月17日)という文書を読んだ。このOrarioは、京都大学のKULASISにずっと不正アクセスを繰り返していて、正直なところ私(安岡孝一)としてはアタマに来ていたのだ。
Orarioの特性と安全性について、本当にスクレイピング技術をクライアント端末側で行っているのであれば、
この部分は間違いではないと私(匿名で失礼)は考えている。
この部分の書き方、実に大学教授らしい逃げ道を多く用意していて。
KULASISにずっと不正アクセスを繰り返していて
上記発言、これは本来「開発時の検証段階」の話をしているのであれば「正解」、である。
逆に今のOrarioの通信についてを不正アクセスとしているのであれば「正解ではない」、である。
何せ、開発者が勝手にアカウントを使って入り込んで様々な検証を行う必要があるため、
KULASISサーバに対してクラッキング/ハッキングを行って根こそぎどうこうしたなどという大がかりな不正アクセスではなく、
あくまで大学側が定める規約規則から若干外れた使われ方がされているという意味の不正アクセスである。
（そもそもスクレイピングなんて技術を使う連中はID/PASSWORDがない状態でのサーバへの不正アクセスなどできない
開発時は「京大のKULASISアカウントをもったユーザが開発に携わっていないのであれば」押し出してきている京大の規約によれば、不正アクセスにあたるのかもしれない。
個人的には当たらないと感じるが。
京大の規定に定められたユーザが「特定のブラウジングツール（Orario）」により、
KULASISにアクセスしているのだからアクセスとしては不正ではない。
本当にスマートなWebスクレイピングで行われているのであれば、Webブラウザと全く同じ動きをするはずで、
それを不正アクセスと断罪してOrarioは不正というのは表現が汚いと考える。
これはコメント欄にもあるが、
https://srad.jp/comment/3196554
また、ChromeやSafari（及びその他マイナーなWebブラウザ）なども御校のWebサーバーよりコンテンツデータを取得し、HTMLを構文解析し画面表示を行っていますが、これらはセキュリティポリシーには適合しているのでしょうか？
ご大層にはっておられるリンクを流し読みをする限り、そんな厳格に何かを定めているわけではないように思われる。
それ故、実際にOrarioがスマートフォンによるスクレイピングを行っているのであれば、
Webブラウザの一種とも言えなくはない為、これを不正と断ずるのは、「正しくない」だろう
京大のユーザが開発に携わったかを証明できない以上、彼にとっては不正なのかもしれないが、
ここでそれをOrarioは不正アクセスと断ずる論理性が私(匿名で失礼)にはわからない。
他にもこの部分
Orarioアプリでは「Webオートメーション(Webスクレイピング)」と呼ばれる技術を用いています。この技術により、利用者様のスマートフォン（にインストールされているOrarioアプリ）に学生アカウント（大学ID・パスワード）を入力すると、自動で当該利用者様の教務用ページから時間割の生成に必要な情報のみを取得し、Orarioアプリの時間割テーブルに当該利用者様の時間割を生成・表示することができるという仕組みとなっています。
全く信用できない。少なくとも先月以前、OrarioからKULASISへのアクセスパターンを解析した限りでは、そんな風なアクセスパターンには見えなかった。嘘を書くのもいい加減にしろ。
Webスクレイピング技術に関して、なぜアクセスパターンが問題になるかが一つ疑問である。
下記のOrarioが出しているPDF(http://www.orario.jp/wp-content/uploads/2017/04/Orario%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%A6%8B%E8%A7%A3.pdf)にあるように、簡単にいうならばID/Passwordを利用したPOST通信を行い、その返答値をスクレイピング（切り貼り）している。
それをアクセスパターンを解析で一体何が取れるのか？という部分が、この辺りが分かる自称専門家の私(匿名で失礼)にもさっぱりわからない。
もっというと、「そんな風なアクセスパターンには見えない」、というならば、セキュリティの観点上公開すべきではないだろうか、
逆に一体アクセスパターンを見て私(匿名で失礼)も何を行っているのかが気になるところである。
ただでさえ、不正アクセスという言葉をつかって攻撃しているわけだから、
アクセスパターンを公開して断罪すべきだし、セキュリティ観点からみても他大学との共有はすべきで、
学生に対してもその証拠を出して止めさせるべきだろう、というのが個人的見解である。
学生の求める「単位」をつかって脅しをかけている時点で、お察しだが……。
そもそも上記で述べた開発時のほぼ不正アクセスと考えられる通信についてを「アクセスパターン解析で見つけた」というのであれば理解ができるが、
現在すでにスクレイピングが確立している通信に関して、アクセスパターンでOrarioかどうかを判別するのが可能かというと何とも言えないと思う。
（ご丁寧にOrarioが通信用のUserAgentにOrarioの文字を含めているなら別だが……
（もちろん、アクセスログを見て、ログインページからWebスクレイピングしたいページへ遷移するまでの時間を取るとあまりに短すぎる、という話ならやれるかもしれないが……。
たとえKULASISが京都大学がオリジナルで開発した大学教務事務パッケージだとしてもそうだろうと考えている。
同様に日立や富士通も同じような大学教務事務パッケージがあるが、
基本ログ処理がザルでろくにuser-agentの確認もできない大学も多く存在したりすることを知ってる自分としては、
本当だろうか？嘘を書くのもいい加減にしろ？ と思う。
UIが糞（システムのスマートフォン対応がノロい）だからアプリが流行るということに気づくべき。
富士通、日立にしてもそうだが、APIを提供したほうがいいのではなかろうか。
とくにKULASISだったか何だったは、京都大学謹製と聞いている（違ったら失礼
少なくとも他の大学教務事務パッケージではなかったと記憶している。
であれば、京都大学がAPIを提供し大学側で専門家を集めてOrarioを超えるものを作ってはどうか？
実際大学でこういうことをやろうにも、問題になってくるのは予算で。
教務、事務、学務、図書館、など様々な縦割りが存在し、それぞれがそれぞれの予算でそれぞれのシステムを入れている。
これが実に糞で。
一つの大きなシステムを入れ替えるとなると、横との連携をとって全ての組織の号令をとらなければならない。
ここまで問題になってくるとやはりその辺りの対応の遅さが問題なのではないかと考えている。
大学がアホ → 学生に良い物を提供したいという思いがあるならもっとフットワーク軽くしろ
教授がアホ → 曖昧な表現で、素人を先導しようとするのが見え見えで気に入らない
Orarioアホ → コメントにもあるけどやり方が汚いのは確かだから甘んじて受け入れろ
以上です
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー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を学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
真面目に答えず、出来る限り嘘と虚構を織り交ぜて答えていきたい。
広義的にいうならスパムだな。
で、この文章がどうやって作られているかというと、主にコンピューターによって自動生成されている。
自然言語処理には「形態素解析」や「構文解析」などの技術が用いられているのだが、よく分からないのでスキップしよう。
で、それらが文法を解するのだが、致命的な弱点がある。
つまり、それで出来上がる文章は文法的には正しく見えるかもしれないが、文意がないので支離滅裂になる。
言語障害を「ワードサラダ」と通称することがあって、そこからこのスパムはそう呼ばれるようになった。
これの厄介なところは、検索エンジンがそれら支離滅裂な文章をスパムとして弾くことが困難なことだろう。
ザックリいうなら、コンピューターが書いたものなのだから、それはコンピューターにとって「正しい文章」だと判断される、と考えてくれ。
SEO(検索エンジン最適化)にとって、ワードサラダの対策は永遠の課題……らしい。
このようなことをする目的としては、労力なしに広告収入を得るため、SEOの妨害とか愉快犯など、人によって目的は様々のようだ。
誤解してはいけないが、自動で文章を生成する技術自体が悪いのではなく、それの利用方法の問題であることは知っておいたほうがいい。
http://tradenote.info/blog-entry-3.html
一般に、バッカスナウア記法は正規表現では処理できないネストの階層を記憶できるなどの根本的な差があります。
これは正規表現が有限決定性オートマトン（DFA）ないしε遷移と不特定の同種記号の遷移を用いる非決定性オートマトン（NFA）に基づいているのに対し、BNF記法での解析は必然的にスタックを内部状態に持つからです。
https://ja.wikipedia.org/wiki/LL%E6%B3%95
これは左からトークンを走査して、導出する非終端記号を左から決定していくアルゴリズムです。
例えばA→A Bという構文規則があった場合に、Aの還元内でAを還元できるかどうか判定し続けて無限ループに陥ってしまい、いつまで経ってもBの判定に辿り着けません。これを左再帰といい、LLでは左再帰を直接扱う事ができません。
非終端記号の間接的還元を考慮したはじめに現れる終端記号の集合（FIRST集合）を構築して上手く左再帰を回避しなければなりません。
マッチングに用いる規則をベタに関数内部に再帰させながら順番に書いていくだけなので実装は容易です。
https://ja.wikipedia.org/wiki/LR%E6%B3%95
https://ja.wikipedia.org/wiki/LALR%E6%B3%95
こちらは左からトークンを走査して、導出する非終端記号を右から構築するアルゴリズムです。
BNF構文規則から走査に相応するDFAを構築し、DFAの遷移を記憶しながらスタックに状態をpush/popし構文解析を行います。
なのでLL法にあるような左再帰を直接扱えないという欠点がなく、むしろスタックが簡潔になるため積極的に左再帰のBNF記述を行った方が効率よく処理を進められます。
LR法はDFAの大きさが巨大になるため、実用的ではないようです。
LALR法はLR法を改良したアルゴリズムで、扱える構文クラスの範囲はLRよりも少し小さくなりますが現実的な計算資源で構文解析を行う事ができます。
