タグ

ブックマーク / practical-scheme.net (30)

  • Before the Startup

    起業の前に --Before the Startup--- Paul Graham, October 2014 これは、Paul Graham: Before the Startup を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2014 by Paul Graham 原文: http://paulgraham.com/before.html語訳:Shiro Kawai (shiro @ acm.org) <版権表示終り> (このエッセイは、スタンフォード大での サム・アルトマンのスタートアップ講座 に招かれた時の講義を基にしたものだ。大学生が対象だけれど、多くの部分は 起業を考

    Before the Startup
  • Lisp:S式の理由

    S式は人に優しいか Shiro: Lispの不人気の理由として筆頭に上げられるのが、括弧だらけの 独特の見た目。とっつきにくい、一般的な表記法と違っていてわかりにくい、 等々、様々なことが言われてきました。しかし、 S式を捨てたLispも開発されましたが 流行ったとはいい難く、Lispな人々はいまだに括弧に固執しているかのようです。 S式のメリットをLisperに尋ねれば、エディタがどうの、マクロがどうの、といった 回答が真っ先に返って来ると思うんですが、そういう理屈をいくら理解しても S式がダメな人がS式を好きになったりはしません。どうも、もっと根的な 感覚に大きな隔たりがあるような気がします。非Lisperから理解しがたい、 Lisperの持つ感覚とはどんなものなんでしょうか。Lisp脳から見た世界は どんなものなのでしょうか。 構文木を人間が書く? S式は言ってみれば言語の構文木そ

    Lisp:S式の理由
  • Scheme:多値

    多値の機能はR5RSになってから追加された、Schemeでは比較的新しい機能だ。 CommonLispやDylanにはある。 純粋な意味での多値、すなわちコンティニュエーションに一つ以上の値が渡るという意味での 多値を実装している言語は、メインストリームではあまり無いと思う。 ただ、多重代入(データストラクチャをdecomposeして複数の変数に代入する機能) があれば、ほとんど多値と同じことができる。RubyPythonにはこの機能がある。 そのため、多値の必要性に関しては大きな議論があり、Schemeコアな人々の中でも 意見が割れている。最近もcomp.lang.schemeで 大きなスレッドが立った。 個人的には多値はかなり頻繁に利用している。 このページでは主として使いどころに関していろいろ書いてみる。 突っ込み歓迎。 --Shiro 方法 - どうやって使う?現象 - どんな時

    Scheme:多値
    joan9
    joan9 2012/05/08
  • Scheme:マクロ:anaphoric ifの代替

  • Scheme:Schemeプログラマのレベル10

    emeitchさんのリクエストより。元ネタは Perlプログラマのレベル10。 私家版、Schemeプログラマのレベル10 くれぐれも気にしないように。 レベル0 SchemeとかLispとかいうカッコだらけですごくわかりにくい言語があることは知っているが、 最強とか主張する信者がいるらしいのでなるべく関わらないようにしている。 EmacsLisp?もその親戚らしいけどコードを見ただけでくらくらする。 でも便利なマクロは自分の.emacsにコピペしている。 レベル1 Schemeに関するwebサイトを見たり、大学の講義での説明とかを聞いて、 factorialとかappendとかreverseとかを書いたり、 ネストした木構造のノードの数を数えたりできる。 でもそれが何の役に立つかわからない。こんな言語で実用的な プログラムが書けるなんて信じられない。 カッコの位置を間違えて動かないプロ

    Scheme:Schemeプログラマのレベル10
    joan9
    joan9 2010/12/04
  • Lisp:S式の理由

    S式は人に優しいか Shiro: Lispの不人気の理由として筆頭に上げられるのが、括弧だらけの 独特の見た目。とっつきにくい、一般的な表記法と違っていてわかりにくい、 等々、様々なことが言われてきました。しかし、 S式を捨てたLispも開発されましたが 流行ったとはいい難く、Lispな人々はいまだに括弧に固執しているかのようです。 S式のメリットをLisperに尋ねれば、エディタがどうの、マクロがどうの、といった 回答が真っ先に返って来ると思うんですが、そういう理屈をいくら理解しても S式がダメな人がS式を好きになったりはしません。どうも、もっと根的な 感覚に大きな隔たりがあるような気がします。非Lisperから理解しがたい、 Lisperの持つ感覚とはどんなものなんでしょうか。Lisp脳から見た世界は どんなものなのでしょうか。 構文木を人間が書く? S式は言ってみれば言語の構文木そ

    Lisp:S式の理由
    joan9
    joan9 2010/06/29
  • Lisp:Geometry

    (Shiro: 私はNichimen Geometryになってから、 プラグイン書き等で少々いじったにすぎないので、 Symbolics時代のこととか、周辺事情にもあまり詳しくないっす。 識者の方、がんがん修正してください)。 (khashi) 情報追加しといたんですが、まとまりがなくなってしまったんで、適当に整理しといてください。 Geometryとは Lispで書かれたモデリングツール。 もともとSymbolicsのグラフィックス・パッケージS-Products のモデリング・モジュール。 1981年公開の映画「トロン」のモデリングを担当してたLarry Maloneによって開発された。 このツールが最初に日でデモされたのは1985年の筑波博覧会アメリカ館。 市販されてから20年の歴史を持っている。 尚且つ20年間1人のプログラマによってメンテナンスされている。 開発当初は、Zeta

    Lisp:Geometry
    joan9
    joan9 2010/06/29
  • Lisp:よくある正解 - Lispについての正しい認識と、それでもLisperがLispを使う理由

    Lispについての正しい認識と、それでもLisperがLispを使う理由 yoriyukiさんのエントリがなかなか 真実を突いていたので、ネタにさせていただきます。 原因のほとんどは経路依存性とかネットワーク効果によるもので、Lisp自体の性質とは無関係だと思います。と言った上で、私が何となくLisp系言語を使わない理由としては、 Too dynamic: 実行時にコードが差し替えられることがすごい利点だ、と言っている人がいましたが、逆に言えば今どのコードが走っているか理解しにくい、という欠点にも繋がる。 Meta programming:S式のおかげでMeta Programmingがしやすいが、Meta Programmingを多用したプログラムは理解しにくい。 動的型付け:利点でもあるけど、特有のバグを引き起こす。 識別子に関数と値の2種類が別々にバインドできる。これは私には非常に美

    Lisp:よくある正解 - Lispについての正しい認識と、それでもLisperがLispを使う理由
    joan9
    joan9 2010/06/29
  • Lisp:よくある誤解

    Lispについてのよくある誤解と、その中にあるちょっとした真実 はてなの質問: プログラミング言語で最強(スケーラブル)なのは、 Lispだと思われます。 http://jp.franz.com/index.html しかし、 世間ではマイナー言語のようです。 なぜでしょうか。 についた回答のいくつかには、「Lispを少しだけかじった人がしがちな誤解」が 含まれてるようなので、それをネタに少し解説してみます。 ただ、誤解が生じるのは、やっぱりそれなりの理由があって、従ってその 誤解の中にも(条件つきの)真実が含まれていることがあります。 そのへんまでをも含めて考えてみましょう。以降、引用は回答からです。 Lispはスクリプト言語? 一昔前まで、これらのスクリプト系の言語は「とてつもなく遅い」のが嫌われる最大の要因でしたが、最近のコンピューターの性能向上でようやくRuby,Python,Li

    Lisp:よくある誤解
    joan9
    joan9 2010/06/29
  • Scheme:!と?

    Schemeの名前づけの慣習には、一応こんなのがある。 a. 破壊的操作を行う手続き、構文には!をつける (set-car! etc) a'. !のついた手続きの返り値は未定義(portableには利用できない) b. 真偽値を返す手続きには ? をつける b'. ?のついた手続きの返り値は真偽の判断のみに使える(#t以外の有用な 値を返すことはあてにできない) a, bについてはほとんどの場合守られているといえるだろう。 ただ、よりきつい縛りであるa', b' については、srfiやライブラリレベルでは 守られていないこともあり、混乱を生じやすい。 ちょっとまとめてみる。 !の返り値!の返り値が「利用できてしまう」もの!の返り値を「利用せざるを得ない」もの?の返り値#f, #t以外を返す?-関数述語としてもよく使われるが、#f, #t以外を返すために?がついていないものその他の記号/*$

    Scheme:!と?
    joan9
    joan9 2010/04/15
  • Shiro:プログラマへの64の質問への回答

    元の質問は YukiWiki:プログラマーへ64の質問 にあります。 突っ込み歓迎。突っ込みはハイフン三つ(---)で書いてくことにしましょう。 0.プログラマは何事も0からスタートするべきだと思いますか? 内部表現はそれでいいですが、外部表現は相手に合わせましょう。 入力には寛容を。出力には厳格を。nobsun なるほど。いい言葉だ。Shiro でも、0 vs 1 みたいな排他的なものに、どうやって寛容を導入するのやら 戯 1.プログラマの定義は何でしょうか? 人に使ってもらえるプログラムを書く人。 2.あなたがいつもやることとは? C-x C-s  (作業途中のセーブ) あるある。そして、 mew を使ってると、無意識に i を連発。yari 今使おうとするツールのSave手段をまず「身に付けて」から作業開始。命綱は最初に確認するっしょ。 戯 3.あなたが絶対やらないことは? ログを書

    Shiro:プログラマへの64の質問への回答
    joan9
    joan9 2010/03/05
  • Gauche:DBI/DBD

    (2005/07/03 15:35:57 PDT): 現在、別パッケージで提供されているDBI/DBDだが、特定のデータベースに 依存しない部分をGauche体に取り込む。0.8.6に入る予定。 http://www.kahua.org/cgi-bin/kahua.cgi/kahua-web/show/dev/DBI 今のdbiのAPIは、当時のGaucheの機能が不十分だったこと(特に例外機構)や、 とりあえず使えることを優先して開発されたため、あまりすっきりしていない。 この機会にAPIを整理することにした。 実際にprepared statementのサポートを真面目に考え始めたら、 現状のdbiのアーキテクチャにかなり大幅な変更が必要になることがわかり、 結局中身はほとんど完全に入れ替わっている。 ただ、今までのdbiに依存しているアプリもあるし、ドライバの方もすぐには 新しいd

    Gauche:DBI/DBD
  • Shiro:OpenSourceMagazine0606 パワーハッカーへの道

    (これは、オープンソースマガジン2006年6月号の「ハッカー養成塾!」という コーナーに寄稿した記事の、編集前の原稿です。) パワーハッカーへの道ハッカーは書いて理解するハッカーは道具をつくるハッカーは頭の中を掃除するハッカーにも書けない時があるおわりに次回注釈ハッカー養成塾! 他の方の原稿 パワーハッカーへの道 川合 史朗 そこそこ、プログラムは書けると思う。 エリック・レイモンド(*eric)の言うとおり言語もいくつか かじってみたし、有名なソフトのソースコードも読んでみた。 でも、もっと良いコードを、ばりばり書けるようになりたいな。 稿では、ハッカーの世界の入口を通り抜けたそんな人が、 次を目指すにはどうすれば良いかを考えてみたい。 ハッカーは書いて理解する フルタイムのプログラマとして働き出して間もない頃、 ある有名なハッカーと話していて、 少し前に発表された論文の技法はどう思う

    Shiro:OpenSourceMagazine0606 パワーハッカーへの道
  • Gauche:SXMLとSXPath

    SXPath の S 式表現がよくわからなかったのでまとめてみました。 -- leque(2007/02/11 01:26:05 PST) sxpath 手続き sxpath 手続きの定義は以下のようになっている。 ;; $Id: sxpath.scm,v 1.1 2003/07/22 11:22:11 shirok Exp $ ... (define (sxpath path . ns-binding) (let loop (...) (cond ((null? path) ; parsing is finished (lambda (node . root-var-binding) ...)) ...))) 手続きの直前のコメントには省略記法の展開ルールが書いてある(GaucheRefj:sxpath 参照)。 ここで path は SXPath のパス表現、ns-binding は

    Gauche:SXMLとSXPath
  • Scheme:マクロ:CommonLispとの比較

    安全なマクロ束縛変数の衝突自由変数の衝突S式≠プログラム?議論、コメント 関連: Scheme:マクロ:anaphoric ifの代替, Scheme:マクロの効用, Scheme:マクロの危険 2007/05/15 00:08:13 PDT追記: 黒田さんの再反論と、それに対するコメント:Scheme:マクロ:CommonLispとの比較:意味論。 安全なマクロ MSIの黒田さんの About Schemeより: first class symbol がないということは様々な弊害を引き起こしますが、なかでも深刻なのは、名前の衝突に関して無力な点です。 そうすると、実質 macro が書けない… 例えば以下の arithmetic-if は、いかなる名前とも衝突しない uninterned な名前を var に割当てることで、 どういうコンテクストにおいても動作保証のできるマクロ展開結果を

    Scheme:マクロ:CommonLispとの比較
  • Scheme:マクロ:CommonLispとの比較:意味論

    前回までのあらすじ MSIの黒田さん wrote in About Scheme: 「Schemeじゃまともなマクロが書けないでしょう」 Shiro wrote in Scheme:マクロ:CommonLispとの比較: 「Schemeではhygienic macroという形でその問題を解決してます」 MSIの黒田さん wrote in GaucheNight: 「でもR5RSではセマンティクスが文字の並びで定義されてるんだから、S式の操作でプログラム生成をするマクロとは相容れないんじゃないの」 何が問題なのか Shiro(2007/05/16 04:43:15 PDT追記): 論点がわかりにくいという話があったので最初に整理しておきます。 R5RSにおいて、Schemeの正式な構文は 7.1節に、 基構文(lambda、if、set!、関数呼び出し、変数参照)のセマンティクスは 7.2

    Scheme:マクロ:CommonLispとの比較:意味論
  • naoya_t:ポール・グレアムのエッセイと和訳一覧

    ポール・グレアムのエッセイと和訳一覧 (originally maintained by naoya_t) Paul Grahamのエッセイ(原文)と、公開されている日語訳のリストです。 見つけたら or 訳したら、自由に追加して下さい。複数の訳が存在する場合は全て追加してください。 How to Get New Ideas 新しいアイデアを得る方法 (lionfan) The Need to Read 読む必要性 (Shiro) Is There Such a Thing as Good Taste? 良いセンスはあるか? (lionfan) Beyond Smart 知能を超えて (lionfan) Weird Language ヘンな言語 (Shiro) How to Work Hard 全力で働く方法 (lionfan) A Project of One's Own 自分の仕事

    naoya_t:ポール・グレアムのエッセイと和訳一覧
  • Arcからの挑戦

    Arc をリリースしてから2、3日経ったので、もうみなさんとも、それを耳にして何かしらの意見を持ってくれたように思う。 今のところは、評判がどうというほどでもなく、なんかウェブにでてきたみたいだねといった程度だ。 なにしろまだ日が浅いので、 Arc でプログラムした経験談といった高級なものは望むべくもないのだが、私はそれを楽しみに待っている。 それでも、的を射た反応もあった。意義をいくらかでも理解してくれている人たちからの、ファースト・インプレッションだ。 どうやら、これらには特徴的なパターンがあることに気づいた。 Arc についての主たる批判は、書くのに苦労していたわりには大したことないじゃんということだった。 Ron Garret 曰く: そして Arc について主な不満: 作るのにずいぶんかかったうえ、あんなに高い目標を立てていたわりには、 まるで、言語デザインの難問に向かってパント

    Arcからの挑戦
  • RSSMix: Recent Entries

    RSSMix: Recent Entries[What's This?][Sources]2024/03/07 13:46:59 UTCWiLiKi: Shiro:AuditionRecords2024/03/07 11:25:13 UTCChaton Common-lisp-jp: 新着Lisp記事: 『実用Common Lisp』読書会(142) ...2024/03/02 11:51:08 UTCChaton Common-lisp-jp: 新着Lisp記事: コンピューティング史見聞録(13) ...2024/02/24 21:05:28 UTCWiLiKi: Scheme:初心者の質問箱2024/02/23 14:34:54 UTCChaton Common-lisp-jp: 新着Lisp記事: 信号の包絡線を計算する (Common ...2024/02/22 21:31:15

    joan9
    joan9 2009/06/16
  • Chaton

    Chaton (pronounced like [sha-ton], a 'kitten' in French) is a simple Comet-based Webchat server written in Gauche. Originally it is developed to host a successor of Gauche chat room on Lingr ( http://www.lingr.com ), when Lingr announced to terminate its service. Although Chaton never aims at serving in such a large scale and with tons of features like Lingr, the "look and feel" of the interface s