Joy: Forth の関数なイトコ - 言語ゲーム
Manfred von Thun 著、第17回 EuroForth 会議にて発表(2001 年 11 月 23 - 26 日、ドイツ、ザールブリュッケン、ダグストル城) Reuben Thomas による代理発表。 Joy 言語概要 Joy 言語は純粋関数型言語です。他の関数型言語では、関数に引数を適用する事が基礎になっていますが、Joy の基礎は関数合成です。Joy の全ての関数はスタックを引数として、結果のスタックを生成します。結果的には、Joy はただの普通の後置記法に見えますが、Joy の関数はスタックからいくつでも引数を取り、スタックにいくつでも結果を残します。正しく結合されたプログラムは、プログラムを意味する関数の合成を意味します。Joy のデータ型にはクォートされたプログラムがあり、リストは単にそれの特別なケースとなっています。ある関数はクォートされたプログラムがスタックの先
QCon 2016 Tokyo http://www.qcontokyo.com/ メモ - 言語ゲーム
メモしました。風邪を引いてビアバッシュ行けなかった。 エンジニアリングの物語り 人に語るに値するカルチャー Pete Sodering 氏 企業文化を作り上げるために物語が一番手っ取り早いという話を例を上げて解説。物語が企業の実際の歴史だとすると、文化を意図的に作り上げる事は出来ないのでは無いかという気がした。 企業文化とは? 意見の差異を解決したり、問題を解決する能力。 多様性とか、コードの重視とか、OSS のサポートととか、リモートワークの推奨とか、卓球台とか、犬とか、、、 企業文化には犠牲にする物がある。トレードオフを伝えるには「物語」が一番良い。 本の紹介 『Sapiens - a Brief History of Humankind』 : Yuval Noah Harari Twilio (Telephony) の例 Twilio の CEO はプログラマ。エンジニアは Twil
タイルスクリプト進捗 - 言語ゲーム
今日は大島さんの赤ちゃんに会う事が出来ました。ちっこくて可愛かったです。 さておき、煮詰まってきたところで進捗を纏める。最大の問題点は、論文でタイルスクリプトは初心者に簡単と書いてあるのに、このタイルスクリプトは全然簡単では無いという点。その原因は、etoys や scratch のスクリプトが何故簡単なのかの分析が足りて無いからなので、それについてまず考える。 何故 etoys が簡単なのか。 etoys の売り文句は、どのようにタイルをドラッグしても文法エラーになる組み合わせが発生しないという点だ。エラーを起こさないために次の工夫がしてある。 型チェック: etoys は文字列、数値、色、などなど細かい型が沢山あって、間違った場所にタイルが入らないようになっている。 単純な文法と構文チェック: etoys には、数値や文字列等の値と、コマンドや代入などの文(行)の違いがあって、数値を文
Logic Machines and Diagrams isbn:0226282449 全体的感想 - 言語ゲーム
素晴らしい本すぎてどこから書いていいやら分からない！とりあえずメモ 論理機械の歴史概観 前4C: アリストテレスの論理学。次の四つの型を組み合わせる。 A : all S is P (universal affirmative) E : no S is P (universal negative) I : some S is P (particular affirmative) O : some S is not P (particular negative) 13C ルルスの円盤。ただの組み合わせ。 1772 オイラーが初めて論理を図形的に解釈。 1779 Stanphope の Demonstrator。 アリストテレスの機械的解釈。二つのカードが重なっている大きさで論理が繋がっているか知る単純な仕組みだが、数量的な論理も扱える。 1854 ブール代数。ブールは OR の代わりに XO
意思決定 - 言語ゲーム
意思決定とやらを上手く可視化出来なくて困っている。個人的な事柄から仕事で必要な物まで、意思決定の必要な事が沢山ある。引越をするべきか、するとしたらどこが良いか、予算はいくらか? こういった決定の一つ一つについて、納得行く決定という物は無く、大抵前はこうだったからとか、どうでも良い理由で決めてしまっている。これでは困る。 理想は意思決定に必要な目の前に情報が揃っていて、しかもそれはグラフみたいな目に美しく頭に優しい形式で、しかも本当の事が書いてあると望ましい。現実はグラフがあったとしてもドレイクの方程式程度の目安にしかならないのかも知れない。しかしいくらあやふやな前提であっても、可視化されているのとそうでないのでは違う。判断の材料として「あやふやさ」も大切な指針だ。 そんな事を考えつつ「意思決定」で検索してみると、ハーバート・サイモンという人が色々研究してるとわかった。特に限定合理性というの
空間上の計算の木 - 言語ゲーム
今、『結び目理論とゲーム』という本を読んでいる。 ふと、思い付いたんだけど、計算は木で表現出来る。計算式をパースして文法木に出来るだけじゃなくて、それぞれの値や演算子をさらに細かく分解して結合子で表現すると、枝ぶりだけで計算を表現出来る。 計算では同じ枝ぶりの枝は一つの物だとみなす事が出来るので、同じ枝ぶりを纏めてしまうと木では無く三次元の有向グラフになる。 三次元では前後の関係が生まれる。計算では枝ぶり(依存関係)だけが問題になるので前後関係には意味がないのだけど、前後関係に意味をもたせると同じグラフかどうかを見極めるためには結び目理論が必要になる。計算の木で前後関係に意味を持たせて何か面白い事はあるだろうか?
テキストエディタの数学的表現を探す - 言語ゲーム
昨日眠れなくてずっと布団の中で考えていたメモです。意味と実装という言葉がよくプログラミングの中で使われます。意味は二つのオブジェクトの間の関係を表していて、例えばテキストエディタで言うとテキストデータと実際に表示されるビットマップとの間にはある種の関係の事で、例えば横 80 桁固定のテキストエディタだとすると、 文字列が必ず横 80 文字で折り返す、とか、 A のフォントはこれこれこういう形である。 とか、宣言的に書く事が出来ます。また、実装とは、その関係をコンピュータ上で実行するために必要なプログラムの事を言います。例えばキーボードから A が押された時に、 バッファに A を挿入する。 入力位置のテキストを書き換える。 もしも入力位置のテキストが80文字を越えていたらそこから下全部書き換える。 などと、操作的に書く事が出来ます。問題は、意味から実装を機械的に作る事は出来ないのだろうか？
Smalltalk 式イメージベース開発環境の欠点とその解決方法、開発環境の意味論。 - 言語ゲーム
ここ半年ほど考えていた問題に解決の糸口が見えたのでメモ。主要なプログラミングのスタイルには二通りあります。一つはソースコード式、もう一つはイメージ式です。 ソースコード式は普通にソースコードを書いてから実行する方法です。イメージ式というのは馴染みが薄いですが、プログラムと開発環境が一体になっていて、プログラムを動かしながら動的にプログラムを変更して行きます。作業が一段落すると現在の作業内容をイメージファイルという大きなファイルに書き出して作業を終えます。プログラムの配布にはイメージファイルをそのまま使います。これは Smalltalk で使われる方法で、LISP でも似たような機能があります。 Smalltalk でプログラムを書いた事が無い人は、ずーっとデバッガを実行しっぱなしで、しかもソースコードをいつでも書き換えられる状況を想像すると良いです。この方式の良い所は、プログラムの生きた振
Chalkboard のトレードオフ。アクティブエッセイ用のツールについて(3) - 言語ゲーム
某締め切りの関係で、不本意ながらソースコードも書かず文章ばかり手をかけています。ようするに、こういうのを訳して文体を変えて latex に貼付けるわけです。 前提として、プログラミング言語が高度に発達した将来。人々はプログラミング言語を日常的に書き、語り合う事になるというのを想定しています。機械が自然言語を理解するのでも無く、人間が機械に合わせるのでもなく、両者が歩み寄った形の言語が生まれるでしょう。おそらく 50 年ぐらい未来の話です。私にそのような言語は想像出来ませんが、そんな世界の紙と鉛筆はどうあるべきかというのを今現在の技術で試してみようというわけです。 という戯言はおいといて、デザイン上のトレードオフについて書いてみます。というのも、こういうのを見せると、こんな風に画面のこの位置がこんな風に役割が固定されてあるのが嫌だとか、もっと画面を自由に使って自由にズーム出来るのが良いとか、
線形論理とコンピュータ革命 - 言語ゲーム
週末は Linear Logic and Permutation Stack -- The Forth Shall Be First http://home.pipeline.com/~hbaker1/ForthStack.html 読んでいた。思ったのは、線形論理が私の人生の疑問の半分くらいを解決するだろうという事。そしてアランさんの言うコンピュータ革命とはこういう事なのかも知れないという事。 身分不相応にも未来を予測してみる。近い将来、小学校で習う算数は線形論理に基づいた物になる。未来の子供達は、カッコや優先順位や変数に悩まされる私達の数学を見て、何て野蛮で非能率なのだと言うだろう。まるで我々が漢数字やローマ数字の数学を、きわめて技巧的で非論理的だと思うように。 線形論理に基づくプログラミングとは、変数の使用を一度しか認めないプログラミングの事を言う。一度しか認めなくてプログラムなんか
ぼくのかんがえた最強の?マネージャ - 言語ゲーム
半年くらい前からソフトウェア業界のマネージャをやってます。 マネージャってどういう仕事かというと、お客さんの言うことを聞いて見積もりを立ててスケジュールを立てて開発者を集めて期限を交渉して終わらせます。コードは書きません。一昔前だと Excel とパワポを駆使するのが仕事でしたが、今は Redmine とか JIRA とか言う Web ツールを使って仕事がどこまで進んだかを確認します。結構これが辛い。 実は僕が前十年ほど前に一度サラリーマンを辞めたのは、マネージャと言う仕事があまりにもくだらなかったからです。プロジェクトをぐいぐいと引っ張って良い製品を作るお仕事が出来ればやりがいがあると思いますが、実態は営業がついた嘘の尻拭いをして誤魔化したり謝るのがお仕事です。なので、今の会社に入ってからも、企画とか、開発リーダーはします。でもマネージャはしません。マネージャはしません。マネージャはしま
Smalltalk のクラスと Haskell の型クラスを比較します。 - 言語ゲーム
私は Haskell の一番すごい所は型クラスだと思っているんですが、ここ数日それを言葉にしようとずっと悩んでいました。結局、もう一つの好きな言語なSmalltalk と比較して型クラスがどういう物か書いてみる事にしました。 型クラスという名前について Smalltalk に染まってしまった人にとって、「型クラス」というのは最悪なネーミングです。あまりにも Smalltalk のクラスと違いすぎるからです。機能的には traits や Java のインタフェースから継承を除いた物と思ったら良いです。また、「継承」や「インスタンス」など、Smalltalk と Haskell 両方で使われる言葉はことごとく別ものと思った方が良いです。 型クラスの位置づけ Smalltalk をはじめとするオブジェクト指向言語の機能をそのまま Haskell で実現しようとすると最初はすごく戸惑います。日本語
prolog Verilog HDL で 3 4 - 言語ゲーム
図書館で HDL の教科書を読むと、ハードウェア記述言語というのはある意味マルチパラダイム言語だという事がわかった。と言うのも、ハードから近い順に次のような書き方を全部サポートしているのだ。 構造（Structure）記述 : 回路図をそのまま文字にしただけ データフロー（Dataflow）記述 : 数式のレベルで書ける 機能（Behavior）記述 : 副作用のある代入や、制御構造が使える。 こ、これは面白い！どこが面白いかと言うと、この Structure, Dataflow, Behavior というのは、プログラミング言語で言うと、論理型言語、関数型言語、手続き型言語に対応している。しかもこの順序は、実装から遠いと思っていた順だ。つまり、普通手続き型言語が一番機械語に近くて、論理型言語が一番遠くて実装がややこしい。しかし、ハードの世界になると逆転して、実は論理型が一番メカに近くて、
屠殺とオープンソース - 言語ゲーム
僕はソフトウェアの利用者から直接お金を受け取る事に強い抵抗があります。ソフトウェアを作る事は理想を実現する為のボランティア精神に基づいた聖的な事なので、大体オープンソースにしています。そこから直接利益を得るなんて汚らわしいのです。たぶん同じように思ってる人は沢山いると思います。 だけどオープンソースというのはソースコードについての用語であり、金銭についてどうこう言う物ではありません。だからお金を受け取る事の気持ち悪さはオープンソースの精神とは関係ないと言えます。お金を受け取る気持ち悪さは、むしろ屠殺の気持ち悪さと似ています。 要するにお金を受け取らないソフトウェア作者というのは、釣りに行って魚を逃がした帰りに寿司屋に行く感覚なのです。 私達の社会は分業化が進んでいるので、直接牛を殺さなくても牛肉を食べる事が出来ます。直接牛を殺す経験が無いので、生物を殺す事によって起こる感情を感じずにすみ、
今城町モスバーガーにて - 言語ゲーム
久しぶりに実家で夏を過ごしている。 本当は一週間夏休みを取る予定だったが、仕事が間に合わず明日の朝東京に戻らなくてはならない。実家にはまだ自分の部屋があって昔貰ったり書いたりした物が沢山あるので色々反省する気分になってしまう。 去年の末に日本に帰ってきた時は、毎日残業をするような社畜生活は自分には絶対無理だ!と思っていたけど、案外何とかなっている。少しの間毎晩8時には家に帰れる時があったが、そうなると逆に落ち着かなくて余った時間家で何をしたら良いものかと悩んだ。というわけで最近は、だいたい勤務時間 10:00 - 22:00 というのが標準だ。ちなみに、LA に居た頃は 10:00 - 17:00 だった。。。 まだ入社一年目なので仕方が無いけど、これは良くない。勤務時間が 5 時間伸びた分生産性が上がるわけが無く。むしろ今までの心の余裕が無くなって新しい事にチャレンジする気力が失われるん
API Design Matters http://queue.acm.org/detail.cfm?id=1255422 - 言語ゲーム
http://d.hatena.ne.jp/oraccha/20090606/1244225100 経由で。 C# の Select() 関数についてひとしきり文句を書いた後に、実際良い API を作るコツを挙げている。 API は必要な機能を備えろ タイムアウトが 35 分以内で無ければならないとか、微妙な制限があってはならない。 API は不便を感じない限り出来るだけ小さく 例えば UNIX で wait, waitpid, wait3 wait4 と色々あるのはやり過ぎ。wait4 だけでよい。微妙に似た関数が沢山あって、一つの一般的な関数で他の奴が実装出来ない作りになってるのが最悪なパターン。 文脈なくして API なし キーから辞書を引いて文字列を返す関数を考える。キーに対応する文字列が無かった時、次のやり方があるだろう。 例外発生 null を返す 空文字列を返す どれが正しい
なぜポイントフリースタイル = コンビネータが重要なのか - 言語ゲーム
「Joy: Forth の関数なイトコ」 http://d.hatena.ne.jp/propella/20070517/p1 をちゃんとアップしてからとも思ったんだけど、書く勢いが無くなる前に書きます。私が http://www.latrobe.edu.au/philosophy/phimvt/joy/forth-joy.html を読んで超感動したのは最後の Joy Algebra の章です。なぜ感動したかと言うと、メタファを適切に選ぶ事によってこんなに話が単純になるのか！という事を思い知らされたからです。そして、コンビネータがどれだけこれからのプログラミングで重要になるか確信が持てたからです。順を追ってのちゃんとした説明は、もうちょっと勉強してからじゃないと書けないけど、頭の中にある気持ちだけ書きます。 25年前に私がプログラミングを始めた頃、マイコンハッカーは機械語で書いていました
Reactive Programming の事をつらつら書く。 - 言語ゲーム
最近再び Functional Reactive Programming (FRP) について調べているのでまとまり無くメモする。まず大まかな言葉の意味については http://en.wikipedia.org/wiki/Reactive_programming から辿るのが良いと思う。簡単に言うと、FRP とはスプレッドシートの計算モデルを拡張したライブラリや言語、プログラミング技術の事を言う。Function という言葉は付いていたり付いていなかったりするけど、Reactive Programming は副作用を制限する手法なので、どの手法も多かれ少なかれ関数的に使う。 FRP はかなり大雑把に使われる言葉なので人に説明するのが難しい。だけどよく似た粒度の言葉としてはコレクションライブラリくらいが丁度良いと思う。関数プログラミングや論理プログラミングのような大げさな言葉では無い。APL
アリゲーター・エッグでラムダ計算 - 言語ゲーム
計算の本質は何でしょうか？計算には、足し算引き算掛け算と色々あります。さらに因数分解や微分積分など、計算の種類を挙げればきりがありません。しかし、いくら沢山のルールを沢山覚えても、それで計算の本質を分かった事はなりません。ここで視点を逆転して、より難しい計算ではなく、より単純な計算について考えてみる事にします。 面白いことに、どんな複雑な計算も単純な計算の組み合わせで出来ています。掛け算は足し算の組み合わせですし、引き算は足し算を逆にしたものです。さらに、足し算よりもさらに単純な計算を考える事は出来るでしょうか？昔から沢山の数学者がこのパズルに挑戦し、沢山のモデルが生まれました。今日ご紹介するラムダ計算もその一種です。ラムダ計算は非常に単純な計算モデルですが、単純すぎて計算過程を追うのが難しいです。そこで、アニメーションを使うと仕組みがわかりやすいのでは無いかと考えました(Firefox,
税とオンライン広告とラッファー曲線 - 言語ゲーム
最近またマンキューの教科書を読んでいます。ミクロ編の Principles of Microeconomics isbn:0538453044 で税金についてなかなか面白い事が書いてあるのでメモします。 まず需要供給曲線について復習。需要供給曲線というのは、生産者と消費者がそれぞれ自分のトクになるように市場で振る舞うと、結局みんなにとって一番トクな値段に落ち着くという事を示した物です。それぞれお互いが得した量を余剰 (surplus) と呼びます。特に消費者が得した分を消費者余剰 (consumer surplus) 生産者の分を生産者余剰 (producer surplus) と呼びます。例えばなぜ消費者がトクするかというと、ある値段に決まったときには、本当はもっと出せるのに意外と安かった！と思う人がいるからです(図の赤い部分)。生産者の場合は、本当はもっと安く売れるのに意外と高く売れた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
