「Erlang」を含む日記 RSS

はてなキーワード: Erlangとは

2018-10-26

前はerlangだかelixir分散ストレージ作ってるって言ってなかった?

止めたのかな

筋悪だなあと思ってたから驚きはしないけど

2017-11-10

プログラミング言語自体への興味はものすごく強い方だが

もう色々捨てて残りの人生erlangとrustでいいやと思ったけど

アプリエクステンションていうのかああいうのでpython,luaも要るしな

javascriptも書かんといけないことは多い

ドキュメントはRが絡んでくるし

あんま減ってねえというかむしろrustが増えてるくらいの感じだった・・・

2016-08-09

golang半年近く使ってみて

後なんかweb系の企業golang採用多いので、ある程度詳しくなっておけば就職困らなそうという予防線

今のところが成功しなかったらeurekaとかmercariとか雇ってくれませんか!

どっちもユーザーです!(ペアーズでは3名ぐらい逢った、メルカリではバイクMacbook Air売ったなー。)

ポケモンGoとかやんねーし、地味に自分がよく使っているアプリサービスから成功パターンを得るのがいいのかなぁ

なんか、人との接点がうまくできているCtoCサービスがうまくいっているような感じが(CtoCなんだから当たり前か、何いってんだ)

人とコンバージョンしたいです。

2016-03-25

NPM Dispute Resolutionのテキトー翻訳

誤訳御免。

とりあえず力尽きたので、公開されたメールのやりとり

https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d#.9ae37wmf1

とか、NPMの説明

http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

を読む際の判断材料になれば。

紛争の解決

このドキュメントでは他のnpmを公開している人とのモジュール名の紛争について取るべきステップ記述している。

このドキュメントは"npm行動規範(Code of Conduct)"で説明されている容認可能な行為明確化であり、このドキュメント記載されている内容はnpm行動規範のいかなる側面に対しても矛盾する解釈を与えるものではない。

tl;dr
  1. "npm owner ls <pkgname>"コマンドで作者のメールアドレスを調べる
  2. 作者にメールする。その際"support@npmjs.com"にもCcする
  3. 数週間すぎても解決しない場合、われわれが解決に乗り出す

パッケージ名を不法占拠してはならない。コードを公開するか、さもなくば去るように。

説明

あるユーザモジュールを公開していて、その後、他のユーザがその名前を使いたいと思うケースがしばしばある。ここではよくある例を記述する(個々の例は実際の出来事に基づいている)。

  1. アリスがnodeに特化したわけではない"foo"というJavaScriptモジュールを書いていた。アリスはnodeを使っていなかった。ユースフは"foo"という名前をnodeで使おうと思い、それをnpmモジュールとして作成した。しばらくしてからアリスはnodeを使い始め、彼女プログラム管理権を守ろうとした。
  2. ユースフは"foo"というnpmモジュールを書いて公開した。おそらくだいぶ時間がたった後、アリスが"foo"にバグを見つけて修正した。彼女はユースフにプルリクを送ったがユースフはそれに時間を割く暇がなかった。なぜなら彼は新しい仕事と新しい子供を得、新しいErlangプロジェクトに集中しておりもはやnodeには関与していなかったからだ。アリスは新しい"foo"を公開したかったがその名前はすでに使われているためそれができない。
  3. ユースフ10行のフロー制御ライブラリを書き"foo"という名前でnpmで公開した。単純で小さなものなので、それはまったく更新する必要のないものであった。アリスは非常に高評価世界中販売されている"foo"という名前JavaScriptツールキットフレームワークメーカーであるFoo社で働いている。彼女らはそれをnpmで"foojs"として公開したが、"npm install foo"してナンカチガウと混乱する人が定期的に発生している。
  4. ユースフ業務上必要に迫られよく知られている"foo"というファイル形式のパーサを書いた。そして彼は新しい職を得てその試作品更新していない。アリスがより完璧な"foo"パーサを書いたがユースフの"foo"が邪魔をしてそれを公開できない。

それぞれの状況下でのアリスからクレーム議論されるであろう。しかしそれらのケースでアリスが取るべき適切な段取り共通している。

  1. "npm owner ls foo"する。これによりアリスは所有者(ユースフ)のemailアドレスを知ることができる
  2. アリスはユースフメールして状況を『最大限丁寧に』説明し、モジュール名についてどうしたいのか伝える。彼女はそのメールCCにnpmサポートスタッフ(support@npmjs.com)を加える。またそのメールに"npm owner add alice foo"することにより、アリスを"foo"パッケージの所有者に加えることができることをユースフに伝える。
  3. 十分な時間の経過後、ユースフが返事をしなかったりユースフアリスの間で解決に至らなかった場合サポート(support@npmjs.com)にメールすれば我々が解決に乗り出す(「十分な」とは通常少なくとも4週間だ)。
