ホワット・ア・ワンダフル・ワールド 人間が情報を与えるか，機械が推論して情報を増やすかという違い
型宣言と型推論とか，手動メモリ管理と GC とか，要するに全部，人間が手で情報を与えるか，機械が推論するかということに一般化できると思う． んでまぁ，一般にうれしいのは，最初のプロトタイプは人間が不必要なことまで考えなくても動いてくれて，後々必要になってきたらボトルネック部分に情報を追加してあげると，さらに最適なコードが出る，ということをインクリメンタルにやっていけるようなモデルだと思う． その点，手続き型言語ってのは，細かいところまでを最初からいきなり全部指定しないといけないから，人間の脳に対する負荷がデカいし，柔軟性も失われてしまうし，機械がプログラムの意味を変えないで最適化できる余地も無くなってしまう．というようなことは，これまでにも散々書いてきたことなので，まぁ良いとして． いろいろ気になった記事があったので，単なるメモ． lethevert is a programmer のコメ
ホワット・ア・ワンダフル・ワールド 東京行ってきました
Author:あろは (alohakun) WAKATSUKI toshihiro デバッガ開発者見習い（予定） 連絡先 : alohakun ___at___ gmail.com mixi : http://mixi.jp/show_friend.pl?id=182927 twitter : http://twitter.com/alohakun このページはインラインフレームを使用しています 1 日目の中野サンプラザの Linux ジャンボリーはかなり面白かったです．みんな本当に技術が好きなんだな〜 っていう kernel ハック上等な技術者ばかりが集まりワイワイやってる感じ．QLeap さんの会社の同僚の方 （40 代なのにメチャクチャ若々しい．やっぱり純粋な技術者 ? はいつまでも少年なのかな） の口癖 ? の 「んー，なんていうのかな」 が伝染ってしまいました （笑）ミラクルの
ホワット・ア・ワンダフル・ワールド ET Q&A
問い詰める会 wiki の方で質問されて （私の不勉強により） うまく答えられなかったことを，研究室の M 先輩を問い詰めて （笑） いろいろ教えていただいたので，ちょっとまとめてみます． たぶん Web 上での議論には限界があるので （また収集がつかなくなる），さらなる疑問点などは，問い詰める会などでよろしくお願いします．コメント欄などに質問をオープンな形でメモするぶんには大歓迎です （レスはあまり期待しないでください） (免責 : これは私の理解，解釈であり，間違いは全て私の責任です) # というか，問い詰める会は，理論的なことをちゃんとやってる M 先輩とかが行った方が （笑） Q. 正しさの根拠の違い 命令型 : アルゴリズムの一実装 （コーディング）．正しさの議論が困難．仕様 (what) の概念無し．how そのもの 関数型 : how を書くことには変わりないんだけど，プログ
ホワット・ア・ワンダフル・ワールド 高級言語もまた，ライブラリなのだ
「良い言語だけど，ライブラリが揃ってないから，まだ使えない」 こういう感想は，新しい言語が出現するたびに，過去に何度も何度もつぶやかれてきた． 高級言語の価値が，プログラムの短さだとしたら，最も良い言語というのは，最もライブラリが揃っている言語，ということになる． Arcからの挑戦 どうしてそうするかって? なぜなら、プログラムを短くするために高級言語はあるからだ。 プログラミング言語のパワーは、それで書かれるプログラムの長さに反比例する。 100%確実にそうだとまでは言わないが、マジでそんな感じだ。 もし誰かがこういったとしよう。馬鹿げたことだと思わないかな。 「そのプログラム、君の言語だとコードは10行で、俺の言語だと50行だけど、俺の言語はパワフルだぜ」 こう思わざるをえない: じゃあ、あんたの言うパワーってなんなのよ? しかし，最初からライブラリが揃っている言語というものは存在しな
ホワット・ア・ワンダフル・ワールド プログラミング言語の構文は知識ベースである
僕がやってる研究をスローガン的に言うと，プログラマの知識を体系化し，プログラム構築プロセスの構造化を目指す，というもの． もうちょい具体的には，様々な実行環境やらデータ構造やらアルゴリズムやらの定義が入ったデータベース (知識ベース) から，最適化器やコードジェネレータなど，言語処理系を自動生成するというもの (修論までの内容) なんですが． # ドクタからは，単に天下り的に知識を定義として与えるという，従来のコンパイラの延長なものに留まらず，システム自体が与えられた定義から知識を演繹して自動獲得し，高速なコードを探索していくようなシステムを目指している． (via Matz にっき 2008-02-12 _ [Ruby] nishimotzの日記 - Rubyのチカラ) nishimotzの日記 2008-02-11 - Rubyのチカラ どこでどういう省略記法を許すか、という規則を実装
ホワット・ア・ワンダフル・ワールド gcc フロントエンドの minimal
ずいぶん昔に GCC の ひらメソッド wiki (諸事情により wikia に移転しました) の方で教えていただいたネタなので，いまさらですが． チャレンジしたことが無いとなかなか実感がわかないと思うのですが，tree.h や tree.def を理解した上で LANGHOOKS や GGC など独特のフレームワークを攻略しないといけないので，GCC のフロントエンドを作るのは死ぬほど学習曲線が高いです． 一応，treelang というフロントエンドのサンプルが含まれていたりするのですが，これもまたけっこう独特なデータ構造を使っていたりするので，何が treelang に特有の部分で，どこが gcc 固有のお約束なのかが見えにくかったり．(何よりも，僕が yacc/lex 怖い現代っ子というのが大きい) そんなこんなで，こういう，本当に minimal なフロントエンドはいろいろ参考にな
ホワット・ア・ワンダフル・ワールド Ruby の Gtk::MozEmbed バインディング
Mozilla のレイアウトエンジン Gecko をアプリケーションに組み込むにはどないすりゃーいいんじゃと思っていたら，こんなの発見． ままならない日記 2007-06-05 ■[Ruby][Gnome]Gtk::MozEmbed 20:23 これはGeckoエンジンをGUIコーポーネントとして使うためのライブラリです。とてつもなく便利です。試しに適当なコードを書いてみたところ、69行でブラウザが書けました。 てなわけで，リンク先のサンプルコードを実行してみたら，本当にちゃんと動いてちょっと感動． # apt-get install libgtk2-ruby libgtk-mozembed-ruby パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています... 完了 以下の特別パッケージがインストールされます: libatk1-ruby libcairo-ruby
ホワット・ア・ワンダフル・ワールド PDP-11 はスゲェ美しいッ! 百万倍も美しい !
最近，OSC 2007 をきっかけに 30 日 OS 本を買っていろいろ遊んでいたら，昔よりは多少理解が深まってきた． ようやく Lions Book と，このサイトの真の素晴らしさがわかるようになってきたよ… ちょっとは成長したのかもしれない． 2238クラブ 昔の C 言語 (pre K&R) は，本当に素朴でイイよなぁ… もうソースコード見ると出てくる機械語が透けて見えるぐらい素朴．というか，ポインタの型はもちろん，整数とポインタの区別さえテキトーだから，高級言語というよりも高級アセンブラ． ちなみに，コンパイラのソースコードが現在でも公開されてる． Very early C compilers and language main 文を見た瞬間，そのあまりのシンプルさにビックリ ！ main(argc, argv) int argv[]; { extern init, flush;
ホワット・ア・ワンダフル・ワールド 伊東家の食卓 : 80386 以降のリアルモードでメモリ空間 4 G をフルに使う裏技
mixi で syd さんに教えてもらいました．こんな裏技があったとは… ja.wikipedia リアルモード Intel 80386では、プロテクトモードに移行した後、セグメントリミットを設定した後にリアルモードに復帰すると、命令にプレフィックスをつけることでそのセグメントリミットまでの実メモリ空間にアクセスすることが可能になるバグと思われるものもあり、この状態を Unreal mode と呼ぶことがある。この仕様は以降のすべてのCPUで有効となっている。 日本語ではこれ以外にほとんど情報が無いなぁ… ちなみに syd さんは， 高校のころ，東大の TSG とかいうコンピュータサークルがこの裏技に関する記事を書いていたのを見て知ったそうです．ほえー東大すごす． 具体的には，こういうコードで unreal mode に以降できるのだそう．初めて読む 486 と OS 自作入門を参考にしつ
ホワット・ア・ワンダフル・ワールド ちょっと感動した
ふとしたきっかけで，「角を矯めて牛を殺す (枝葉に気を取られすぎて，本質を損なってしまう愚)」という諺の意味を調べていたら，偶然京都大学の博士学位授与式 式辞を見つけた． いや〜，京大は素晴らしいなー 竹内先生のお話によれば、林学における基本的な実験計画は少なくとも二、三十年単位、あるいは五十年から百年を１つのサイクルと見て組み立てられているようであります。どのような種類の樹木がどのような気候のどのような土壌に適合するか、新しく植林してそれがどのように生育してゆくか、雑木と植えた針葉樹とが種々の条件のもとでどのような競合関係を構成するか、ある植物がどのようにして他地域に広がり、他の植生を侵略してゆくかといったことを実際に観察するといったことは、その例であります。 このような研究は１人の教授在任期間で完結せず、２代、３代の教授に引き継がれていって初めてはっきりした結果が出せるわけで、実に
ホワット・ア・ワンダフル・ワールド 携帯文化のメンタリティ
Author:あろは (alohakun) WAKATSUKI toshihiro 連絡先 : alohakun ___at___ gmail.com mixi : http://mixi.jp/show_friend.pl?id=182927 twitter : http://twitter.com/alohakun abstract プログラミングという人間の知的行為を体系化し，単なる職人芸ではなく，サイエンスにするための研究をしています． 具体的には，等価変換計算モデルに基づいた，仕様記述からのプログラム合成の研究をしています． もっと噛み砕くと，プログラムの正しさをどのように定式化し，どのような枠組みで，どのように変換を進めていけば，正しさを保証したまま，効率的なプログラムを手に入れることができるのか，ということについて研究しています． キーワード : equivalent tra
ホワット・ア・ワンダフル・ワールド なぜ Inferno/limbo は重要なのか (Why Inferno : Compact Multi-Platform Distributed OS and limbo programming language matters ?)
なぜ Inferno/limbo は重要なのか (Why Inferno : Compact Multi-Platform Distributed OS and limbo programming language matters ?) 端的に言って，プログラミング言語だけ，あるいは OS だけ，あるいはライブラリやフレームワークだけを研究するということはナンセンスなのである． なぜ UNIX は成功したのか，C は成功したのか ? それは，UNIX 自身が C 言語のプラットフォームであるとともに，C のライブラリであり，C は UNIX を実装するために設計された言語であったからだ．全てがひとつの 「システム」 の構成要素であり，どれ一つ取り外せない循環を成している． では，なぜ UNIX は駄目なのか ? それは端的に言って，時代の宿命である．UNIX は優れた設計思想を持ってはいた
ホワット・ア・ワンダフル・ワールド コンパイラインフラストラクチャ LLVM
COINS はいろいろと微妙な気がするので，別のコンパイラインフラストラクチャ LLVM (Low-Level Virtual Machine) を見てみた． The LLVM Compiler Infrastructure Project LLVM ってのは，仮想マシンなんだけど，例えば Java の JVM，Perl の parrot，Ruby の TVM (旧旧 Rite，旧 YARV) みたいに，特定のプログラミング言語に向けたものではない （ってまぁ，みんな言うんだけど） なので，C-- のように，GC みたいな高級で，なおかつ言語に強く依存するような機能は提供しない (オプションとしては提供されているらしい) 単純な RISC-like な命令セットを持つ VM で，STL を駆使した C++ で書かれているらしい． GCC のバックエンドを持っているので，C/C++ からバイ
ホワット・ア・ワンダフル・ワールド Treelang Hacking Guide (2)
しっかし，GCC のフロントエンドとかって，グローバル変数使いまくりで，インタフェースがさっぱりわからんのだよな． とりあえず，LANG_HOOKS とかいう死ぬ程でかいマクロ （関数ポインタ (= 言語固有のフック)） の塊に，フロントエンドに固有の関数が #define LANG_HOOKS_INIT treelang_init #define LANG_HOOKS_PARSE_FILE treelang_parse_file ．．． みたいなノリで，いろいろ登録されてる （ミドルエンドとのインタフェース treelang/treetree.c)． んで，treelang_init で，ファイル開いて，yyin グローバル変数経由で treelang_parse_file に渡されてる (yyin に格納されてるファイルポインタは，treelang_finish で閉じられてる)．もう
ホワット・ア・ワンダフル・ワールド 感想文
なんか，higepon さんところに，shin-ichiro.h さん/を さん/Shiro さんと錚々たる人々が集結して continuation の実装について議論している光景が凄いと思った．これがネットの力ですよ．higepon さん人気ものですのう w ■[Scheme] 継続マラソン - 継続の実装方法を考える12 ■[Scheme] 継続マラソン - 継続の実装方法を考える11 - SigScheme 個人的には，他との差別化のためには，mona OS 自体に何らかの専用 API (システムコール) を追加する，という方向性が面白いのでは無いかと思います （もともと POSIX とは関係無い OS なのだから）．あとついでに，OS レベルで GC とかしちゃったり．ただ setjmp/longjmp を使うとかだと，あまり未踏性というか，mona OS と絡めるメリットは無いよ
ホワット・ア・ワンダフル・ワールド Nested VM
昔ボクも全く同じこと考えていて， 「switch case を使えば，関数呼び出しを実現できるなぁ… あと BASIC のコンパイラとかも実装できるかも．」 ... (中略) みたいな感じ．標準 C をオブジェクトコードとして出力するコンパイラ屋さんにとっては常識なのかもしれないけど，こうすれば labels as values みたいな非標準機構に頼らなくても，リターンアドレスとかを取得できる． switch case のラベルは，きっと最近の C コンパイラなら，ハッシュ (インストラクションポインタ + ラベル値で goto) になるはずだから，効率もそんなに落ちないはず． そのうち gcc -S して確認してみよう． まぁ，たぶんこんな面倒なことするよりも，もっと上のレベルで CPS 変換みたいな解析をして，全ての関数呼び出しを goto に変換してしまえば良いので，たぶんこの方法
ホワット・ア・ワンダフル・ワールド libsigsegv でスタックオーバフローをポータブルにハンドリング
Windows/Linux その他マルチプラットフォームの clisp では，libsigsegv というライブラリを使って，スタックオーバフローシグナルのハンドリングという激しく環境依存する処理をポータブルに実現しているみたいです． GNU libsigsegv - Handling page faults in user mode しっかし，これ，全くドキュメントが無い ！ というわけで，サンプルコードを見ながら，ちょっとテストコードを書いてみました．簡単化のため，以下のソースは，たぶん Linux 上でしか動きません．libsigsegv-2.4/tests/stackoverflow1.c が，ifdef で非常にポータブルっぽくなってる (そのぶん複雑でわかりにくい) ので，可搬性を求める方はそっちを見てみてください． コンパイルには，sigsegv.h と libsigsegv
ホワット・ア・ワンダフル・ワールド 何でもモジュール
Author:あろは (alohakun) デバッガ開発者見習い（予定） 連絡先 : alohakun ___at___ gmail.com mixi : http://mixi.jp/show_friend.pl?id=182927 twitter : http://twitter.com/alohakun このページはインラインフレームを使用しています Gauche の拡張モジュールを書く方法はだいたいわかってきたので，ちょっち他のスクリプト言語ではどうやって C の拡張モジュールを書くのか調べ てみた． # 詳しくは，過去の記事に散々書いているので省略．興味がある人は，gauche 本体のソースの *.stub (これが一番素晴らしいサンプル．gauche ぐらいしっかり書かれていると，まさしくソースがドキュメント) か，Shiki の stub ファイル (こっちはヘボプログラマ
ホワット・ア・ワンダフル・ワールド プログラミング言語の速度
コメント欄に書いてたら，長くなってしまったのでこっちに加筆して転載． soutaroにっき ■プログラミング言語の実行速度 00:23 大体俺の中では， C＞C++＞OCaml(native)＞Java・.NET＞Haskell＞＞＞VB6＞OCaml(bytecode)＞Perl/Python＞＞＞＞Ruby みたいなイメージ．合ってるかどうか全然自信ありませんのでバカ日本地図を眺めるような感じで見てください． つまり，Javaより速いって聞くと「速っ！！」っていうイメージになるんですよね． んで，Java・.NET以上なら，大体どんなアプリケーションでもいけると思うんですが，そうするとOCaml(native)の立場が微妙になる感じがする．それにRubyでもがんばればけっこうなんとかなるみたいですし，そうすると結局プログラミング言語における実行速度というのはいまやほとんどのケースで問題
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ホワット・ア・ワンダフル・ワールド Google Custom Search Engine