■_
ベイスターズはまだ話の決着がついてないというw
うーむ今ひとつ見栄えがしないチャートじゃ喃 ○| ̄|_
一つ前へ
2011年10月(中旬)
一つ後へ
2011年11月(上旬)
が、入門には一番いいのではないか。という話。
a CONS is an object which cares: Common Lisp is the best language to learn programming October 30, 2011 Common Lisp is the best language to learn programming Now that Conrad Barski's Land of Lisp (see my review on Slashdot) has come out, I definitely think Common Lisp is the best language for kids (or anyone else) to start learning computer programming. Conrad Barski の Land of Lisp が出版されて、わたしは Common Lisp は子供(あるいは そのほか誰でも)がコンピュータープログラミングを学び始めるのに最良の言語ではないか と確信しています。 Between Land of Lisp, David Touretzky's Common Lisp: A Gentle Introduction to Symbolic Computation (really great book for people new to programming, available for free) and The Little LISPer (3rd edition, editions four and up use Scheme) you have three really great resources to get started. Land of Lisp のほかにも、David Touretzky の Common Lisp: A Gentle Introduction to Symbolic Computation (プログラミング入門者にとって本当に great な本で、無料で入手できます) と The Little LISPer (第三版。第四版以降はSchemeを使っています) があり、 入門するのに really great なりソースがみっつもあるのです。 Lisp's syntax is a great advantage because it is so simple to learn and has so few special cases. The interactive, iterative development style and real late-binding means you can build programs in parts and add to them as you go. The presence of real metaprogramming means you always have the ability to look at any part of your program and its state to find out what it's doing/what's wrong. The HyperSpec and Common Lisp The Language are two of the best programming language reference manuals ever written. Lisp の構文は大きなアドバンテージです。なぜなら学ぶのにとてもシンプルなものであり 特殊なケースがほとんどないからです。対話的な、iterative な開発スタイルと 本物の遅延束縛によってあなたはプログラムをパーツごとに構築するのが可能となり、 それを思うように組み合わせられることができます、 本物のメタプログラミングの presence はあなたが自分のプログラムの任意の部分を 調べる能力と、正しく動いているのか間違っているのかを見分けられる能力とを 常に持っているということを意味しています。 HyperSpec と Common Lisp The Language はこれまで書かれたプログラミング言語の リファレンスマニュアルとして最良の二つです。 The best parts about Common Lisp are that it's a language that's hard to outgrow and that it makes difficult things easy. One of the chapters in Land of Lisp explains HTTP and HTML and has you build a basic web server. That chapter is only 15 pages! There's tons of ideas in the language, and because you're not restricted to a particular programming paradigm, you're always discovering better ways of doing things and developing a personal style. Common Lisp について最良の部分は、肥大しすぎにくいということと 難しいことを簡単にするというところです。 Land of List の章のひとつで HTTP と HTML を説明しているところがあって あなたはそこで基本的なwebブラウザーを作ります。 その章はたったの15ページしかありません。 この言語にはやまほどのアイデアがあり、 特定のプログラミングパラダイムに制限されないので あなたは常に、なにかを行い個人的なスタイルを develope する 最良の方法を見つけ出せるのです。 Posted by Vladimir Sedach at 15:00
各メーカーのHDD生産が100%止まったわけではないですが、あらゆるメーカーが大量に商品を用意する年末商戦期に、例年より圧倒的に少ない量のHDDしか市場に出回らない可能性が高いという状況です。
私の会社ではExcelの新バージョンに移行するたびに、開発者が数カ月かけてExcelのマクロを更新する。時間がかかるし、計画策定やテストの手間も発生する。
So raise a glass (non-alcoholic, please – it's only 16!) to CPAN, and wish it another successful 16 years. Hat tip to Nat Torkington for the link and reminder that today's CPAN's birthday.
Q.なぜポイントフリースタイルで書くのですか? A.そこにポイントがあるから
むー、あと二つくらいはいきたかったんだがなあ
そして十一月
PST で10月30日一杯、オライリーが一部の電書を半額にしているそうです。
Dennis Ritchie Day - O'Reilly Radar Tim O'Reilly Dennis Ritchie Day On 10/30/11 let's remember the contributions of computing pioneer Dennis Ritchie. by Tim O'Reilly Sunday, October 16 was declared Steve Jobs Day by California's Governor Brown. I admire Brown for taking a step to recognize Jobs' extraordinary contributions, but I couldn't help be struck by Rob Pike's comments on the death of Dennis Ritchie a few weeks after Steve Jobs. Pike wrote: I was warmly surprised to see how many people responded to my Google+ post about Dennis Ritchie's untimely passing. His influence on the technical community was vast, and it's gratifying to see it recognized. When Steve Jobs died there was a wide lament — and well-deserved it was — but it's worth noting that the resurgence of Apple depended a great deal on Dennis' work with C and Unix. Dennis Ritchie の untimely な死去についてのわたしの Google+ への投稿に対するとても 多くの人の反応を見て、わたしは彼の technical community における影響は非常に大きく、 and it's gratifying to see it recognized. Steve Jobs が死去したとき、 there was a wide lament -and well-deserved it was - しかし、Apple の復活は C と Unix による Denis の成果に大きく依存したものなのです。 The C programming language is quite old now, but still active and still very much in use. The Unix and Linux (and Mac OS X and I think even Windows) kernels are all C programs. The web browsers and major web servers are all in C or C++, and almost all of the rest of the Internet ecosystem is in C or a C-derived language (C++, Java), or a language whose implementation is in C or a C-derived language (Python, Ruby, etc.). C is also a common implementation language for network firmware. And on and on. C というプログラミング言語は今となってはとても古いものですが、今日なお非常に広い範囲で使わ れ続けています。Unix や Linux (そして Mac OS X。さらに Windows もそうだとわたしは思ってい ます) のカーネルはすべて C で書かれたものです。web ブラウザーや主要な web サーバーはすべて が C か C++ で書かれているし、Internet ecosystem (インターネット生態系) の残りすべては C か C から派生した言語 (C++ や Java) で書かれていますし、さもなくば C や C から派生した言語 で記述されている言語 (Python、Ruby などなど) で書かれています。C はまた、 ネットワークのファ ームウェアの実装に一般的に使われている言語でもあります。And on. and on. And that's just C. Dennis was also half of the team that created Unix (the other half being Ken Thompson), which in some form or other (I include Linux) runs all the machines at Google's data centers and probably at most other server farms. Most web servers run above Unix kernels; most non-Microsoft web browsers run above Unix kernels in some form, even in many phones. Dennis はまた Unix を作り出したチームの半分でもあります(もう半分は Ken Thompson です)。 Unix は Google のデータセンターにあるすべてのマシンで動いているし、おそらくは他の server farms のほとんどでもそうでしょう。web サーバーの大半は Unix カーネル上で動いて います。Microsoft のものでない web ブラウザーの大部分は何らかの形でUnix カーネル上で 動いています。それは多くの電話(携帯電話?) であってもそうです。 And speaking of phones, the software that runs the phone network is largely written in C. 今電話について触れましたが、phone network で実行されているソフトウェアの大半は C で書かれたものです。 But wait, there's more. でもちょっと待ってください。まだあります。 In the late 1970s, Dennis joined with Steve Johnson to port Unix to the Interdata. From this remove it's hard to see how radical the idea of a portable operating system was; back then OSes were mostly written in assembly language and were tightly coupled, both technically and by marketing, to specific computer brands. Unix, in the unusual (although not unique) position of being written in a "high-level language," could be made to run on a machine other than the PDP-11. Dennis and Steve seized the opportunity, and by the early 1980s, Unix had been ported by the not-yet-so-called open source community to essentially every mini-computer out there. That meant that if I wrote my program in C, it could run on almost every mini-computer out there. All of a sudden, the coupling between hardware and operating system was broken. Unix was the great equalizer, the driving force of the Nerd Spring that liberated programming from the grip of hardware manufacturers. 70年代の終盤、Dennis は Steve Johnson と共に Interdata への Unix の移植に参加しました。 From this remove it's hard to see how radical the idea of a portable operating system was; そのころの OS は大部分がアセンブリ言語で書かれ、技術的にもマーケティング的にも コンピューターのブランドを specific するためにそれと固く結びついていました。 “高水準言語”で書かれた unusual (ただし unique ではない) な位置にあった Unix は PDP-11 以外のマシンでも動作するよう作ることが可能でした。 Dennis と Steve は機会を掴み、そして1980年代の初めまでに 基本的には世にあったすべてのミニコンピューターに その時点ではまだオープンソースコミュニティと呼ばれてはいなかったコミュニティによって Unix は移植されていました。 それはつまり、わたしのプログラムが C で書かれていれば 世にあったほとんどすべてのミニコンピューター上で実行できたということを意味します。 All of a sudden, ハードウェアとオペレーティングシステムのカップリングは壊れたのです。 Unix は great equalizer であり ハードウェアのmanufacturers の grip からプログラミングを自由にした Nerd Spring の driving force でした The hardware didn't matter any more, since it all ran Unix. And since it didn't matter, hardware fought with other hardware for dominance; the software was a given. Windows obviously played a role in the rise of the x86, but the Unix folks just capitalized on that. Cheap hardware meant cheap Unix installations; we all won. All that network development that started in the mid-80s happened on Unix, because that was the environment where the stuff that really mattered was done. If Unix hadn't been ported to the Interdata, the Internet, if it even existed, would be a very different place today. ハードウェアはもはや重要ではありません。なぜならすべてのハードウェアで Unix が走るからです。 さらに言えば、ハードウェアはほかのハードウェアと与えられたソフトウェアをめぐって争いをするからです。 Windows は明らかにx86の興隆に一役買いました。しかし Unix folks はそれを capitalize したのです。 安価なハードウェアは安価な Unix のインストールを導きます。われわれは勝利したのです。 80年代中ごろに始まるネットワーク開発はすべて Unix 上で行われました。 それは本当に重要なことが行われた環境が Unix であったからです。 もし Unix が Interdata に移植されていなかったら、 そしてそれでも Internet が存在していたとしたら、 今日のそれとは非常に異なるものであったでしょう。 I read in an obituary of Steve Jobs that Tim Berners-Lee did the first WWW development on a NeXT box, created by Jobs' company at the time. Well, you know what operating system ran on NeXT's, and what language. For myself, I can attest that there would be no O'Reilly Media without Ritchie's work. It was Unix that created the fertile ground for our early publishing activities; it was Unix's culture of collaborative development and architecture of participation that was the deepest tap root of what became the open source software movement, and not coincidentally, much of the architecture of the Internet as well. These are the technologies I built my business around. Anyone who has built their software or business with knowledge from O'Reilly books or conferences can trace their heritage back to Ritchie and his compatriots. わたし自身の話をすると、Ritchie の成果がなかったら O'Reilly Media もあり得なかったでしょう。 I don't have the convening power of a Governor Brown, but for those of us around the world who care, I hereby declare this Sunday, October 30 to be Dennis Ritchie Day! Let's remember the contributions of this computing pioneer. わたしには Govnor Brown ほどの convening power はありませんが、 わたしはここに、10月30日を Denis Ritchie Day とすることを宣言します! P.S. Help spread the word. Use the hashtag #DennisRitchieDay on Twitter and Google+© 2011, O'Reilly Media, Inc. (707) 827-7019(800) 889-8969 All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.
ちと違うか。
The Codist Objects in the Job Description May Be Fuzzier Than They Appear Published: 10/29/2011 Look for a job in most places involves reading a lot of job descriptions. Once you get a job you usually find out that the description never matches the actual work. Even worse is reading a job description for your replacement - you wonder how you ever did all of that. Eventually you begin to understand job-description-speak and being a good engineer you figure out what the coded words mean. It's like reverse engineering, except there was no engineering to speak of at the start. 1. Great work environment (素晴らしい職場環境) We give you a chair to sit in and we expect you to sit there for 10 hours a day or more わたしたちはあなたに椅子を一脚提供します。 一日に十時間以上そこに座っていることをわたしたちは期待しています。 2. Minimum Required Skills (要求されるスキルは最低限) You must know everything there is to know about everything, including stuff we no longer use and stuff that hasn't been invented yet あなたは知っておくべきことはすべて知っていなければなりません。 それにはわたしたちがもはや使っていない技術やまだ発明されていない技術も含まれます。 3. Compensation: Not Specified (報酬) We want you to go through our 24 hours of interview hell before we tell you how little the salary is 給与が以下に少額であるかを伝える前に、あなたにはわたしたちによる24時間のインタビュー地獄 を受けてもらうことを要求します。 4. Translate business requirements and functional specifications into software and suggest innovative solutions to business problems/processes that leverage technology to provide marketing differentiation, performance improvements, and better user experiences We're hiring you to write programs わたしたちはプログラムを書かせるためにあなたを雇いました。 5. Follow relevant coding standards 適切なコーディング標準に従います We don't have any but maybe you know some? Or possibly we prefer style over substance わたしたちはそういったものを一切持っていませんが、あなたは何かしら知っているでしょうか? さもなければわたしたちは substance 以上の style を良しとします。 (略) I could go on and on, reading job descriptions should be a professional sport. But I'd rather work as a programmer writing iOS or OSX apps than read a description for one. Copyright © 2007-2011 Andrew Wulf Mail
4番なにこれ…(^^; 元記事には40番まであります。
これ、「困難」どころか「不可能」だと思うんですけど きちんと「証明」できるでしょうか? …ってどうすりゃいいんだろう
Perlの正規表現について | OKWave Perlの正規表現について質問です. ■質問 aaa bbb aaa bbb ccc "ddd" aaa bbb ccc "ddd eee" aaa bbb ccc ddd eee "fff ggg hhh iii" というような,文字列が書かれているファイルがあるとします. ※ダブルクォーテーションが無い行もあります. ※ダブルクォーテーション内のスペースの数は,行によってそれぞれ異なります. これを,ダブルクォーテーションの中にあるスペースだけ アンダーバーに置換する場合の正規表現を教えて下さい. つまり,下記の出力にしたいです. aaa bbb aaa bbb ccc "ddd" aaa bbb ccc "ddd_eee" aaa bbb ccc ddd eee "fff_ggg_hhh_iii" ■条件 ※ちょっと古いPerlでも動くよう,ゼロ幅肯定/否定後読((?<),(!<))は使わないでください. ※単に実現するだけなら, # cat inputfile | print -pe 'sub f(){}(shift;s/ /_/;return $_;); s/(\".*\")/&f($1)/e;' みたいな感じで置換できそうですが,「正規表現だけで簡単に書けるかどうか」が知りたいのです (正規表現だけで実現出来る場合,そのアルゴリズムを知りたいです). そのため,関数と/eオプションは使わないでください. 投稿日時 - 2011-10-12 08:40:54質問者が選んだベストアンサー 正規表現「のみ」では困難で、私なら、 #! perl -p 1 while (s/(\"[^" ]+) ([^"]+\")/$1_$2/); ぐらいで妥協します。 ダブルクォーテーションに囲まれた文字列が1行に0~1個まで、 すなわち、以下のような行がないなら、もう少し簡略化できるでしょう。 aaa bbb ccc ddd eee "fff ggg hhh iii" "jjj kkk"
【書評】Scalaスケーラブルプログラミング第2版
まぁぶっちゃけやれるかやれないかだったらきっとやれるんだろうけど、僕は来年も同じ体制でやることに関しては非常に不安を抱いています。
この、seedで中間結果を回しつつ再帰してゆくパターンはとても良く見かけるので、慣れておくと便利。
I feel like small blogs cut their own throat by taking away the RSS capability.
Yet Another なんちゃら
Mike's World-O-Programming - Yet Another Monad Tutorial (part 1: basics) Yet Another Monad Tutorial (part 1: basics) It's a standing joke in the Haskell community that every Haskell programmer, as part of his or her learning process, will eventually write one or more monad tutorials. I'm certainly no exception. But since I know that there are already dozens of monad tutorials out there, some quite good, why on earth would I want to write Yet Another One? There are two reasons: Haskell コミュニティには、すべてのHaskellプログラマーはその学習の過程の一部として ひとつ以上のモナドチュートリアルを書いてしまうという standig joke があります。 わたしもまた例外ではありません。 しかしわたしはすでに何ダースものモナドチュートリアルがあることを知っていますから、 わたしがさらにもうひとつのチュートリアルを書こうというのは当然のことです。 それには二つの理由があります。 #ちょっと無理やり 1. I think I can explain some aspects of monads better than most of the monad tutorials I've seen. 2. My own understanding of monads has improved greatly, and I'd like to try to pass that on if I can. (略) Executive summary: What are monads? "What is a monad?" is a question I've been asked many times. I don't want to describe a monad as a "thing" because that is uninformative and also misleading. Instead, my executive summary is this: “モナドとは何か”という質問をわたしは何度も受けました。 “もの”としてのモナドを説明する気はありません。 なぜなら、それは uniformative であると同時に misleading であるからです。 わたしの executive サマリーを代わりに示します Monads are a generalization of functions, function application, and function composition to allow them to deal with richer notions of computation than standard functions. モナドとは、標準の関数よりも richer な notions of cumputation を扱うことを 可能とするための関数の一般化であり、関数の適用であり、関数の合成です。 As we progress, I hope to explain to you not only what monads are and how they work, but also why monads can be so confusing to programmers unfamiliar with them. (Hint: it isn't because they're not smart enough or because they don't know enough category theory.) 詳しい説明は略
Excel (2007) と、Libra Office の calc、キングソフトのOffice 互換ソフト とで同じ操作 (あるデータをクロス集計して、積み上げ棒グラフを作成) を やってみたのだけど、慣れがある程度あるとはいえ Excel が一番楽にできた (Excel でも2003あたりだとどうか?)。 ほとんど操作に迷うことなく欲しい結果を得られた。 さすがに良くできてるよなあと思った瞬間。 2003 以前のExcel とか互換ソフトだと、 ピボットテーブル作ってそれからグラフ作るのってかなり面倒な作業な気がする (表の「値」だけ別のシートなりにコピーしてからグラフ作成しないとうまくいかない感じ)。
電人ザボーガーとゴーカイジャーの主題歌を繰り返し聴いて時代の流れを感じてみたり(笑)
むかーしのこの手の曲の歌詞って
「倒せ」とか「命を賭けろ」とかわりと物騒な表現が頻出してたと思うんだけど、
最近のはそうでもないのね。
歌詞の変化の傾向とか調べてみたいw
"Don’t Call Yourself A Programmer, And Other Career Advice | Kalzumeus Software" http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ "Don't Call Yourself A Programmer : programming" http://www.reddit.com/r/programming/comments/lsyok/dont_call_yourself_a_programmer/
そいや「来年の言語」はどうしよう。 ってここ何年かまじめにやってなかったりするんですがw
【論理】Prolog【初心者】 313 デフォルトの名無しさん [sage] 2011/10/28(金) 18:22:41.97 ID: Be: twitterへのPrologに関する日本語の書き込みがここのところ約一ヶ月 24時間で15~20ツイートを常に維持している。 4-5月ころは3~5平均だったから、相当の増加。外国語のツイートはさらに 爆発的で5倍どころではない。 314 デフォルトの名無しさん [sage] 2011/10/28(金) 18:28:01.50 ID: Be: なんかあったの? 315 デフォルトの名無しさん [sage] 2011/10/28(金) 18:53:04.11 ID: Be: >>314 8月から「7つの言語 7つの世界」の影響で2倍以上の書き込みになった。 外国の事情は、よく判らないけど、似たようなことが起こっているようだ。 9月後半からの急増は相乗効果ではないか。過去の遺物といった否定的な 先入観による書き込みはほとんどなくなり、面白いという書き込みが突然 増えた。 316 デフォルトの名無しさん [sage] 2011/10/28(金) 19:00:13.44 ID: Be: 難しい。わからないも多いな。 317 デフォルトの名無しさん [sage] 2011/10/28(金) 19:35:17.42 ID: Be: よく分からんが、関数型言語への注目が集まった波及効果によって、 宣言型言語の一つである論理型言語(Prolog)にも関心が増えたのではないかと推測 あとはCoqのような実用的な定理証明系が登場して一般人向けの情報が増えた (実用的といっても....だし、一般人といっても.....だけどね) その結果として「論理とプログラミングとの関係」について考える人が増えたのかも 物事を形式的にモデル化するには関数だけでは足りなくて、論理も必要になるから 318 デフォルトの名無しさん [sage] 2011/10/28(金) 20:06:42.91 ID: Be: >>317 確かにそんなことをつぶやいてる人が結構いる。関数型への関心の波及効果と いうのも。対で語られることも多い。 319 デフォルトの名無しさん [sage] 2011/10/28(金) 20:57:19.14 ID: Be: そこでCurryですよ 320 デフォルトの名無しさん [sage] 2011/10/28(金) 21:08:44.19 ID: Be: 第五世代のころは世間的にはどんな扱いだったんだろう? 銀の弾丸みたいだったのかな 321 デフォルトの名無しさん [sage] 2011/10/28(金) 21:28:30.72 ID: Be: >>320 過大評価されたし、バブル期でもあった。 Prologプログラマを派遣してもらうにはひとり120万/月とか。 ナレッジエンジニアの必須技術とされた。実はプログラマ数は あまり増えなかったが、一応メジャー言語の末席。bit誌などの 広告ではProlog処理系が他を圧倒していた。 企業がPrologを見限って、C++に移行して急速に衰退した。 PrologでやりかたったことをC++でできるというわけではなく、 AI技術発展のお裾分けにあずかるという目論見はその時点で 挫折。
Prolog とは直接関係ないけど、 むかーし人工知能とかエキスパートシステムとか知識表現なんかをちょっとだけやってた。 エキスパートシステムって、パソコン(PC-9801)用のパッケージもあって 売ってたりしてたんだけどその後どうなったんだろうか。
釣り企画。かなあ…
こんなのチェックしてる自分に呆れましたね。 同一人物のものっぽい質問が OKWave にもあるんだけどそれはいいやもうw
Larry には Perl 6ネタで一冊書いてほしいなあと思ったり。 別に Programming Perl のようなそれ、というのではなく こういう Programming is Hard, Let's Go Scripting... - Perl.com 話を広げた感じのとか。 そいやこれ、途中まで訳してたけど投げ出してるな(^^; 誰か完訳した人いるのかな。
4th Edition of the Camel Book coming out in December : perl 4th Edition of the Camel Book coming out in December (shop.oreilly.com)Wow, I can learn about pseudohashes.Pseudohashes were already written up in great detail in the 3rd edition. I'm willing to bet that this new edition will remove most, if not all, of that content.I haven't read this edition; I'm going by the marketing blurb: Many Perl books explain typeglobs, pseudohashes, and closures, but only this one shows the motivations behind these features and why they work the way they do.I had no idea what pseudohashes were and just now read this: http://perldesignpatterns.com/?PseudoHash Now i'm horrified and glad they're deprecated.Honestly I have no excitement about this book. I read the last version a few times but I think there is better and cheaper alternatives now. For learning Perl the language I recommend the following: 正直云って、この本に対しては興奮を覚えない。 この本の(現時点での)最新バージョンを何度か読んだのだけど、 今となってはもっと安くて良い代替候補があると思う。 Perl を学ぶのなら、わたしがオススメするのはこんなところ: * Modern Perl (free online) * Perl Best Practices * Higher Order Perl (free online) or Mastering Perl (old draft free online) PBP is somewhat optional. I recommend it to cut off the bad habits before they start but Modern Perl does this as well to a certain extent. PBP についてはオプションで。 悪い習慣がついてしまうのを防ぐためにこの本を薦めるのだけど、 Modern Perl が一部のものについてはそうならないようにしている。 Mastering Regular expressions is a great book but it is not an all Perl book either. Mastering Regular expressions (邦訳 詳説正規表現) は、すばらしい本ではあるけれども 丸々 Perl についての本ではない。 My view is somewhat biased since I knew a few programming languages before learning Perl so keep that in mind. 自分は Perl を学ぶ以前には少数のプログラミング言語しか知らなかったので、 自分の見方にはバイアスがかかっているであろうことを念頭においてほしい。What I want to know is, will they fix the 3rd edition's glaring omission from the glossary? I'm speaking, of course, about "thingy."I'm very happy about this. It's one of the best books on programming there is. I'm definitely buying it. I read most parts of it about 7-8 years ago and I still remember its funny and witty style.
興味をひく単語がちらほら
JavaScriptCore, the WebKit JS implementation -- wingolog JavaScriptCore, the WebKit JS implementation 28 October 2011 3:51 PM My readers will know that I have recently had the pleasure of looking into the V8 JavaScript implementation, from Google. I'm part of a small group in Igalia doing compiler work, and it's clear that in addition to being lots of fun, JavaScript implementations are an important part of the compiler market today. But V8 is not the only JS implementation in town. Besides Mozilla's SpiderMonkey, which you probably know, there is another major Free Software JS implementation that you might not have even heard of, at least not by its proper name: JavaScriptCore. しかし V8 は単なる JavaScript の唯一の実装ではなく、ほかにもあなたもご存知であろう Mozilla の SpiderMonkey のように、major な Free Software である あなたがこれまで耳にしたことのない、 少なくともその正式名称である JavaScriptCore を知らないであろう JavaScript の実装が存在しています。 jsc: js for webkit JavaScriptCore (JSC) is the JavaScript implementation of the WebKit project. JavaScriptCpre (JSC) とは WebKit プロジェクトによる JavaScirpt の実装です。 (略) a register vm The interpreter has a number of interesting pieces, but it is important mostly for defining the format of bytecode. Bytecode is effectively the high-level intermediate representation (IR) of JSC. このインタープリターには多くの interesting pieces がありますが、 このレジスター vm はバイトコードのフォーマットを決める上で最も重要なものです。 バイトコードは、JavaScript の効率的な高水準の中間表現です。 (略) future So that's JavaScriptCore. The team -- three people, really -- is mostly focusing on getting the DFG JIT working well right now, and I suspect they'll be on that for a few months. But we should at least get to the point where the DFG JIT is working and enabled by default on free systems within a week or two. The one other thing that's in the works for JSC is a new generational garbage collector. This is progressing, but slowly. There are stubs in the code for card-marking write barriers, but currently there is no such GC implementation, as far as I can tell. I suspect that someone has a patch they're cooking in private; we'll see. At least JSC does have a Handle API, unlike SpiderMonkey. conclusion So, yes, in summary, JavaScriptCore is a fine JS implementation. Besides being a correct implementation for real-world JS -- something that is already saying quite a lot -- it also has good startup speed, is fairly robust, and is working on getting an optimizing compiler. There's work to do on it, as with all JS implementations, but it's doing fine. Thanks for reading, if you got this far, though I understand if you skipped some parts in the middle. Comments and corrections are most welcome, from those of you that actually read all the way through, of course :). Happy hacking!
きちんと全部読むのは結構骨がおれそう。
あとで読む(多分)
Don't Call Yourself A Programmer, And Other Career Advice | Kalzumeus Software Don't Call Yourself A Programmer, And Other Career Advice Posted on October 28, 2011 by Patrick in Uncategorized If there was one course I could add to every engineering education, it wouldn't involve compilers or gates or time complexity. It would be Realities Of Your Industry 101, because we don't teach them and this results in lots of unnecessary pain and suffering. This post aspires to be README.txt for your career as a young engineer. The goal is to make you happy, by filling in the gaps in your education regarding how the “real world” actually works. It took me about ten years and a lot of suffering to figure out some of this, starting from “fairly bright engineer with low self-confidence and zero practical knowledge of business.” I wouldn't trust this as the definitive guide, but hopefully it will provide value over what your college Career Center isn't telling you. 以下略
ここから先は想像だが、どうしてこうなるんだろうと考えてみた。
I still remember how difficult (yeah thanks to few years work with J2EE and .NET stuff ) it was initially for me to understand those LISP literals with complex expressions with nested functions
なるほど、へまな正規表現はへまなSQL並に危ないなと実感したのだった。
ある機械を使うときに、その機器に割り当てられたIPアドレスを「電話」でやり取り しないといけなかったりするんですが、アドレスが IPv6 になったとき そのやり取りはどうなるんだろうなあと考えてみたり。
ひとつイイナッと思ったのが“Do not program defensively”という言葉、これは Erlang のプログラミングルールからの引用のようですが、つまり「入力を信用しないコードを書くな」ということです。
C++ でシェルを書いているのになんでそれを活用しないのよ的な。
If the shell is written in C++, why not just export its base classes? - The Old New Thing - Site Home - MSDN Blogs If the shell is written in C++, why not just export its base classes? シェルがC++で書かれているというのなら、なぜその base class 群を export しないの? ton suggested that since the shell is written in C++, IShellFolder should have been an abstract class, and then it could have used techniques like exceptions and Inversion of Control. シェルがC++で書かれているのだから、IShell-Folder は抽象クラスであるべきで、 それにより例外だとか Invernsion of Control のようなテクニックを使えるように すべきだというたくさんの提案がなされています。 Okay, first of all, I'm not sure how Inversion of Control is something that requires C++, so I'm going to leave that aside. よろしい。わたしは Invension of Control がどのように C++ を必要としているものなのか 良くわからないので、これは脇におきます。 Second of all, who says the shell is written in C++? As it happens, when IShellFolder was introduced in Windows 95, the entire shell was written in plain C. That's right, plain C. Vtables were built up by hand, method inheritance was implemented by direct replacement in the vtable, method overrides were implemented by function chaining, multiple inheritance was implemented by manually moving the pointer around. 第二に、シェルがC++で書かれていると誰が言ったのでしょうか? IShell-Folder はWindows 95で導入されたもので、シェル全体が plain な C で 書かれていました。そう、plain な C です。 Vtable は手作業で構築され、メソッドの継承は vtable を直接置き換えることで 実装されていましたし、メソッドオーバーライドは function chaining によって 実装されていて、多重継承はポインター周りを手作業で移動することで実装されていました。 const IShellFolderVtbl c_vtblMyComputerSF = { MyComputer_QueryInterfaceSF, MyComputer_AddRefSF, MyComputer_ReleaseSF, MyComputer_ParseDisplayName, ... you get the idea ... }; const IPersistFolderVtbl c_vtblMyComputerPF = { MyComputer_QueryInterfacePF, MyComputer_AddRefPF, MyComputer_ReleasePF, MyComputer_Initialize, }; struct MyComputer { IShellFolder sf; IShellFolder pf; ULONG cRef; ... other member variables go here ... } MyComputer *MyComputer_New() { MyComputer *self = malloc(sizeof(MyComputer)); if (self) { self->sf.lpVtbl = &c_vtblMyComputerSF; self->pf.lpVtbl = &c_vtblMyComputerPF; self->cRef = 1; ... other "constructor" operations go here ... } return self; } // sample cast キャストの例 MyComputer *pThis; IPersistFolder *ppf = &pThis->pf; // sample method call メソッド呼び出しの例 hr = IShellFolder_CompareIDs(psf, lParam, pidl1, pidl2); // which expands to hr = psf->lpVtbl->CompareIDs(psf, lParam, pidl1, pidl2); // sample forwarder for multiply-derived method HRESULT STDCALL MyComputer_QueryInterfacePF( IPersistFolder *selfPF, REFIID riid, void **ppv) { MyComputer *self = CONTAINING_RECORD(selfPF, MyComputer, pf); return MyComputer_QueryInterfaceSF(&self->sf, riid, ppv); } So one good reason why the shell didn't export its C++ base classes was that it didn't have any C++ base classes. ですから、シェルが C++ の base class 群をエクスポートしていない理由は 一切の C++ の base class を持っていなかったからなのです。 Why choose C over C++? Well, at the time the Windows 95 project started, C++ was still a relatively new language for systems programming. While there were certainly people on the shell team capable of writing code in C++, the old-timers grew up with C as their native language, and the newcomers weren't taught C++ in their computer science classes. (Computer science departments still taught primarily C or Pascal, with maybe some Lisp if you took an AI class.) Also, the C++ compilers of the day did not provide fine control over automatic code generation,¹ and since even saving 4KB of memory had a perceptible impact on overall system performance, manually grouping rarely-used functions into the same region of memory of memory (so they could all remain paged out) was still a common practice. なぜ C++ ではなく Cを選択したのでしょうか> それは、Windows 95 のプロジェクトが始まった時期、 C++ は依然としてシステムプログラミングでは比較的新しい言語だったからです。 一部にはシェルのアイテムをC++のコードで書ける人もいましたが、 C をネイティブ言語としてともに成長した old-timers もいたし、 コンピューター科学のクラスで C++ を教えらていなかった新人もいました (コンピューター科学の departments では依然として primarily には C か Pascall を使っていて、AIクラスであれば Lisp も使ったりしているでしょう)。 また、当時の C++コンパイラーは自動コード生成に対する fine control を 提供していませんでしたし、4Kバイトのメモリーを節約することですら システム全体のパフォーマンスに perseptible な影響を及ぼしていましたから、 めったに使われない関数はメモリーのメモリーの同じ領域に押し込む (そのようにしてその領域全体をページアウトできるようにしていました) ことは依然として一般的な practice だったのです。 But even if the shell was originally written in C++, exporting the base classes wouldn't have been a good idea. COM is a language-neutral platform. People have written COM objects in C, C++, Visual Basic, C#, Delphi, you-name-it. If IShellFolder were an exported C++ base class, then you have effectively said, "Sorry, only C++ code can implement IShellFolder. Screw off, all you other languages!" しかしたとえシェルが originally に C++ で書かれていたとしても、 その base class 群の export は良い考えではありませんでした。 COM は言語中立なプラットフォームです。 ユーザーは C をはじめとして C++ や Visual Basic、C#、Delphi 等々で 書かれた COM オブジェクトを持っていました。ですから仮に Ishell-Folder が C++ の base class 群を export していたならば、あなたは effectively にこう言うでしょう "Sorry, only C++ code can implement IShell-Folder. Screw off, all you other languages!" But wait, it's worse than just that. Exporting a C++ base class ties you to a specific compiler vendor, because name decoration is not standardized. So it's not just "To implement IShellFolder you must use C++" but "To implement IShellFolder you must use the Microsoft Visual Studio C++ compiler." しかし待ってください。it's worse than just that. C++ の base class の exporting は 特定のコンパイラーベンダーに強く依存するものでした。 ですから単にIShell-Folder を十ソウルには C++ を使わなければならない “けれども”、 そのIShell-Folder の実装のために Microsoft Visula Studio を使わなければならない。 とはできなかったのです。 But wait, it's worse than just that. The name decoration algorithm can even change between compiler versions. Furthermore, the mechanism by which exceptions are thrown and caught is not merely compiler-specific but compiler-version specific. If an exception is thrown by code compiled by one version of the C++ compiler and reaches code compiled by a different version of the C++ compiler, the results are undefined. (For example, the older version of the C++ compiler may not have supported RTTI.) So it's not just "To implement IShellFolder you must use C++" but "To implement IShellFolder you must use Microsoft Visual C++ 2.0." (So maybe Bjarne was right after all.) とはいうものの、 But wait, it's worse than just that. Exporting a C++ base class means that the base class can never change, because various properties of the base class become hard-coded into the derived classes. The list of interfaces implemented by the base class becomes fixed. The size of the base class is fixed. Any inline methods are fixed. The precise layout of member variables is fixed. Exporting a C++ base class for IShellFolder would have mean that the base class could never change. You want support for IShellFolder2? Sorry, we can't add that without breaking everybody who compiled with the old header file. Exercise: If exporting base classes is so horrible, why does the CLR do it all over the place? 演習: base class 群の export がそんなに horrible なことであるのなら、 なぜ、CLR はそういったことを行ったのでしょう? Footnote ¹ Actually, I don't think even the C++ compilers of today give you fine control over automatic code generation, which is why Microsoft takes a conservative position on use of C++ in kernel mode, where the consequences of a poorly-timed page fault are much worse than simply poor performance. It will bluescreen your machine.* © 2011 Microsoft Corporation.
should i bother trying to make a program with python for data analysis over using excel macros? or will it be a waste of time? : Python I want to do a data analysis on a survey that is comprised of about 25 questions, maybe over 100 files. おおよそ25個の質問がある100 個以上のファイルについての survey で データ解析をしたいと考えています。 What I have been doing so far is writing excel macros to find relationships between the results between the questions.. i.e. making a macro to sort the strength of correlations of the results of all the combinations of questions by telling excel to go to a specific folder and look for it and extract, put it in, sort it at the end, etc.. わたしがこれまでやったことといえば、複数の質問の結果にある関係を見つけ出すために Excel のマクロを書いたくらいです。 要するに、 It's getting much tedious. Is there a better way to analyze such data? I'm assuming python will be more user friendly as well if other ppl wanted to use it. こんなことをするのにはうんざりしてきました。 このようなデータを解析するのにもっといい方法はないでしょうか? わたしは python がほかの ppl が使いたいと思ったならば より user friendly になるものじゃないかと思っています。 I only have basic understanding of python.. わたしは python についてはほんの基本的なところしか理解していません。 Will python be easier to process all these data? What kind of other tools do you recommend if I decide to use python for these data analysis? Should I just stick with doing macros on these files? I feel like i want to make like a desktop app just for this survey, but i don't know if that will take a lot of time.. Things i want to do are something like cross-tabulation, graphing charts(meaningful ones ofc), etc. I'm not a programmer; but intro compsci courses i took covered python.It may be too obvious to say, but if you learn and use Python, you will have a tool you can use in all sorts of situations: a general purpose scripting language, with a vast community. Today data analysis, tomorrow category theory, the next day simulation...If your not set on python R and or matlab are the defacto data analysis tools for power users.Having tried both, I would definitely use R for stats processing over Python/NumPy if given the choice.I would not. I work with R daily and too many times I have to work around the many inconsistencies of the language (accessing non-existing names in a vector that yields you an empty vector, for example). I use rpy2 to interface R with Python to have a much saner work environment. And where I could, I moved to Python/NumPy/SciPy entirely.Projects like pandas and scikits.statsmodels are aiming to fill in the gaps for doing this sort of thing in Python.And in fact I'm using both. ;)Same here. R was just too much to handle. I am not a statistician by trainig,nor a programmer, I do not want to fight the language, just develop smooth algorithms.each of them has there advantages and disadvantages. python is definitely a (by far) more universal tool...Sounds like you want something like this: http://rattle.togaware.com/ I don't think we have enough information to make a judgement on whether or not replicating this in Python is a "waste of time". The author does have Python skills though, so there's probably a good reason he chose not to use it in this case. If you were serious about ramping up your Python skills, you could make a good job of it with numpy or RPy, pyqt/pyside and something like traits/chaco, matplotlib, networkx, or similar. Maybe start something on github & let other interested people join in.From what I gather, R is way to go for this kind of stuff?Actually, Pandas: http://pandas.sourceforge.net/ It uses Numpy underneath the hood, but provides an R-style DataFrames interface. It has lots of built-in statistics and whatnot. The author is a friend of mine and is actively developing it, so if you run into features that it doesn't support, ping him via email or Twitter and I'm sure he'll be responsive.I second that statement. I recently switched part of a project to pandas and it's awesome.I've made several pull requests & bug reports against Pandas, and I can vouch that Wes is very quick to respond - stuff is often resolved within a few hours. Pandas development moves at an impressive pace.Thanks, I think Rstudio looks pretty good and Numpy stuff I'd definitely look into.. I'm tired of excel..From a purely educational point of view: No, it's not. It's worthwhile learning any new skill. From an efficiency point of view: You've already got a working system, why change it? Is it severly hindering progress? Is it in-secure? Is it slow? Inaccurate? I have to deal with changes in process in the company I work for and make sure any changes that are going through are actually for the benefit and those questions above are similar to what I have to ask.NumPy is a good library with some good documentation for this sort of thing.Maybe http://www.knime.org/ is another option worth looking at?Try resolver one Its a spreadsheet that has python embedded. It can also publish webforms i think.I already have resolver one, but I found that it's buggy and has slow response time. It's just a spreadsheet but I can put in python functions within cells.Try python as an exploratory process. Read the files calculate a few numbers and see how much hair you have lost. Matlab seems to be a little more interactive. I've made some simple data analysis/gui applications before in python and it wasn't too bad.Just so you know, you can read/write excel ss from python.Python is far easier than excel macros. Also, fuck excel macros. My boss once gave me a huge data analysis file with excel macros for piecing together 3databases and analyzing about 30 columns of data. Goddamn mess. I gave up trying to figure it out and just wrote out a few handy python functions. Also, if you need help reading and piecing together excel files, pm me.Sorry, Python tops out at processing 99 files. :-( You'll have to stick to Excel.watYeah, it's because Guido won't do a Tail Call Optimizer.
プロ野球のドラフト会議今日だったのね。 すっかり興味を失っていたので以下略。 まああれもねえ
John McCarthy ≪ Sutter's MillJohn McCarthy 2011-10-25 by Herb Sutter What a sad, horrible month. First Steve Jobs, then Dennis Ritchie, and now John McCarthy. We are losing many of the greats all at once. If you haven't heard of John McCarthy, you're probably learning about his many important contributions now. Some examples: もしあなたが John McCarthy のことを聞いたことがないのなら、今ここであなたは 彼の数多い重要な貢献を知ることになるでしょう。いくつか例を挙げます: He's the inventor of Lisp, the second-oldest high-level programming language, younger than Fortran by just one year. Lisp is one of the most influential programming languages in history. Granted, however, most programmers don't use directly Lisp-based languages, so its great influence has been mostly indirect. 彼は Lisp を発明しました。この言語はFortranよりもほんの一年若いだけの二番目に古い 高水準プログラミング言語です。Lisp は歴史上最も影響を及ぼしたプログラミング言語の 一つです。 granted, however, 大部分のプログラマーはLispベースの言語を直接使ったりはしないので その偉大な影響はほぼ間接的なものとなっています。 He coined the term “artificial intelligence.” Granted, however, AI has got a bad rap from being oversold by enthusiasts like Minsky; for the past 20 years or so it's been safer to talk in euphemisms like “expert systems.” So here too McCarthy's great influence has been less direct. 彼は“artificial intelligence”(人工知能)という言葉を発明 (coin) しました。 granted, however, AI は Minksky のような enthusiast たちによって oversold されて そのため、ここでも McCarthy の 偉大な影響は less direct なものとなったのです。 He developed the idea of time-sharing, the first step toward multitasking. Okay, now we're talking about a contribution that's pretty directly influential to our modern systems and lives. 彼はマルチタスキングの最初のステップである時分割のアイデアを生み出しました。 But perhaps McCarthy's most important single contribution to modern computer science is still something else, yet another major technology you won't hear nearly enough about as being his invention: しかしMcCarthyのmodern コンピューター科学に対する最も重要な貢献とはおそらく、 これらのどれでもないあなたがこれまでそれが彼の発明であるとは知らずにいた もう一つ別の major technology です。 Automatic garbage collection. Which he invented circa 1959. 自動ガーベジコレクションがそれです。彼はこれを 1959年ころに発明しました。 No, really, that's not a typo: 1959. For context, that year's first quarter alone saw the beginning of the space age as Sputnik 1 came down at the end of its three-month orbit; Fidel Castro take Cuba; Walt Disney release Sleeping Beauty; The Day the Music Died; the first Barbie doll; and President Eisenhower signing a bill to enable Hawaii to become a state. いえ、間違いではありません。1959年です。 For context, スプートニク1号が三ヶ月の周回の終わりに燃え尽きたことで宇宙時代が開幕し、 Fidel Castro がキューバを支配し、 Walt Disney が Sleeping Beauty を公開し、 The Day the Music Died; 最初のバービー人形が登場し、 Eisenhower 大統領が Hawaii を州へと昇格させる宣誓書にサインした その年です。 #スプートニク1号は1957年10月の打ち上げらしいんですが… GC is ancient. Electronic computers with core memory were still something of a novelty (RAM didn't show up until a decade or so later), machine memory was measured in scant kilobytes, and McCarthy was already managing those tiny memories with automatic garbage collection. GC は ancient です。コアメモリを備えた電子計算機は未だ something of a novelty であり (RAM は十年以上後にならないと登場してきません) マシンのメモリーはキロバイト単位で 数えられていたのですが、McCarthy はそのときすでにそのような小さなメモリー空間を 自動ガーベジコレクションを使って管理していました。 I've encountered people who think GC was invented by Java in 1995. It was actually invented more than half a century ago, when our industry barely even existed. わたしは GC が1995年に Java において発明されたものと信じ込んでいる人たち遭遇したことがあります。 実際には、 GC は半世紀ほど前のわたしたちの indutry が barely even existed なころに発明されていたのです。 Thanks, John. ありがとう John。 And here's hoping we can take a break for a while from writing these memorials to our giants.
Dennis Ritchie « Sutter's Mill Dennis Ritchie 2011-10-12 by Herb Sutter dmr (Dennis Ritchie) What a sad week. なんと悲しい週なのだろう。 Rob Pike reports that Dennis Ritchie also has passed away. Ritchie was one of the pioneers of computer science, and a well-deserved Turing winner for his many contributions, notably the creation of C — by far the most influential programming language in history, and still going strong today. Rob Pike が Dennis Ritchie の死去を報告しました。Ritchie はコンピューターサイエンスの パイオニアの一人であり、彼の数々の功績、とりわけ歴史上もっとも影響力を持ったプログラミ ング言語であって今日もなお強力であり続けている C の作成に対してチューリング賞が贈ら れています。 Aside: Speaking of “still going strong,” this is a landmark week for the ISO Standard C Programming Language as well. Just a couple of days ago, the new C standard passed what turned out to be its final ballot,[*] and so we now have the new ISO C11 standard. C11 includes a number of new features that parallel those in C++11, notably a memory model and a threads/mutexes/atomics concurrency library that is tightly aligned with C++11. The new C standard should be published by ISO in the coming weeks. “still going strong,”ということについてですが、 今週は ISO standard C Programming Language にとっても landmark week です。 ほんの数日前に新しい C の標準が パスしており、 そしてそれは新しい ISO C11 standard になるでしょう C11 は数々の新しい機能を含んでいて、それには メモリモデルや C++11 と tightly に alinged された threads/mutexes/atomics の concurrency ライブラリが含まれています。 この新しい C の標準はこれから数週間のうちに publish されるでしょう [*] ISO rules are that if you pass the penultimate ballot with unanimous international support, you get to skip the formality of the final ballot and proceed directly to publication. Bjarne Stroustrup made an eloquent point about the importance of Ritchie's contributions to our field: “They said it couldn't be done, and he did it.” Bjarne Stroustrup は our field に対する Ritchie の貢献の重要性について eloquent に 主張しました “They said it couldn't be done, and he did it.” (皆はそんなことは不可能だと言ったけれども、彼はやってのけた)。 Here's what Bjarne meant: Bjane の発言の意味するところはこうです Before C, there was far more hardware diversity than we see in the industry today. Computers proudly sported not just deliciously different and offbeat instruction sets, but varied wildly in almost everything, right down to even things as fundamental as character bit widths (8 bits per byte doesn't suit you? how about 9? or 7? or how about sometimes 6 and sometimes 12?) and memory addressing (don't like 16-bit pointers? how about 18-bit pointers, and oh by the way those aren't pointers to bytes, they're pointers to words?). C 以前には、今日わたしたちが industry で目にしているものよりもずっとたくさんの ハードウェアの多様性がありました。 Computers proudly sported not just deliciously different and offbeat instruction sets, コンピューターは キャラクターのビット幅 (1バイトが8ビットであることはあなたにとって都合が良いですか? 9ビットはどうでしょうか? 7ビットは? あるいは6ビットだとか12ビットはどうでしょうか?) であるとかメモリーアドレッシング (16ビットポインターはお好きでない? では18ビットポインターはどうでしょうか? and oh by the way those aren't pointers to bytes, they're pointers to words?). のような fundamental なことにいたるまでほぼすべてのことについて 非常に幅があったのです。 There was no such thing as a general-purpose program that was both portable across a variety of hardware and also efficient enough to compete with custom code written for just that hardware. Fortran did okay for array-oriented number-crunching code, but nobody could do it for general-purpose code such as what you'd use to build just about anything down to, oh, say, an operating system. 広範囲のハードウェアを通して portable であると同時に、そのハードウェアのためだけに書か れたカスタムコードに匹敵するくらい効率が良い汎用のプログラムというものは存在していませ んでした。Fortran は配列指向の number-crunching なコードには良いのですが、誰もそれを オペレーティングシステムのようなものを構築するための general-purpose なコードには使え ませんでした。 So this young upstart whippersnapper comes along and decides to try to specify a language that will let people write programs that are: (a) high-level, with structures and functions; (b) portable to just about any kind of hardware; and (c) efficient on that hardware so that they're competitive with handcrafted nonportable custom assembler code on that hardware. A high-level, portable, efficient systems programming language. そこでこの若き upstart whippersnapper (小癪なヤツ、青二才) は、次のようなプログラムを書くことを 可能とするであろう言語の specify に挑むことにしました。それは (a) 構造体と関数を備えて高水準であり (b) すべてのハードウェアに対して portable であり (c) 同じハード向けの手書きの nonportable なカスタムアセンブラーのコードに匹敵するほどハード ウェア上で効率が良い 高水準で portable で効率の良いシステムプログラミング言語です。 How silly. Everyone knew it couldn't be done. そんなことはできないと誰もが思っていました C is a poster child for why it's essential to keep those people who know a thing can't be done from bothering the people who are doing it. (And keep them out of the way while the same inventors, being anything but lazy and always in search of new problems to conquer, go on to use the world's first portable and efficient programming language to build the world's first portable operating system, not knowing that was impossible too.) C は、成し遂げられないことを知っている人たちを それを行っている人たちをわずらわせないように 遠ざけるための essential である理由のための poster child (広告塔) です (And keep them out of the way while the same inventors, being anything but lazy and always in search of new problems to conquer, 征服すべき新しい問題を捜し求める それまでは不可能であろうと信じられていた、 世界最初の portable なオペレーティングシステムを構築するため 世界最初の portable かつ efficient なプログラミング言語)。 Thanks, Dennis. ありがとう Dennis。
M110は重量が360gで、サイズもW104×H36.5×D105.3mmとコンパクトな持ち歩くのに最適なプロジェクタ。明るさは300ルーメンで、コントラスト比は10,000:1、 解像度は1,280×800ドット(WXGA)に対応する。画面サイズは、30~80インチ(投影距離は0.97~2.58m)でアスペクト比は16:10。1Wのスピーカーを内蔵する。 インタフェースは、D-Sub、HDMI、USB、ビデオ入力、microSDカードスロット。
Yesterday we talked about the Rosyln Compiler and Workspace APIs. Today we take a look at the Rosyln Service APIs and how they can be used to extend Visual Studio. The extensions we will look at today are Code Issue, Code Refactoring, Completion Provider, and Outliner.
Companies rely more and more on big data when making their decisions. Amazon, Cloudera, and IBM have announced their Hadoop-as-a-Service offerings, while Microsoft promises to do the same next year.
NTTとプリファードインフラストラクチャーは
ボツ♪
そういや先月はダムエーをついに買わなかった (創刊号からずっと買っていた)。
ruby-core が結構活発です。
[ruby-core:40356] JIT development for MRI [ruby-core:40357] Re: JIT development for MRI [ruby-core:40361] Re: JIT development for MRI [ruby-core:40384] Re: JIT development for MRI [ruby-core:40385] Re: JIT development for MRI [ruby-core:40390] Re: JIT development for MRI [ruby-core:40394] Re: JIT development for MRI [ruby-core:40395] Re: JIT development for MRI [ruby-core:40399] Re: JIT development for MRI [ruby-core:40405] Re: JIT development for MRI [ruby-core:40409] Re: JIT development for MRI [ruby-core:40322] [ruby-trunk - Feature #5482][Open] Rubinius as basis for Ruby ... [ruby-core:40323] [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.0 [ruby-core:40325] [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.0 [ruby-core:40382] Re: [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.... [ruby-core:40383] Re: [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.... [ruby-core:40401] Re: [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.... [ruby-core:40326] Re: [ruby-trunk - Feature #5482][Open] Rubinius as basis for R... [ruby-core:40330] Re: [ruby-trunk - Feature #5482][Open] Rubinius as basis for R... [ruby-core:40400] Re: [ruby-trunk - Feature #5482][Open] Rubinius as basis for R... [ruby-core:40332] [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.0 [ruby-core:40336] Re: [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.... [ruby-core:40347] [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.0
この辺とか。
Ruby 2.0 Implementation Work Begins: What is Ruby 2.0 and What's New? Ruby 2.0 Implementation Work Begins: What is Ruby 2.0 and What's New? Ruby 2.0の実装作業が始まった: Ruby 2.0 とはなんであり、何が新しいの? By Peter Cooper / October 20, 2011 Yesterday, Matz made a commit to the MRI Ruby repository bumping the trunk version from 1.9.4 to 2.0.0, marking the start of the work of implementing the long-discussed ideas for Ruby 2.0. What is Ruby 2.0? Ruby 2.0 とはなにか? Ruby 2.0 is the next major version release of MRI Ruby, the de facto official Ruby implementation. Ruby 2.0 とは、デファクトオフィシャル Ruby である MRI Ruby のリリースの次なる メジャーバージョンのことです。 Ruby 1.9.3 is due out any time soon and Ruby 1.9.4 is under active development (it has moved to a separate branch now that trunk is 2.0.0). We recently learned that Ruby 2.0 would then follow Ruby 1.9.4. Ruby 1.9.3 はまもなくリリースされますし、Ruby 1.9.4 は活発に開発がなされています (ブランチは分割されて、trunk は現在 2.0.0 となっています)。 We recently learned that Ruby 2.0 would then follow Ruby 1.9.4. Will Ruby 2.0 be a huge leap forward? Ruby 2.0 では大きな飛躍があるのでしょうか? No. While 2.0 will include a number of syntax changes, new features and general improvements, mentioned below, it is anticipated to remain backward compatible with code written for 1.9.3 and Matz has stated that the changes are less significant than those made in the 1.8 to 1.9 jump. いいえ、2.0 には後述する数多くの構文の変更であるとか、新機能、一般的な改良といったものが 含まれますが、1.9.3 向けに書かれたコードに対する後方互換を保つように anticpated されて います。また、Matz は 1.8 から 1.9 へジャンプさせたものよりも less significant な 変更をすでに始めています。 The version number goes up to 2.0 but the changes are rather small. Smaller than the ones we made in 1.9. バージョン番号は 2.0 となりますが、その変更点はむしろ小さなものです。 1.9 へとバージョンを進めたときのそれよりも小規模なものとなるでしょう。 Matz The discussion surrounding Ruby 2.0's feature set spans back several years (mostly on the ruby-talk and ruby-core mailing lists) and 2.0 was initially expected to introduce significant syntax changes and not be backwards compatible. Things have changed with Ruby 1.9 moving into production (it was originally a development only version) and 2.0 being an evolution rather than a revolution. What will (probably) be new in Ruby 2.0? Ruby 2.0 で(おそらく)新しくなるであろうことは? Ruby 2.0 is still not well defined. At the moment, ideas and features are being actively suggested and discussed, but a number have been tipped to make it into Ruby 2.0 at this early stage: Ruby 2.0 はまだ well defined ではありません。現時点で、 アイデアや機能が活発に提案されたり議論されたりしています。 しかし、この early stage にあっても多くのものが Ruby 2.0 に取り込まれています。 Keyword Arguments キーワード引数 In Ruby 2.0: What We Want to Accomplish in the Near Future (recorded in 2010), Matz showed off an example where 1.step(20, 2) could become 1.step(by: 2, to: 20) with the method definition of def step(by: step, to: limit). Ruby 2.0 では、 An implementation of keyword arguments by Yusuke Endoh actually triggered the discussion to move trunk to 2.0.0 so this is actively being discussed and implemented. キーワード引数の実装は Bytecode export/import バイトコードのエクスポートやインポート Ruby 1.9 runs on the YARV virtual machine and so will Ruby 2.0, but Ruby 2.0 is expected to make it simple to save pre-compiled Ruby scripts to bytecode representations and to then run these directly. Running pre-compiled bytecode will skip the parsing stage of the standard interpretation process. If you use Rubinius or JRuby you may be familiar with this concept. Ruby 1.9 は YARV virtual machine 上で動作し、Ruby 2.0もそうなるでしょう。 しかし Ruby 2.0 ではバイトコード表現へとプリコンパイルされた Ruby スクリプトの保存と その直接実行を簡単にすることが期待されています。 プリコンパイル済みバイトコードの実行は標準の解釈プロセスの構文解析ステージを スキップするでしょう。もしあなたが Rubinius か JRuby を使っているのならこのコンセプトには 慣れ親しんでいるかもしれません。 Refinements "Refinements" are a construction to make monkey patching safer. Essentially you could "refine" a global class within the context of a specific module so that the monkey patches would only apply in a certain context. Yehuda Katz wrote an excellent writeup about refinements last year. "Refinements" とは、モンキーパッチをより安全にするものです。 a global class within the context of a specific module を "refine" できるので モンキーパッチはある特定のコンテキストにおいてのみ適用されます。 Yehuda Katz は昨年 refinements についての素晴らしい writeup を書いています。 Refinements are.. controversial. The performance hit they'd introduce has recently made them less likely to arrive in Ruby 2.0 but I don't believe they're entirely off the table yet. Some form of namespacing of class modifications will probably eventually make it in, however. Another implementation has been called 'traits' and is shown off in the Matz video (linked above). Standard libraries becoming gems 標準ライブラリが gem となる On Twitter today, Aaron 'tenderlove' Patterson of the Ruby core team said that the Ruby standard library would be 'moved to gems' in Ruby 2.0 although many of these would still be included with the implementation (rather than being an optional extra download). And more.. As I said before, things are a bit up in the air, but the ideas surrounding Ruby 2.0 should begin to settle over the next year. A couple of weeks ago, Koichi Sasada posted the results of a Ruby 2.0 feature questionnaire to the ruby-core mailing list and encouraged people to extend it. It's not a list of features that will make it into Ruby 2.0, but an attempt to see what people would like. Koichi's initial list was: ささだ氏による initial list は以下の通りです * Cleanup syntax (構文のクリーンアップ) * Bytecode export (バイトコードのエクスポート) * Symbol GC * Remove Proc binding (Proc バインディングの除去) * Macros * Getting parse tree (解析木の取得) * Getting source code (ソースコードの取得) * Cross thread Fiber migration (スレッドを跨いだ Fiber の migration) * Standard Gem * Review all standard libraries (標準ライブラリすべてのレビュー) * Remove obsolete one standard libraries (obsolete な標準ライブラリの除去) * Improve Proc#curry (Proc#curry の改良) * Non-blocking I/O * Dtrace * GC API (replaceable GC) As Ruby 2.0 development continues, I'm going to regularly summarize what's going on and show off new features here on Ruby Inside, so keep your eyes peeled :-)Copyright © 2006–2011 Peter Cooper
Garbage Collection Synopsis, and C++ « Sutter's Mill Garbage Collection Synopsis, and C++ 2011-10-25 by Herb Sutter Insert your favorite "stop the world" joke here. In response to my note about John McCarthy's inventing automatic (non ref-counted) garbage collection, rosen4obg asked: OK, GC was invented half a century ago. When it is going to land in the C++ world? Here's a short but detailed answer, which links to illuminating reading and videos. The Three Kinds of GC The three major families of garbage collection are: ガベージコレクションには大きく三つの系統があって、それは 1. Reference counting. 参照カウント 2. Mark-sweep (aka non-moving) collectors, where objects are collected but live objects don't move. This is what McCarthy first invented. マークアンドスイープ型のコレクター。 オブジェクトの回収は行われますが、生きているオブジェクトが移動することはありません。 3. Mark-compact (aka moving) collectors, where live objects are moved together to make allocated memory more compact. Note that doing this involves updating pointers' values on the fly. This category includes semispace collectors as well as the more efficient modern ones like the .NET CLR's that don't use up half your memory or address space. マークアンドコンパクト型のコレクター。 生きているオブジェクトも割り当てたメモリーをコンパクトにするために移動します。 このことによりポインターの値が on the fly で更新されるということに注意してください。 このカテゴリには semispace collectors も含まれます GC and C++ C++ has always supported #1 well via reference counted smart pointers. Those are now standard in C++11 in the form of unique_ptr, shared_ptr, weak_ptr. C++98 had auto_ptr, but it was never great and has been deprecated. C++ は、参照カウント型のスマートポインターによって #1 を常にサポートしています。 C++ 11 で標準になったものには unique_ptr、standard_ptr、weak_ptr があります。 C++ 98 には auto_ptr がありましたが、これは great ではなく deprecate となりました。 C++ has long supported #2, but less formally because the products were nonstandard, conservative, and not as portable. The major prior art is the Boehm (later Great Circle and Symantec) mark-sweep garbage collector. The new C++11 standard has just added a minimal GC ABI to more formally bless such non-moving collectors; see Stroustrup's GC FAQ for more. C++ は長いこと #2 をサポートしてきていますが、less formally です。 なぜならその products は非標準で、conservative であり、portable ではなかったからです。 major prior art は Boehm の mark-sweep ガーベジコレクターです。 新しい標準の C++11 では minimal な CG ABI が追加されていますが、 これは non-moving なガーベジコレクターをより formaly に bless するためです。 C++ cannot support #3 without at least a new pointer type, because C/C++ pointer values are required to be stable (not change their values), so that you can cast them to an int and back, or write them to a file and back; this is why we created the ^ pointer type for C++/CLI which can safely point into #3-style compacting GC heaps. See section 3.3 of my paper A Design Rationale for C++/CLI for more rationale about ^ and gcnew. C++ は、少なくとも新しいポインター型を導入することなしには #3 のガーベジコレクターを サポートできません。なぜなら、C および C++ のポインターの値は stable であることを 要求されるからです(その値が変わってはいけない)。それによってポインターを int へキャストしたりそこから戻したりできるし、あるいは、ポインターの値を ファイルに書き出したりファイルから読み込んだりできるのです。 これはまた、C++/CLI に #3形式の compacting GC のヒープを安全に point できるように わたしたちが ^ ポインター型を作った理由でもあります。 Other GC Resources For a wonderful 57-minute conversation on garbage collection by one of the world's top GC experts, run don't walk to the C9 “Inside Garbage Collection” interview with Patrick Dussud. Patrick wrote the .NET CLR's GC, and it was far from his first; before that he had deep experience implementing Lisp runtimes, and I'm sure has forgotten more about GC than I'll ever know. He's also a great guy to work with. For a great book on GC, I love Garbage Collection by Jones and Lins.
count から。
emacs-18.59.tar.gz ファイル数 言語 空行 コメント 121 C 10,210 10,536 56,309 158 Lisp 6,108 6,658 44,540 159 C/C++ Header 4,711 6,815 5,141 1 yacc 82 136 373 7 make 76 67 297 1 Assembly 43 58 219 1 Perl 13 48 159 1 lex 25 0 125 3 Bourne Shell 34 44 117 emacs-20.1.tar.gz 553 Lisp 47,686 71,759 303,068 180 C 28,593 31,351 144,389 277 C/C++ Header 7,911 12,930 11,935 12 Bourne Shell 889 1,405 7,130 1 yacc 82 136 373 2 Assembly 42 93 253 5 DOS Batch 10 46 182 1 Teamcenter def 24 57 129 1 lex 25 0 125 3 make 17 12 94 1 Bourne Again Shell 6 16 23 1 C Shell 2 14 9 1 sed 0 3 4 emacs-21.1.tar.gz 758 Lisp 71,814 102,108 473,338 181 C 47,449 48,124 220,643 304 C/C++ Header 9,754 15,610 15,539 12 Bourne Shell 1,306 2,041 10,971 2 XML 91 106 4,262 2 Perl 337 59 1,036 1 C# 268 0 775 1 m4 44 19 469 6 DOS Batch 34 144 417 2 Assembly 42 93 253 1 Teamcenter def 27 65 138 1 lex 25 0 125 1 Bourne Again Shell 6 16 23 1 make 8 5 20 1 C Shell 2 14 9 1 sed 0 3 4 emacs-22.1.tar.gz 1,071 Lisp 118,419 150,649 894,478 183 C 52,107 58,872 238,055 12 Bourne Shell 3,103 2,881 24,153 316 C/C++ Header 11,182 18,132 17,358 1 XML 54 62 2,224 2 HTML 2 4 1,368 3 Perl 383 89 1,172 1 C# 269 0 778 6 DOS Batch 86 257 662 1 Patran Command Language 37 0 192 1 Python 24 49 159 1 m4 10 4 68 1 make 39 41 46 1 Bourne Again Shell 16 32 23 1 C Shell 7 18 9 1 Assembly 2 34 6 1 sed 0 5 4 emacs-23.1.tar.bz2 1,274 Lisp 123,494 159,385 935,625 176 C 49,795 56,490 231,086 11 Bourne Shell 3,309 2,757 25,216 135 C/C++ Header 6,366 9,441 13,917 6 Objective C 2,339 1,785 9,574 3 HTML 3 6 1,369 4 Perl 425 109 1,257 1 C# 268 0 772 6 DOS Batch 117 245 763 3 Python 56 101 333 1 Patran Command Language 36 0 190 1 m4 10 4 68 1 make 42 33 66 3 XML 17 18 43 1 Bourne Again Shell 17 31 23 1 C Shell 8 15 8 1 sed 0 5 4
んー、もうちょっと見やすくまとめなおそう。
Ada じゅーよー
Ada matters! - By Dr. Robert Dewar (AdaCore)Ada matters! By Dr. Robert Dewar The computing industry is rather peculiar: If a technology is not the latest and greatest, people think it has vanished entirely. You can, for example, often meet otherwise knowledgeable people who think that mainframes and COBOL have completely disappeared. Here at AdaCore, we often find people who think that Ada has disappeared and are surprised to find out that not only is it still around - in the domain of large, critical applications it is especially alive and well. For example, the new air-traffic control system for the UK, iFACTS ( www.praxis-his.com/news/radarMar2007.asp ),is being written from the ground up in Ada using the SPARK formal methods approach. So why is Ada still around when many college students are learning Java, and there are even people around who think C and C++ are disappearing? The answer is remarkably simple. A recent National Academy of Sciences report, "Software for Dependable Systems: Sufficient Evidence?" ( http://books.nap.edu/catalog.php?record_id=11923 ), addresses the issue of security-critical software, and states: ではなぜ、多くの大学生が Java を学んでいて、さらに C や C++ が disappearing していると 考えている人すらいるときに Ada はまだ生き残っているのでしょうか? その答えはとても簡単です。 最近の National Academy of Sciences report の "Software for Dependable Systems: Sufficient Evidence?" では、serurity-criticcal なソフトウェアや stetes の問題に言及しています。 "The overwhelming majority of security vulnerabilities reported in software products - and exploited to attack the users of such products - are at the implementation level. The prevalence of code-related problems, however, is a direct consequence of higher-level decisions to use programming languages, design methods, and libraries that admit these problems." There are no silver bullets when it comes to safety- and security-critical software. No tools can guarantee success, but as this quote indicates, it helps to use appropriate technology, including the right programming language. Last year's High Confidence Software and Systems (HCSS) conference, sponsored by NSA to address security-critical issues, featured an interesting presentation from Microsoft addressing such issues in the context of Windows. The primary sources of problems in Microsoft's experience are buffer overruns and integer overflow problems. Reasonable enough, so how can a programming language help? safety-critcal であったり serurity-critical なソフトウェアについては、銀の弾丸は存在しません。 成功を保証できるツールもありませんが、上記の引用が示すように、 正しいプログラミング言語を含む適切な技術を使うことが助けになります。 The answer is: quite a bit. However, if we look at C or C++, these languages notoriously have absolutely nothing to help avoid overruns. Microsoft is trying to add assertions to C to help, and found about 100,000 possible buffer overflows in the Vista code. Ada, by contrast, fully checks all array references as a matter of course, to eliminate the possibility of buffer overflow. Although Java is often cited as a safer alternative to C and C++, when it comes to integer overflow, the semantics for Java can introduce some dangerous vulnerabilities. Overflows wrap silently, so that adding 1 to a positive number can suddenly make it negative. In Ada, every integer value can have a sensible range assigned, and automatic checks ensure that values do not go outside this range. Java はしばしば C や C++ に対するより安全な代替物として看做されますが、 整数オーバーフローを考えたとき、そのJavaに対するセマンティクスは いくつかの危険な脆弱性を持ち込む可能性があります。 オーバーフローは黙ってラップするので、正の数値に1加えたときに 突如としてその結果が負の数になってしまう可能性があるのです。 Ada においてはすべての整数値は sensible range を割り当てられていて、 値がその範囲からはみ出さないことを保証するための検査が自動的に行われます。 These are just a couple of small examples of how a language can help. It's not at all surprising that Ada should address issues like these; it was designed for the purpose of writing large critical programs, something that cannot be said of languages like C, C++, or Java. If you search language standards for features related to safety and security, you will draw a blank, unless you are looking at the Ada standard. With Ada, you will find a whole annex devoted to high-integrity programming. Ada によって、high-integrity プログラミングのために devote された annex 全体を見出すことでしょう。 Ada does not guarantee success, but as the NAS study indicates, it makes sense to use tools suitable for the purpose; if one's purpose is writing large safety- or security-critical programs, then Ada is a natural choice. That's why it should not be surprising that Ada continues to play a critical role and that Ada is a programmer's frequent companion. Many might not be aware of that fact, however. An example, though, is the avionics system of the new Boeing 787 Dreamliner, which makes extensive use of Ada. Of course, travelers won't be aware of this when they fly, and that's the point. Software that works properly is out of sight, and out of mind. Programmers who build such systems know the advantages of Ada - and continue to choose it as one key element of critical systems. Dr. Robert Dewar is cofounder, president, and CEO of AdaCore; he also has had a distinguished career as a professor of Computer Science at the Courant Institute of New York University. He has been involved with the Ada programming language since its inception in the early 1980s and, as codirector of both the Ada-Ed and the GNAT projects, led the NYU team that developed the first validated Ada compiler. Robert was one of the authors of the requirements document for the Ada 95 revision, and he served as a distinguished reviewer for both Ada 83 and Ada 95. He has coauthored compilers for SPITBOL (SNOBOL), Realia COBOL for the PC (now marketed by Computer Associates), and Alsys Ada. He is also a principal architect of AdaCore's GNAT Ada technology. He has also written several real-time operating systems for Honeywell Inc. and frequently shares his thoughts on computers and on open-source software at conferences. He can be reached at dewar at adacore.com.
じかんたんねー
libConfuse is a configuration file parser library, licensed under the terms of the ISC license, and written in C.
例の本
買いました。
有隣堂やらジュンク堂あたりの大型書店では24日から売ってたところもあるようですが、
行ってる時間的余裕がなかったので今日に(って本来の発売日今日だよねえ)。
んでまあいろいろあるようですが
wrong, rogue and booklog - 伝記の冒頭部分で描かれるのは、ジョブズ氏が1984年、思うように販売が進まない「マッキントッシュ」を売...
wrong, rogue and booklog - 黙ってようと思ったんだけれど…
伝記「Steve Jobs スティーブ・ジョブズ」の翻訳者、井口耕二さんの語る翻訳作業の舞台裏とは? | 和洋風◎
『スティーブジョブズI・II』の翻訳について-その1: Buckeye the Translator
『スティーブジョブズI・II』の翻訳について-その2: Buckeye the Translator
『スティーブジョブズI・II』の翻訳について-その3: Buckeye the Translator
『スティーブ・ジョブズ』を買っていい電子書店はどこか - ただのにっき(2011-10-24)
ジョブズの本で考える、本の適正価格 « マガジン航[kɔː]
ぼつぼつ読んでいきます。
スティーブ・ジョブズ I
色々切り捨てて、Webでプログラミングするならこれぐらいは最低限必要、と思える分野に絞ったつもりですが…それなりに分量があります。
McCarthy believed AI should be interactive, allowing for a give and take similar to AI simulators like Eliza and, more recently, Siri
Be Pythonic Be Pythonic Shalabh Chaturvedi, 12:30AM on 20 Nov, 2009 This article is intended for new users of Python. 本 article は Python の新規ユーザーに向けています When going from one language to another, some things have to be unlearned (see Transfer of Learning). What you know from other languages may not be always useful in Python. This page contains some idioms used in Python that I particularly like, and I hope others find useful in their quest for Pythonicity. ある言語から別の言語へと移るとき、いくつかのことがらを unlearn しなければなりません。 あなたがほかの言語について知っていることは Python では有用ではないかもしれません。 このページでは、Python で使われているいくつかのイディオムを紹介します。 それは特にわたしが気に入っているものであり、ほかの人が Pythonicity を求めるときに 有用になるとよいと思っているものです。 You need counters rarely, and iterators only occasionally カウンターが必要になることはほとんどなくて、イテレーターだけでほぼ用が果たせます Wrong: 間違い(Python的でない) i = 0 while i<10: do_something(i) i += 1 Pythonic: for i in xrange(10): do_something(i) The following example indexes a list. リストのインデックスを使うサンプルです Wrong: 間違い(Python的でない) i = 0 while i<len(L): do_something(L[i]) i += 1 Pythonic: for item in L: do_something(item) An iterator variable is useful when you want to maintain looping state between two 'runs': 二つの 'runs' の間で looping state を保持したいときにイテレーター変数は便利です。 itrL = iter(L) for item in itrL: do_something(item) if is_some_condition(item): break for item in itrL: # continues where previous loop left off do_something_else(item) # 先のループの残りを続ける You may not need that for loop このようなループは必要ないかもしれません Python provides many higher level facilities to operate on sequences, such as zip(), max(), min(), list comprehensions, generator expressions and so on. See Built-in Functions for these functions and more. Python は zip()、max()、min()、list comprehensions、ジェネレーター式などといった シーケンスを操作するための higher level な facitilites がたくさんあります。 Keep data in tuples, lists and dictionaries, and operate on entire collections for that fuzzy Pythonic feeling. For example, here is some code that reads a CSV file (with first row being the field names), converts each line into a dictionary record, and calculates the sum on the 'quantity' column: f = open('filename.csv') # f is an iterator field_names = f.next().split(',') # get the first item from the iterator using next() records = [dict(zip(field_names, line.split(','))) for line in f] # this will pull remaining lines print sum(int(record['quantity']) for record in records) Though a little naive (you should be using the csv module anyway, which is part of the Python Standard Library), this example demonstrates some useful features. Using zip() with dict() you can combine a tuple of field names with a tuple of values and make a dictionary - combine with list comprehensions you can do this to an entire list in one go. Tuples are not read-only lists タプルはリードオンリーのリストではない Tuples usually indicate a heterogenous collection, for example (first_name, last_name) or (ip_address, port). Note that the type may be same (as in first_name and last_name may both be strings), but the real world meaning is usually different. You can think of a tuple as a row in a relational database - in fact the database row is even called a tuple in formal descriptions of the relational model. By contrast, a list of names is always a list, even though a particular function may not change it, that does not make it a tuple. Tuple unpacking is a useful technique to extract values from a tuple. For example: タプルのアンパッキングはタプルから値を extract するのに有用なテクニックです。 for (ip_address, port) in all_connections: if port<2000: print 'Connected to %s on %s' % (ip_address, port) Reading this code tells you that all_connections is a list (or iterable) contaning tuples of the form (ip_address, port). This is much clearer than using for item in all_connections and then poking inside item using item[0] or similar techniques. Unpacking is also useful while returning multiple values from a function: name, ext = os.path.splitext(filename) # split a file name into first part and extension # ファイル名を fist part と拡張子にわける Classes are not for grouping utility functions クラスはユーティリティ関数群のまとめるためのものではない C# and Java can have code only within classes, and end up with many utility classes containing only static methods. A common example is a math functions such as sin(). In Python you just use a module with the top level functions. Say no to getter and setter methods getter メソッドや setter メソッドはいらないと言おう Yes, encapsulation is important. No, getters and setters are not the only way to implement encapsulation. In Python, you can use a property to replace a member variable and completely change the implementation mechanism, with no change to any calling code. Functions are objects 関数はオブジェクトである A function is a object that happens to be callable. This example sorts a list of dictionaries based on the value of 'price' key in the dictionaries: # define a function that returns useful data from within an object def get_price(ob): return ob['price'] L.sort(key=get_price) # sort a list using the ['price'] value of objects in the list You can also use sorted(L, key=get_price) to return a new list instead of modifying the list in-place.
Scala Punctuation Help : scala I'm reading some Scala code, trying to learn the language and understand the code itself, and I keep coming across some unintelligible punctuation that does stuff. Problem is that it's pretty much impossible to search in any search engine for punctuation - it's all filtered out before the query get's processed. This is compounded by the fact that I haven't found any single document that outlines all the insane shortcuts that Scala seems to have in an easy way. Can you point me to, or better yet write, such a guide? Just a comment/document/html page/blog post with a list of punctuation and the thing it does. In particular, I'm confused about: * -> * ||= * ++= * <= * _._ * :: * :+= Your help would be greatly appreciated! Edit: added more to the listThose can be methods or combination of assignments and methods, so the meaning depends on the class defining the methods. Without context here is the most likely interpretation: -> is utility method creating a tuple: those are the same: 1 -> "one" Tuple2(1, "one") (1, "one") ||= is most likely apply the || method (such as boolean or) on a var and reassigning the result to it like in scala> var b = false; val a = true scala> b ||= a scala> b // Boolean = true This is similar to Java's int i = 0; i += 1 but generalized. Same for ++=, where ++ most of the time concatenates Traversable (a collection) scala> var arr1 = Array(1) arr1: Array[Int] = Array(1) scala> arr1 ++= Array(2) scala> arr1 // Array[Int] = Array(1, 2) <= is likely less than equal scala> 1 <= 1 // Boolean = true scala> 1 <= 0 // Boolean = false _._ is likely using placeholder syntax in an anonymous function. The first underscore is the object, the second the method being called. I'll have to think of an example. Edit: most likely this is invalid scala code. Can you post a larger context on this example? :: is most likely use for adding (really prepending) an element to a list or pattern matching: scala> val l = 1 :: Nil l: List[Int] = List(1) scala> l match { case a :: Nil => a case _ => -1 } // Int = 1 :+= is most likely applying :+ to an object and reassigning to the var, where :+ appends an element to a collection. scala> var v = Vector(1) v: scala.collection.immutable.Vector[Int] = Vector(1) scala> v :+= 2 scala> v // scala.collection.immutable.Vector[Int] = Vector(1, 2)
こういうことを考えると、これからますますリンガ・フランカとしての英語が浸透していくと、コストをかけて英語の実用書やドキュメンタリーを邦訳をすることは長期的に見ると虚しい試みになっていくかもしれないと思ってきたな。
某球団の話はおおむね方向性が見えてきているようですが、まだなにも書かないw
だめだ寝る。
が出たというので本屋で探してみたら、前のとは値段がえらく違うのねえ(^^;
厚みも増えてるみたいだけど。
274p → 564p ということなんだけど、目次を見た感じではなにが増えたのか良くわからなかった。 前のを読んだのもだいぶ前のことだしねえ。
O'Reilly Japan - Hacking:美しき策謀 第2版 謝辞 訳者まえがき 賞賛の声 はじめに 0x100 はじめに 0x200 プログラミング 0x210 プログラミングとは何か? 0x220 擬似コード 0x230 制御構造 0x231 if-then-else 0x232 whileループとuntilループ 0x233 forループ 0x240 その他の基本コンセプト 0x241 変数 0x242 算術演算子 0x243 比較演算子 0x244 関数 0x250 実際に使ってみる 0x251 全体像を見る 0x252 x86プロセッサ 0x253 アセンブリ言語 0x260 基本に立ち返る 0x261 文字列 0x262 符号付き、符号無し、長整数、短整数 0x263 ポインタ 0x264 フォーマット文字列 0x265 キャスト 0x266 コマンドライン引数 0x267 変数のスコープ 0x270 メモリのセグメント化 0x271 C言語におけるメモリセグメント 0x272 ヒープの使用 0x273 エラー判定付きのmalloc()関数 0x280 続・基本 0x281 ファイルアクセス 0x282 ファイルの権限 0x283 ユーザID 0x284 構造体 0x285 関数ポインタ 0x286 疑似乱数 0x287 運試しゲーム 0x300 プログラムの脆弱性攻撃 0x310 汎用的な脆弱性攻撃テクニック 0x320 バッファオーバーフロー 0x321 スタック上でのバッファオーバーフロー攻撃 0x330 bashを用いた実験 0x331 環境変数を使用する 0x340 他のセグメントでのオーバーフロー 0x341 ヒープセグメントでのオーバーフロー 0x342 関数ポインタのオーバーフロー 0x350 フォーマット文字列 0x351 フォーマットパラメータ 0x352 フォーマット文字列を利用した攻撃 0x353 任意のメモリアドレスから読み込みを行う 0x354 任意のメモリアドレスに書き込みを行う 0x355 ダイレクトパラメータアクセス 0x356 ショートライトを使用する 0x357 .dtorsを狙った攻撃 0x358 notesearchのさらなる脆弱性 0x359 グローバルオフセットテーブル(GOT)の上書き 0x400 ネットワーク 0x410 OSIの参照モデル 0x420 ソケット 0x421 ソケット関連の関数 0x422 ソケットアドレス 0x423 ネットワークのバイト順 0x424 インターネットアドレスの変換 0x425 簡単なサーバの例 0x426 ウェブクライアントの例 0x427 tinywebサーバ 0x430 下位層に目を向ける 0x431 データリンク層 0x432 ネットワーク層 0x433 トランスポート層 0x440 ネットワークのスニッフィング 0x441 生のソケットをスニッフィングする 0x442 libpcapスニッファ 0x443 階層を読み解いていく 0x444 アクティブスニッフィング 0x450 DoS攻撃 0x451 SYN Flooding 0x452 Ping of Death 0x453 Teardrop 0x454 Ping Flooding 0x455 Amplification Attack 0x456 分散DoS攻撃 0x460 TCP/IPのハイジャック 0x461 RSTを用いたハイジャック 0x462 継続的ハイジャック 0x470 ポートスキャン 0x471 ステルス型のSYNスキャン 0x472 FINスキャン、X-masスキャン、NULLスキャン 0x473 デコイの使用 0x474 アイドルスキャン 0x475 積極的な防御策(シュラウド) 0x480 ネットワーク経由でハッキングを行う 0x481 GDBを用いた分析 0x482 最後の詰め 0x483 ポートバインド型シェルコード 0x500 シェルコード 0x510 アセンブリ言語 VS. C言語 0x511 アセンブリ言語によるLinuxのシステムコール 0x520 シェルコードへの道 0x521 スタックを用いたアセンブリ命令 0x522 GDBを用いた調査 0x523 nullバイトの除去 0x530 シェルを起動するシェルコード 0x531 優先順位の問題 0x532 さらに小さく 0x540 ポートバインド型シェルコード 0x541 標準ファイル記述子を差し替える 0x542 制御構造の実装 0x550 コネクトバック型シェルコード 0x600 攻撃と防御の共進化 0x610 攻撃を検知する 0x620 システムデーモン 0x621 シグナル超入門 0x622 tinywebデーモン 0x630 ハッカーの必需品 0x631 tinywebdに対する脆弱性攻撃ツール 0x640 ログファイル 0x641 人ごみに紛れる 0x650 見逃してはいけない明らかな兆候 0x651 小分けにして考える 0x652 すべてを元通りにする 0x653 子プロセスでの作業 0x660 高度なカムフラージュ 0x661 ログに出力されるIPアドレスを詐称する 0x662 ログレス攻撃 0x670 全体インフラ 0x671 ソケットの再利用 0x680 ペイロードを隠密裏に搬入する 0x681 文字列のコード化 0x682 NOPスレッドの隠蔽 0x690 バッファの制約 0x691 ASCIIコードの印字可能文字だけで作られたポリモーフィックシェルコード 0x6a0 さらなる対策 0x6b0 実行不能スタック 0x6b1 ret2libc 0x6b2 system()へのリターン 0x6c0 スタック領域のランダム化 0x6c1 BASHとGDBを用いた調査 0x6c2 linux-gateのバウンスオフ 0x6c3 知識の応用 0x6c4 最初の試み 0x6c5 確率を味方にする 0x700 暗号学 0x710 情報理論 0x711 無条件安全性 0x712 ワンタイムパッド 0x713 量子鍵配布 0x714 計算量的安全性 0x720 アルゴリズムの実行時間 0x721 漸近的計算量 0x730 対称暗号 0x731 Lov Groverの量子検索アルゴリズム 0x740 非対称暗号 0x741 RSA 0x742 Peter Shorの量子因数分解アルゴリズム 0x750 ハイブリッド暗号 0x751 MitM攻撃 0x752 SSHプロトコルによるホストのフィンガープリントの違い 0x753 ファジーフィンガープリント 0x760 パスワードクラッキング 0x761 辞書攻撃 0x762 総当たり攻撃 0x763 ハッシュ検索テーブル 0x764 パスワード確率マトリクス 0x770 ワイヤレス802.11b暗号 0x771 WEP(Wired Equivalent Privacy) 0x772 RC4ストリーム暗号 0x780 WEP攻撃 0x781 オフライン総当たり攻撃 0x782 キーストリームの再利用 0x783 IVに基づく解読用辞書データベース 0x784 IPリダイレクション 0x785 FMS(Fluhrer、Mantin、Shamir)攻撃 0x800 まとめ 0x810 参考文献 0x820 リソース 索引
O'Reilly Japan - Hacking:美しき策謀 訳者まえがき まえがき 1章 0x100 はじめに 2章 0x200 プログラミング 0x210 プログラミングとは何か? 0x220 プログラムの脆弱性攻撃 0x230 汎用的な脆弱性攻撃テクニック 0x240 マルチユーザにおけるファイル権限 0x250 メモリ 0x251 メモリの使用を宣言する 0x252 文字列終端のNULLバイト 0x253 メモリ領域のセグメンテーション 0x260 バッファオーバーフロー 0x270 スタックを足場にしたオーバーフロー攻撃 0x271 攻撃コードを使わない攻撃 0x272 環境変数の使用 0x280 ヒープやbssを足場にしたオーバーフロー攻撃 0x281 ヒープを足場にしたオーバーフローの基本 0x282 関数へのポインタのオーバーフロー 0x290 フォーマット文字列を利用した攻撃 0x291 フォーマット文字列とprintf() 0x292 フォーマット文字列の脆弱性 0x293 任意のメモリアドレスを読み出す 0x294 任意のメモリアドレスに書き出す 0x295 ダイレクトパラメータアクセス 0x296 dtorsを狙った攻撃 0x297 GOTの上書き 0x2a0 シェルコードを開発する 0x2a1 よく使用するアセンブリ命令 0x2a2 Linuxのシステムコール 0x2a3 Hello, world! 0x2a4 シェル起動コード 0x2a5 他のセグメントを使用しないようにする 0x2a6 NULLバイトの除去 0x2a7 スタックを活用することでシェルコードをさらに小さくする 0x2a8 ASCIIコードで表示可能な命令 0x2a9 ポリモーフィックシェルコード 0x2aa ASCIIコードの表示可能文字だけで作られたポリモーフィックシェルコード 0x2ab Dissembler 0x2b0 libcへのリターン 0x2b1 system()へのリターン 0x2b2 libcへのリターンの連鎖的な実行 0x2b3 ラッパを使用する 0x2b4 libcへのリターンを用いてNULLを出力する 0x2b5 1回の呼び出しで複数のワードを出力する 3章 0x300 ネットワーキング 0x310 ネットワーキングとは? 0x311 OSIの参照モデル 0x320 興味深い階層の詳細 0x321 ネットワーク層 0x322 トランスポート層 0x323 データリンク層 0x330 ネットワークのスニッフィング 0x331 アクティブスニッフィング 0x340 TCP/IPのハイジャック 0x341 RSTを用いたハイジャック 0x350 DoS攻撃 0x351 Ping of Death 0x352 Teardrop 0x353 Ping Flooding 0x354 Amplification Attack 0x355 分散DoS攻撃 0x356 SYN Flooding 0x360 ポートスキャン 0x361 ステルス型のSYNスキャン 0x362 FINスキャン、X-masスキャン、NULLスキャン 0x363 デコイの使用 0x364 アイドルスキャン 0x365 積極的な防御策(シュラウド) 4章 0x400 暗号学 0x410 情報理論 0x411 無条件安全性 0x412 ワンタイムパッド 0x413 量子鍵配布 0x414 計算量的安全性 0x420 アルゴリズムの実行時間 0x421 漸近的計算量 0x430 対称暗号 0x431 Lov Groverの量子検索アルゴリズム 0x440 非対称暗号 0x441 RSA 0x442 Peter Shorの量子因数分解アルゴリズム 0x450 ハイブリッド暗号 0x451 MiM攻撃 0x452 SSHプロトコルによるホストのフィンガープリントの違い 0x453 ファジーフィンガープリント 0x460 パスワードクラッキング 0x461 辞書攻撃 0x462 総当たり攻撃 0x463 ハッシュ検索テーブル 0x464 パスワード確率マトリクス 0x470 ワイヤレス802.11b暗号 0x471 WEP(Wired Equivalent Privacy) 0x472 RC4ストリーム暗号 0x480 WEP攻撃 0x481 オフライン総当たり攻撃 0x482 キーストリームの再利用 0x483 IVに基づく解読用辞書データベース 0x484 IPリダイレクション 0x485 FMS(Fluhrer、Mantin、Shamir)攻撃 5章 0x500 まとめ 参考文献 索引
んーむ。ジョブズ本があるし後回しでいいかなあ。
Shibuya.lisp » Blog Archive » 括弧への異常な愛情 または私は如何にして心配するのを止めてCommon Lispを愛するようになったか Shibuya.lisp » Blog Archive » Compiler言語に負けないハッキング耐性を持ちながら更なるセキュアなアプリ構築を容易にしたSecure Scheme Suite の提案 Shibuya.lisp » Blog Archive » Lispマシンを作ってみた
トップバッターの方は時間配分を間違えた感じがあったのが残念ですね。 時間が足りなくなって飛ばしてしまったスライド(と内容)が気になるw
二番目のセッションはどうにもわたしには狙いどころが良くわかりませんでした(^^;
で、本日の主役 :) こういう (ハード寄りという意味での) low-level な話は大好きです。 命令フォーマットの設計とか興味津々で聞いてました。 んで、DRAMの制御のあたりはやはり難しいのだなあと。 わたしは仕事でもメモリーコントローラーに丸投げ(リセット直後にパラメーターセットするだけ) しかやったことがないので、FPGAで云々というのはやるときついでしょうね。
LT 編はまた。 はやみずさんの飼っているハリネズミが可愛いのはわかった :)
そのLTで発表できるようなネタをようやく思いついたので、次回なんとかできるように頑張る (と自分にプレッシャー)。
twitter で気になる発言があったときに、 どういう意図でそのように発言したのかを確かめたいことがままあるのだけど、 それが RT で流れてきたもので自分とフォローしている/されている の関係がない人 だったりするとどう切り出したものやら悩んでしまって結局何もしないということが。 喧嘩売ってるようにとられちゃかなわんしねえ。
で、そういうものの例を挙げようとしたらなぜか発言主がそのツイートを削除してしまったw
以前から気にはなってたんですよ、 「ハンバーグ」でひとつの単語なんだからそこから「バーガー」だけ切り出して 「テリヤキバーガー」とか「チーズバーガー」とかいうのは変じゃないかと。 最近なにかのときに基本あれは「サンドウィッチ」であって、 ~バーガーと呼ぶのは日本語化された結果だと教えてもらいました (マクドナルドに限ったことではないそうです)。
マクドナルドのハンバーガーはサンドイッチだった | 水無月ばけらのえび日記 ビッグマック200円の話題でマクドナルドのサイトを見ていたのですが、驚きの発見が。 それはメニューのページ。 「ビッグマック」や「チーズバーガー」などのメニュー、一般的にはハンバーガーと呼ばれてい ると思いますが、公式サイトのメニューに付けられた見出しのラベルは、なんと「サンドイッチ」。 下の方にも「サンドイッチとのお得なバリューセット」という文言がありますし、間違いなどで はないようです。どうもマクドナルドでは、いわゆるハンバーガー類を正式には「サンドイッチ」 と呼ぶらしいですね。
Is Java Really Losing Popularity Among Developers? 本当に developer たちからの支持をなくしてしまったの? というのを TIOBE index 結果から推察。
Is Java Really Losing Popularity Among Developers? | Java.net Is Java Really Losing Popularity Among Developers? Posted by editor on October 22, 2011 at 1:17 AM EDT In his latest post, Dustin Marx points us to an article by Paul Krill which was originally posted on InfoWorld, titled Survey: Java losing popularity among developers. The article is subtitled: "If recent trends continue, C could supplant Java as the most popular programming language by next month." Being a student of numbers and graphs and statistics and mathematical modeling of all types of data (see, for example, my 1999 Stock Market Modeling Techniques paper), I found this title and subtitle both provocative and interesting. I wasn't surprised to find that the base data for the article was the latest TIOBE Programming Community Index (October 2011). Their October headline is "Java is losing ground despite its new version 7 release." And the first sentence is: Java lost almost 1% of its popularity in September. If this trend continues, C will be number one again next month. Huh? So, are they saying that 1% of global Java developers were suddenly laid off in October? That seems unlikely! What are we really talking about here? Let's take a look at the TIOBE October 2011 graph: (略)Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
reddit での反応。
Is Java Really Losing Popularity Among Developers? : programming tl;dr version: Java isn't losing it's mindshare, it's losing it's sex appeal.If it ever had any. Jave got that backoffice Cobol feel a long time back. (I am not saying that it is a bad thing).Oh, it had sex appeal...in 1995. Seriously. People got excited about it. A language that didn't lock you in to Microsoft tools? A language that you could write a program in Windows, compile on a UNIX workstation, and run on MacOS? Applets that could be embedded into webpages? This was sexy stuff, back then.Yep. I was thrilled to move to Java from years of C++, and before that C. Automated garbage collection, without any horrible auto_ptr stuff? Built in cross-platform gui tooling? And later on, the magic of reflection and generics... Mind you, now I've moved on again, to a range of newer languages (as suits the environment) - [J]Ruby, (Java|Coffee)Script, Scala, maybe if I'm lucky some Clojure. Java is a fine language, but it's stagnated, and all these languages have moved beyond it.C ? It's still more run-anywhere than Java ever was - from 8-bit-CPUs to odd 20-bit and 24-bit processors.Simplicity has always been a design goal of Java. I don't agree. Scheme is simple. I think that Java had as design goals: * Platform portability * Being safe * Adding certain features that C and C++ didn't have in the language itself to reduce fragmentation across platforms. Threads, networking, GUI stuff, etc. * Improving the way in which interfaces to modules were exposed. * Adding GC A simple languages means complicated (or at least verbose) code. I disagree. Well, okay. At an extreme point, a simple-to-the-exclusion-of-all-elese language might do that. Say you had a Turing machine or something. I think that Java's verbosity tends to be due at least in part to two factors: (1) wanting to avoid hard-to-read abbreviated terms of the sort that show up all over in C and (2) its original lack of generic containers (so that casting showed up everywhere a container does). Sex appeal was not a goal. Possibly not in designing the language itself, though its marketing tried really, really hard to attach "cool" and "Java". In this context simplicity means a lack of features (generics, value semantics, all that crazy shit you read about when you read a C++ standard). Java has generics and also pass-by-value semantics.Java has generics Still rudimentary when compared to Scheme macros, or C++ templates and constexpressions.As someone who has made a good living from Java for ten years, IT'S TOO DAMNED VERBOSE!!!! That said, Java has produced some great pragmatic libraries, like Spring, Ibatis, Hibernate, and Wicket. While they lack the panache of C++'s STL, they make real-world "plumbing" problems go away. But still, yeah, I'm tired of writing Java.C is my first love and last love.The JVM still has potential, Java the language does not.That's the biggest question. Everyone has been saying for 10 years that Java is dying, but then what on earth should replace it? * Redditors say Python. (and okay, a few say Ruby) * Scala fans say Scala * Clojure fans say Clojure * Haskell fans say... nothing (hmmmm) * Go fans say Go! * Groovy fans say Groovy * Cylon fans say nothing (but they do have a plan) * Lua fans say Lua * Putri fans say Putri * F# fans say F# * etc etc Meanwhile, there's barely a language that really is getting the critical mass that Java has. There's just 20 semi-popular and over a 100 obscure languages all claiming to be The Next Java.
なんで Haslell fan はなにも言わんのだろう?
sympy - Python library for symbolic mathematics - Google Project Hosting SymPy is an open source Python library for symbolic mathematics. It aims to become a full-featured computer algebra system (CAS) while keeping the code as simple as possible in order to be comprehensible and easily extensible. SymPy is written entirely in Python and does not require any external libraries.
古い発言が元で reddit でまた盛り上がってましたが
An interview with Zed Shaw October 21, 2011 Who are you, and what do you do? I am Zed A. Shaw and my life can currently be carved into three pieces of the pie: I have written software for other people, and also created my own open source projects like Mongrel, Lamson, Mongrel2, and a bunch of others. I now tend to write books teaching people to code, insane satirical blog posts to piss people off, essays on various topics, and I am the creator of one software methodology. Included in this is frequent speaking gigs at different conferences, teaching classes on programming, and just generally being a kind of Clown-Pauper-Prince of the software world. I also attempt to make music and post everything I make, good or bad, as part of the act. I created Fretwar as an experiment in getting other people to give people a reason to make music and put it online. I've also built 3 guitars, two of which really suck and one which I love and play a lot. (略) What would be your dream setup? This is my dream setup. It's a constant work in progress, but if I'm going to spend most of my days and nights doing something I'm going to invest the time and money to have nice good tools. That's part of the fun of technology. You can envision something that you want to try or produce and then go looking around for a piece of tech to build or buy. 略
訳している余裕が
とりあえず大見出しのところを抜き出し。
Signs that you're a bad programmer - Software Engineering Tips Signs that you're a bad programmer Why was this written? Most of these faults were discovered the hard way by the author himself, either because he committed them himself or saw them in the work of others. This paper is not meant for grading programmers, it was intended to be read by programmers who trust their ability to judge when something is a sign of bad practice, and when it's a consequence of special circumstances. This paper was written to force its author to think, and published because he thinks you lot would probably get a kick out of it, too. 1. Inability to reason about code 2. Poor understanding of the language's programming model 3. Deficient research skills / Chronically poor knowledge of the platform's features 4. Inability to comprehend pointers 5. Difficulty seeing through recursion 6. Distrust of code Signs that you are a mediocre programmer 1. Inability to think in sets 2. Lack of critical thinking 3. Pinball Programming 4. Unfamiliar with the principles of security 5. Code is a mess このあともいろいろ続く
これも別の機会に Design mistakes in mixed C C and Lua projects was: How can I be sure LuaJIT is working?
Design mistakes in mixed C/C++ and Lua projects | Hacker News This is interesting. What made you adopt Io instead of Lua? Or was it dictated by the engine?First, because I knew Io and not Lua. I had gotten interested in Io years before. Io was actually my first dynamic language, not Python or Ruby or Javascript. I stopped using Io for a few years when I moved on to other things, but _why's article "Io Has a Very Clean Mirror" brought it back to mind. I seriously considered Lua but I felt object orientation needs to be incorporated very fundamentally in a language. I had previous experience with mIRC which shares Lua's idea of "everything is a table", and while mIRC is no doubt productive I felt tables would be a step backwards compared to Io's objects. At the time I started, the C/C++ binding frameworks for Lua were not as mature as they are now, not as numerous, or I simply wasn't aware of them. From a language aesthetic standpoint my decision came down to Io, or Ruby, but I looked at the C Ruby source code and it didn't seem very suited to embedding. For instance the official implementation of Ruby had some dependence on global/static variables which precluded the idea of running multiple instances of the VM in a process. Io allows this, although I haven't used it yet; I plan to use it to support threading, one VM per thread. And basically the Ruby interpreter codebase wants to own main() and call my code as a library; I wanted to own main() and call the interpreter as a library. Io supports this, and it's codebase is smaller.
This is amazing. Microsoft has made the inner workings of their IL compiler open to everyone by exposing the inner workings through an API.
Welcome to getpython3.com - this site aims to be a resource for Python 3 for developers.
・大盛堂
創業者のエピソードが昨日辺りのついったーで流れてましたが、
西武百貨店のある辺りから今のところに移ったのっていつ頃でしたっけ?
・フリーソフト Free software
・twitter でによによ
・買った
同じ作者の別の作品があわせて発売されていたのだけど、
シュリンクされていて中身を見られなかったので結局買わなかった。
たぶん大外れにはならないと思うのだけど、
上下巻をノーチェックでぽんと買うほどの余裕が今はないので(^^;
そりゃあ店員さんに見せてくれといえば見せてもらえるのだろうけど、心理的障壁高いのよね。
シュリンクせざるを得ない事情はわからんでもないのだけど、どうにかならんもんですかい喃。
・んで、こういうのも買った。
雑誌はほとんど追いかけなくなっているのでこういう作品があったとは気がつかなんだ。
・shibuya.lisp#7
行ってきた。あとで書く。
Perl 6を学びたい。どうすれば? というお悩み。
Learning Perl 6, a good idea? : perl I've never used Perl, but I'm intrigued by its philosophy and community. I'm currently thinking of learning Perl 6, but is it perhaps too early? When discussing the features of Perl 5 most people mention CPAN and how great it is, but my understanding is that there is no such thing for Perl 6 yet. Also, I'm unsure about the state of documentation and books. My question is: Why should one learn Perl 6 nowadays and what does it have to offer? わたしは Perl を使ったことがありませんが、その philosophy であるとかコミュニティに 興味があります。今、Perl 6を学んでみようかと考えているのですが、まだ早すぎるでしょうか? Perl 5の機能について議論をしたとき、ほとんどの人は CAPN とそれがどれほどすごいもので あるかに言及します。でもわたしの理解は Perl 6 でそれにあたるものはまだないという ものです。また、Perl 6のドキュメントや書籍の整備の状況についてよく知りません。 わたしの疑問はこうです: Perl 6を今日学ぶべき理由と、offer すべきものはなにか?Perl 6 Modules lists ~100 modules which worked with Rakudo at some time in the past, but that's no guarantee they work now. The book Using Perl 6 is a work in progress. It needs a lot of editing. Beyond that, you probably need to scour the Perl 6 specification and trawl through several blog posts. Learning something new is often a good thing in and of itself.Learning something new is often a good thing in and of itself. This is the main reason for why i'd encourage people to look at Perl 6.I love the ideas behind perl 6, and the language has some amazing things in it, but the implementations are all quite limited right now. わたしは perl 6の背景にあるアイデアが好きだし、言語そのものもいくつかの amazing な ものを持っています。けれども、その実装は現状では非常に限定されたものに過ぎません。 Perl is in a very awkward place right now, with perl 5's arrow syntax being quite different from the "." syntax all the other languages have standardized on, and it's C based implementation being oriented around command line, unix, and single threaded short running applications. It's asynchronous IO is a bit clunky and it's threading, while I've found rather easy to use, seems to cause lots of people trouble. Perl 6's promises to address a lot of 5's issues eventually, it's syntax is much more appropriate for today's programming, but the implementations are all incomplete and still quite a way from being ready for production. From what I understand none of the implementations have touched threading in a meaningful way. To me, learning perl 6 as a way to broaden your programming horizons makes sense, but if you want to actually do anything with it, go for perl 5.If you are interested in a useful language, learn Perl 5. But if your interest goes beyond that and you're interested in languages, Perl 6 is totally amazing and worth learning. あなたが有用な言語に興味があるのなら Perl 5を学びましょう。 そうではなくて乗り越えようとしているものだとか言語そのものに興味があるのなら Perl 6 は totally amazing で学ぶ価値のあるものでしょう。Chromatic expresses why Perl 6 isn't much use at the moment as a practical language pretty well. That being said, Perl 6 takes all the greatest and best ideas from the popular dynamic languages, tidies them up and puts them all in 1 place for you to play with, and then occasionally introduces bugs to them. If you're looking for community, Perl 5 is still the place to be, and with Moose and Method::Signatures and a few other tools you get a language approaching the futuristic idea's of Perl 6.
もうひとつ reddit から。
small question about the case macro in common lisp : lisp consider: (defun test (x) (case x ((1 2 3 a b c) t) (t 'nil))) (test 1) -> t (test 'c) -> t (test 'f) ->nil ok fine. makes sense. But because case is a macro, the list of symbols to compare x against in each clause of the case statement is not being evaluated. So what if I wanted to do something like (case 1 ((range 5) t) (t 'nil)) -> nil even though 1 is certainly in (range 5). I dont know much about CL, so I made up some random crap like (case 1 (`(,range 5) t) (t 'nil)) ->nil and other variants. I even tried: (let ((x '(1 2 3)) (case 1 (x t) (t 'NIL)) ->nil and (let ((x '(1 2 3)) (case 1 ((x) t) (t 'NIL)) -> nil So how can I get the case macro to actually expand the first argument of a clause inside a case statement?(let ((list '(a b c d e f g))) (cond ((member 'e list) :yes) (t :no)))Yes. Much better than my suggestion. :)yes cond is certainly the right way to go in that particular case, but I was wondering the syntax to force case (or similar macro) to eval the case keys.Long story short, I believe CASE works the way it does because of historical performance considerations (which are probably still pertinent today). Look at why and how switch statements work in C to gain some insight. However, you can make a new macro that takes something that looks like a case statement and converts it into a COND statement. For instance, see CLISP's macro EXT:FCASE for an example of how you might do this, although I don't think FCASE does exactly what you want. Edit: In case you don't have the source at hand, here is what I have in my personal util library (adapted/stolen from CLISP source): #-clisp (defun case-expand (whole-form form-name test keyform clauses) (let ((var (gensym (concatenate 'string (symbol-name form-name) "-KEY-")))) `(let ((,var ,keyform)) (cond ,@(maplist #'(lambda (remaining-clauses) (let ((clause (first remaining-clauses)) (remaining-clauses (rest remaining-clauses))) (unless (consp clause) (format t "~a: missing key list" whole-form) (break) ) (let ((keys (first clause))) `(,(cond ((or (eq keys 'T) (eq keys 'OTHERWISE)) (if remaining-clauses (format t "~a: the ~a clause must be the last one" whole-form clause ) 't)) ((listp keys) `(or ,@(mapcar #'(lambda (key) `(,test ,var ',key)) keys))) (t `(,test ,var ',keys))) ,@(rest clause))))) clauses))))) #-clisp (defmacro fcase (&whole whole-form test keyform &body clauses) (case-expand whole-form 'fcase test keyform clauses))No, case does not evaluate case keys. You can use read-time evaluation if you want to test for constants, like this: (defconstant +foo+ (list (gensym) (gensym))) (defun bar (x) (case x (#.+foo+ 100) (t 0))) That will only work for compile-time constants, though.I think everybody ends up writing that macro. You should, too, it's a good exercise :). 誰もが結局はそういうマクロを書くものだと思うし、あなたもそうすべきだろう。 いい練習になるよ :) But if you don't want to, you can use alexandria:switch.
あるあるなお悩みから。
Perl Search Engine – Perl Hacks Perl Search Engine Often on sites like StackOverflow you'll see questions that people could have answered for themselves if they had just searched the right web sites (usually perldoc or CPAN). But instead, they just went straight for Google and ended up with some dodgy, out of date information that just left them confused. StackOverflow のようなサイトでは、webサイト(通常は perldoc とか CPAN) を検索するだけで 質問者自身が回答を見つけられるような質問をしばしば見かけます。 彼らはそういったことはせずにただ単にぐぐっていまい、結局のところ doggy で混乱を招くだけのような out of date な情報をつかんでしまっています。 In order to get round that, I've created a Google Custom Search Engine which searches known Perl web sites. You can try it out here. そういった状況に対処するために、 既知の Perl web サイトを検索する Google Custom Search Engine を作ってみました。 If you want to use this search engine on your site, the code is below.<div id="cse" style="width: 100%;">Loading</div> <script src="//www.google.co.uk/jsapi" type="text/javascript"></script> <script type="text/javascript"> google.load('search', '1', {language : 'en'}); google.setOnLoadCallback(function() { var customSearchControl = new google.search.CustomSearchControl('008350714774536055976:a2zesuxuecs'); customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET); customSearchControl.draw('cse'); }, true); </script> <link rel="stylesheet" href="//www.google.com/cse/style/look/default.css" type="text/css" />
Please explain Haskell for a layperson : haskell I know programming a little, and every programming news site I visit talks/praises about Haskell. Since I have a poor mathematical/theoretical background on CS, I can't see why Haskell is admired by a huge amount of people. Could any of you please explain me in a very intuitive way as to why Haskell could become better than C/C++/Java and so on? What are its weakness and strength? わたしは少ししかプログラミングを知らないのですが、わたしが訪れるプログラムニュースサイトは どこも Haskell について言及しています。わたしのコンピューター科学に関する数学的な 背景だとか理論的な背景は poor なものなので、なぜ Haskell がこれほど多くの人から 賞賛されているのかが理解できないのです。なぜ Haskell が C/C++/Java などよりも 良いものになる可能性があるのかを、直感的な方法でわたしにどなたか説明しては もらえないでしょうか? Haskell の弱点と強みとは何でしょうか?This is a very common question in this sub-reddit. See cdsmith's recent comment to another thread for some relevant reading material: http://www.reddit.com/r/haskell/comments/l7wtd/why_learn_haskell/c2qi03c There are a multitude of reasons why people like Haskell over other languages. I think in the end you'll need to read up, get your feet wet and see for yourself. Edit: Here's another link that may be helpful: http://amtal.github.com/2011/08/25/why-haskell-is-kinda-cool.html"Why Functional Programming Matters"Read Learn You A Haskell for a hands-on introduction to Haskell. Why use Haskell? Haskell is type-safe. Where other languages let you write code that mistakenly passes a string to a function that takes an int, Haskell refuses to compile such code. There's a joke in the Haskell community that when your code finally does compile, it's guaranteed to be bug-free. There's a grain of truth in that, because most bugs are the result of poorly-typed code. Haskell は型安全です。他の言語があなたに int を引数にとる関数に文字列を間違って 渡してしまうコードを書くのを見過ごしてしまうのに対して、Haskell はそのような コードのコンパイルを拒絶するのです。 コードがコンパイルできれば、それはバグがないコードであることが保証されるという 冗談が Haskell コミュニティにはあります。 大部分のバグというものは poorly-typed なコードのためなので、 この冗談にはわずかながらも真実があります。 Although Haskell is strictly typed, its type system is also rich. You can easily write your own custom data types, called records, and Haskell can automatically figure out how to print, compare, and sort instances of your types if you write deriving (Eq, Ord, Show). Haskell's algebraic type system lets you construct data structures of arbitrary complexity, by building onto types such things as [Thing], a list of Things, or [[Thing]], a matrix of Things, or Tree Thing, a tree of Things. Again, Haskell automatically figures out how to print, compare, and sort these abstract types, too. Haskell は厳格に型付けされるものですが、その型システムは rich なものでもあります。 record と呼ばれるあなた独自のカスタムデータ型は簡単に書けますし、 Eq、Ord、Show の deriving を記述していれば Haskell は自動的にあなたのその型のインスタンスの print、compare、sort を 自動的に figure out できるのです。 Haskell is pure. Code for computations, x = 2 + 2, is separate from code for side effects, putStrLn (show x). For newbies, this one is an inconvenience, but once you get used to it, it's quite powerful. Haskell is parallel. Because Haskell is pure, parallelization is trivial. As long as code has no side effects and doesn't share variables, it can be run in multicore mode. See YelloSoft. Haskell is lazy. Because Haskell is pure, Haskell can intelligently decide when to perform calculations. It's normal to write a Haskell function like primes :: [Int] that returns the infinite list of prime numbers. How do you use such a thing? You only take a finite chunk of numbers from it at a time. take 5 primes -> [2, 3, 5, 7, 11] Haskell is declarative. Haskell's pattern matching allows you to write clear, concise functions. fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) It's just like a partial function in mathematics. Where other languages use try/catch blocks to handle errors, Haskell code mostly uses the Maybe a type, where a is a type of your choice. If you're parsing an integer, you'll could use maybeRead :: Maybe Int, which either returns Just x, where x is the successfully parsed integer, or Nothing, to signify that the parse failed. The type system itself is the error handling mechanism.One word: composition. The bane of modern software engineering is that software is complex, and no one can sanely hold all the details of a large project in their mind at the same time. The key is to find ways to express the result in smaller pieces which are individually understandable. The problem then becomes that when you take two pieces and put them together, they end up doing something you didn't expect or want. Haskell, more through culture than anything else, manages this. Various people here have pointed to technical merits, but at the end, it's really the culture that these technical merits have encouraged/forced/enabled which allows for this.
ほかにもたくさん回答が寄せられていますが省略。
ダイナマイト・キッド。覚えてる。
平野耕太†247 ドリフターズ 不死身の化物などこの世におらん!! 675 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:37:38.65 ID:/vYWLLQ20 Be: ノブ:義務教育終えてる奴で知らんやついないだろう 与一:ひょうふっと矢を射る人、古典でやるよね お豊:誰だ1号 菅野:誰だ2号 ハンニバル:世界史取ってなかったからよくは知らんかった、知ってるのキーワードくらい スキピオ:同上 ワイルドバンチ:キッドは聞いた事ある、ブッチはごめん アナスタシア:誰だ3号 他の廃棄者:知ってる 晴明:神社とか某漫画が昔流行ったよね サンジェルマン:オカルト系好きだとどっかで確実に引っかかる人 多聞:名前は知ってる程度 とりあえず知らん・よく知らん人らが扱われてる本を暇な時に読みたいなと思う 確か過去スレで何度かお勧め上がってたよなぁ 679 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:45:03.26 ID:G6CqGuw+0 Be: >>675 ブッチが分からない時点で、そのキッドは「ビリー・ザ・キッド」と間違えてる気がするんだが 通常、ブッチ・キャシディとサンダンス・キッドのセットで記憶されてるはず つか、こいつらがバラ売りされてるのって見た事ない 680 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:49:17.48 ID:XuwCFXa40 Be: キッドは弾きれても戦えるんだろ。 テキサスクローバーホールドとかスピニングトゥホールドとかで。 681 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:52:05.72 ID:zr6dCZdQ0 Be: ペキンパー映画で見た筈だが、正直忘れとった>キッド&ブッチ 682 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:58:20.51 ID:I0eO/ETV0 Be: いまのいままでビリーザキッドのことだと思ってたw 683 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:58:49.39 ID:4uFwYTH80 Be: キッドと言われて思い出すのはテリー・ザ・キッドよりダイナマイト・キッド 684 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:02:13.93 ID:jg/6maUE0 Be: サンダウン・キッドかな 685 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:05:03.99 ID:G6CqGuw+0 Be: >>681 ペキンパーの「ワイルドバンチ」は強盗団の名前こそ同じだがコイツらとは関係無いはず 686 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:14:55.75 ID:3rJnwv3vO Be: ブッチとサンダンスは明日に向かって撃てで知ったな あれももう40年前の映画か。 687 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:16:25.55 ID:zr6dCZdQ0 Be: >>685 あー関係ないのか。どおりで。 688 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:30:27.63 ID:/vYWLLQ20 Be: >>679 いや、あれなんだ、ますむらひろしの昔の作品で サンダンスキッドが猫で出ててな ブッチは猫のありがちな名前だと思って完全スルーしてたんだ… 693 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:41:16.00 ID:tmPrcpf10 Be: >>683 ダイナマイト・キッドといえば佐山タイガーのデビュー戦・・・って年バレるなw でもキッドといえばペガサス・キッドだろ そういえば中の人=クリス・ベノワも悲しいというか無惨な最期だったなぁ 706 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 21:06:39.27 ID:4uFwYTH80 Be: >>693 エディ・ゲレロとか新日ジュニア→WWF(WWE)レスラーはなんというか落差の大きい人生になっちゃってるなぁ… gdgd妖精s面白ぇ
I am pushing on the "devel" branch of Github's repository[1] revisions of series 0.2, code named Seizon Senryaku;
Smalltalk implementation running on Rubinius.
perlにあってpythonに無いもの ×dankogai ×yusukebe(会場からはmopemopeさんがいる、という声が) ○Acme
無印良品
たまにいくと面白げな文房具が増えてたりするので見逃せない。
文房具といえば Amazon.co.jp: 最強の文房具 (別冊宝島) (別冊宝島 1786 カルチャー&スポーツ): 美崎栄一郎: 本 Amazon.co.jp: ニッポンの新オドロキ文房具―技術に、機能に、デザインに世界が驚嘆する! (別冊GoodsPress): 本 Amazon.co.jp: すごい文房具 リターンズ (CIRCUS MAX 11月号増刊): KKベストセラーズ: 本 最近この辺の本を立て続けに買って(微妙に内容が被ってないから困ったもんだ :)、 これいいなあ、あれいいな、これ試してみたいなあなどと楽しんだり。
使い分け難しい
Perlについての質問箱 48箱目 755 デフォルトの名無しさん [sage] 2011/10/21(金) 13:27:53.49 ID: Be: 用語の質問です。 Perlのオブジェクト指向では、「attribute」と「property」の両方が使われているようなんですが、 これらはどのように使い分けられていますか。 ググってみたけど、いまいちわかりません。 package Hogehoge; sub new { my $class = shift; return bless {@_}, $class; } sub x { return $_[0]->{x} }; sub y { return $_[0]->{y} }; my $hoge = Hogehoge->new(x=>1, y=>2); print $hoge->{x}; # これはattribute? property? print $hoge->x; # これはattribute? property? 758 デフォルトの名無しさん [sage] 2011/10/21(金) 14:43:43.08 ID: Be: >>755 こういう認識しか無いんだけど、こういうのとは違うん? http://perldoc.perl.org/perlglossary.html インスタンス変数 > instance variable > An attribute of an object; data stored with the particular > object rather than with the class as a whole. アクセサ > accessor methods > A method used to indirectly inspect or update an object's state > (its instance variables). 759 デフォルトの名無しさん [sage] 2011/10/21(金) 15:53:56.50 ID: Be: sub x : lvalue { $_[0]->{x} }; sub y : lvalue { $_[0]->{y} }; こういうのかな。 メソッドでもLvalue subroutineと呼ばれてる希ガス。 760 デフォルトの名無しさん [sage] 2011/10/21(金) 16:53:02.26 ID: Be: 755です。 もいっかい調べ直したところ、Perlでの「attribute」というのは、オブジェクト指向とは関係なく、 関数定義において付属的に追加できるデータのことのようです。 ttp://gihyo.jp/dev/feature/01/perl-pluggable/0002 でもオブジェクト指向の説明でもよく見かけるように思うし、どうなんでしょ。 761 デフォルトの名無しさん [sage] 2011/10/21(金) 17:06:03.59 ID: Be: perlの言語仕様でいうところのattributeはサブルーチンやレキシカル変数に つけられるやつの方だけど、オブジェクト指向でもattributeという言葉は よく使われるのでperlのオブジェクト指向ライブラリの一つのMooseみたいに その意味でattributeを使っちゃってることもある。どれを指しているかは よく考えながら読むしかないね。 762 755 [sage] 2011/10/21(金) 17:20:01.32 ID: Be: こっちはインスタンス変数をプロパティといっている。 ttp://d.hatena.ne.jp/chaichanPaPa/20100206/1265436393 > 結果的にリファレンスが、ハッシュ変数(プロパティ)とサブルーチン(メソッド)を持つことになるのです。 > プロパティとメソッドと言えば、そう、オブジェクトになるのですね…これが!! こっちはインスタンス変数とアクセッサの両方をプロパティと呼んでいるっぽい。 http://idocsq.net/page/350 うーん。用語が統一されてない。
原語では delimited coutinuation つーのですね。
Delimited continuation - Wikipedia, the free encyclopedia Delimited continuation In programming languages, a delimited continuation, composable continuation or partial continuation, is a "slice" of a continuation frame that has been reified into a function. Unlike regular continuations, delimited continuations return a value, and thus may be reused and composed. プログラミング言語において、delimited continuation もしくは composable continuation とか partial continuation というものは、ある関数へと reified (具現化?) された continuation frame の“スライス”である。通常の continuation とは異なり delimited continuation は値を返す。したがって、再利用されたり組み合わされたりする 可能性がある。
「限定継続」だから limited ~ かと思ったのですが違うのですね。 というかなんで「限定」継続?
delimitedの意味 - 英和辞典 Weblio辞書 delimited 【形容詞】 1 限界がある、または境界を作る (having the limits or boundaries established) a delimited frontier through the disputed region 紛争地域を通って区切られた国境
delimitの意味 - 英和辞典 Weblio辞書 delimit 区切る, 限界を定める 用例 delimit [限界を定める,区切る] These motifs consist of clusters of hydrophobic residues which are delimited from one another by short stretches of Asp, Glu, Pro and other residues favoring the formation of loops. (Plant Mol Biol)
Island Life - O(n^2)正規表現 では、NFAでもDFAでもO(n^2)は避けられないのか、というとこの正規表現については 高速化の 可能性はある。 まずこのパターンは、"@"が入っていない文字列にはマッチしようがない。 したがっ てあらかじめ"@"を入力文字列中から探して、見つからなければ マッチ無しと断定で きるので、真面目に入力をひとつづつずらしながらマッチを試みる 必要はない。一般的には、 パターン中に「必ずマッチしなければならない部分文字列」 がある場合に、それを取り出して Boyer-Mooreなどの高速な部分文字列検索を 行うことで、マッチしない場合を高速に除外できる。 これをやってるエンジンを見たことはあるんだけど、Perlだったかな。
ちょっと方向が違いますが、GNU の regex がマッチする文字列の先頭に来うる文字集合を チェックしてて、その集合に入ってない限り読み飛ばすということをしています。 言及されている「必ずマッチしなければならない部分文字列」を検索するのは Perl だったと思います。ほかでもやっているかもしれないけど(最近のは(特にPCRE) 眺めてないのでどう変わったかよくわかってない)。
perl はこの辺かな
/* Most of decisions we do here should have been done at compile time. The nodes of the REx which we used for the search should have been deleted from the finite automaton. */ char * Perl_re_intuit_start(pTHX_ REGEXP * const rx, SV *sv, char *strpos, char *strend, const U32 flags, re_scream_pos_data *data) { (さくっと略) restart: /* Find a possible match in the region s..strend by looking for the "check" substring in the region corrected by start/end_shift. */ { I32 srch_start_shift = start_shift; I32 srch_end_shift = end_shift; if (srch_start_shift < 0 && strbeg - s > srch_start_shift) { srch_end_shift -= ((strbeg - s) - srch_start_shift); srch_start_shift = strbeg - s; } DEBUG_OPTIMISE_MORE_r({ PerlIO_printf(Perl_debug_log, "Check offset min: %"IVdf" Start shift: %"IVdf" End shift %"IVdf" Real End Shift: %"IVdf"\n", (IV)prog->check_offset_min, (IV)srch_start_shift, (IV)srch_end_shift, (IV)prog->check_end_shift); }); if (flags & REXEC_SCREAM) { I32 p = -1; /* Internal iterator of scream. */ I32 * const pp = data ? data->scream_pos : &p; if (PL_screamfirst[BmRARE(check)] >= 0 || ( BmRARE(check) == '\n' && (BmPREVIOUS(check) == SvCUR(check) - 1) && SvTAIL(check) )) s = screaminstr(sv, check, srch_start_shift + (s - strbeg), srch_end_shift, pp, 0); else goto fail_finish; /* we may be pointing at the wrong string */ if (s && RXp_MATCH_COPIED(prog)) s = strbeg + (s - SvPVX_const(sv)); if (data) *data->scream_olds = s; } else { U8* start_point; U8* end_point; if (prog->extflags & RXf_CANY_SEEN) { start_point= (U8*)(s + srch_start_shift); end_point= (U8*)(strend - srch_end_shift); } else { start_point= HOP3(s, srch_start_shift, srch_start_shift < 0 ? strbeg : strend); end_point= HOP3(strend, -srch_end_shift, strbeg); } DEBUG_OPTIMISE_MORE_r({ PerlIO_printf(Perl_debug_log, "fbm_instr len=%d str=<%.*s>\n", (int)(end_point - start_point), (int)(end_point - start_point) > 20 ? 20 : (int)(end_point - start_point), start_point); }); s = fbm_instr( start_point, end_point, check, multiline ? FBMrf_MULTILINE : 0); } } /* Update the count-of-usability, remove useless subpatterns, unshift s. */
う。記憶にあるのとだいぶ違う(上記のコードは 5.12 のもの)……また時間見つけて読まねば。
引用したコードの最後のほうにある fbm_instr ってのが、 Boyer-Moore 法を使った固定文字列検索。のはず。
MATLAB はぜんぜん知らんのですが。
MATLAB's function syntax is abysmal : programming MATLAB's syntax is abysmal FTFYIt's pretty decent for doing interactive calculations in a terminal, but it quickly falls apart when you have to do longer scripting.This is exactly how I feel about bash - it's nice for interactive uses, but it quickly becomes incredibly unwieldy when you have to do longer scripting.I was talking to a guy once who was doing some research for his sociology PhD or something. He mentioned how he had an 80,000-point dataset and he had done all the statistical analysis on it in shell script because he didn't know anything else. I cringed a little when I herd that.Oh...my...godWhat? An 80k dataset isn't that large, and if he's got the shell utilities to do the computations you want, shell doesn't seem unreasonable at all for it. I've processed much larger things from the shell. In fact, if the computations you are doing permit processing a stream and you're running a whole pipeline of computations, using a shell pipeline may well be both vastly more memory-efficient (doesn't need to load the dataset into memory) and faster (pipelines give you some degree of free parallel processing) than the alternative you may have been thinking of. The problem I have with shell is mostly that: * the straightforward thing in string processing is usually also not the bulletproof to do things, due to whitespace issues * shell has a bazillion weird little features to learn (at least in bash and zsh; maybe back in the day, it was smaller) * fancy data structures are a pain, which is either not a problem or very annoying, depending upon your task * shell code itself isn't that fast, though stringing together shell utilities can be just fine.using a shell pipeline may well be both vastly more memory-efficient (doesn't need to load the dataset into memory) and faster (pipelines give you some degree of free parallel processing) than the alternative you may have been thinking of What is the alternative you have been thinking of that doesn't support stream processing? I use Python and iterator support is fine..MATLAB's programming language is abysmal FTFTFYMATLAB is abysmal FTFTFTFYMad FTFUU mad, bro?MATLAB is not a programming language FTFTFTFYMATLAB is abysmal FTFY
で、元記事。
Matlab function syntax is abysmal « Dale Peterson Matlab function syntax is abysmal By luke, on October 12th, 2011 Today I was helping some undergraduates in a mechanical vibrations course to use ode45. The way you specify the right hand side of the ode's must fit Matlab's particular form (using an @ before the function name, which must be contained in a file of the same name, with a ‘.m' extension). Looking at the documentation, I found this gem that really made me want to suck start a shotgun: One way to provide additional parameters to a functional argument of a function function is to write a file that: -- Accepts the additional parameters as inputs -- Invokes the function function -- Contains the function called by the function function as a nested function That last one is a real doozy. Try saying that 5 times real fast, then explain what the hell it means to an undergrad. I'd rather explain what a pointer to pointer to char is, personally.
自分が作った新言語をアピールする材料探しのためのチェックリスト?
Programming Language Checklist Programming Language Checklist by Colin McMillen, Jason Reed, and Elly Jones. You appear to be advocating a new: [ ] functional [ ] imperative [ ] object-oriented [ ] procedural [ ] stack-based [ ] "multi-paradigm" [ ] lazy [ ] eager [ ] statically-typed [ ] dynamically-typed [ ] pure [ ] impure [ ] non-hygienic [ ] visual [ ] beginner-friendly [ ] non-programmer-friendly [ ] completely incomprehensible programming language. Your language will not work. Here is why it will not work. You appear to believe that: [ ] Syntax is what makes programming difficult [ ] Garbage collection is free [ ] Computers have infinite memory [ ] Nobody really needs: [ ] concurrency [ ] a REPL [ ] debugger support [ ] IDE support [ ] I/O [ ] to interact with code not written in your language [ ] The entire world speaks 7-bit ASCII [ ] Scaling up to large software projects will be easy [ ] Convincing programmers to adopt a new language will be easy [ ] Convincing programmers to adopt a language-specific IDE will be easy [ ] Programmers love writing lots of boilerplate [ ] Specifying behaviors as "undefined" means that programmers won't rely on them [ ] "Spooky action at a distance" makes programming more fun Unfortunately, your language (has/lacks): [ ] comprehensible syntax [ ] semicolons [ ] significant whitespace [ ] macros [ ] implicit type conversion [ ] explicit casting [ ] type inference [ ] goto [ ] exceptions [ ] closures [ ] tail recursion [ ] coroutines [ ] reflection [ ] subtyping [ ] multiple inheritance [ ] operator overloading [ ] algebraic datatypes [ ] recursive types [ ] polymorphic types [ ] covariant array typing [ ] monads [ ] dependent types [ ] infix operators [ ] nested comments [ ] multi-line strings [ ] regexes [ ] call-by-value [ ] call-by-name [ ] call-by-reference [ ] call-cc (略)
「必要ならオレの最後の息が途絶えるまで、そして銀行にあるAppleの$40bを使い尽くしてでも、この悪を正してやる。」
「Androidを叩き潰してやる。アレは完全なパクリだからだ。そのためには熱核戦争さえ率先してやるつもりだ。」
「必要なら最後の息までこの不正義を正すために戦う。アップルの400億ドルの銀行にある資産を全て費やしてもかまわない」
「アンデロイドを破壊する。これは盗まれた製品だからだ。核戦争でも始める覚悟がある」
IE7, 8, 9, 10を眺めたり、WP7を眺めたりして、実に強く思うのだが、マイクロソフトは尻を力いっぱい蹴飛ばす強力な敵がいないとダメな会社なんだな。
比較対象がRubykaigiしかないんだけど、それと比較するとみんな大人だなー、というかまっとうだなという印象がある。言語に対する変なパッションがなくて、淡々と便利な道具を使ってる感じというか。
JavaやPHPのコミュニティがどうなってるかも興味深いですね、機会があったら覗いてみたい。
一つ前へ
2011年10月(中旬)
一つ後へ
2011年11月(上旬)
リンクはご自由にどうぞ
メールの宛先はこちら