根拠

これまでのほとんど全てのケースでは、巻き込まれ当事者は重大な介入を要さずに妥当な解決へと到達することができた。多くの人々は本当に合理的になることを望み、おそらく彼らがあなた邪魔をしていることに気付いてすらいない。

モジュールエコシステムはそれらが可能な限り自律的である限り最も活気づいて力強くなる。もし管理者がある日あなたが取り組んでいたものを削除したら、それは理由のいかんにかかわらず多くの人を怒り心頭にさせつつあるのだ。人々が自分らの問題相手との敬意を持った会話により解決すれば、その交流にたいして皆が良い気持ちで終わりを迎えるチャンスを得るだろう。

例外

幾つかの事柄は許されておらず、npmの管理者注意喚起された時点で議論なく削除されるだろう。例えば:

  1. マルウェアインストールした機材の脆弱性を突いたり壊したりするために作られたパッケージ
  2. 著作権ライセンス違反(例えば、MITライセンスプログラムコピーして著作権及びライセンス記述を削除あるいは改変する)
  3. 違法コンテンツ
  4. 将来使おうとしているパッケージ名を「不法占拠」し実際には使わない。申し訳ないがその名前がいかに素晴らしいか、あるいはそれがいつの日か起こるであろう物事完璧フィットしているかどうかは関係ない。もし誰かがそれを今日使いたいと望み、あなたがそのスペースを空のtarball占領していたら、あなたは退去させられるだろう。
  5. パッケージレジストリに置く。パッケージはなんらかの機能を持たなければならない。それは馬鹿げたものであっても構わないが、無であってはならない(不法占拠を参照)
  6. レジストリ個人的アプリケーションデータベースとして使ったり、パッケージ的ではないものを置くなどの変な行為
  7. 下品言葉ポルノハラスメントなどの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/)の元で再利用可能。

2015-02-26

関数型言語使ってる時の気持ちよさは、ベーシックべた書きの頃と同じ

ひょっとすると、これはべたべたな一直線の手続き書き時代以来の「全てが一直線に並ぶ気持ちよさ」なのかもなぁ、と思った。

Haskellなんかを書いてると、究極的に、関数型言語におけるプログラムとは、一引数関数の深い深い一直線の入れ子みたいに感じられる。

(いやまぁ、タプルとかもあるけど、原則的に)

構造化⇒OOPと来て、プログラミング言語Go to hellを廃し、色んな物をDRYに書けるように進化してきたけど、その結果色々なものが並列にばらばらっと並んでいる感じになった。

OOP大本smalltalkメッセージパッシング原則の時点で、対等な二つの並列に並んだオブジェクトのやりとりがベースになっている。

勿論オブジェクトは大体内部に別のオブジェクトを抱えていたりして、親子関係があるのは普通だけれど、子同士はやはり並列に順序なく並んでいる。

この並列性のおかげで、例えばそれこそメッセージパッシングをそのまま引き継ぐErlangなんかは、高いスケーラビリティと耐久性を持つわけで、これ自体は素晴らしい発明だ。

ただ、やっぱり並列なヤツラが、ごちゃごちゃっと同時にあって、そいつらが同時にガチャガチャなんかやってたら、神の見えざる手的に、なんとなく全てが上手く噛み合って、プログラムが動きます、って、これどうしても全体像を把握しにくい。

人間脳みそって、そんな同時並列のものを把握できるようには、出来ていないんだと思う。

上手く動いてはいるんだけど、何で上手く行ってるのか分かるんだけど、分かりにくい。

この気持ち悪さが、今日もどこかのITおじさんを全部staticな書き方に走らせ、OOPわかんねー、と首をかしげながら、何となく使ってる人達の心を、巨大なメソッド作りに導いているのではないかな、と。

なんてったって、Scalaなら並列処理でさえ、モナドなFutureで事実上直線に繋いでいってかいちゃう(Akkaもあるけどあれはオブジェクティブな側面なので)わけで、これは凄く懐かし気持ちいいと思う。

かくして関数型言語は「なんかとにかくきもちいいぃぃぃぃ」な信者を量産している。そしてOOP派との間に、意味分からん溝だけが広がっていく。

2014-04-22

