■_
・戦う司書
いや面白い。ここまできちんと「一話完結になっていない」お話も近頃では珍しいような。
それだけに次を早くという気分に。
でも次(4話。ネット配信で観てるので)で～編みたいなのは決着つくのだっけか。
ステーショナリーハックス!
掲載されている文房具(通販のみみたいなのは除いても)を全部確認できるような
お店どこかにないんだろうか ○|￣|＿
I'd just be the catcher in the rye and all. I know it's crazy, but that's the only thing I'd really like to be. I know it's crazy.
The catcher in the rye
J. D. Salinger
このページの内容は日々更新されます。 そのため、検索エンジンに引っかかったものがここに残っているとは限りません。 同じ内容のものは zakkicho[0-9]+.html なページに多分あります。 特に逆ポーランド記法←→中置記法の変換に関して探している人は ここ とか ここ にあります。
・戦う司書
いや面白い。ここまできちんと「一話完結になっていない」お話も近頃では珍しいような。
それだけに次を早くという気分に。
でも次(4話。ネット配信で観てるので)で～編みたいなのは決着つくのだっけか。
ステーショナリーハックス!
掲載されている文房具(通販のみみたいなのは除いても)を全部確認できるような
お店どこかにないんだろうか ○|￣|＿
C++ in Coders at Work C++ in Coders at Work (Coders at Work における C++) One of the topics I asked most of my Coders at Work interviewees about was C++. I am not an expert, or even a competent C++ programmer and recognize that my own opinions about C++ are not well-informed enough to be worth much.1 But C++ fascinates me?it's obviously a hugely successful language: most “serious” desktop apps are still written in C++ despite the recent inroads made by Objective C on OS X and perhaps some C# on Windows; the core of Google's search engine is written in C++; and C++ dominates the games industry. Yet C++ is also frequently reviled both by those who never use and by those who use it all the time. わたしが自分の Coders at Work でインタビューの相手に最も尋ねたのは C++ についてのこと です。わたしは (C++の) エキスパートではありませんし competent な C++ プログラマーです らありません。そしてわたし自身の C++ についての意見は、well-informed enough to be worth much.1 ではないと認識しています。しかし C++ はわたしを魅了しました。C++ は明ら かに多大なる成功を収めた言語 (hugely successful language)です: OS X では Objective Cに よって作られれるものが多くなってきているし、 Windows では C#が使われるようになってきて るとしても大部分の “serious” なデスクトップアプリは今でも C++ で書かれていますし、 Google のサーチエンジンの核となる部分は C++で書かれています。C++ はまた、ゲーム業界で は支配的な地位にあります。C++ は今もなお、C++を全然使ったことのない人と年中使っている 人の両方から頻繁に罵られて (reviled) います。 That was certainly reflected in the responses I got from my Coders interviewees when I asked them about it. Jamie Zawinski, as I've discussed recently, fought tooth and nail to keep C++ out of the Netscape code base (and eventually lost). Some of that was due to the immaturity of C++ compilers and libraries at the time, circa 1994, but it seems also to have to do with his estimation of the language as a language: そのことはわたしが自分の Coders interviewees にそれについてたずねたときの回答に明確に 反映されています。Jamie Zawinskiはわたしが最近ディスカッションしたように、Netscapeのコ ードベースからC++を排除すべく奮闘しました(and eventually lost).その一部は1994年当時の C++ コンパイラーとそのライブラリの immaturity のためでしたが、 but it seems also to have to do with his estimation of the language as a language: C++ is just an abomination. Everything is wrong with it in every way. So I really tried to avoid using that as much as I could and do everything in C at Netscape. C++ は単なる abomination (嫌悪感を起こすもの)です。あらゆることがらをあらゆるやり方 でもって間違っています。ですから、わたしは Netscape で可能な限り C++ の使用を排除し てCで行うことを試みたのです。 Part of Zawinski's issue with C++ is that it is simply too complex: Zawinskiの C++ についての issue はただ単に複雑すぎるということです: When you're programming C++ no one can ever agree on which ten percent of the language is safe to use. There's going to be one guy who decides, “I have to use templates.” And then you discover that there are no two compilers that implement templates the same way. あなたが C++でプログラミングしようとしたとき、C++ が安全に使える言語であるということ に賛同する人は 10% もいないでしょう。テンプレートを使わなければならない (“I have to use templates”) と決断した一人の男がいたとしても、後になってから、テンプレートを同じ やり方で実装しているコンパイラーが二つとないことを発見することになるのです。 Note that Zawinski had started his career as a Lisp programmer but also used C for many years while working on Netscape. And he later enjoyed working in Java. So it's not that C++ was either too high-level or too low-level for him or that he couldn't wrap his head around object orientation. Zawinski が Lisp プログラマーとしてそのキャリアを開始しただけでなく、Netscape で働いて いる間、長年にわたって Cを使っていたことに注意してください。そして彼はのちに Java で enjoyed working しています。ですから、彼にとって C++ がレベルの高すぎるものでも低すぎ るものでもなかったのですし、かといって、彼が自分のアタマをオブジェクト指向モードにでき なかったということでもありません。 Joshua Bloch, who also hacked low level C code for many years before becoming a big-time Java head, told me that he didn't get into object-oriented programming until quite late: “Java was the first object-oriented language I used with any seriousness, in part because I couldn't exactly bring myself to use C++.” He echoed Zawinski's point about how C++ forces programmers to subset the language: Joshua Bloch は big-time Java head になる以前は長年にわたりハードウェア寄りの C コード (low level C code) を hack していた人物なのですが、その彼がわたしとても遅いままである 限り、オブジェクト指向プログラミングには移行しないと言いました「Java はわたしがなんら かの seriousness を伴って使った初めてのオブジェクト指向言語でした。それは、部分的には C++ を使う気にならなかったからなのですが」彼は、 C++ が如何にプログラマーに言語のサブ セットを強要しているのかという Zawinski の指摘を繰り返しました: I think C++ was pushed well beyond its complexity threshold and yet there are a lot of people programming it. But what you do is you force people to subset it. So almost every shop that I know of that uses C++ says, “Yes, we're using C++ but we're not doing multiple-implementation inheritance and we're not using operator overloading.” There are just a bunch of features that you're not going to use because the complexity of the resulting code is too high. And I don't think it's good when you have to start doing that. You lose this programmer portability where everyone can read everyone else's code, which I think is such a good thing. わたしは C++ は複雑さの threshold (閾値 or 臨界点)を越えてしまったと思います。それで いてまだあまりにも多くの人がC++を使ってプログラミングしていますが、しかしそれはその 人たちにサブセットを強要しているということなのです。ですから、わたしが知っている C++ を使っている企業はどこもこういうのです 「確かにわたしたちは C++ を使っていますが、多 重継承も演算子多重定義も使っていません」のように。そこにあるのは、resulting code の 複雑さが高度すぎるためにあなたが使いもしないであろう機能の単なる寄せ集めに過ぎません。 誰もが自分以外の誰かの書いたコードを読解できるという、わたしがとても良いことであると 考えている programmer portability をあなたは失ってしまっているのです。 Ken Thompson, who still mostly uses C despite working at Google which is largely a C++ shop, has had as long an exposure to C++ as just about anyone, having worked with with Bjarne Stroustrup, C++'s inventor, at Bell Labs: Ken Thompson はC++ を広く使っている企業である Google で働いているにもかかわらず今でも C を使うことがほとんどであるような人物で、皆さんと同じように長く C++ と付き合ってきて おり、Bell Labs で C++ の inventor である Bjarne Stroustrup と一緒に働いたこともありま す。 I would try out the language as it was being developed and make comments on it. It was part of the work atmosphere there. And you'd write something and then the next day it wouldn't work because the language changed. It was very unstable for a very long period of time. At some point I said, no, no more. わたしは C++ が開発段階にあり意見を求めていたときに試そうとしたことがあります。それ は仕事の一部といった雰囲気でした。そして、あなたがなにかしら書いたことは翌日には動か なくなってしまっているのです。なぜなら、言語の方が変更されてしまったからです。C++ は非常に長い期間、とても不安定なものでした。その時点でわたしが言ったことは no, no more (もういいよ勘弁してくれ)でした。 In an interview I said exactly that, that I didn't use it just because it wouldn't stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language. I never said it was a bad language. On and on and on. Since then I kind of avoid that kind of stuff. あるインタビューで、本当にわたしが言ったことは、C++ は議論の真っ最中にあって二日と安 定したものではないので自分は使っていないというものでした。 Stroustrup はそのインタビューを読んだとき、わたしの部屋に飛び込んできてわたしが彼を underminign しているとか、わたしの言ったことは問題発言であり C++ は bad language で あると言ったとか非難しはじめたのです。わたしは C++ が bad language であったとは決し て発言していません。 On and on and on. 以来わたしはその種のことを避けるようにしています。 At that point in the interview I almost changed the topic. Luckily I took one more try at asking for his actual opinion of C++. His reply: その時点でわたしは話題を変えたのですが、幸運なことにわたしにはもう一度、彼のC++に対す る本当の意見を尋ねる機会がありました。彼の返事はこうです: It certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and it's just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it's personal or corporate, selects a subset and these subsets are different. So it's not a good language to transport an algorithm－to say, “I wrote it; here, take it.” It's way too big, way too complex. And it's obviously built by a committee. 確かに C++ には良い点があります。しかし一般的に言ってしまえば (But by and large)、 C++ は悪い言語 (bad language) だろうと思います。C++ はたくさんのことがらを half well に行っていて、mutually exclusive なアイデアの単なる garbage heap に過ぎません。個人 的な知り合いや会社がらみであるかを問わずわたしが知っている誰もがサブセットを選択して いて、しかもそのサブセットは別々のものなのです。ですから、 “I wrote it; here, take it.”(ちょっとプログラムを書いてみたよ。持っていて) といった感じでアルゴリズムを transport するのには良い言語ではありません。 C++ は仕様が大きすぎる上に複雑極まりありません。そしてなにより委員会製のものです。 Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said “no” to no one. He put every feature in that language that ever existed. It wasn't cleanly designed－it was just the union of everything that came along. And I think it suffered drastically from that. Stroustrup は C++ に対して彼が行った技術的な貢献以外にも、採用されて使ってもらうために (to get it adopted and used) 何年も何年も運動をしてきました。彼は鞭と椅子を持って全ての 標準委員会を巡ったのですが、彼は誰に対しても “no” とは言わないのです。彼は存在する機 能のことごとくを C++ に取り込みましたがそれはきちんと設計されたものではなく、単なる持ち 込まれたものすべての集合体だったのです。そこから受けた痛手はかなりのものだったと思いま す (And I think it suffered drastically from that) Brendan Eich, the CTO of the Mozilla Corporation, whose Mozilla browser is written almost entirely in C++, talks about “toe loss due to C and C++'s foot guns” and when I asked him if there are any parts of programming that he doesn't enjoy as much as he used to, he replied: Mozilla ブラウザーをほぼ全て C++ で書いた人である Mozilla Corporation の CTO、Brendan Eich は “toe loss due to C and C++'s foot guns”(C や C++ の foot guns のために失われ たつま先?) について語りました。そしてわたしは彼に、使うのが楽しくなかった parts of programming がなにかあったかどうかを尋ねました。彼の返答はこうです: I don't know. C++. We're able to use most of its features?there are too many of them. It's probably got a better type system than Java. But we're still screwing around with '70s debuggers and linkers, and it's stupid. I don't know why we put up with it. わかりません。C++ は機能があまりにもたくさんありすぎますから、わたしたちが使える機能は その全部ではなく大部分といったところでしょう。C++ の型システムはおそらくJavaよりも良い ものでしょう。けれども、今でもわたしたちは70年代のデバッガーとリンカーでムダに時間を 費やしています。それはとても馬鹿げたことです。なぜそんなことを我慢しなければならない のでしょうか。 At least among my interviewees, even the most positive comments about C++ tended to fall in the category of “damning with faint praise”. I asked Brad Fitzpatrick, who used C++ in college and again now that he's at Google, whether he likes it: 少なくとも私がインタビューした人たちに関して言えば、C++ に対して最も好意的なコメントで さえ“damning with faint praise”(褒めているようで実はけなしている)といったところに行 きがちでした。大学で C++ を使い、そして今また Google でC++を使っているBrad Fitzpatrick に C++ が好きかどうか尋ねてみました: I don't mind it. The syntax is terrible and totally inconsistent and the error messages, at least from GCC, are ridiculous. You can get 40 pages of error spew because you forgot some semicolon. But－like anything else－you quickly memorize all the patterns. You don't even read the words; you just see the structure and think, “Oh, yeah, I probably forgot to close the namespace in a header file.” I think the new C++ spec, even though it adds so much complexity, has a lot of stuff that'll make it less painful to type－as far as number of keystrokes. The auto variables and the for loops. It's more like Python style. And the lambdas. It's enough that I could delude myself into thinking I'm writing in Python, even though it's C++. 気にしてません。構文は不細工 (terrible) だし一貫性は全然なくて、少なくとも GCC が吐き だすエラーメッセージときたらふざけた代物 (ridiculous) です。セミコロンを幾つか忘れた だけで 40ページにも及ぶエラーメッセージを受け取ることになるかもしれません。しかし、 他のことと同様に、あなたはすぐに全てのパターンを覚えてしまいます。単語を読んだりはしま せん。エラーメッセージそのもの構造を見るだけで考えるのです。 “Oh, yeah, I probably forgot to close the namespace in a header file.” (あー、ヘッダーファイルで名前空間を閉じるのを忘れちゃったくさいなあ) わたしはそれが複雑さをさらに増やすことになるとしても、タイプする苦痛を軽減するような 性質をたくさん持った新しい C++ の spec を考えています －as far as number of keystrokes. たとえばもっと Pyton 的スタイルな auto 変数や for ループ。 それと C++ を使っているのに Python で書いていると思わせてしまうような lambda。 Dan Ingalls, who helped invent modern object oriented programming as part of Alan Kay's team that developed Smalltalk, never found C++ compelling enough to use but isn't totally adverse to using it: Smalltalk を開発していた Alan Kay のチームにあってmodern なオブジェクト指向言語プログ ラミングの発明を助けていた Dan Ingalls は C++ に compelling enough なものをついに見出 せませんでしたが、C++ を使うことを全面的に否定はしませんでした。 I didn't get that much into it. It seemed like a step forward in various ways from C, but it seemed to be not yet what the promise was, which we were already experiencing. If I had been forced to do another bottom-up implementation, instead of using machine code I would've maybe started with C++. And I know a couple of people who are masters of C++ and I love to see how they do things because I think they don't rely on it for the stuff that it's not really that good at but totally use it as almost a metaprogramming language. わたしは C++ にあまりのめりこみませんでした。C++ は C から色々な方法で前進 (step forward) したもののように思えるのですが、それはまだわたしたちがすでに経験したところの what the promise was ではないようです。仮にわたしが別の bottom-up implementation をすることを強制 されたなら、機械語を使うのではなく C++ から始めることもあるかもしれません。わたしは C++ をマスターした人を二、三人ほど知っているのですが、彼らがどのように C++でプログラミングす るかを見るのが大好きです。なぜなら、彼らはメタプログラミング言語のように使われることをまっ たく考慮されていないような仕様にほとんど頼ることなくプログラミングしているとわたしは思っ ているからです。 Joe Armstrong, similarly, has never felt the need to learn C++: Joe Armstrong もまた、C++ を学ぶ必要を全く感じませんでした: No, C++, I can hardly read or write it. I don't like C++; it doesn't feel right. It's just complicated. I like small simple languages. It didn't feel small and simple. わたしは C++ をほとんど読みも書けもしません。わたしは C++ が好きではありませんし、 (C++が) 正しいものであるとも感じません。そう、単に複雑なんです。わたしは小さくて 単純な言語が好きなのです。C++ は小さくもなければ単純でもないように思います。 And finally Guy Steele, who probably knows more about more languages than anyone I interviewed (or possibly anyone, period), has also not been drawn to C++. But he did go out of his way to try to say something nice about Stroustrup's effort: そして最後は Guy Steele です。彼はおそらくわたしがインタビューした人たちの誰よりも言語 についてより知っている人で (or possibly anyone, period)、彼もまた C++ に引き寄せられは しませんでした。しかし彼は Stroustrup の努力 (業績?) に対してその必要がないのにわざわざ (go out of his way)、 something nice を述べようとしたのでした。 I have not been attracted to C++. I have written some C++ code. Anything I think I might want to write in C++ now could be done about as well and more easily in Java. Unless efficiency were the primary concern. わたしは C++ に魅力を感じることはありませんでした。C++ のコードを少しは書きましたが Java で書くのと同じくらい簡単にできるなら C++ で書きたくなるかもしれないとは思いまし た。効率が primary concern でなければ。ですが。 But I don't want to be seen as a detractor of Bjarne Stroustrup's effort. He set himself up a particular goal, which was to make an object-oriented language that would be fully backwards-compatible with C. That was a difficult task to set himself. And given that constraint, I think he came up with an admirable design and it has held up well. But given the kinds of goals that I have in programming, I think the decision to be backwards-compatible with C is a fatal flaw. It's just a set of difficulties that can't be overcome. しかしわたしは Bjarne Stroustrup の努力に対する detractor (中傷する人) になりたくは ありません。彼は自身に C に対する完全な後方互換性を持ったオブジェクト指向言語を作り 上げるという particular goal を設定しました。それは彼自身にとっても困難な任務であり、 そして課せられた制約の中で彼は admirable design を得て、それをよく形にしたとわたし は考えています。けれどもそうやって得られたもので自分がプログラミングをしてみると、 C に対して後方互換にするという決断は致命的な不備 (flaw) であったとわたしは思うのです。 それは克服することのできない difficulties の集合でしかないのです。 Obviously with only fifteen interviewees in my book I have only a sampling of possible opinions. There are great programmers who have done great work with C++ and presumably at least some of them would have had more enthusiastic things to say about it if I had spoken with them. But this is what I heard from the people I spoke with. 言うまでもないことですが、わたしが C++ に対する意見を取り上げることが可能であったのは わたしが自分の本でインタビューした相手の15人だけです。 C++ を使って great work を成し 遂げた偉大なプログラマーたちがいましたし、少なくともその中の一部の人はわたしが話を聞く 機会があったならば C++ についてより enthusiastic なことを話してくれたかもしれません。 しかしここで書いたことは、わたしが対話した人たちから聞いたことなのです。 1. I think I once managed to read all the way through Stroustrup's The C++ Programming Language and have looked at at least parts of The Design and Evolution of C++. But I have never done any serious programming in it. I have made a couple attempts to learn it just because I felt I should but in recent years I've mostly given up, thinking that perhaps Erik Naggum, scourge of Usenet, was right when he said: “life is too long to know C++ well.” わたしは一度 Stroustrup 氏の The C++ Programming Language を通読し、 さらに The Design and Evolution of C++ の一部を読んだことはありますが、 C++ を使ってなんらかの serious programming をしたことはありませんでした。 C++ について学んでおくべきと考えて何度かその機会を作ったのですが、 ここ最近はほとんどギブアップしている状態です thinking that perhaps Erik Naggum, scourge of Usenet, was right when he said: “life is too long to know C++ well.” (C++ をよく知るには人生は長すぎる) Last updated 2009-10-16T13:55:11Z.
TV版とかの BOX の値段ほんとにこれ?
「ボトムズ」新作OVAがBlu-ray/DVDで'10年3月発売 -AV Watch 2010年 2月23日 DVD 装甲騎兵ボトムズ DVD-BOX I 7枚組 18,900円
ああ、BOXが全部で三つあるってことか。でも三つとも同じ値段だとすると 二年位前に出たDVD-BOXよりもずいぶんと安くなるような。
まあ、どこかがすぐにでも訳しそうな気ががががが。
InformIT: Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson > Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson Erich Gamma, Richard Helm, and Ralph Johnson talk to Larry O'Brien about Design Patterns, 15 years later. Larry O'Brien: 85,000 apps for the iPhone have been developed and deployed in the past year-and-change. One can write a globally-accessible "Hello, World! The time is X" Web page in just one line of PHP, for instance. "Designing object-oriented software is hard," are the first words of Design Patterns. Are those words still accurate? Richard Helm: Software design is always hard. Although most modern development environments do lots to reduce complexity through reusable libraries and toolkits (Eclipse, Apple, Microsoft), designing a software solution to the business problem is still hard. (ry) When discussing which patterns to drop, we found that we still love them all. (Not really—I'm in favor of dropping Singleton. Its use is almost always a design smell.) So here are some of the changes: * Interpreter and Flyweight should be moved into a separate category that we referred to as "Other/Compound" since they really are different beasts than the other patterns. Factory Method would be generalized to Factory. * The categories are: Core, Creational, Peripheral and Other. The intent here is to emphasize the important patterns and to separate them from the less frequently used ones. * The new members are: Null Object, Type Object, Dependency Injection, and Extension Object/Interface (see "Extension Object" in Pattern Languages of Program Design 3, Addison- Wesley, 1997). * These were the categories: o Core: Composite, Strategy, State, Command, Iterator, Proxy, Template Method, Facade o Creational: Factory, Prototype, Builder, Dependency Injection o Peripheral: Abstract Factory, Visitor, Decorator, Mediator, Type Object, Null Object, Extension Object o Other: Flyweight, Interpreter As I said above these are just notes in a draft state. Doing a refactoring without test cases is always dangerous...
shiro 2009/10/23 01:01 srfi- 1のが"foldl"とか"fold-left"ではなく"fold"と名づけられているのにはそういう理由があったのです。 あの仕様については色々議論があったのですが、素直な理由はたぶんお察しのとおり、Schemeで処理結果をaccumulateしてゆく通常のパターンに一致するから、というのが大きいと思います。
・Stationary Hacks! ステーショナリー ハック!
見ていて楽しい。
まとめて買える通販サイトとか用意してくれればいいのに
(でも実際あったらどんだけお金を使うか怖いw)。
あ、紹介しているものの販売元などは巻末にまとまっていますし、
紹介してるページではリストの番号が記載されてはいます。
・きんようび
さてどういう風に行動の計画を立てるか。
Real World Haskell (の翻訳本)と、タイガーブック(の翻訳本）とを
買えそうな所にいくとか、アレに申し込むとか。
正規表現について -OKWave PHP5.2.4を使用しています。 1文字以上のアルファベットと数字の組み合わせは許可（含めて） かつ 「ab」は許可しない（含めない） という正規表現はどのように記述すれば良いのでしょうか？ （「01ab」「abc」は許可、「ab」は許可しない） 一応自分なりに考えてみたのですが、 $str = "abc"; if (preg_match("/[^(ab)][a-z0-9]+/", $str)) { print "match<br>\n"; } やはり駄目でした・・・
[^なにか] で「なにか」以外だってことは知ってる(わかってる)わけだよな。 その後に [a-z0-9] と書いているから、[ と ] に囲まれた「文字のいずれか」 が対象になるというのもまあ大丈夫なんだろう。 [^(ab)] てのは () のグルーピングの機能を知ってる(見つけた)ということなんだろうけど どうして () で囲んだ方が「強い」って思っちゃうのかなあ。
回答に否定先読みを使ったパターンが挙げられているんだけど。 あれキライなんだよなあ。
R の引数の解釈って結構楽しいな。
> sin(0) [1] 0 > sin(pi) [1] 1.224606e-16 > sin(0, pi, 2*pi) 以下にエラー sin(0, pi, 2 * pi) : 3 arguments passed to 'sin' which requires 1 > sin(c(0, pi, 2*pi)) [1] 0.000000e+00 1.224606e-16 -2.449213e-16 > sin(seq(0, 2*pi, 16)) [1] 0 > sin(seq(0, 2*pi, length=16)) [1] 0.000000e+00 4.067366e-01 7.431448e-01 9.510565e-01 9.945219e-01 [6] 8.660254e-01 5.877853e-01 2.079117e-01 -2.079117e-01 -5.877853e-01 [11] -8.660254e-01 -9.945219e-01 -9.510565e-01 -7.431448e-01 -4.067366e-01 [16] -2.449213e-16 >
んで、新山さんがコメントしてたやつ
Proposal: Moratorium on Python language changes [LWN.net] Proposal: Moratorium on Python language changes [Posted October 21, 2009 by corbet] From: Guido van Rossum To: Python-Ideas Subject: Proposal: Moratorium on Python language changes Date: Wed, 21 Oct 2009 09:42:01 -0700 I propose a moratorium on language changes. This would be a period of several years during which no changes to Python's grammar or language semantics will be accepted. The reason is that frequent changes to the language cause pain for implementors of alternate implementations (Jython, IronPython, PyPy, and others probably already in the wings) at little or no benefit to the average user (who won't see the changes for years to come and might not be in a position to upgrade to the latest version for years after). わたしは言語の変更に関する moratorium (停止期間) を提案します。これは、数年のPython の 文法や言語のセマンティクスに関する変更を行わない期間を設けようというものです。その理由 は、言語に対する頻繁な変更はalternate な実装(Jython, IronPython, PyPy, and others probably already in the wings)の実装者たちに対して苦痛を与えるものだからです。それでい て平均的なユーザーにとってほとんど利益のないものです。 (who won't see the changes for years to come and might not be in a position to upgrade to the latest version for years after). The main goal of the Python development community at this point should be to get widespread acceptance of Python 3000. There is tons of work to be done before we can be comfortable about Python 3.x, mostly in creating solid ports of those 3rd party libraries that must be ported to Py3k before other libraries and applications can be ported. (Other work related to Py3k acceptance might be tools to help porting, tools to help maintaining multiple versions of a codebase, documentation about porting to Python 3, and so on. Also, work like that going on in the distutils-sig is very relevant.) 現時点における Python 開発コミュニティの主たる目標はPython 3000 を広く受け入れてもらう ことにあるはずです。Python 3.x を comfortable にできるようにする前に完了しておくべき作 業はたくさんあります。他のライブラリとアプリケーションが移植できるようになる前にPy3k に移植されなければならないサードパーティ製ライブラリの solid ports の作成といったもの が特に (そのほか Py3k の acceptance に関連する作業には移植を助けるツールも入るかもし れません。複数バージョンにまたがるコードベースの保守を助けるツールPython 3への移植に関 するドキュメントなどなど同様に、going on in the distutils-sig のような作業も非常に有益 なものです)。 Note, the moratorium would only cover the language itself plus built-in functions, not the standard library. Development in the standard library is valuable and much less likely to be a stumbling block for alternate language implementations. I also want to exclude details of the CPython implementation, including the C API from being completely frozen -- for example, if someone came up with (otherwise acceptable) changes to get rid of the GIL I wouldn't object. 注意していただきたいのは、この停止期間が設けられるのは言語それ自身と組み込み関数に対し てであって、標準ライブラリは関係ないということです。Development in the standard library is valuable and標準ライブラリの開発は valuable でありかつaltarnete language implementations に対して stumbling block になってしまうことはそれほどでもありません。 わたしはまた、CPython の実装の詳細は除外してC API は完全に凍結して含めることを望んでい ます。たとえば、誰かが GIL を取り除く変更を作ったりすれば(さもなければ受け入れ可能なも のがあれば)わたしはそれに異議を唱えることはないでしょう。 But the moratorium would clearly apply to proposals for anonymous blocks, "yield from" (PEP 380), changes to decorator syntax, and the like. (I'm sure it won't stop *discussion* of those proposals, and that's not the purpose of the moratorium; but at least it will stop worries elsewhere that such proposals might actually be *accepted* any time soon.) しかしこの停止期間は無名ブロック( anonymous blocks)、"yield from" (PEP 380), デコレーターの構文の変更などに対しては明確に適用されます。(I'm sure it won't stop *discussion* of those proposals,これらに関する*議論*が止まることはないとわたしは確信し ていてand that's not the purpose of the moratorium;それは停止期間の目的ではありません が最低限、そういった提案がすぐにでも*採用されて*しまうかもしれないという心配を止めるで しょう -- --Guido van Rossum (home page: http://www.python.org/~guido/)
コメントのほうは力尽きたので省略 ○|￣|＿
おー。こっちも順調に伸びてるなあ Python likely to halt language grammar and semantics changes for several years : programming
ところで Python3 を使ってる人っているのかね? Python は言語としては、もう世界的な「普及期」を過ぎてしまったような気がする。"
実務経験が一番だと思いますが、評価が高い資格を教えて頂けないでしょうか。
明日までに理解しなければならないのですが、一から分かりやすく説明頂けないでしょうか？(09/10/21 23:07)
The code you had before was creating and modifying a local variable called lst, so it would appear to "disappear" between calls.
「企業が参入することで、見栄えの改善など、Linux全体をより有用なものにしていくためのさまざまな要素がもたらされた。『コマーシャル対オープンソース』という図式があるわけではない。そんなことは考えたくもない」
・中途半端
ちょっと調子が良くないので今日はとっとと寝ます。
というわけでとっても中途半端なのはご勘弁。
sapply(1:100, function(x) { if (x %% 3 == 0 && x %% 5 ==0) "FizzBuzz" else if (x %% 3 == 0) "Fizz" else if (x %% 5 == 0) "Buzz" else x} )
Do I cast the result of malloc? - Stack Overflow Do I cast the result of malloc? (mallocの結果をキャストする?) In this question, someone suggested in a comment that I should not cast the results of malloc. I.e. この質問は、malloc の結果をキャストすべきではないという誰かのコメントについてです。 int *sieve = malloc(sizeof(int)*length); rather than int *sieve = (int *)malloc(sizeof(int)*length); Why would this be the case? この場合どうすればよいでしょうか?You don't cast the result, since: malloc()の結果をキャストすべきではありません。なぜならば: * It is unnecessary, as void * is automatically and safely promoted to any other pointer type. void * は自動かつ安全に任意の別のポインター型に promote されるので必要ない * It can hide an error, if you forgot to include <stdlib.h>. stdlib.h をinclude し忘れたときにエラーを隠してしまう可能性がある * It adds clutter to the code, casts are not very easy to read (especially if the pointer type is long). コードに clutter を加えることになるし、キャストは(特にポインター型が長い場合に) 極簡単に読めるものではないから。 * It makes you repeat yourself, which is generally a badness. 一般的に悪いこととされている repeat yourself をすることになるからIn C you can implicitly cast a void pointer to any other kind of pointer, so an explicit cast is not necessary. Using one may suggest to the casual observer that there is some reason why one is needed, which may be misleading. C ではvoid ポインターは他の任意の型に暗黙のうちにキャストされるので 明示されたキャストは必要ありません。In C, you don't need to cast the return value of malloc. The pointer to void returned by malloc is automagically cast to the correct type. However, if you want your code to compile with a C++ compiler, a cast is needed. A preferred alternative among the community is to use the following: int *sieve = malloc(sizeof *sieve * length); which additionally frees you from having to worry about changing the right-hand side of the expression if ever you change the type of sieve. Casts are bad, as people have pointed out. Specially pointer casts. 皆がすでに指摘しているように、キャストは悪。 特にポインターのキャスト。
Needless pointer-casts in C - Stack Overflow I got a comment to my answer on this thread: http://stackoverflow.com/questions/105477 In short I had code like this: int * somefunc (void) { int * temp = (int*) malloc (sizeof (int)); temp[0] = 0; return temp; } I got this comment: Can I just say, please don't cast the return value of malloc? It is not required and can hide errors. I agree that the cast is not required in C. It is mandatory in C++, so I usually add them just in case I have to port the code in C++ one day. C ではキャストが必須ではないことには賛成します。 However, I wonder how casts like this can hide errors. Any ideas? Edit: Seems like there are very good and valid arguments on both sides. Thanks for posting, folks.It seems fitting I post an answer, since I left the comment :P Basically, if you forget to include stdlib.h the compiler will assume malloc returns an int. Without casting, you will get a warning. With casting you won't. So by casting you get nothing, and run the risk of suppressing legitimate warnings. Much is written about this, a quick google search will turn up more detailed explanations. edit It has been argued that TYPE * p; p = (TYPE *)malloc(n*sizeof(TYPE)); makes it obvious when you accidentally don't allocate enough memory because say, you thought p was TYPe not TYPE, and thus we should cast malloc because the advantage of this method overrides the smaller cost of accidentally suppressing compiler warnings. I would like to point out 2 things: 1. you should write p = malloc(sizeof(*p)*n); to always ensure you malloc the right amount of space 2. with the above approach, you need to make changes in 3 places if you ever change the type of p: once in the declaration, once in the malloc, and once in the cast. In short, I still personally believe there is no need for casting the return value of malloc and it is certainly not best practice.One possible error it can introduce is if you are compiling on a 64-bit system using C (not C++). キャストによって起きうるエラーというのは C を使っている64ビットシステムでコンパイルした場合にあり得る。 Basically, if you forget to include stdlib.h, the default int rule will apply. Thus the compiler will happily assume that malloc has the prototype of "int malloc();" On Many 64-bit systems an int is 32-bits and a pointer is 64-bits. 基本的に、stdlib.h の include を忘れた場合、デフォルトの int rule が適用される。 したがってコンパイラーは malloc が "int malloc();" というプロトタイプを 持っていると仮定してしまうが、多くの64ビットシステムではintは32ビット幅で、ポインターは 64ビット幅です。 Uh oh, the value gets truncated and you only get the lower 32-bits of the pointer! Now if you cast the return value of malloc, this error is hidden by the cast. But if you don't you will get an error (something to the nature of "cannot convert int to T *"). なんとその結果、値は切り詰められてポインターの下位32ビットだけがとりだされてしまう! ここで、mallocの戻り値をキャストしてしまっていると、このエラーはキャストによって 隠されてしまう。しかしキャストをしていなければエラーとなる (intをT*に変換できないといったことによる)。 This does not apply to C++ of course for 2 reasons. Firstly, it has no default int rule, secondly it requires the cast. これは二つの理由で C++ では適用されない。 第一に、デフォルト int rule を持っていない。 第二に、キャストが必須である。 All in all though, you should just new in c++ code anyway :-P. とはいえ、C++では new を使うべきだと思うけどね :-PActually, the only way a cast could hide an error is if you were converting from one datatype to an smaller datatype and lost data, or if you were converting pears to apples. Take the following example: int int_array[10]; /* initialize array */ int *p = &(int_array[3]); short *sp = (short *)p; short my_val = *sp; in this case the conversion to short would be dropping some data from the int. And then this case: struct { /* something */ } my_struct[100]; int my_int_array[100]; /* initialize array */ struct my_struct *p = &(my_int_array[99]); in which you'd end up pointing to the wrong kind of data, or even to invalid memory. But in general, and if you know what you are doing, it's OK to do the casting. Even more so when you are getting memory from malloc, which happens to return a void pointer which you can't use at all unless you cast it, and most compilers will warn you if you are casting to something the lvalue (the value to the left side of the assignment) can't take anyway.On the other hand, if you ever need to port the code to C++, it is much better to use the 'new' operator.I think you should put the cast in. Consider that there are three locations for types: T1 *p; p = (T2*) malloc(sizeof(T3)); The two lines of code might be widely separated. Therefore it's good that the compiler will enforce that T1 == T2. It is easier to visually verify that T2 == T3. If you miss out the T2 cast, then you have to hope that T1 == T3. On the other hand you have the missing stdlib.h argument - but I think it's less likely to be a problem.
Should I explicitly cast malloc()'s return value? - Stack Overflow Should I explicitly cast malloc()'s return value? (malloc の戻り値はきちんとキャストすべき?) I wanted to ask about the following case: char *temp; temp=malloc(10); Since the return type of malloc is void, will the pointer returned by the malloc be implicitly cast to char type before being assigned to temp? What does the standard say in this regard? 標準ではこれについてなんと記載されてるんでしょうか? If our pointer variable is some struct type for ex. たとえば何かの構造体変数へのポインターがあったとして struct node *temp; temp=(struct node *)malloc(sizeof(struct node)); If we allocate memory to temp without casting it to struct node type, will it be implicitly cast to struct node type or is it necessary to explicitly cast it to struct node type? struct node type へのポインターにキャストすることなく わたしたちがtemp に割り付けたメモリーは 暗黙のうちに struct node type にキャストされるのか、 あるいはstuct node type へのポインターへの明示されたキャストを置く必要があるのでしょうかI don't think it applies to function pointers. それって関数ポインターには適用されないでしょC leaves it undefined whether you can cast function pointers to non-function pointers or back. C++ explicitly forbids it, and C++1x conditionally supports it C では関数ポインターから非関数ポインターへのキャストおよびそれと逆方向のキャストが できるかどうかは未定義のままになっている。 C++ では明確に禁止されていて、C++1x では conditionally supports される。And POSIX (2008 at least) requires that function pointers are the same size as data pointers, where the C standard leaves that undefined. (少なくとも2008年版の)POSIX では関数ポインターのサイズとデータポインターのサイズは 同じであることを要求しています。これは C 標準 では未定義になっています。If you like the "don't repeat yourself" mindset, it should be appealing that you don't need to repeat the type name from the declaration of the variable, in the malloc() call. Because, as folks have pointed out, you don't: pointers convert to and from void * without loss, with the exception of function pointers. Also, on that note, you don't need to repeat yourself with the use of sizeof either. Your second example, when allocating a structure, can be written like this: struct node *temp; temp = malloc(sizeof *temp); Which in my not so humble opinion is the best way. Avoiding repeating yourself cuts down on the number of things you write, which in turn cuts down on the risk that any of those things are wrong. Note the asterisk in the sizeof argument, this means "the size of the object pointed to by this pointer", which is of course the same as "the size of the type struct node" but without repeating the type name. Sure, you do repeat something, i.e. the variable name itself, but that is often a simpler expression and easier to get right, and also can be easier for the compiler to spot an error in.
しかし、市場はマーケット機能に傾きつつあり、すでに国内でも、iPhone、Androidでマーケット機能が動き出しています。おそらくこれを戻すことはできないでしょう。
want to avoid repeatedly running a lot of patterns, if really a DFA or a parallel NFA, instead of faking it with a trie structure for constant strings, and for non-constants regular Perl 5 patterns, and sorting them into longest to shortest order
The Risks and Benefits of Teaching Purely Functional Programming in First Year
HashSetに、要素の順序保証なんかありません。
boostなんてコンパイル遅くなるし, むやみやたらと複雑でコンパイルエラー分からないし, クラス名爆発して, gasが死ぬし, コードおっかけるの大変だし, 時々バグってるしで実はあんまし好きく無いのに, みんな好きだなあ. こっち行くので酸っぱい葡萄.
メールの宛先はこちら