Red Hat の開発者、Java に影響を受けた新言語「Ceylon」を開発中 61
ストーリー by reo
次はアッサムだな 部門より
次はアッサムだな 部門より
ある Anonymous Coward 曰く、
本家 /. 記事「Red Hat Uncloaks 'Java Killer': the Ceylon Project」(Red Hat、「Java キラー」という the Ceylon Project を披露) によると、Red Hat に所属し、Hibernate などを開発した Gavin King 氏が新しい言語「Ceylon」を披露したそうだ。
これを受け、King 氏は自身のブログにて Ceylon について解説している。SourceForge.JP Magazine の記事によると、Project Ceylon は「Java ではなく、Java に深く影響を受けた新しい言語」だそうで、Java に影響を受け、Java の良くない点を改善するものとなるようだ。Ceylon は Java 仮想マシン上で動き、静的型付け、自動メモリ管理やセーフリファレンスなどを特徴とするとのこと。
なるほど、それは正しい。 (スコア:5, おもしろおかしい)
セイロンだ。
＃ごめんなさい、ごめんなさい。
Re:なるほど、それは正しい。 (スコア:2, おもしろおかしい)
アッ、寒っ！
Re:なるほど、それは正しい。 (スコア:1, おもしろおかしい)
ダージリン（ダジャレ）を言うのはダレジャ？
既に Scala があるような (スコア:3, すばらしい洞察)
重要なのはライブラリ (スコア:2, すばらしい洞察)
世に受け入れられているのはライブラリが豊富だからです。
業務では仕様が安定している事も重要ですが、まずは趣味で使ってもらう事を考えると二の次。
DやらなにやらC/C++の汚さに業を煮やしてオレオレC言語を作ろうとする流れはよくありますが、
最初からよっぽど豊富なライブラリを備えていない限りは
既存のライブラリとリンクが出来ないと使う気が起きないわけですね。
となると最低限既存ライブラリとマングルを合わせる事が必要ですが、それでもまだ使う気が起きないので
既存ライブラリのヘッダファイルの読み込みもサポートして欲しいわけです。
そしたら結局既存言語のパーサーを備えなきゃいけないので、
じゃあ既存言語使えば良いじゃん、というジレンマ。
と、ここまで書きましたが、過去の不満点を改良した言語には期待しています。
Re:重要なのはライブラリ (スコア:3, すばらしい洞察)
ライブラリが重要という意見はその通りだけど、
でも、広く使われるようになる為に必要なのは使いやすいIDEだと思うよ。
でなきゃ、VB（≠.net）があれだけ流行る理由がない。
Re: (スコア:0)
私は、昔ながらのエディタと
コマンドラインからのコンパイラ呼び出しが好きですね。
そういう人って少数派なんですかね。
Re: (スコア:0)
スクリプト言語ならともかく、
少なくともJavaに関しては少数派どころか害悪と言ってもいいですね。
生産性が30倍は違う。
Re:重要なのはライブラリ (スコア:2, 参考になる)
LL側から補足すると、例えば python では ipython などのインタラクティブシェルを併用することによってモジュールのメソッド補完・ドキュメントの参照・コードテストなどができます。私の良くあるスタイルはエディタ、コマンドライン、インタラクティブシェルの３つを併用ですね。
まぁ、それが eclipse や DeveloperStudio に勝るとは考えていませんが、単なる慣れや好みということですね。
Re: (スコア:0)
eclipseやVisualStudio(2005以降)を使い出したらとてもそんな昔の環境に戻れません。
本当に生産性が数十倍違ってきます。
まぁその分ライブラリがなかなか覚えられないわけですが。
インテリセンス便利過ぎ。
Re:重要なのはライブラリ (スコア:1, 参考になる)
Eclipseですが、補完機能はもちろんのこと、
リファクタリング機能がすごく便利です。
リファクタリングを前提として使うと、
例えば変数名を簡単に変えられるので、変数名を考えるのを後回しに出来ます。
str1, str2と適当に付けて、あとで意味を考えてsrc, destにするとか。
これが出来るのもJavaやC#が静的言語としてしっかりしてるからで、
PHPやRuby、Pythonなどでは到底無理ですね。
まあ、これらは動的言語としてのメリットがありますが。
Re: (スコア:0)
インテリセンス便利ですね。私もそう思います。
が、その一方でスペースを自由に空けさせてもらえないとか、
括弧を自由に閉じさせてもらえないとかあって、
いまいち好きになれないんですよ。まあ、私の癖が悪いんでしょうが。
あと、プロジェクトフォルダに
わけの分からないファイルが自動生成されるのもちょっと...
プロジェクトをコピーしたいときに気になります。
私みたいな日曜プログラマじゃなくスキルの高いプロなら
そんなファイルのこともきちんと把握してるんでしょうけどね。
# Java の IDE についてはよく知りません。ごめんなさい。
Re: (スコア:0)
スペースなどは、Visual Studioならメニューのツール→オプションのテキストエディタ→C#→書式設定などで少しはカスタマイズできます。足りない人にはこれでも全然足りないのでしょうけど。あと、Eclipseでも似たような設定があったはず。
Re: (スコア:0)
有益な情報をありがとうございます。
おかげでずっと不満だった if,for,while などの後の中括弧が
好みの開き方にカスタマイズできました。
ただ、スペースはやっぱり好きにはできないみたいです。
私の癖は規則性がなくて行き当たりばったりなんです。
まてよ、オートフォーマットを無効にすればいいのか？
おお、うまくいった。うん、これで IDE が少し好きになれる。
Re:重要なのはライブラリ (スコア:2, すばらしい洞察)
シェア拡大というか、広く受け入れられるには、もちろんライブラリが重要だと思います。
否定するつもりは、これっぽっちもありません。
しかし、その前の段階で「おっ、これはなかなか面白そうだ。オレにもちょっと書かせろよ～」（byハッカーな人）的な
言語仕様の筋のよさが船出の時期には必要で、それがライブラリの充実につながっていくと思います。
yagiyama
Re: (スコア:0)
Re:重要なのはライブラリ (スコア:1, すばらしい洞察)
ない。
ソースコードに加えて、言語拡張までメンテしなきゃいけない言語なんて誰が使うんだよ。
C++コミュニティみたいに「ほら、templateでこんな面白いことができた」と言語そのもので遊ぶことと、
日曜プログラマが言語を使って遊べるものを作ることはユーザー層が違うということを理解すべき。
Re:重要なのはライブラリ (スコア:1)
マクロを活用したプログラミングって問題分野に特化した新しい言語を作るのと等しいと思う。
プロトタイピング専用言語とかだったらそれは有用だと思うけれど、Javaのようにあらゆるアプリケーションをカバーする言語にとってはデメリットが大きすぎる。
そういうのが必要ならばLispやForthみたいなモノを使えばいいと思う。
Re:重要なのはライブラリ (スコア:2)
たしかに、lispのマクロは特定の問題に特化させる言語を作り出すのですけれども、
べつにそういった言語は「拡張にすぎない」のですから、元の言語が消えてなくなるわけじゃなし、
全然問題ないと思います。
あらゆるアプリケーションを同時に扱うというのは、別に、
超多機能の一つのプログラムが網の目のように絡まっているわけではないのですし・・・
それってリファクタリングが必要でしょ?
で、lisperは分割したそれぞれの機能毎にそれぞれの言語を作る。
その必要が無いときも多いですけれども。
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re: (スコア:0)
JVM上で動くのだから過去のライブラリにかんしちゃ問題ないんでないの？
Re: (スコア:0)
C++から複雑さを取り除いたことが売りの一つだったはずのJava言語が、
今やジェネリックスだのアノテーションだのforeachだのを追加して複雑になっていくことへの批判だろ。
Re:重要なのはライブラリ (スコア:2, 参考になる)
ジェネリックス
→List等と書けるようになっただけでも十分進化。関係ない変なデータを入れるミスが減る&IDEの推測が洗練されるので、むしろ楽になってる。(toArray()がObject[]を返すのだけはどうにかしろって感じですが)
アノテーション
→メタデータをつけられるのは便利。ちゃちゃっとオーバーライド元の関数を調べたり、「過去のモジュール用に仕方なく残してあるんだから新規開発で使うなって言っただろ！」みたいなメソッドにマークをつけられたり。
foreach
→ループ変数の書き間違い(2重ループのなかでjにしなきゃいけないのにi使ってたとか)が減るって便利じゃないですか？ いちいちint i=0; isize; i++って書くのもめんどくさいですし。
挙げられた例は当時「ようやく入ったか、何で今まで入れてなかったんだ」って不満に思っていたところなので、そこを複雑さって言われてしまうとちょっと納得しにくいです。
シンプル=最強ならBrainf*ck最強伝説ですよ。
Re: (スコア:0)
> →List等と書けるようになっただけでも
<>を消されちゃったんですねわかりますん。
> toArray()がObject[]を返すのだけはどうにかしろ
toArray(T [])じゃダメなの?
Re:重要なのはライブラリ (スコア:1)
ご推察の通りですorz 正しくはList<Integer>。そのもう少し下にある「isize」も「i<size」の誤り。
プレビューで確認する癖をつけないといけませんね。
実際にはそちらを使ってます。ですけど、「IntegerのListだ」って予め教えてあるんですから、何も言わなくてもIntegerの配列を返してくれるのが自然な話じゃないですか。
多分何か事情があってこうなったんでしょうけど…。
Re: (スコア:0)
Map<K,V>::get(Object key)
が結構きつい
putはちゃんと
put(K key, V value)
なので気付かずにやってしまいがち
ジェネリクス以前との互換性のためなのだろうか？
Re: (スコア:0)
Re: (スコア:0)
型推論がないのが面倒で煩雑で。
Eclipseならnewだけ先に書いておいて、右クリックからローカル変数作成、でできるけど、
必ずしも欲しい宣言になるわけじゃないし、何より長ったらしい。
>アノテーション
独自アノテーション作って、必要なフィールドにだけつけといて、リフレクションで列挙してくのもたまにやる。
Re:重要なのはライブラリ (スコア:2)
Java 言語が複雑になっていることは間違いないですし、C++ から複雑さを取り除いたはずなのにというのはおおむね同意なのですが。
人間も成長していますし、時代によって Java 言語に求められているちょうどいい複雑さというのは変わっていっていると思います。ですので、ジェネリクスやアノテーションが追加されたことが、Java 言語が思想とぶれていることにはならないかと。
また、ジェネリクスに関しても Java と C# を比べると、Java の方がシンプルだと思いますよ。
Re:重要なのはライブラリ (スコア:1)
趣味でも仕事でもC++な私ですが、STLの使いやすさに惚れて、他の言語に移行できません。C++は人並み以上には使いこなしていると自負していますが、最近のJavaやC#には、C++に比べて「難しそう」という先入観があります。初期の頃のJavaやC#は多少使えますが、今はちょっと手を出すのが億劫です。
Re: (スコア:0)
えーと、Netscapeから始まってMozillaになって、今度は更にFirefoxになって・・・・・・
Re: (スコア:0)
習得しやすさとか、罠にはまらないという意味では
この3つは別に複雑でも何でもない。
# この件についてはJavaで一番罠にはまりやすいフレームワークの作者が作った
# 言語なんて程度は知れてると思うけど:P
Re: (スコア:0)
どの言語も違いはライブラリ程度しかないと思ってるんだろうな。
http://practical-scheme.net/trans/beating-the-averages-j.html [practical-scheme.net]
まあAlgolの子孫たちしか知らないととくにそう思いがちだろうね。Algol自体はCall-by-nameというとんでもない機能を持ってたんだけどね。
Re: (スコア:0)
> どの言語も違いはライブラリ程度しかないと思ってるんだろうな。
どうしてこうなるのか男の人って不思議。
Re: (スコア:0)
とはいえ、優れた言語でアルゴリズムを工夫して、というようなプログラミングの楽しみよりも
単純に既存のライブラリを利用して派手な仕事をすることに人々の関心が移ってきているのも事実でしょう。
SICPを教えていたMITの授業も、最近ではPythonに切り替えたそうです。
Re: (スコア:0)
JavaだってManglingはないし、ライブラリが最初から豊富ってことはないですよね。
言語として何か売りとなるものが重要かと。
例えばJavaはマルチスレッドが標準でサポートされているのが売りの一つだったし。
# 今の地位を決定的にしたのはEclipseによる、IDEとの相性の良さだと思うけど。
Re: (スコア:0)
ライブラリが豊富すぎるのが問題なんじゃないですか、たぶん。
Javaは成功したために無能が増えすぎて、彼らが車輪の再発明を繰り返していると
Goslingがどこかで言ってたような。
このプロジェクトの目的は、Javaコミュニティに隔離場所を作りたいってことなんじゃないかと。
Javaの言語仕様については、代入は := にすべきだとか
ブロックの使い方に不満があるとか、その程度のことしか思ってなさそう。
いちおう関数型チックな機能もあるけど、すでにScalaがあるわけだし。
対オラクル戦 (スコア:0)
がついに言語にまで及び始めましたか。
Re: (スコア:0)
Chai VM に最適化されるようになるんですよ、お茶つながりだし。
Re: (スコア:0)
# Javaはよー知らんけど、リード文にある特徴、Javaとあまり変わらないような。型付けも静的だしGC積んでるよね？
# 半可通すぎるだろって突っ込みは歓迎です。半どころか1e-4可通くらいですけど。
Re: (スコア:0)
Google(Android)もこれに乗り換えればオラクルとの裁判は終了か?
Hibernate などを開発した (スコア:0)
でさ (スコア:0)
言語としての評価はどうなの?
Re: (スコア:0)
JavaVMってだけで誰にも歓迎されないだろ？
Androidも強力なアプリは殆どネイティブだし。
簡易的なアプリならRIAのアプリ化で十分だしさ。
Re: (スコア:0)
静的な型を選んでしまった事は
rubyやPHPに対する、非常に大きなハンディキャップになると思います。
静的に型を決定するという事は、まつもと御大の言うとおり非現実的な拘束であって
ちょっとメソッド名を間違えただけで、コンパイルすらできない状態になります。
まさに「このプログラムは無害だ、なぜならば、動かないからだ」の状態です。
このおかげで、PCの世界は、理想的な状態に比べ20年以上は遅れているはずだと
勝手に妄想しています。本当に勝手な妄想ですがｗ
翻って動的型付けの言語は、プログラマに対してもユーザに対しても柔軟で
特にPHPは変数宣言すらも省いてしまい
Re: (スコア:0)
ネタですか？
> ちょっとメソッド名を間違えただけで、コンパイルすらできない状態になります。
動的言語でメソッド名間違えたら実行時にエラーになるだけですよ。
# 全部突っ込み入れたいけど頭悪すぎなので略
Re: (スコア:0)
俺のエスパー的直観だと
int foo;
print_int(foo); // ○
print_str(foo); // ×
みたいな事を言ってるような気がする。
オーバーロードで良いじゃん
Re: (スコア:0)
最近pythonかじった程度な自分には、動的型付けって何が嬉しいのか理解できない。
型を気にせず適当に書くといたるところでstr(count)やらint(input)やら書く羽目になる。
しかも実行するまでわからない。
簡単に実行できるから静的型付け言語にとってのコンパイルするようにテストするのがいいのだろうか？
それでも型ごとのテストケースつくるのだけで面倒くさい気がする。
静的型付け言語よりよっぽど型意識しなきゃならん気がするなーと。
根本的に自分の書き方間違っているような気もするけど、
静的型付け言語に洗脳されてる自分には気が付つけないもっと簡単なやり方でもあるのだろうか
Re: (スコア:0)
それstrとかintした後何に使ってんの？
print("total count is: " + count) とか sum += input ってそのまま書けば良いじゃん
pythonはしらね
Re: (スコア:0)
でした。
pythonは動的型付けではないってことか
Re: (スコア:0)
そうそうwww
型を明示させてくれないくせにチェックはきっちりしてくれちゃうんだよなwww