サーバーエンジニア? には何年ぐらいでなれるの?

俺はずーーーーとWindowsアプリを作ってきた。

iアプリとか、iOSとかAndroidアプリも作った。

大体20年ぐらいクライアント側のアプリをずっと作ってきたおっさんだけど、ここ1年ほど前にサーバー側に移った。

今までずっとWindowsで作ってきたから、何もかも新しいことばかり。

Macで開発するようになって、SSHTMUXも覚えた。

LinuxFreeBSDのどっちがいいかわからないからCentOSFreeBSDの両方で開発している。

Shellスクリプトもちょこっとわかるようになった。

今は主にErlangで0から開発した数十台に分散して動くサーバー運用している。

言語を覚えるのは苦ではなくて色んな言語を使うことができるけど、OSはなんだか別な感じがする。

今日FreeBSDOpenSSLアップデートをしたらサーバーに繋がらなくなって、なんかpsshとかも動かないし、もうわけわからなくて全部再インストールすることにした。

からないなりにいろいろ頑張って実際にサーバー運用しているけど、知識の足りなさを実感している。

俺はもう40代から、やっぱり脳みそがだめなのかなぁ、とか思いながら今自棄酒飲んでいるところ。

今、第一線で活躍している人はだいたい何年ぐらいでまともに”使える”ようになったんだろうか?

教えてほしい。

2014-04-10

http://anond.hatelabo.jp/20140410134501

id:minamiyama1994 さん、反論してくださってありがとうございます

Haskellファンのご意見がいただけて嬉しいです。元増田です。

記事全体で「関数型言語」と呼ばれているものは「関数型言語一般」ではなく「Haskellや一部OCamlの話題を含むごくごく一部の言語」の話である

わかりにくくてすいません。記事では「関数型言語」の話はしていません。「関数型プログラミング」の話をしました。

関数型言語」は範囲がよりボンヤリとした表現です。たとえばC言語関数型言語かどうかをみても賛否両論にわかれるでしょう。

私が記事を書いた目的は、”関数型プログラミングに縁のない人に関数型プログラミングをわかりやすく紹介したい”でした。

その目的のため、「関数型言語」という表記を注意深くとり除き、代わりに「関数型プログラミングサポートした言語」という言い方をしています

このスタンスの上で、

関数型プログラミングをフルにサポートした言語”の代表として、Haskellを紹介し、

関数型プログラミングへのサポート片手落ち言語”として、LispErlangなどを扱いました(それらのファンの皆、ごめんなさい)。

言語パラダイムの話題」と「言語の話題」と「ライブラリの話題」と... を混同している

関数型プログラミング初心者の方は、それらの差異なんてどうでもよい、と考えるのではないでしょうか。

関数型プログラミングとは何が良いのか、を大雑把に知りたい。

そうなのではと考えて、あえて区別せずに記事を書きました。

「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」? モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリ設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう

id:minamiyama1994 さんの仰るとおり、モナドはパーサー以外の多くの応用があります

現状多くのパーサーがモナディックパーサーとして書かれていますモナディックでないパーサーは、あまり多くのユーザーには使われないでしょう。

モナドなどの抽象的な構造が幅を利かせてるお陰で、ライブラリに秩序が生まれ、ユーザーはそれを使いやすく・読みやすくなっている、というのが私の言いたかった主張です。

(なお細かいことで恐縮ですが、ある種のモナディックパーサーはApplicativeでは書けません。その点をお忘れですよ)

テキスト処理」に対して

お前それShellやPerlRubyPythonの前でも言えるの?

GUI」に対して

GUIライブラリ設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて

この二つは、先人が不利な環境ですごく頑張った成果が現状なのだ、と思っています

本質的には関数型プログラミングの強みが活かせる分野のはずです。

「個人の技量の話題」

レシピ」に関しては、関数型プログラミングスタイルでは、手続きを手続きとして自然表現できるのに対し、オブジェクト指向ではできない(DSLチックなものになってしまう)、ということを言いたかったのですが、

わかりにくかったですね。

「書きやすい」

(*)関数の例で、関数型プログラミング無駄の無さを示せた、と思ったのですが…

僕自身はC++Haskellの両方を書く人間で、確かにC++の方が「短く書ける」と「感じる」ことは多い

マヂですか…反論のためのでっち上げとかじゃなくて(失礼)?(追記: Haskellの方が「短く書ける」、のタイポだそうです)

記事そのもの価値基本的にないっぽい、こういう記事撲滅されないかなぁ

Haskell布教のために有休とって4時間かけて書いたのにーw

