  |
はてなキーワード: ERLANGとは
凡人以下ながら新しいネタとか技術とか数学やアルゴリズムは引き出しを増やすように心がけてるんだけどね
食い扶持になる可能性もあるし
しかし、未だにRustがうまく使えないというか、学習コストが高すぎる気がするんだがどうしたもんかな…
国が公開してるとあるExcelファイルを読み込んで、それを望まれるCSVやJSONに加工する、
という仕様は同じにして色々な言語で書いて比較しようと思っているのだけど、
PHPやNode.js、Python、Goは自分には問題なく書けてる
多分、C++やCも、流石に何か便利なものにvcpkgやconanとか使って依存するだろうけど書けると思う
しかし、Rustは難しいなあ
Excelファイルをパースするサンプルコードも難しいというか、長くね？と思ってしまうんだけど
これに慣れる日は来るんだろうか…
Goは学習コストが低いと思うから、とりあえず動作するコードを書くのは問題ないんだよなあ
C#とかDとかNimとかErlangとかKotlinとかDartとかもやろうかなあ
でも、少なくとも後ろ2つはほとんどJavaみたいなもんだろうか
どんなに優れたツールや設計思想などがあっても、使う奴がダメだと全く無意味。弊社もWebアプリを作ってて、RESTだのFluxアーキテクチャだのいろいろ導入を試みたが、ほとんど無駄に終わった。
どんなクソ組織でも効果があると確信持って言えるのは上の3つだけ。1つ目は初歩的すぎると思われるかも知れないが、筆者の想定するダメな組織・ダメなプログラマというのは、このレベルの連中を含む。
静的型付け言語（サーバーサイドならJavaやC#、フロントエンドならTypeScript）を使わせれば、少なくともコンパイル時に分かるエラーは修正させられる。
というか、ダメなプログラマに動的型付けの言語は触らせてはいけない。必ずそのプロジェクトは半年後には保守できなくなる。
テストは強制的に書かせるし、テストのないクラスや、通らないテストあったらコミットできないようにする（それは容易にできる）。
もう一つの方法は、そもそも優秀なエンジニアしか参加できないようにすること。たとえば、Scala、Haskell、Erlang、Common Lispなどで書かれていれば必然的にそれが分かるエンジニアしか開発できないし、こういう言語を自主的に学習しているエンジニアは優秀である可能性が高い。
このプログラミング言語はMtGだと多分この色の組み合わせだろう。
みたいなのをまとめたら次のようになった(TIOBEのランキング順トップ50)。
後半は知らない言語もあって怪しいが、おおよそこのようになると思われる。
※改めて見てみると何箇所か違和感があったので最初の版からちょっとだけ修正した。
| 順位 | プログラミング言語 | 色の組み合わせ | 内訳 |
|---|---|---|---|
| 1 | Java | アブザン | 白黒緑 |
| 2 | C | ゴルガリ | 黒緑 |
| 3 | Python | ティムール | 緑青赤 |
| 4 | C++ | ジャンド | 黒赤緑 |
| 5 | C# | バント | 緑白青 |
| 6 | Visual Basic .NET | セレズニア | 緑白 |
| 7 | JavaScript | ボロス | 赤白 |
| 8 | PHP | グルール | 赤緑 |
| 9 | SQL | 無色 | |
| 10 | Swift | 4C(緑欠色) | 白青黒赤 |
| 11 | Go | ゴルガリ | 黒緑 |
| 12 | Assembly language | 黒単 | 黒 |
| 13 | R | イゼット | 青赤 |
| 14 | D | グリクシス | 青黒赤 |
| 15 | Ruby | 赤単 | 赤 |
| 16 | MATLAB | イゼット | 青赤 |
| 17 | PL/SQL | 無色 | |
| 18 | Delphi/Object Pascal | アゾリウス | 白青 |
| 19 | Perl | ラクドス | 黒赤 |
| 20 | Objective-C | エスパー | 白青黒 |
| 21 | SAS | アゾリウス | 白青 |
| 22 | Visual Basic | 緑単 | 緑 |
| 23 | Dart | ジェスカイ | 青赤白 |
| 24 | Scratch | 白単 | 白 |
| 25 | Scala | 5C | 白青黒赤緑 |
| 26 | Groovy | ナヤ | 赤緑白 |
| 27 | Transact-SQL | 無色 | |
| 28 | F# | アゾリウス | 白青 |
| 29 | Rust | マルドゥ | 赤白黒 |
| 30 | COBOL | オルゾフ | 白黒 |
| 31 | ABAP | アゾリウス | 白青 |
| 32 | Lisp | シミック | 緑青 |
| 33 | Kotlin | 4C(緑欠色) | 白青黒赤 |
| 34 | Logo | 白単 | 白 |
| 35 | RPG | ディミーア | 青黒 |
| 36 | Lua | 緑単 | 緑 |
| 37 | Fortran | スゥルタイ | 黒緑青 |
| 38 | PowerShell | ジェスカイ | 青赤白 |
| 39 | Ada | ディミーア | 青黒 |
| 40 | LabVIEW | ディミーア | 青黒 |
| 41 | Erlang | 緑単 | 緑 |
| 42 | Julia | イゼット | 青赤 |
| 43 | ML | 青単 | 青 |
| 44 | Scheme | シミック | 緑青 |
| 45 | Haskell | エスパー | 白青黒 |
| 46 | TypeScript | ジェスカイ | 青赤白 |
| 47 | OpenEdge ABL | アゾリウス | 白青 |
| 48 | LiveCode | アゾリウス | 白青 |
| 49 | PostScript | 無色 | |
| 50 | ActionScript | ジェスカイ | 青赤白 |
見返してみるとおおよそ次のルールに従って決めているような気がした。
緑の判定があやふやな気が若干しないでもない…
| 色 | イメージ |
|---|---|
| 白 | 高レイヤ、初心者向け |
| 青 | 浮世離れ、ベンダー |
| 黒 | 低レイヤ、黒魔術 |
| 赤 | 速い、先進的 |
| 緑 | 基盤、グルー |
| 無色 | 道具 |
後なんかweb系の企業がgolang採用多いので、ある程度詳しくなっておけば就職困らなそうという予防線。
今のところが成功しなかったらeurekaとかmercariとか雇ってくれませんか！
どっちもユーザーです！（ペアーズでは3名ぐらい逢った、メルカリではバイクとMacbook Air売ったなー。）
ポケモンGoとかやんねーし、地味に自分がよく使っているアプリやサービスから成功パターンを得るのがいいのかなぁ
なんか、人との接点がうまくできているCtoCサービスがうまくいっているような感じが（CtoCなんだから当たり前か、何いってんだ）
人とコンバージョンしたいです。
誤訳御免。
とりあえず力尽きたので、公開されたメールのやりとり
とか、NPMの説明
http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm
このドキュメントでは他のnpmを公開している人とのモジュール名の紛争について取るべきステップを記述している。
このドキュメントは"npm行動規範(Code of Conduct)"で説明されている容認可能な行為の明確化であり、このドキュメントに記載されている内容はnpm行動規範のいかなる側面に対しても矛盾する解釈を与えるものではない。
パッケージ名を不法占拠してはならない。コードを公開するか、さもなくば去るように。
あるユーザがモジュールを公開していて、その後、他のユーザがその名前を使いたいと思うケースがしばしばある。ここではよくある例を記述する（個々の例は実際の出来事に基づいている）。
それぞれの状況下でのアリスからのクレームは議論されるであろう。しかしそれらのケースでアリスが取るべき適切な段取りは共通している。
これまでのほとんど全てのケースでは、巻き込まれた当事者は重大な介入を要さずに妥当な解決へと到達することができた。多くの人々は本当に合理的になることを望み、おそらく彼らがあなたの邪魔をしていることに気付いてすらいない。
モジュールのエコシステムはそれらが可能な限り自律的である限り最も活気づいて力強くなる。もし管理者がある日あなたが取り組んでいたものを削除したら、それは理由のいかんにかかわらず多くの人を怒り心頭にさせつつあるのだ。人々が自分らの問題を相手との敬意を持った会話により解決すれば、その交流にたいして皆が良い気持ちで終わりを迎えるチャンスを得るだろう。
幾つかの事柄は許されておらず、npmの管理者に注意喚起された時点で議論なく削除されるだろう。例えば：
もしそうした悪い振る舞いを見たらすぐにabuse@npmjs.comに連絡ください。あなた自身でそうした悪い振る舞いを解決しようとする必要はない。われわれはここにいます。
これは生きた文書であり時間とともに更新される。変更点を確認したければ、gitの履歴(https://github.com/npm/policies/commits/master/disputes.md)を参照
Copyright (C) npm, Inc., All rights reserved
本ドキュメントは"Creative Commons Attribution-ShareAlike License."(https://creativecommons.org/licenses/by-sa/4.0/)の元で再利用可能。
ひょっとすると、これはべたべたな一直線の手続き書き時代以来の「全てが一直線に並ぶ気持ちよさ」なのかもなぁ、と思った。
Haskellなんかを書いてると、究極的に、関数型言語におけるプログラムとは、一引数関数の深い深い一直線の入れ子みたいに感じられる。
（いやまぁ、タプルとかもあるけど、原則的に）
構造化⇒OOPと来て、プログラミング言語はGo to hellを廃し、色んな物をDRYに書けるように進化してきたけど、その結果色々なものが並列にばらばらっと並んでいる感じになった。
OOPの大本のsmalltalkはメッセージパッシングの原則の時点で、対等な二つの並列に並んだオブジェクトのやりとりがベースになっている。
勿論オブジェクトは大体内部に別のオブジェクトを抱えていたりして、親子関係があるのは普通だけれど、子同士はやはり並列に順序なく並んでいる。
この並列性のおかげで、例えばそれこそメッセージパッシングをそのまま引き継ぐErlangなんかは、高いスケーラビリティと耐久性を持つわけで、これ自体は素晴らしい発明だ。
ただ、やっぱり並列なヤツラが、ごちゃごちゃっと同時にあって、そいつらが同時にガチャガチャなんかやってたら、神の見えざる手的に、なんとなく全てが上手く噛み合って、プログラムが動きます、って、これどうしても全体像を把握しにくい。
人間の脳みそって、そんな同時並列のものを把握できるようには、出来ていないんだと思う。
上手く動いてはいるんだけど、何で上手く行ってるのか分かるんだけど、分かりにくい。
この気持ち悪さが、今日もどこかのITおじさんを全部staticな書き方に走らせ、OOPわかんねー、と首をかしげながら、何となく使ってる人達の心を、巨大なメソッド作りに導いているのではないかな、と。
なんてったって、Scalaなら並列処理でさえ、モナドなFutureで事実上直線に繋いでいってかいちゃう（Akkaもあるけどあれはオブジェクティブな側面なので）わけで、これは凄く懐かし気持ちいいと思う。
かくして関数型言語は「なんかとにかくきもちいいぃぃぃぃ」な信者を量産している。そしてOOP派との間に、意味分からん溝だけが広がっていく。
大体20年ぐらいクライアント側のアプリをずっと作ってきたおっさんだけど、ここ1年ほど前にサーバー側に移った。
今までずっとWindowsで作ってきたから、何もかも新しいことばかり。
LinuxとFreeBSDのどっちがいいかわからないから、CentOSとFreeBSDの両方で開発している。
Shellスクリプトもちょこっとわかるようになった。
今は主にErlangで０から開発した数十台に分散して動くサーバーを運用している。
言語を覚えるのは苦ではなくて色んな言語を使うことができるけど、OSはなんだか別な感じがする。
今日、FreeBSDのOpenSSLのアップデートをしたらサーバーに繋がらなくなって、なんかpsshとかも動かないし、もうわけわからなくて全部再インストールすることにした。
分からないなりにいろいろ頑張って実際にサーバーを運用しているけど、知識の足りなさを実感している。
俺はもう40代だから、やっぱり脳みそがだめなのかなぁ、とか思いながら今自棄酒飲んでいるところ。
今、第一線で活躍している人はだいたい何年ぐらいでまともに”使える”ようになったんだろうか？
教えてほしい。
id:minamiyama1994 さん、反論してくださってありがとうございます。
Haskellファンのご意見がいただけて嬉しいです。元増田です。
記事全体で「関数型言語」と呼ばれているものは「関数型言語一般」ではなく「Haskellや一部OCamlの話題を含むごくごく一部の言語」の話である
わかりにくくてすいません。記事では「関数型言語」の話はしていません。「関数型プログラミング」の話をしました。
「関数型言語」は範囲がよりボンヤリとした表現です。たとえばC言語が関数型言語かどうかをみても賛否両論にわかれるでしょう。
私が記事を書いた目的は、”関数型プログラミングに縁のない人に関数型プログラミングをわかりやすく紹介したい”でした。
その目的のため、「関数型言語」という表記を注意深くとり除き、代わりに「関数型プログラミングをサポートした言語」という言い方をしています。
このスタンスの上で、
”関数型プログラミングをフルにサポートした言語”の代表として、Haskellを紹介し、
”関数型プログラミングへのサポートが片手落ちな言語”として、LispやErlangなどを扱いました(それらのファンの皆、ごめんなさい)。
関数型プログラミング初心者の方は、それらの差異なんてどうでもよい、と考えるのではないでしょうか。
関数型プログラミングとは何が良いのか、を大雑把に知りたい。
そうなのではと考えて、あえて区別せずに記事を書きました。
「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」？ モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう
id:minamiyama1994 さんの仰るとおり、モナドはパーサー以外の多くの応用があります。
現状多くのパーサーがモナディックパーサーとして書かれています。モナディックでないパーサーは、あまり多くのユーザーには使われないでしょう。
モナドなどの抽象的な構造が幅を利かせてるお陰で、ライブラリに秩序が生まれ、ユーザーはそれを使いやすく・読みやすくなっている、というのが私の言いたかった主張です。
(なお細かいことで恐縮ですが、ある種のモナディックパーサーはApplicativeでは書けません。その点をお忘れですよ)
「テキスト処理」に対して
お前それShellやPerl、RubyやPythonの前でも言えるの？
「GUI」に対して
この二つは、先人が不利な環境ですごく頑張った成果が現状なのだ、と思っています。
本質的には関数型プログラミングの強みが活かせる分野のはずです。
「個人の技量の話題」
「レシピ」に関しては、関数型プログラミングのスタイルでは、手続きを手続きとして自然に表現できるのに対し、オブジェクト指向ではできない(DSLチックなものになってしまう)、ということを言いたかったのですが、
わかりにくかったですね。
「書きやすい」
(*)関数の例で、関数型プログラミングの無駄の無さを示せた、と思ったのですが…
マヂですか…反論のためのでっち上げとかじゃなくて(失礼)？(追記: Haskellの方が「短く書ける」、のタイポだそうです)
Haskell布教のために有休とって４時間かけて書いたのにーw
撲滅…
ｼｮﾎﾞｰﾝ(´・ω・｀)
いくつかまとめて反論したい
まず最初に言っておきたいけれども、僕自身はHaskellが大好きな関数型言語大好き人間である、ということを先に述べておきたい、それを踏まえた上で以下をお読みいただきたい
最初の「オブジェクト指向 v.s. 関数型プログラミング」や「ふたつのアプローチの比較」はまあ問題ないかなぁという感じ、問題があれば他の誰かに任せます
問題は「関数型プログラミングの利点」と「関数型プログラミングの得意分野はなにか」
まず「関数型プログラミングの利点」だけれども、ファンクタが云々、モナドが云々、これは「関数型言語の話」ではなく「Haskellの話」である
そこを引いてあくまでHaskellの話だと割りきって見たとしても、「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」？ モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう、パーサの理解にモナドの知識はあまり関係がないと言っても差し支えないのではないか
「書きやすい」に関してはこれはもう「主観の問題だよね」以上の言い様がない、僕自身はC++とHaskellの両方を書く人間で、確かにC++Hakellの方が「短く書ける」と「感じる」ことは多い、がしかしそれはあくまで個人の主観であり、更にはなにか明確な基準を取ったとして、やはりこれは「関数型言語」ではなく「Haskell」の話である、わかりやすく言えば「関数型言語であるLispを僕は読み書きできない」、特定言語の、主観に大きく左右される特徴を関数型言語一般の話であるかのように敷衍して話すのは感心できない
「静的型付け」云々もこれはもう完全にHaskellやOCamlの話である、LispやErlangとは何だったのか
多くの数値計算アルゴリズムは逐次的に定義されている、関数型言語で扱いやすいものではない、簡単にいえば「それFortranの前でも言えるの？」である
遅延評価はこれまたHaskellの特徴であり関数型言語一般の特徴ではないし、別に他の非関数型言語でエミュレートできないものでもない、更に言えばこれが何か数値計算に対して有利な何かをもたらすかといえばそういうわけでもない
「分数や虚数が扱えます」、に至ってはむしろ近頃の言語で扱えない言語何かあるんですか、である、大抵の言語にはその手のライブラリはある、関数型言語に限った話ではない
お前それShellやPerl、RubyやPythonの前でも言えるの？
この手の話は「ライブラリ」の話になり、言語パラダイムにより議論されるべき問題ではない、もちろん自動並列化などの問題で数学モデルに基づいていることが多いHaskellなどは有利かもしれない、が、やはりそれは特定言語や特定のライブラリの話になり、関数型言語一般の話ではない、並行処理の扱いにくい関数型言語の設計など容易だろう
言語の話でも言語パラダイムの話でもライブラリの話でもない、個人の技量の話だろう、関数型言語でも下手にしか書けない人は上手には書けない
GUIライブラリの設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて
最後に要点をまとめると
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
基礎体力を養う意味ではここら辺がいいと思うんですがどうでしょう。
これがわかるとCLRやJVMのインフラ部分もわかりますし、組み込み方面にも強くなります。
C++はマルチパラダイム言語であり、これをひとつやれば構造化プログラミングとオブジェクト指向プログラミングの両方がわかります。
C++はCのほぼ上位互換言語ですので（正しくはC99が制定されるまでは）、プレーンなCしかやらない理由はありません。
嫌なとこも多くある言語で（どうしてEffective C++シリーズやExceptional C++シリーズみたいな書籍が多くでてるか考えるといいよ）、メモリ管理も手動ですが（これは半分嘘。RAIIがあるから半分自動。GCがないから半分手動）、逆に細かいとこに気を配る態度を養うには最適です。
Erlangで並列プログラミングをやるのもいいかもしれません。
Common LispかSchemeで怪しい（でも美しい）世界を爆走するのもいいかもしれません。
これだけやっとけばC#やJava、軽量言語の類はあっさりと料理できるでしょう。
あくまでもプログラミング言語についてはですからね。
I have been working on a programming language, also called Go, for the last 10 years.私は、プログラミング言語にも、移動と呼ばれ、過去10年間のために働いている。 There haveが存在して
been papers published on this and I have a book.された論文は、この上で公開され、私の本がある。
I would appreciate it if google changed the name of this language; as I do not want to have toもしGoogleがこの言語の名前を変更私はそれをお願い申し上げます。私にはしたくない
Comment 1 by dsymonds , Today (7 hours ago) コメント1 dsymondsで 、 今日（7時間前）
References?参考文献？
Comment 2 by fmccabe , Today (7 hours ago) コメント2 fmccabeで 、 今日（7時間前）
If you google (sic) francis mccabe go you will find some references.場合は（）を原文のままGoogleのフランシス、いくつかの参照を見つける行くマッケイブ。
I published the book on lulu.com私lulu.com上の本を出版
Comment 3 by reidellis , Today (4 hours ago) コメント3 reidellisで 、 今日（4時間前）
I think Mr McCabe's language is called "Go!".私は氏マッケイブの言語"と呼ばれてみろ！"。 Here's the Lulu link:ここでは、ルルのリンクです：
http://www.lulu.com/content/paperback-book/lets-go/641689 http://www.lulu.com/content/paperback-book/lets-go/641689
Comment 4 by niral.n95 , Today (3 hours ago) コメント4 niral.n95で 、 今日（3時間前）
reidellis: is right! reidellis：ですね！ its "Lets Go!"その"はLets Go！" or "Go!".や"ゴー！"。 This is google "go", "The Goこれは、"行くに"google、"移動されます
Programming Language" Bigg Difference.. :)プログラミング言語"Biggの違い..：）
Ps Anyone hearing the release of Google "go" would have picked up their book that psの誰""行っても本を手にしてはGoogleのリリース公聴会では
never sold and started finding the work "GO" and as they would find their 1st "GO"販売されなかったとの仕事"Go"を見つけることを始め、などに気づくような、その第一の"Go"
they wil go , Eureka!彼らはエウレカ行くウィル！ :) ：）
Comment 5 by fmccabe , Today (3 hours ago) コメント5 fmccabeで 、 今日（3時間前）
My language is called Go!.自分の言語へと呼ばれます！。 The book is called Let's Go!.本の行こうと呼ばれます！。
The issue is not whether or not Google's go will be well known.問題かどうかは、Googleの移動も呼ばれることもありません。 It is one of fairness.これは1つの公平性の一つです。
Comment 6 by zhenshe41 , Today (3 hours ago) コメント6 zhenshe41で 、 今日（3時間前）
In Go!行くで！ , can the IDE know the differences between Go!は、IDEへの違いを知ることができます！ and go ?行く？
Comment 9 by shirish4you , Today (2 hours ago) コメント9 shirish4youで 、 今日（2時間前）
ah...ああ... Google should change the name... Googleは、名前を変更する必要があります...
Comment 11 by spronkey , Today (2 hours ago) コメント11 spronkeyで 、 今日（2時間前）
Indeed they should.確かにそうあるべきだ。 Full support for you, Mr. McCabe.あなたのためのフルサポート、ミスターマッケイブ。 It's not that hard to findそれを見つけるために、ハードではない
references to your language online either - it was on the first page of Bing, secondあなたの言語のオンラインへの参照のいずれか-それはビンビンの最初のページに2番目だった
of Google for 'go programming language'. Googleの'のために行くのプログラミング言語'。
In fact, the title of the Google go tutorial page is even "Let's Go".実際には、Googleのタイトルのチュートリアルページに行っても"行こう"です。
It would be pretty poor for you folks Google to keep this name given your "do noそれはかなりあなたのための人々 、Googleはこの名が指定さを維持する貧困層になるお客様の"ありませんか
evil" slogan!悪"のスローガン！
Comment 12 by nofakesallowed , Today (2 hours ago) コメント12 nofakesallowed、 今日（2時間前 に ）
Google should totally change the name, fmccabe you should find a (cheap) lawyer just Googleの完全に、あなたは（安い）弁護士を見つける必要がありますだけfmccabeの名前を変更する必要があります
in case...場合には...
Google has deep pockets. Googleの深いポケットにしています。
Comment 13 by nofakesallowed , Today (2 hours ago) コメント13 nofakesallowed、 今日（2時間前 に ）
btw, what's up redditところで、どうしたのreddit
Comment 14 by alex.salkever , Today (2 hours ago) コメント14 alex.salkeverで 、 今日（2時間前）
fmcabe -- could you contact me at alex @ dailyfinance.com? fmcabe -あなたalex@dailyfinance.comで、私に連絡だろうか？ Might want to write a可能性のある記述する
little article about this.このことについて少し記事 Thanks.ありがとう。
Comment 16 by matthew.m.mckenzie , Today (2 hours ago) コメント16 matthew.m.mckenzieで 、 今日（2時間前）
google should change!グーグル変更してください！
Comment 17 by senthil.nayagam , Today (2 hours ago) コメント17 senthil.nayagamで 、 今日（2時間前）
maybe name it Goo or Foo多分グーかはFooという名前を付けます
Comment 18 by mail2ankitgupta , Today (119 minutes ago) コメント18 mail2ankitguptaで 、 今日（119分前）
A company claiming to capture world's info, missed it!!!同社は、世界の情報をキャプチャすると主張し、それを逃した！
Comment 19 by terence.stuart , Today (117 minutes ago) コメント19 terence.stuartで 、 今日（117分前）
Let the language with the most users keep its name.ほとんどのユーザーは、その名前のままにして言語をしましょう。
Er... Erを... That's not yours, is it?それは、あなたではないって？
Comment 20 by blair.briggs , Today (113 minutes ago) コメント20 blair.briggsで 、 今日（113分前）
Go, find a new name.移動し、新しい名前を探します。 ;) ;）
Comment 21 by josecamporro , Today (111 minutes ago) コメント21 josecamporroで 、 今日（111分前）
I agree with majority on this.私はこの上の部分に同意する。 Google should change the name of this language... Googleはこの言語の名前を変更する必要があります...
Francis McCab is right, Go!フランシスMcCabが正しいでGO！ and Go are not that different.と移動の違いはありませんです。 And he went first, public.彼は、公共の最初に行った。
Comment 22 by sebastian.krause , Today (104 minutes ago) コメント22 sebastian.krauseで 、 今日（104分前）
Google should consider a different name simply for the reason that "Go" is just a too Googleはその理由は、"移動"されに別の名前を検討する必要がありますだけでも
common word and it might eventually become difficult to google for references and一般的な単語と、最終的に参照するためにGoogleが困難になる可能性があります
examples about this language.この言語についての例です。 A somewhat more unique name can have its benefits.もう少しユニークな名前は、その利点を持つことができます。
Comment 23 by Afro.Systems , Today (95 minutes ago) コメント23 Afro.Systemsで 、 今日（95分前）
I think lango would be a great name and I am hereby to give away to google any私はランゴすばらしい名前だと思うと私は、ここから何かグーグルに与えるために午前
copyrights for the name.名の著作権。
Comment 24 by ismetdere , Today (94 minutes ago) コメント24 ismetdereで 、 今日（94分前）
Goo, whould be just fine.グー、されるだけで罰金whould。
Comment 25 by QrczakMK , Today (68 minutes ago) コメント25 QrczakMKで 、 今日（68分前）
Goo is already taken too, although it has been dead for a few years I think.ただし、それが思う数年前に死んだがグー、すでにも、撮影されます。
Comment 26 by zak.wilson , Today (68 minutes ago) コメント26 zak.wilsonで 、 今日（68分前）
Goo is the name of a Lisp dialect.具は、Lispの方言の名前です。
Comment 27 by daniel.kolman , Today (67 minutes ago) コメント27 daniel.kolmanで 、 今日（67分前）
Both Google and fmccabe should find a new name, "Go" is silly name for a programming Googleとfmccabe、"Go"をテコな名前にプログラミングされている新しい名前を見つける必要があります
language.言語。
Comment 28 by br...@silcon.com , Today (67 minutes ago) コメント28 brで... silcon.com @、 今日（67分前）
how about GOOP = Google Object Oriented Programming?方法については無神経な人= Googleのオブジェクト指向プログラミング？
mccabe- personally, I agree with you, but while you may be first, and you may beマッケイブ、個人的に、私はあなたと、しかし、中に最初にすることに同意し、することがあります
published, your issue title begs not to take you seriously regardless of your actual公開され、あなたの問題のタイトルを真剣にかかわらず、お客様の実際の場合を取らないように頼む
I do hope this is resolved in your favor though.私はあなたのおかげでも解決されてほしいですか。
Comment 29 by jwb.public , Today (66 minutes ago) コメント29 jwb.publicで 、 今日（66分前）
how about ogle?方法については色目を使う？
Comment 30 by srikumarks , Today (60 minutes ago) コメント30 srikumarksで 、 今日（60分前）
Given that is derives from Limbo, "Bo" would be short and sweet as well.つまり、辺獄から、"ボー"不足しているだろうと甘いだけでなく派生を考える。 They can alsoこれらのこともできます。
use "boroutines" :P "boroutines"：pを使用
Comment 31 by ismetdere , Today (57 minutes ago) コメント31 ismetdereで 、 今日（57分前）
Goo is gone too?具も行ったですか？ damn..気.. what about Goat?何ヤギは？
Comment 32 by killercore , Today (52 minutes ago) コメント32 killercoreで 、 今日（52分前）
I'd go for JAgo: Just Another go私JAgoのために行くだろう：ちょうど別のものへ
Comment 33 by jason.lee.quinn , Today (51 minutes ago) コメント33 jason.lee.quinnで 、 今日（51分前）
Goat Special Editionヤギスペシャルエディション
Comment 34 by nikola.tepper , Today (50 minutes ago) コメント34 nikola.tepperで 、 今日（50分前）
It is completely absurd to use name of an already existing language.それは完全に既存の言語の名前を使用するのはばかげている。 Hey Google,ちょっとGoogleは、
couldn't you, i don't know... 、私を知らない場合が...。 google it?とGoogleの？ Oh right, the name is so generic, that isそう、名ので、つまり、汎用的なもの
almost impossible to get relevant matches.ほとんどの関連性と一致を得ることは不可能。 If this language catches on, it'll be aこの言語にキャッチし、それになります
nightmare to search for problems and solutions.問題と解決策を検索する悪夢のような。
Comment 36 by jsykari , Today (40 minutes ago) コメント36 jsykariで 、 今日（40分前）
May I humbly suggest "go2"? 5私は謙虚に""go2いかがでしょう？
Even C++ got away with naming the language after an esoteric feature of C -- perhapsも、C + +の距離Cの難解な機能の後に、言語の名前付け規則だ-おそらく
naming a language after "goto" isn't that bad. "の後に、後藤は"悪くはない言語のネーミングになります。
Comment 37 by Linnsey , Today (38 minutes ago) コメント37 Linnseyで 、 今日（38分前）
There are so many hobby and specialist programming languages it'd be hard to find aあるので趣味や専門のプログラミング言語でそれを見つけることは難しいですね、多くの
name that's not taken.名は、撮影ではない。
Comment 39 by david.kitchen , Today (32 minutes ago) コメント39 david.kitchenで 、 今日（32分前）
@33 Disturbing but funny... @ 33不穏がおかしい... I can imagine the logo now: 3OE私は今のロゴを想像することができます：3OE
@34 Look at the dates of these things, it would appear that go started around the @これらのものの日程を34歳で見て、その周りを開始へ表示されます
same time that the book was being written (but Go! already existed).同じ時間には、図書（ただし、移動書かれていた！既に存在していた）。 I wouldn't be私ではない
surprised to learn that due diligence was done at the time but simply that since thenは、デューデリジェンスの時間でも行われていた知って驚く人は、単にそれ以来、
it just hadn't been revisited.それだけで再訪されていませんでした。
@36 http://xkcd.com/292/ @ 36 http://xkcd.com/292/
Comment 40 by patla073 , Today (31 minutes ago) コメント40 patla073で 、 今日（31分前）
Why not just name it Golang?理由だけではなく、それGolang名前は？
Erlang - "Ericsson Language"アーラン- "エリクソンの言語"
Golang - "Google Language" Golang - "Googleの言語"
Comment 41 by drc.uvic , Today (31 minutes ago) コメント41 drc.uvic、 今日（31分前 に ）
Does anyone use 'Go!'?誰'移動を使用しますか！'？ If yours is better, or has a decent user base then a name change might be the right thingもしあなたの優れているか、またはその名前の変更は正しいかもしれませんが、まともなユーザーベースを持って
to do.を行う。 If you're bringing it up for academic pride then I don't see why they should have to change anything.もし私はなぜ何も変更する必要がありますが表示されない学問の誇りをのために育てている。
Comment 42 by abouthors , Today (29 minutes ago) コメント42 abouthorsで 、 今日（29分前）
Jago is already taken by a program to play the game of go. Jago既に行くのゲームをプレイするためのプログラムによって行われる。
Comment 44 by charles.majola , Today (18 minutes ago) コメント44 charles.majolaで 、 今日（18分前）
This is issue 9 ......この問題は9 ...... Plan 9..... Plan 9の.....
Coincidence?偶然？
Comment 45 by tuxthelinuxdood , Today (14 minutes ago) コメント45 tuxthelinuxdoodで 、 今日（14分前）
It is obvious that Google employees did not research the name in terms of existingこれは、Google従業員の面では、名前を研究していない明らかにされ、既存の
languages before release.リリース前の言語。 In such a situation I believe Google is at fault and the nameこのような状況では私はGoogle断層の名前ではと考えています
should be changed.変更する必要があります。 I doubt it will happen but it to change it would be in line with "do私はそれが起こるとは思えませんが、それを行となる"を変更するか
no evil".邪悪な"。
Comment 46 by GeoffreyJ.Lee , Today (14 minutes ago) コメント46 GeoffreyJ.Leeで 、 今日（14分前）
How about "Google Go"?方法については"Googleの移動"？
Go2 is pretty clever though, so my vote is on that. Go2かなりかかわらず、僕の投票をするには利口だ。
Comment 47 by roblesjm , Today (9 minutes ago) コメント47 roblesjmで 、 今日（9分前）
Google always releases new products with the prefix "Google". Googleでは常に接頭辞"Googleとの"新製品をリリースします。 In this case, I don'tこの場合、私はしないでください
know if Google want release a new product or make an Alliance like Android.知っている場合、Googleは新製品をリリースしたい、またはするアライアンスのAndroidのような。
In the first case, I would use "GoogleC".最初のケースで、私は"を使用します。GoogleC"。 For the second, something like "GCP" fromについては、2番目の、何か"GCPの"からのような
(Google C Python). （GoogleのĈパイソン）。
Comment 48 by ismetdere , Today (4 minutes ago) コメント48 ismetdereで 、 今日（4分前）
Goat it is...ヤギって... there, settled.そこに定住した。
Comment 49 by Peter.Schweizer , Today (4 minutes ago) コメント49 Peter.Schweizerで 、 今日（4分前）
i'd suggest "giggity giggity goo" as new name since quagmire is a very funny guy私は""新しい名前として泥沼非常に面白いやつなんだからgiggity giggityグーをお勧めしたい
btw.ところで。 hi reddit :)ハイテクしかし：）
Comment 50 by ruivaldo , Today (4 minutes ago) コメント50 ruivaldoで 、 今日（4分前）
"Do" ? ""ですか？ Makes sense, check the purpose of the lang.理にかなっては、langの目的をご確認ください。
何を勉強していいのかわからない。
各言語でHello Worldぐらいは書ける。erlangでハノイの塔を解いた時はこんなに短く書けるのかと感動した。でもいずれの言語もちょっとずつしかかじって無くて、自分がこれから何を勉強していいのかわからない。
Java, C++, Ruby, Python, JavaScript, PHP, erlang, 最初は練習用の問題みたいなのを解いているのが楽しくて、ブログとかで目につく言語で気になったものを選びながら各言語でやってみた。でもこのあと何をしたらいいんだろう？
オブジェクト指向？クラスと違うの？プロトタイプベース？何ソレおいしいの？
こんな僕は何を読んで、何を学べばいいのでしょう。
