« 箱到着 | トップページ | ホテルでUbuntu(11) »

GoLangというらしい。

第1回 Google Go登場の背景
なんて連載が始まったところを見ると、結構注目されているのかな。
記事中の記載で、Goの文法を見た感じ、確かに違和感がある部分もあるな、と。
加えて。
継承がないってのは、ちと驚いた。
最近の言語のわりに、その機能がないってのは、どういうことなのかな、と想像してみる。

まあ、継承の乱用は、結局コードの見通しを悪くするし、熟練したプログラマじゃないと、継承を綺麗に使ったオブジェクトの設計が非常に困難であることを考えると、生産性を高めることを目的としたGoでは、継承を排したのも解らないでもない。

んでも。

慣れの問題かも知れないけど、結構画面関係でライブラリ組むときに継承使えないのは痛いんじゃないのかな。
まあ、それに代わる仕組みがあるなら構わないけど。
#ま、ワタクシが組むワケじゃないから、いいか。(笑)

実際、そんな頻繁に継承使うか、といわれれば、あんまし、アプリケーション開発その物では使わなかったりするけど。
基盤機能なら、まあ、ね。継承されることを前提とした基底オブジェクトを作って、その型を基本とした関連ライブラリを作ったりすることもあるけどさ。
なので、Goのライブラリが充実してくると、あまり継承は使わないのかも知れなくて。

そこを目指しているんですかね。

なんとなく、この連載を注目してると、その辺も見えてくるのかも知れないですね。

|

« 箱到着 | トップページ | ホテルでUbuntu(11) »

パソコン・インターネット」カテゴリの記事

日記・コラム・つぶやき」カテゴリの記事

コメント

脈絡なく、どんどんいきます。
http://www.google.com/intl/ja/ime/

wineではインストールできなかったんですが。

投稿: 松本 | 2009年12月 3日 (木) 14時23分

Webのシステムなんですかね?
だとすると、ChromeOSでも、これが標準になるのかな?
そういう意味では期待の大きいシステムですが〜。(笑)

こちらも週末試してみます。
#箱を入れ替えてから。(笑)

投稿: かおりん | 2009年12月 3日 (木) 21時32分

まあ、完全にアプリケーション作成用の言語じゃない、ってことなんじゃないでしょうか。もっと下のレイヤを弄るため、とか。
Googleはコンパイラ型としてはC++、あるいはJava用いてますが、これらじゃ「やり辛い」もっと下層弄る為に実験的に作った、って事なんでしょうけどね。
良く分からんのですが、「ちょっと変わった記述規則」用いるのなら、Common Lisp勉強しても大して変わらん、ってのが(僕みたいな)ユーザー側の感想です(笑)。C/C++、Java、JavaScriptコミュニティは反応違うのか(笑)。

>Goと同じく並列処理指向の新興コンパイル言語として注目を集めているScala(コンパイル言語の中ではもっとも推論機能が充実している言語の1つである)では、ifが値を返す式であるとされ、また、returnを省略できる規則がある(最後に評価された式が関数の返り値となる)ため、同様の関数定義(def Fx)は以下のように書くことができる。

>  def Fx(i:Int) = if (i > 0) i*i else 0

>※ここでは、戻り値となるi*iと0の双方が整数であるため、関数Fxの戻り値は自動的にInt型であると推測される

ほう。ScalaってPythonみたい。
でもANSI Common Lispだったら実際こうなんで、

(defun fx (i) (if (> i 0) (* i i) 0))

こーなってくると大して変わんねえよな(笑)。elseとかの「構文要素」が無いだけ、Lispの方が短くてシンプルじゃないのか、とか思います。
C/C++の文脈で「改良しよう」としても、ある意味もはや余地無し、ってのも言えるのかな。表現方法の限界と言うか。

投稿: cametan | 2009年12月 4日 (金) 02時48分

まあ、言語なんで、用途を限定する方がどうかしているのかも知れませんけどね。
継承がないってだけで、基盤設計に向かないってこともないと思うので。

ただ、クセがある言語って、結構嫌われるので、C/C++系の人間には受け入れられない可能性はないでもないですねぇ。
#元々がクセあるからな。(笑)

Java/C#は、そんでも頑張ってるんだと思うんですが、なかなかねぇ。
#VBは論外としても。

確かに仰る通りに、あそこまで違うとなると、別言語の習得も視野に入ってくるかも知れません。
正直、似てるけど、ちょっと違うってのが一番使い難いんですよね。(^^;

結構、それでJavaScriptでタイプミスをやらかすので。

ま、まだ出たばっかりですから、もう少し様子見、って感じです。

投稿: かおりん | 2009年12月 4日 (金) 22時48分

>まあ、言語なんで、用途を限定する方がどうかしているのかも知れませんけどね。
>継承がないってだけで、基盤設計に向かないってこともないと思うので。

うん、ここなんですよ。焦点は。
継承がない、ってのはオブジェクト指向の文脈ですよね?
一方、Cは継承が無いです。そしてLinuxカーネルはその「継承が無い」言語で作られている。
C++作者の自虐的ジョークにもありましたが、C++なんかのオブジェクト指向言語は「継承無し」のCで記述されたカーネルに比べてもその容量は最低見積もっても5倍です。Windowsの「重さ」はオブジェクト指向での「重さ」って考えても良いかもしれない。多分。

最近のGoogleの動向見てると、たとえばAndroidにしても、あるいはChrome OSにしても、今僕等が使っている正式名称、GNU/LinuxからGNU抜いたような形になってきてるんですよ。それこそツールまわりはFreeBSDから引っ張ってきたり。FSF謹製の「アプリケーション」使うの避けてるように見えるんです。
つまり、動向としては、「丸裸のLinuxカーネルに」色々自作のものくっつけて行ってるように見えるんですよね。明らかに他の、UbuntuのようなGNU/Linuxの普通のディストロと「違う道」を模索してるように思えるんです。
そうすると、残るは「カーネルのみ」なんですよね。僕の予感では、Googleは「脱Linuxカーネル」も視野に入れてるんじゃないか、って感じるんです。取りあえずカーネル回りで色々と技術を蓄積しておいて、最後はカーネルも「独自のもの」を出す可能性があるのでは、と。
そう考えると、Goの登場は合点が行くんですよ。おそらく「新しい形式で」カーネル記述する為の言語なんじゃなかろうか、と。
そしてだからこそ、

・コンカレント処理
・ガベージコレクション

と言う2点に注力して、コンパイル速度を上げて、なおかつ「継承がない」のでは、って思えるんです。

特に、コンカレント処理可能なカーネルの需要、ってのは増えると思うんですよね。これは言語側でサポートしてくれた方が、いわゆる一般アプリケーションより有利なのでは、とは思います。マルチコア化がどんどん進むでしょうし、また、Googleの並列処理を行うサーバーでも総合的に色々とコントロールするには、カーネルから、ってのは理にかなってると思うんですよね。
もう一つ、ガベージコレクションも今後大事で、もはや「必須技術」って言ってもいいんじゃないか、って思えます。そもそも現状だと、ガベージコレクションを持たないからこそセキュリティが甘い、ってのは言えるでしょ?プログラマがメモリの管理を全部行わなければならないが故、危険なリークも起きるわけです。大昔はガベージコレクションは「非効率性」の代名詞だったんですが、今は技術が進歩したんで、カーネルレベルで欲しいのは、むしろ「効率的なガベージコレクションエンジン」なのでは、と。

こう考えてみると、Goはやっぱり「普通のアプリケーションの記述」が狙いなんじゃなくって、カーネル記述に焦点を絞った実験的言語なんじゃないのかな、って思えるんです。

>正直、似てるけど、ちょっと違うってのが一番使い難いんですよね。(^^;
>結構、それでJavaScriptでタイプミスをやらかすので。

あ、分かります(笑)。そうですよねえ(笑)。

投稿: cametan | 2009年12月 5日 (土) 00時34分

ああ、カーネルね。
なるほど。なら継承は不要ですかね。
#あっても書けるけど。

継承その物は、なくても書けるんですが、あった方が楽って話なので。
まあ、ないならないなりの実装になるんじゃないかとは思います。
実際、現場ではあんまし使いませんし。

先にも書きましたが、見通しがね、悪くなるんですよ。
解ってる人しか使えない、ってことになる。

まあ、大昔のGOTOじゃないですけど。(^^;

本来効率的に実装するための技術なんですが、使いどころを間違えると、単に見通しの悪い使いにくいライブラリになるという。
ワタクシとしては気に入ってる機能なので、ないのはちょっと、とも思うんですけどね。>継承

現実見れば、さほど重要じゃないのかもしれません。
コンカレント処理は、確かに今後重要な機能だとは思いますね。
今後、どんどんマルチコア化が進むんでしょうし。
コンパイラレベルで対応しててくれれば、楽ですよねぇ。
ガベコレも、マルチコア化が進む現在、必須になるのかもしれません。
メモリ管理で、マルチコアってかなり大変だと思われるので。
その辺がターゲットになってるんですかね。

投稿: かおりん | 2009年12月 5日 (土) 00時49分

>その辺がターゲットになってるんですかね。

うん、僕はそうだと思います。
実際、Googleって、オープンソース寄り企業、って捉え方されていますが、実際問題、「開発企画を発表」する、って事ほぼないですし、発表した、あるいはオープンソースとして「公開した」時、って結構ベースは「完成してる」事が多いんですよね。広い意味でベータテスティング募る為のオープンソースって感じで。公開した時には、既に結構いいトコまで進んでる。
って事は……Goを発表した、って事は既に実験段階で「Goで何か書いてる」って考えて良いと思います。おそらくカーネルの試作くらい既にやってる、って思うんですよ。

大きい文脈で言うと、「カーネル記述の為に」設計された言語っていままで2つしか無いわけでしょう?OS記述目的で開発された言語、って。
一つは(C++じゃなくって)AT&TのC。もう一つはLisp(正確に言うと、Lisp方言のLispマシンLisp)しかないんです。
この二つの言語「以外は」どれもアプリケーションを効率良く記述する為に開発されたものなんで。要するに「アプリケーションを記述する上での"便利さ"って何なんだ?」ってのが言語設計の目的なんで、「OSを記述する為に必要充分な機能は?」ってんじゃないんですよね。
LispマシンLispは、もうハードウェア構成が違うマシン上でのOS記述用言語なんで、この場合除きますが、ノイマンマシン用の「OS記述に特化した」設計の言語、って'73登場のC以外には「全く無い」って言って良い状況だと思います。
PascalもJavaも「仮想マシンで動かす」全く別の目的を持って作られていますし、そもそもハードウェアレベルまで下がる事は初めっから考慮してないでしょうしね(仮想マシン、って意味ではPerl/Pythonも同様でしょう)。C++もC#もシンタックスをCに似せた、ってだけでやっぱり目的はそこには無い。JSもそうですよね。
GoogleのGoはOS記述に焦点を絞って「もう一段先に進もうよ」って意味じゃないか、って思うんです。21世紀に1970年代のコンピュータより遥に良い環境を入手している僕等に向けての「OS記述用言語とは何なのか?」と問う再定義だと思うんですよね。

投稿: cametan | 2009年12月 5日 (土) 02時41分

確かに言われてみれば、OS記述を目的としたような言語って最近聞かないですね。
仮想マシン全盛であることは間違いなさそうな。

仮にカーネルの記述を目的とした言語とすれば、これで弄ってると、そもそものカーネルの速度もある程度想定できるような感じになるんですかね。

ちと面白そうではあるんですが。

ちと、今のところ、GoLang使って、なんか書くような目的がないので、アレなんですけどね。
文字列処理とか、その辺でなんか試すようなことがあれば、GoLangでも試してみれば、現状の各種言語との体感的な比較は可能かもしれません。

さて、ChromeOSのVer3くらいから、Googleカーネルになるんですかね。

投稿: かおりん | 2009年12月 5日 (土) 10時49分

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/500703/46922278

この記事へのトラックバック一覧です: GoLangというらしい。:

« 箱到着 | トップページ | ホテルでUbuntu(11) »