撲滅…

ショボーン(´・ω・`)

http://anond.hatelabo.jp/20140409010816

いくつかまとめて反論したい

まず最初に言っておきたいけれども、僕自身はHaskellが大好きな関数型言語大好き人間である、ということを先に述べておきたい、それを踏まえた上で以下をお読みいただきたい

最初の「オブジェクト指向 v.s. 関数型プログラミング」や「ふたつのアプローチ比較」はまあ問題ないかなぁという感じ、問題があれば他の誰かに任せます

問題は「関数型プログラミングの利点」と「関数型プログラミングの得意分野はなにか」

関数型プログラミングの利点」に対して

まず「関数型プログラミングの利点」だけれども、ファンクタが云々、モナドが云々、これは「関数型言語の話」ではなく「Haskellの話」である

そこを引いてあくまでHaskellの話だと割りきって見たとしても、「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」? モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリ設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう、パーサの理解モナドの知識はあまり関係がないと言っても差し支えないのではないか

「書きやすい」に対して

「書きやすい」に関してはこれはもう「主観の問題だよね」以上の言い様がない、僕自身はC++Haskellの両方を書く人間で、確かにC++Hakellの方が「短く書ける」と「感じる」ことは多い、がしかしそれはあくまで個人の主観であり、更にはなにか明確な基準を取ったとして、やはりこれは「関数型言語」ではなく「Haskell」の話である、わかりやすく言えば「関数型言語であるLispを僕は読み書きできない」、特定言語の、主観に大きく左右される特徴を関数型言語一般の話であるかのように敷衍して話すのは感心できない

「静的型付け云々」に対して

「静的型付け」云々もこれはもう完全にHaskellOCamlの話であるLispErlangとは何だったのか

関数型プログラミングの得意分野はなにか」に対して

数値計算」に対して

多くの数値計算アルゴリズム逐次的に定義されている、関数型言語で扱いやすものではない、簡単にいえば「それFortranの前でも言えるの?」である

遅延評価はこれまたHaskellの特徴であり関数型言語一般の特徴ではないし、別に他の非関数型言語エミュレートできないものでもない、更に言えばこれが何か数値計算に対して有利な何かをもたらすかといえばそういうわけでもない

分数虚数が扱えます」、に至ってはむしろ近頃の言語で扱えない言語何かあるんですか、である、大抵の言語にはその手のライブラリはある、関数型言語に限った話ではない

テキスト処理」に対して

お前それShellやPerlRubyPythonの前でも言えるの?

「並行処理」に対して

この手の話は「ライブラリ」の話になり、言語パラダイムにより議論されるべき問題ではない、もちろん自動並列化などの問題で数学モデルに基づいていることが多いHaskellなどは有利かもしれない、が、やはりそれは特定言語特定ライブラリの話になり、関数型言語一般の話ではない、並行処理の扱いにくい関数型言語設計など容易だろう

レシピ」に対して

言語の話でも言語パラダイムの話でもライブラリの話でもない、個人の技量の話だろう、関数型言語でも下手にしか書けない人は上手には書けない

GUI」に対して

GUIライブラリ設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて

まとめ

最後に要点をまとめると

記事そのもの価値基本的にないっぽい、こういう記事撲滅されないかなぁ

2011-12-12

コンピュータプログラミング概念技法モデル」の目次

第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 練習問題

2011-01-16

http://anond.hatelabo.jp/20110115234607

コンピュータがコアスキルってのもよしあしで、コンピュータってのは合理化の権化なので、自分達で自分達の仕事をどんどん減らすのが良い技術者なんですよ。行き着く先は市場飽和だとわかってて、それでもやるの?って話なわけですが…。

# いや、好きだからいいんですけどね。

別のコンピテンシがありながら、道具としてコンピュータを使いこなす方は尊敬します。数学的な抽象モデルの取り扱いが得意なら、周りを説得してScalaとかErlangとかの関数型言語に走るとか、RとかMATLABとかの専用言語に走るとかしたほうが、むしろ差別化は容易かもしれません。

はいえ、仕事となるとなかなかそうも行かないんですけどね。

2010-05-05

情報学部の新入生にはアセンブラC++関数型言語(何がいいかまでは知らないけど)やらせりゃいいと思う

基礎体力を養う意味ではここら辺がいいと思うんですがどうでしょう

アセンブラコンピュータの基礎を理解するには必須でしょう。

これがわかるとCLRJVMインフラ部分もわかりますし、組み込み方面にも強くなります。

後にOSコンパイラ勉強するにも役立つでしょう。

C++マルチパラダイム言語であり、これをひとつやれば構造プログラミングオブジェクト指向プログラミングの両方がわかります。

C++はCのほぼ上位互換言語ですので(正しくはC99が制定されるまでは)、プレーンなCしかやらない理由はありません。

最初ベターCとして始めればいいです。

嫌なとこも多くある言語で(どうしてEffective C++シリーズやExceptional C++シリーズみたいな書籍が多くでてるか考えるといいよ)、メモリ管理も手動ですが(これは半分嘘。RAIIがあるから半分自動GCがないから半分手動)、逆に細かいとこに気を配る態度を養うには最適です。

関数型言語は新しい世界を知るために勉強しましょう。

Erlangで並列プログラミングをやるのもいいかもしれません。

Common LispSchemeで怪しい(でも美しい)世界を爆走するのもいいかもしれません。

MLHaskellが最も現代的ですかね。

これだけやっとけばC#Java、軽量言語の類はあっさりと料理できるでしょう。

あくまでもプログラミング言語についてはですからね。

アルゴリズム離散数学もちゃんとやってくださいね。

システム屋になりたきゃソフトウェア工学経済学経営学、ついでにナンパもちゃんとしなきゃダメですよ。

2009-11-11

http://translate.google.com/translate?hl=ja&u=http%3A%2F%2Fcode.google.com%2Fp%2Fgo%2Fissues%2Fdetail%3Fid%3D9

fmccabeで、 今日(7時間前)報告

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がこの言語名前を変更私はそれをお願い申し上げます。私にはしたくない

change my language!私の言語を変更!

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公開され、あなたの問題のタイトル真剣にかかわらず、お客様の実際の場合を取らないように頼む

stature.身長

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の目的をご確認ください。

2009-10-29

彼氏Erlang使ってた。別れたい…

Erlangだと軽量プロセスで並行処理された時なんか恥ずかしいww

^C + a しちゃうしww

男にはせめて普通スレッド起動して欲しい・・・

gen_serverとかに一部の処理を任せたら・・・・もう最悪ww

せめて普通にフォークピースレッドぐらいは使って欲しい。

常識的に考えて欲しいだけなんです!

軽量プロセスを起動された時の恥ずかしさとか分かる?

あのね?たとえば一ヶ月10??20万人ぐらいがサーバアクセスするでしょ?

それぞれ相応の速度が出ていれば満足じゃない?

だからみんな普通にピーヘッチピーやパールルビーパイソンでサーバ処理するでしょ?

ErlangでErlyWebなんて使ってたら大恥かくでしょうがww

2009-02-23

何を勉強していいのかわからない。

何を勉強していいのかわからない。

プログラムというものに興味を持ち、独学で勉強した。

言語Hello Worldぐらいは書ける。erlangハノイの塔を解いた時はこんなに短く書けるのかと感動した。でもいずれの言語もちょっとずつしかかじって無くて、自分がこれから何を勉強していいのかわからない。

Java, C++, Ruby, Python, JavaScript, PHP, erlang, 最初は練習用の問題みたいなのを解いているのが楽しくて、ブログとかで目につく言語で気になったものを選びながら各言語でやってみた。でもこのあと何をしたらいいんだろう?

オブジェクト指向クラスと違うの?プロトタイプベース?何ソレおいしいの?

こんな僕は何を読んで、何を学べばいいのでしょう。

2008-11-11

彼氏php使ってた。別れたい…

phpだと、うっかりエラー表示出た時なんか恥ずかしいww

下向いちゃうしww

男にはせめてPython使って欲しい・・・

strip_tagsとかでサニタイズなんてされたら・・・・もう最悪ww

あとせめてphpでも普通にClassぐらいは作って欲しい。

常識的に考えて欲しいだけなんです!

phpできます!」なんて自信たっぷりに言われた時の恥ずかしさとか分かる?

あのね? たとえば週末1020人ぐらいで勉強会とかするでしょ?

それぞれ作ったwebアプリ公開するわけじゃない?

みんな普通にDやSchemeErlangHaskellで構築するわけでしょ

PHPで自慢げに公開したら大恥かくでしょうがww

http://anond.hatelabo.jp/20081111000645





(関連リンク)
今年ぼくが書いたはてな匿名ダイアリーまとめ - ぼくはまちちゃん!(Hatena)
ドリームメーカー : ブラウザで簡単にノベルゲームが作成できるWebサイト
ソーシャルゲーム速報

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん