一つ前へ
2011年9月(中旬)
一つ後へ
2011年10月(上旬)
first-class citizen
の訳語ってどうするのがいいのかなあと考えてみたり
(第一級市民ってのはまあそうなんだろうけど、
文化的な背景やら考えると直訳はすべきじゃないのではないかと)。
番長 黒羽根
読んだ
なんとも気の重くなる内容だった。
同様のことが書かれた本はこれまでも結構でてるけどね。
某社を見てると日本もこうなるのかなあと思ったり思わなかったり。
ちまちま訳してたら先を越されてがっくりですよ! ○|￣|＿ 日本人プログラマーについての記事が Hacker News で話題になった | スラッシュドット・ジャパン
もうひとつ、こっちは逆のパターンで某有名サイトがちょっと前にわたしが紹介したのを紹介してて (無論向こうのほうがきちんと書いてはいる)、しかもそれで多少盛り上がってたりすると 以下略
転んでも泣かない。
そいや strawberry perl どうなってんだろ
Perl on Windows? : perl Why is Windows not considered a first-class citizen for Perl? With the release of Perl 5.14.2, Strawberry Perl 5.14.0 is still not available. I understand they are separate projects but why are they separate? If Perl is to grow(?) or at least keep mindshare with Ruby and Python where Windows is a first-class citizen, is there any plan to bring Strawberry into the fold?I don't need to work with Windows lately, but when I did, Activestate was reasonable. I believe their free community edition is up to 5.14.1Thanks Kip. I'm aware of the Activestate version but why isn't there standard Windows version? Heck, even Haskell treats Windows as tier 1.At a guess, the reason there isn't a 'standard Windows version' is that that has been the role played by Activestate for a great many versions along the way. No vacuum, no rush to fill it. The only difference (in so far as I know) between 'tier 1' as you put it and AS is that they take the nth version, recompile with any Windows specific necessary differences add various (usually useful) items to the distribution and then release after testing. Windows is not Unix after all, so this isn't much of a price to pay other than a fairly short length of time.How is Windows not a first-class citizen? Strawberry Perl uses the exact source code released by p5p. p5p doesn't release binary builds for any platforms.Perhaps you can communicate to the people behind Strawberry Perl that they can communicate their needs on the front page. Certainly Larry Wall is not the only linguist in the Perl demesne?
んーー、ひょっとして前に見たことある? ま、いいや。
Reid's Python Quiz Reid's Python Quiz Python 2.5 is relatively recent and not supported everywhere yet, so it's important to understand the behavior of both Python 2.5 and earlier versions. 1. (a) What number does the following code print? 次のコードが出力する数値はなにか? adders = [] for i in range(0, 100): adders.append(lambda x: x+i) print adders[17](42) (b) What about the following similar-looking code? 同じように見える次のコードではどうか? adders = [lambda x: x+i for i in range(0, 100)] print adders[17](42) 2. (pre-Python 2.5 only) What does the following code print? Partial credit for approximately correct answers. (Hint: the function that exits a program is called sys.exit.) Python 2.5 以前に限り。次のコードが出力するものは何か? try: exit(0) except Exception, e: print e 3. What number does the following code print? 次のコードが出力する数値は? units = [1, 2] tens = [10, 20] nums = (a + b for a in units for b in tens) units = [3, 4] tens = [30, 40] print nums.next() 4. Which of these lines produce the same output? 以下のもののうち、同じ出力をするものは? print "word" in [] == False print ("word" in []) == False print "word" in ([] == False) Answers
http://web.mit.edu/rwbarton/www/python-answers.txt Reid's Python Quiz : Python
↑の問題は↓ということなのでご注意。
Reid's Python Quiz : Python (2) is ancient trivia. I guess it was interesting back when Python 2.5 was "relatively recent". (4) is about operator precedence. (3) is clearly explained. (1) is a common gotcha. In case a, the lambda is created only with the name i in its __code__.co_names. The function loads i with the op LOAD_GLOBAL. However, by the time the for loop ends, global i is 99 . For case b, in Python 2 the list comprehension leaks i, so the lambda function references the global i just like in the first case. But in Python 3 the list comprehension is a closed scope, which triggers the creation of a closure. The reference to the local i is stored in __closure__[0].cell_contents, and the name 'i' is stored in __code__.co_freevars. The function loads i with the op LOAD_DEREF. The end result is similar, except it no longer depends on global i. So 'del i' won't break it (since there's no i to delete). To use the value of i as a constant in the function definition, you could double up on the lambda: adders = [(lambda k: (lambda x: x + k))(i) for i in range(0, 100)] I prefer this over altering the function signature with a default argument.
取るに足らないことように見えるかもしれないが、どんな形であれバーンアウトは自分のしていることに価値がなく、 認められていないと感じるところから始まる。インターネットは、あなたのしていることが素晴らしいというフィードバックを 伝える絶好のツールだが、どうも、批判や罵倒の言葉を投げかける人の方が、感謝のメールを送る人よりも多い気がする。 顔も見えないし、声のトーンも見えないことが、誤解をさらに広げている
APL についてちょっと書きたいことがあるのだけど、 まとめるのめんどー
最近、NHKのニュース見てて気になる言い回しが二つばかり。 ひとつは「午後ほど天気が崩れるでしょう」のようなもの。 "午後ほど - Google 検索 ほど【程】［副助連語］の意味 - 国語辞書 - goo辞書 もうひとつは、スポーツ(プロ野球)のダイジェストでよく出てくる 「ここはミスを挽回したかったと意地の逆転打」のような「～と～」の使い方。 どーも気になってしかたがない(笑)
紀伊國屋書店新宿南店の6Fにある洋書売り場の、CS関係の棚の数が減っててしょんぼりんぐ。 まあ予想できたことではあるんですけどねえ。
こういう会社で Jane Street » ようこそ Jane Street » OCaml
OCaml for the Masses - ACM Queue OCaml for the Masses Why the next language you learn should be functional (略) Yet functional languages never really made it to the mainstream. They came closest, perhaps, in the days of Symbolics and the Lisp machines, but those days seem quite remote now. Despite a resurgence of functional programming in the past few years, it remains a technology more talked about than used. It is tempting to conclude from this record that functional languages don't have what it takes. They may make sense for certain limited applications, and contain useful concepts to be imported into other languages; but imperative and object-oriented languages are simply better suited to the vast majority of software engineering tasks. Tempting as it is, this conclusion is wrong. I've been using OCaml in a production environment for nearly a decade, and over that time I have become convinced that functional languages, and in particular, statically typed ones such as OCaml and Haskell, are excellent general-purpose programming tools—better than any existing mainstream language. They also have an enormous range, being well suited for small scripting tasks as well as large-scale high-performance applications. They are not the right tool for every job, but they come surprisingly close. (略)
結構根強い愛好者がいるみたいですね＞OCaml
今はどうかわかりませんが、モルガン・スタンレーではAPLが広く使われたとか。 APLは関数型言語とはまた違うとは思いますが、 ふつーとは違うものが使われる(た)ということで。
というお題。
Want to learn Lisp. : lisp I have very little programming experience, just basic concepts like variables, functions and data types. I'm not sure which dialect I'm best off learning. scheme or common lisp? Or maybe a different one. Some suggested books have been Land of Lisp, although the author told me he never really intended it for beginners, he does feel lisp is a great first language though. Also SICP, Little schemer and practical common lisp. I would appreciate any suggestions. I really only have one goal, to make a roguelike. Other than that I just want to have fun.If you want to make a roguelike then I would suggest the Land of Lisp book as it makes something similar in there. It's not completely roguelike, but they go through similar skills that you need to make a roguelike. Though the book might not be enough to start from scratch.Yeah I emailed the author and he personally told me he never intended the book to be for beginners, though he said it might be possible. He did say he thinks common lisp is the perfect language for making a roguelike. Not sure whether I should get it or not.Something that's crucially important when learning to program is having fun. I don't know if LoL is for you, but most beginner books are terribly dry. That's a sure way to kill off a budding interest in programming.I agree with the author of LoL, common lisp is an excellent language for writing a roguelike. You can test, define and redefine everything at the lisp command prompt (called the "REPL") which is a huge help in developing a complex application. It is a multiparadigm language - you can write in a mix of procedural. functional, and object-oriented style, depending on what approach is best for the problem at hand. The object system, called CLOS, is extremely powerful and flexible. The language compiles to machine code and can often approach C/C++ in terms of execution speed. SBCL is probably the best free lisp, but you need to set up your own editor. The commercial lisps come with their own editing environment/IDE but are very expensive (except Corman Lisp which is reasonably priced but I think windows-only?). Once you are ready to start on your roguelike, you will need a "graphics" library to allow you to put symbols on the screen. I have written a library that allows you to use the libtcod library from common lisp. Libtcod is a console emulation library (like curses) that is used by many recent roguelikes. The library is at: http://bitbucket.org/eeeickythump/cl-tcod/ At the libtcod forum site there is a subforum for roguelike development in common lisp. It's not very active but there are a few interesting posts there, including a list of roguelikes written in various lisps. The best editor and IDE, by miles, is Emacs. But Emacs has a steep learning curve -- it's probably too much to try and learn Emacs + CL at the same time. Start with something simpler, maybe lispide, or your favourite text editor + a console window. The best first book is probably practical common lisp, which you can download for free.Thanks for this reply, I have got practical common lisp, luckily I recently learned to use emacs, and the practical common lisp book pointed me to a emacs package called lisp in a box, which allows me to jump right in. It works very well. Thanks for the link to libtcod, the people at the roguelike group pointed me there but I was sad to see its make for C and python only. so with your library, could I use all what libtcod has to offer? I look forward to learning more, thanks.
だいぶ盛り上がっていた話題。
Test-Driven Development? You've gotta be kidding me... : programming tldr: Good techniques are useful but being anal and obsessive about them is not.The problem is with TDD, there are a lot of people that think that you can't take it too far, and that there is no law of diminishing returns. Allowing tests to drive you design isn't a bad thing, it is allowing tests to be the only thing that drives your design.About a year ago, automated tests on the codebase my team worked on were a joke. After some heavy refactoring (which was scary, given we had low test coverage) and runtime dependency tweaking (read: embracing Guice Injection), we're in the greenest-grass place I've ever seen our product. Often times, tests (be they unit or integration) are easier to write that the to-be-implemented code itself (which also became easier to write in almost all cases). I'd leave you all with this: to pick up TDD like it's some dogma that must be followed to the death is a mistake (as it would be with any methodology). However, to go any significant distance in the opposite direction on the should-I-use-TDD? spectrum can be just as fatal of a decision.TDD is extremely valuable for elaborate or sensitive business logic. If you have complex conditions and a wide variety of scenarios, well thought out tests can save you a ton of time and get you better code. It also gives you the freedom to refactor parts of it, or extend it to handle a new condition with the confidence that you aren't breaking the 83 other possible outcomes. If you're writing tests to make sure simple CRUD actions are working, you're wasting your time. It's about finding the right balance. Edit: grammar
以下延々と300以上。
で、その火元。
Write More Tests: Test-Driven Development? Give me a break... Write More Tests Saturday, 24 September 2011 Test-Driven Development? Give me a break... Update: At the bottom of this post, I've linked to two large and quite different discussions of this post, both of which are worth reading... Update 2: If the contents of this post make you angry, okay. It was written somewhat brashly. But, if the title alone makes you angry, and you decide this is an article about "Why Testing Code Sucks" without having read it, you've missed the point. Or I explained it badly :-) (略) Have I had experience (and much value) out of sometimes writing tests for certain problem classes before writing any code? Yes. Changes to existing functionality are often a good candidate. Small and well-defined pieces of work, or little add-ons to already tested code are another. But the demand that you should always write your tests first? Give me a break. This is idiocy during a design or hacking or greenfield phase of development. Allowing your tests to dictate your code (rather than influence the design of modular code) and to dictate your design because you wrote over-invasive test is a massive fail. Writing tests before code works pretty well in some situations. Test Driven Development, as handed down to us mortals by Agile Testing Experts and other assorted shills, is hocus. (略)
訳つけたいけど余裕がががが。
コードのどこに問題あるのでしょうか？それとも環境の問題？原因不明です。
PyParsec is a parser combinator library for Python.
中途半端に訳しているのが結構あるんだよなあ。げしょ。
そろそろ。かな? 速報：アマゾンのタブレットは Kindle Fire、199ドル SICP for Kindle : programming jonathanpatt/sicp-kindle - GitHub
R.O.D は何年待っているのだっけ?w
ラノベじゃないけど、RSBC の新作…は無理だろうなあ
【棺担ぎのクロ。】きゆづきさとこ 37【ＧＡ】 355 名無しんぼ＠お腹いっぱい [] 2011/09/25(日) 10:03:48.39 ID:8aXc+oPK0 Be: もうすぐ誌面が白くないＧＡが読めるな・・・！！ 359 名無しんぼ＠お腹いっぱい [sage] 2011/09/25(日) 15:33:36.53 ID:glfH170e0 Be: >>355-356 単行本作業のために休載って可能性ががが 360 名無しんぼ＠お腹いっぱい [sage] 2011/09/25(日) 16:31:38.33 ID:OkRDmtDG0 Be: それでコミックの内容が充実するのなら、むしろ休載してほしい。 休載は1ヶ月だが、コミックは10年後も読むからね。 361 名無しんぼ＠お腹いっぱい [sage] 2011/09/25(日) 16:39:25.86 ID:NhTxDXKt0 Be: んでコミックが出るのが10年後になったりしてな 362 名無しんぼ＠お腹いっぱい [sage] 2011/09/25(日) 17:40:26.70 ID:+Jwwh2ka0 Be: 我々は10年待ったのだ！ あかん、それ死亡フラグ 363 名無しんぼ＠お腹いっぱい [sage] 2011/09/25(日) 20:51:12.41 ID:zZSFZZDF0 Be: 他に１０年待ってるのがあるから（ラノベだけど）勘弁してくれｗ 364 名無しんぼ＠お腹いっぱい [sage] 2011/09/26(月) 07:46:34.83 ID:7XPG0Spb0 Be: 俺も作者が生死不明で5年待ってるコミックがあるけど意外と待てるもんだよ だから一ヶ月や二ヶ月や半年くらい余裕で待つからクロの3巻をだな 365 名無しんぼ＠お腹いっぱい [sage] 2011/09/26(月) 10:11:40.71 ID:ZELPkFS00 Be: それこそジャングルくろべえなんか一体何年待ったことか・・・ 366 名無しんぼ＠お腹いっぱい [sage] 2011/09/26(月) 12:55:53.05 ID:pJI6G/O40 Be: 士郎正宗の適当連載っぷりに比べればすべてがぬるま湯以下 攻殻やドミニオンどうにかしろと って言うかカリカリしすぎ 367 名無しんぼ＠お腹いっぱい [sage] 2011/09/26(月) 15:44:33.46 ID:Mv36Nx2V0 Be: まあでも他に楽しみな作品があるから待てるんだよな 370 名無しんぼ＠お腹いっぱい [sage] 2011/09/27(火) 03:12:43.46 ID:RUreeSpa0 Be: >>363 そういや、R.O.Dってどうなったんだろうな…… 371 名無しんぼ＠お腹いっぱい [sage] 2011/09/27(火) 22:37:41.79 ID:/K55VqEm0 Be: ﾅﾂｶｼｽ… 372 名無しんぼ＠お腹いっぱい [sage] 2011/09/27(火) 23:27:36.96 ID:W/gT8FFa0 Be: >>370 五鎮姉妹の続きが読みたいです・・・
いなばさんあたりはたくさん待っているのがありそうな気がする。
適応→適用 ですよねえ。 三つ目のパラグラフの「適応」はどっからでてきたんだろう…
グーグルから「JavaScriptは根本的な問題を抱えている」とのメモがリークか － Publickey Javascript has fundamental flaws that cannot be fixed merely by evolving the language. We'll adopt a two-pronged strategy for the future of Javascript: JavaScriptは単なる言語の進化では修正できない根本的な問題を抱えている。そこで私たちは JavaScriptの将来について2つの戦略を適応するつもりだ。 * Harmony (low risk/low reward): continue working in conjunction with TC39 (the EcmaScript standards body) to evolve Javascript Harmony（低リスク／低リターン）：JavaScriptを進化させるため、TC39（EcmaScript標準化団体）と ともに継続して作業にあたる。（訳注：Harmonyとは将来のJavaScript/EcmaScriptのバージョンに対 するコード名） * Dash (high risk/high reward): Develop a new language (called Dash) that aims to maintain the dynamic nature of Javascript but have a better performance profile and be amenable to tooling for large projects. Dash（高リスク／高リターン）：新しい言語（Dashと呼ぶ）を開発する。これはJavaScriptの動的性質 を保ったまま、よりよいパフォーマンスと大規模プロジェクトのツールとして適応するものを目指す。
なんか興味深いものが
Announce: Niecza Perl 6 v10 - nntp.perl.org Announce: Niecza Perl 6 v10 This is the tenth release of Niecza Perl 6, as usual scheduled on the last Monday of the month. (略) [Minor new features] \qq[] syntax is now implemented. qp|| now returns a path object. New Test.pm6 methods succeeds_ok and fails_ok (and eval_ variants) to catch warnings. (Design by flussence) @foo? and %foo? in signatures are now correctly supported. Many more trig functions now implemented. (Solomon Foster) Standard grammar has been updated, in particular bringing the new concept of regex separators; x ** y is now spelled x+ % y. Do not expect other forms of % and %% to work just yet. [Selected bug fixes] sqrt now returns the correct value for arguments with a negative imaginary part. Also sqrt(0) returns Num not Complex now. (略)
\qq[] とか qp|| ってなんだろう。見覚えがない。
@foo? なんかもわからんなあ
よくある紹介記事ですが。
Hipster programming languages | (R news & tutorials) Hipster programming languages September 26, 2011 By Christopher Bare (This article was first published on Digithead's Lab Notebook, and kindly contributed to R-bloggers) If you look at the programming languages that are popular these days, a few patterns emerge. I'm not talking about languages that have the most hits on the job sites. I'm talking about what the cool kids are coding in - the folks that hang out on hacker-news or at Strange Loop. Languages like Clojure, Scala and CoffeeScript. What do these diverse languages have in common other than an aura of geek-chic? * Functional programming is emphasized over object-oriented programming. 関数プログラミングがオブジェクト指向プログラミングよりも強調されている * Common patterns for manipulating lists: map, filter, reduce. リスト操作のための一般的なパターン: map, filter, reduce * Modern syntax in which everything is an expression and syntactic noise like semicolons is reduced. すべてが式であるような modern な構文と、セミコロンのような構文的ノイズの削減 * CoffeeScript compiles to JavaScript, while both Clojure and Scala target the JVM. Targeting legacy platforms seems to be getting easier and more popular. CoffeScript は JavaScript へコンパイルする一方、Clojure と Scala は JVM をターゲット としています。レガシープラットフォームをターゲットにすることはより簡単かつ よりポピュラーなものになってきたようです。 * Innovative approaches to concurrency. 並列性に対する innovative なアプローチ 略 CoffeeScript CoffeeScript is javascript, redesigned. It cleans up the syntax adding many of the niceties familiar from Ruby and Python. CoffeScript は再設計された javascript です。 構文は整理され、Ruby や Python から多くの niceties が持ち込まれました。 略<-- Curly braces and semicolons are out. String interpolation, list-comprehensions, default arguments, and more tasty sugar are in. Its creator, Jeremy Ashkenas, believes in code as literature and it shows all the way through the project. Take a look at the annotated source code for the CoffeeScript grammar and see if it doesn't make you weep for the ugliness of your own code. Don't forget, CoffeeScript gets about 10 times hipper when combined with node.js, the event-driven app-server based on google's V8 javascript engine. --> Clojure Clojure is a dialect of lisp targeting the JVM. 略 Scala Scala is a strongly typed object-functional hybrid. It's targets include the JVM and Microsoft's CLR. It's an academic language derived from the ML family, but meant to be a pragmatic replacement for Java. 略<--It has a C++ like reputation for being fully understood only by guru level developers. One of it's key features is a type system that is Turing complete in itself. I guess I'm not completely convinced that a rocket-science type system is the answer, but it's there's cool stuff in there - generics done properly, higher-kinded types, which as near as I can tell takes parametric types to a level of meta beyond generics. One nice thing is that Scala has a tighter mapping to Java than Clojure so the interop between the two is a little more reasonable. The Akka project is a Scala platform for concurrent applications, providing both the actor model and software transactional memory. Those wanting to learn more can track down some interesting talks by language designer Martin Odersky available, plus the Scala Types podcast. --> A couple more Not enough languages for you? I'll throw in a couple more hip languages, R and Haskell. Truly cool kids know Haskell. What can I say, except that I am not yet that cool. I need to go out to a shed in the woods with a couple of books and learn me some Haskell. これでは十分ではない? ではさらに二つの hip languages を紹介しましょう。 R と Haskell です。 R may have a bastardized syntax, but, eventually, it's functional core shines through. R is seeing a surge in popularity based on the highly hip and trendy field of data science, where it's powerful statistical methods and graphing come in handy. Aside from mclapply, R is a bit lacking in support for concurrency. Rhipe and Revolution Analytics's RHadoop are trying to change that. Fashion You might be tempted to say it's all fashion. What goes around comes around. To some extent that's true, but, in each of these languages, there's something new and worthwhile to be learned. We have a ways to go before code is as expressive as we want it to be. Someone smart said that you'll like a programming language in proportion to what it teaches you. Mostly, I want to remind myself to set aside some time to play with these languages and see what new tricks they have to teach this old dog. This article was kindly contributed to R-bloggers by Digithead's Lab Notebook. R-bloggers.com offers daily e-mail updates about R news and tutorials on topics such as: visualization (ggplot2, lattice, maps, animation), programming (RStudio, Sweave, LaTeX, SQL, Eclipse, git) statistics (regression, PCA, time series, trading) and more...Copyright © 2011 R-bloggers. All Rights Reserved.
ポイントサービスの運営は企業にとってそれなりの負担があるはずで、ベンダーがこれを代替する パッケージを提供できれば、移行を検討するに違いない。多くの消費者がポイントサービスを支持する理由は、 "運営会社から特典を得る"ことにあるのだから、ポイントカードの共通化はむしろ歓迎されるだろう。
どんなにシェアの高いガリバーでも、技術革新によって駆逐されるというのは、技術者にとって肝に銘じなければならないことの一つであろう。
しかし、最近の若いもんは優秀すぎて困る。
内蔵する1.8インチのHDD(200GB)に無線LAN(IEEE802.11b/g/n)経由でアクセスして、ファイルを記録したり 読み込んだりすることが可能だ。また、DLNA規格に準拠しており、本製品内に保存してある音楽・映像ファイルなどを、 スマートフォンやPC、DLNA規格対応端末で再生することもできる。さらに、USB2.0端子も1基備えているので、 PCと有線で接続してのファイルの読み書きも可能だ。
あの袋がよくあるタイプのに変わってしまったときはちょっと寂しかったなあ。 理工学書の扱いはだいぶ減るみたいで(ブックタワーもフロアの半分くらいになってた)、 行くことも少なくなるのかなあ。 神保町の本屋さん、書泉のバッグの歴史(Excite Bit コネタ) - エキサイトニュース 書泉 | アイドルイベント情報、鉄道・格闘技等、バックナンバー豊富な書店です。
MLがずいぶんと盛り上がったようで。
digitalmars.D - Would You Bet $100,000,000 on D? digitalmars.D - Would You Bet $100,000,000 on D? * Peter Alexander <peter.alexander.au gmail.com> Sep 16 2011 o Walter Bright <newshound2 digitalmars.com> Sep 16 2011 + Peter Alexander <peter.alexander.au gmail.com> Sep 16 2011 # "Nick Sabalausky" <a a.a> Sep 16 2011 * Timon Gehr <timon.gehr gmx.ch> Sep 17 2011 o "Xavier" <xman nospam.net> Sep 17 2011 + Timon Gehr <timon.gehr gmx.ch> Sep 18 2011 * Lutger Blijdestijn <lutger.blijdestijn gmail.com> Sep 17 2011 * Peter Alexander <peter.alexander.au gmail.com> Sep 17 2011 o Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Sep 17 2011 + Peter Alexander <peter.alexander.au gmail.com> Sep 17 2011 # Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Sep 17 2011 * Peter Alexander <peter.alexander.au gmail.com> Sep 17 2011 # Peter Alexander <peter.alexander.au gmail.com> Sep 17 2011 o Adam D. Ruppe <destructionator gmail.com> Sep 17 2011 + Adam D. Ruppe <destructionator gmail.com> Sep 17 2011 + Peter Alexander <peter.alexander.au gmail.com> Sep 17 2011 # Adam D. Ruppe <destructionator gmail.com> Sep 17 2011 * Peter Alexander <peter.alexander.au gmail.com> Sep 17 2011 o Peter Alexander <peter.alexander.au gmail.com> Sep 18 2011 # Don <nospam nospam.com> Sep 19 2011 * Peter Alexander <peter.alexander.au gmail.com> Sep 19 2011 * Dmitry Olshansky <dmitry.olsh gmail.com> Sep 19 2011 + "Nick Sabalausky" <a a.a> Sep 17 2011 o Walter Bright <newshound2 digitalmars.com> Sep 17 2011 o "Xavier" <xman nospam.net> Sep 17 2011 o Peter Alexander <peter.alexander.au gmail.com> Sep 18 2011 + =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> Sep 18 2011 # Walter Bright <newshound2 digitalmars.com> Sep 18 2011 + Walter Bright <newshound2 digitalmars.com> Sep 18 2011 # Peter Alexander <peter.alexander.au gmail.com> Sep 18 2011 * Walter Bright <newshound2 digitalmars.com> Sep 18 2011 # Jonathan M Davis <jmdavisProg gmx.com> Sep 16 2011 * "Nick Sabalausky" <a a.a> Sep 17 2011 o "Xavier" <xman nospam.net> Sep 17 2011 + "Nick Sabalausky" <a a.a> Sep 17 2011 # "Xavier" <xman nospam.net> Sep 17 2011 * "Xavier" <xman nospam.net> Sep 17 2011 o "Nick Sabalausky" <a a.a> Sep 17 2011 + "Xavier" <xman nospam.net> Sep 17 2011 # Timon Gehr <timon.gehr gmx.ch> Sep 17 2011 # "Nick Sabalausky" <a a.a> Sep 17 2011 # Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Sep 17 2011 * renoX <renozyx gmail.com> Sep 19 2011 # Josh Simmons <simmons.44 gmail.com> Sep 17 2011 * "Xavier" <xman nospam.net> Sep 17 2011 # J Arrizza <cppgent0 gmail.com> Sep 17 2011 * "Xavier" <xman nospam.net> Sep 17 2011 + dsimcha <dsimcha yahoo.com> Sep 16 2011 # Peter Alexander <peter.alexander.au gmail.com> Sep 16 2011 * Walter Bright <newshound2 digitalmars.com> Sep 16 2011 * "Xavier" <xman nospam.net> Sep 16 2011 * Jacob Carlborg <doob me.com> Sep 17 2011 + Jesse Phillips <jessekphillips+d gmail.com> Sep 16 2011 # Walter Bright <newshound2 digitalmars.com> Sep 16 2011 * "Xavier" <xman nospam.net> Sep 16 2011 o "Nick Sabalausky" <a a.a> Sep 16 2011 + "Xavier" <xman nospam.net> Sep 17 2011 # "Nick Sabalausky" <a a.a> Sep 17 2011 * David Nadlinger <see klickverbot.at> Sep 17 2011 o "Nick Sabalausky" <a a.a> Sep 17 2011 o "Mike James" <foo bar.com> Sep 17 2011 + "Xavier" <xman nospam.net> Sep 16 2011 + Josh Simmons <simmons.44 gmail.com> Sep 17 2011 + "Marco Leise" <Marco.Leise gmx.de> Sep 17 2011 + "Vladimir Panteleev" <vladimir thecybershadow.net> Sep 17 2011 + Sean Kelly <sean invisibleduck.org> Sep 17 2011 + Sean Kelly <sean invisibleduck.org> Sep 17 2011 + "Marco Leise" <Marco.Leise gmx.de> Sep 18 2011 + "Steven Schveighoffer" <schveiguy yahoo.com> Sep 20 2011 o maarten van damme <maartenvd1994 gmail.com> Sep 16 2011 o Jesse Phillips <jessekphillips+d gmail.com> Sep 16 2011 o "Nick Sabalausky" <a a.a> Sep 16 2011 + Peter Alexander <peter.alexander.au gmail.com> Sep 16 2011 # Walter Bright <newshound2 digitalmars.com> Sep 16 2011 # "Nick Sabalausky" <a a.a> Sep 16 2011 o "Vladimir Panteleev" <vladimir thecybershadow.net> Sep 16 2011 o Timon Gehr <timon.gehr gmx.ch> Sep 16 2011 + dsimcha <dsimcha yahoo.com> Sep 16 2011 # Timon Gehr <timon.gehr gmx.ch> Sep 16 2011 o "Xavier" <xman nospam.net> Sep 16 2011 + Sean Kelly <sean invisibleduck.org> Sep 16 2011 + Josh Simmons <simmons.44 gmail.com> Sep 16 2011 # "Nick Sabalausky" <a a.a> Sep 17 2011 * "Nick Sabalausky" <a a.a> Sep 17 2011 # Adam D. Ruppe <destructionator gmail.com> Sep 17 2011 + Josh Simmons <simmons.44 gmail.com> Sep 17 2011 # "Nick Sabalausky" <a a.a> Sep 17 2011 + Peter Alexander <peter.alexander.au gmail.com> Sep 17 2011 # Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Sep 17 2011 * "Xavier" <xman nospam.net> Sep 17 2011 + Sean Kelly <sean invisibleduck.org> Sep 17 2011 + maarten van damme <maartenvd1994 gmail.com> Sep 18 2011 o Adam D. Ruppe <destructionator gmail.com> Sep 16 2011 o Jonathan M Davis <jmdavisProg gmx.com> Sep 17 2011 + "Xavier" <xman nospam.net> Sep 17 2011 o Jonathan M Davis <jmdavisProg gmx.com> Sep 17 2011 + "Xavier" <xman nospam.net> Sep 17 2011 # Timon Gehr <timon.gehr gmx.ch> Sep 17 2011 o Trass3r <un known.com> Sep 18 2011 + dsimcha <dsimcha yahoo.com> Sep 18 2011 # Walter Bright <newshound2 digitalmars.com> Sep 18 2011 * dsimcha <dsimcha yahoo.com> Sep 18 2011 + Trass3r <un known.com> Sep 18 2011 + Trass3r <un known.com> Sep 18 2011 + Trass3r <un known.com> Sep 18 2011 + Trass3r <un known.com> Sep 18 2011 + Jacob Carlborg <doob me.com> Sep 19 2011 # Jacob Carlborg <doob me.com> Sep 19 2011 + Trass3r <un known.com> Sep 19 2011 + Trass3r <un known.com> Sep 19 2011 o mountain.li <mountain.li morningstar.com> Sep 18 2011
最初のところだけ。
Peter Alexander writes: I recently stumbled across this (old) blog post: http://prog21.dadgum.com/13.html In summary, the author asks if you were offered $100,000,000 for some big software project, would you use your pet programming language? This is interesting, because if we answer "no" then it forces us to think about the reasons why we would *not* use D, and perhaps those concerns are what we should be focusing on? --- To get the ball rolling, here are the reasons I would not use D for a big project with high stakes: 1. If I had to port to ARM, or PowerPC, or some other architecture then I would very likely have trouble finding a compiler and other tools up to the task. I wouldn't have that problem with (say) Java or C. 2. I'm not convinced that any of the available compilers would cope with a very large code base. I don't know what the largest D2 project is, but I think I would be right in saying that it has less than 1 MLOC. 3. Depending on what the project was, I would probably be worried about available libraries. If, for example, the project required the use of DirectX, I'd just use C++. 4. I'd be worried about garbage collector performance, although this is less of a concern than the others because it's not too difficult to work around if you know you need performance up ahead. 5. If I did use D, I would (and do) force myself to use only simple features. I would be too scared of the type system blowing up, or obscure template errors causing pain. One error I always seem to get when using Phobos is that it can't find a match for a function because the types somehow didn't pass the template constraints for some obscure reason. When there are multiple constraints, you don't know which is failing. Often it is due to the complicated const/immutable/shared parts of the type system. --- Essentially, I agree with his conclusion in the post. Tools and libraries would be my biggest concerns (in that order). The fact that D (usually) makes things easier for me barely registered when thinking about this.Walter Bright writes: On 9/16/2011 2:47 PM, Peter Alexander wrote: Essentially, I agree with his conclusion in the post. Tools and libraries would be my biggest concerns (in that order). The fact that D (usually) makes things easier for me barely registered when thinking about this. If you had $100,000,000 none of these are an issue, as you can easily afford to hire top developers to address any and all of them. There's a reason why huge companies like Microsoft, Google, Intel and Apple bring compiler dev in house. It's because they are so heavily reliant on compiler technology, they cannot afford not to.
なぜかHaskellへ飛び火
Would You Bet $100,000,000 on Haskell? : haskell Would You Bet $100,000,000 on Haskell? (digitalmars.com)I feel that this point sums it up: If you had $100,000,000 none of these are an issue, as you can easily afford to hire top developers to address any and all of them. At it's core Haskell is a wonderful language, but the ecosystem could use some love. Being able to employ quality developers to work full time on tools like cabal would go a long way. And more resources (such as technical writers) thrown at key libs would be fantastic.I think the budget should not be taken literately, it's more like "would you choose X when you agree to finish a project which is very very important and must not fail or be late".I understood it as something similar to that, but with the caveat that you are backed by boundless resources. I think this is important as this prevents "brick walls" of, say, a compiler bug or a missing library - you can just contract those problems away.I think the order of magnitude of the budget does matter. If my startup has less than 100k of funding, I'd probably not choose Haskell for the one, very important project. If I'm in charge of a $1M project, then I'd think about using Haskell. If it's U$100M then hell yes. Since the $100M version is such a no-brainer, the $1m version is probably more interesting.right, and also, how mature it is to take on a very big project.I think a direct link to the article would be practical: http://prog21.dadgum.com/13.html I think the tool-chain etc of Haskell is mature enough for the kind of stuff he mentioned, yes. A lot of the article is about optimization.Talk is cheap. I might say I'd use Haskell, but to be sure, send me the money and we'll find out.
ちょっと濃い話をとある人たちとしまして。
どうもプログラミング言語 (といってもサンプルは Perl、Ruby、Python、PHP、Scala、C++ くらい)によって ユーザー(というか愛好者?)の傾向というのがあるようなないようなといった話とか。
Python 本体と独立してやってんのかな＞PyPy
結構細かく見込み予算が出されているのが印象的。
PyPy :: Call for donations - PyPy to support Python3! Call for donations - PyPy to support Python3! The release of Python 3 has been a major undertaking for the Python community, both technically and socially. So far the PyPy interpreter implements only version 2 of the Python language and is increasingly used in production systems. It thus contributes to the general risk of a long lasting Python community split where a lot of people continue using Python 2 while others work with Python 3, making it harder for everyone. The PyPy project is in a unique position in that it could support Python 3 without having to discontinue supporting Python 2, with the possibility of reusing a large part of of code base and fully reusing its unique translation and JIT-Compiler technologies. However, it requires a lot of work, and it will take a long time before we can complete a Python 3 port if we only wait for volunteer work. Thus, we are asking the community to help with funding the necessary work, to make it happen faster. Here is a more detailed view on how our proposed work benefits the Python community and the general public. (略) We have the advantage of targeting something that already exists without having to define the destination as they go along, and also the internal architecture of PyPy makes it easier to do the porting. Step 1: core language In this step, we implement all the changes to the core language, i.e. everything which is not in the extension modules. This includes, but it is not necessarily limited to the following items, which are split into two big areas: * Sub-step 1.1: string vs unicode and I/O: o adapt the existing testing infrastructure to support running Python 3 code o string vs bytes: the interpreter uses unicode strings everywhere. o the print function o open is now an alias for io.open, removal of the old file type. o string formatting (for the part which is not already implemented in Python 2.7) o the _io module (for the part which is not already implemented in Python 2.7) o syntactic changes to make io.py importable (in particular: metaclass=... in class declarations) o Estimate cost: $35,000 * Sub-step 1.2: other syntactic changes, builtin types and functions, exceptions: o views and iterators instead of lists (e.g., dict.items(), map, range & co.) o new rules for ordering comparisons o removal of old-style classes o int/long unification o function annotations o smaller syntax changes, such as keyword-only arguments, nonlocal, extended iterable unpacking, set literals, dict and set comprehension, etc. o changes to exceptions: __traceback__ attribute, chained exceptions, del e at the end of the except block, etc. o changes to builtins: super, input, next(), etc. o improved with statement o Estimate cost: $28,000 Note that the distinction between sub-steps 1.1 and 1.2 is blurry, and it might be possible that during the development we will decide to move items between the two sub-steps, as needed. For more information, look at the various “What's new” documents: * http://docs.python.org/py3k/whatsnew/3.0.html * http://docs.python.org/py3k/whatsnew/3.1.html * http://docs.python.org/py3k/whatsnew/3.2.html Total estimate cost: $63,000 Step 2: extension modules In this step, we implement all the changes to the extension modules which are written in C in CPython. This includes, but it is not necessarily limited to: * collections, gzip, bz2, decimal, itertools, re, functools, pickle, _elementtree, math, etc. Estimate cost: this is hard to do at this point, we will be able to give a more precise estimate as soon as Step 1 is completed. As a reference, it should be possible to complete it with $37,000 Step 3: cpyext The cpyext module allows to load CPython C extensions in PyPy. Since the C API changed a lot between Python 2.7 and Python 3.2, cpyext will not work out of the box in the Python 3 PyPy interpreter. In this step, we will adapt it to work with Python 3 as well. Note that, even for Python 2, cpyext is still in a beta state. In particular, not all extension modules compile and load correctly. As a consequence, the same will be true for Python 3 as well. As a general rule, we expect that if a Python 2 module works with cpyext, the corresponding Python 3 version will also work when this step is completed, although the details might vary depending on the exact C extension module. Estimate cost: $5,000 Benefits of This Work to the Python Community and the General Public (以下略)
20ドルくらいはだしますかね(金額に深い意味はありません)
The Comonad.Reader » A Parsec Full of Rats, Part 1 The Comonad.Reader » A Parsec Full of Rats, Part 2
あとで読む…ようにしよう
また別の新言語。 FACT (Functions Are Classes Too) - programming language written in C : programming
rookieMP/FACT - GitHub FACT is perhaps the first "scope-oriented" programming language. It may not be, however, I wouldn't be surprised if someone else came up with this first. All code is © 2010, 2011 Matthew Plant, under the GPL version 3. (略)
Common Lisp はなんで case insensitive なんじゃーと ぶーたれた人がいまして(デフォルトでの話)。
a CONS is an object which cares: Common Lisp is case sensitive Common Lisp is case sensitive One Common Lisp feature that needs more publicity is case sensitivity. A common misconception is that Common Lisp is case insensitive, when in fact symbols in Common Lisp are case sensitive. By default, the Common Lisp reader is case-converting: all unescaped characters in a symbol name get upper-cased. This gives the practical effect of making it seem as though symbol case doesn't matter. This is desirable behavior for interfacing with other case-insensitive languages (such as Fortran; from what I understand the main motivation for the default Common Lisp behavior), but a pain to interface with case-sensitive ones (such as C). The behavior of the reader can be customized via readtable-case. 略 An easy way to manage the readtable-case is by using the named-readtables library. I've recommended named-readtables before; besides case sensitivity, it helps manage reader macros. [This blog post is adapted from the case sensitivity CLiki FAQ entry I wrote. Feel free to make corrections and other suggestions on the CLiki page.]Robert said... I could be wrong, but I don't believe FORTRAN compatibility would be the reason for the upcase-default and upcasing for LISP symbols. I am inclined to suspect that it's just because LISP is a very old language. Have you verified the FORTRAN conjecture? September 21, 2011 4:12 PM
A common misconception is that Common Lisp is case insensitive, when in fact symbols in Common Lisp are case sensitive. : lisp A common misconception is that Common Lisp is case insensitive, when in fact symbols in Common Lisp are case sensitive. (carcaddar.blogspot.com)After working with Common Lisp a while, I've come to the conclusion that I'd rather have a case-insensitive language. It removes the class of bugs possible with variables & functions that vary only by case. case-insensitve だと、大小文字が違うだけで同じ名前のついている関数と変数が原因の バグが発生しなくていいよ!After working with Common Lisp for a while, I don't see the need to case sensitivity either unless I have to talk to something that does, like every other language on the face of the planet (that might be an overstatement). Same issue with OS X and a case sensitive file system. It almost never causes a problem, but inevitably some idiot makes a two files, one called "Makefile" and another called "makefile".I always wondered, why upper case, why couldn't it lowercase everything? いつも疑問に感じているのだけど、なんで小文字にするんじゃなくて大文字にするんだろう?I think it's due to history. Back in the day ('70s) all code was uppercase. それは歴史的経緯ってやつだと思うよ。 70年代はみんな大文字だったし。The keyboards didn't have lowercase letters back when lisp was invented ;) lisp が発明されたときにはキーボードに小文字が刻印されてなかったんだよ :)Why is really the only question I have? Other than interfacing with other language's case conventions, I can't remember intentionally wanted two different variables that only differ in case in the same context. It has just always seems like setting a trap for myself.I view it as "CL is case sensitive, except the sensitive part is somewhat broken". One readtable-case flag affects all symbols in a file, it requires coordination with print-case, etc. In fact, CLHS 22.1.3.3.2.1 feels the need to itemize the ways in which a read/write cycle can go wrong. Franz has done some interesting experiments with sensitivity. Personally, I think the case conversion should probably be moved to the vicinity of INTERN. In such a scheme, the reader might do no case conversion, but FIND-SYMBOL could do fuzzy matching depending on a couple factors specific to package-specific settings. Thus symbols in CL: could continue matching all cases, symbols in C++: could be case specific, ...
original Lisp を Python で実装したという Lithp: An interpreter for John McCarthy's original Lisp : programming
lithp.py Lithp - A interpreter for John McCarthy's original Lisp. The heavily documented code for Lithp can be found on Github. It wasn't enough to write the Lisp interpreter -- I also wanted to share what I learned with you. Reading this source code provides a snapshot into the mind of John McCarthy, Steve Russell, Timothy P. Hart, and Mike Levin and as an added bonus, myself. The following source files are available for your reading: * atom.py * env.py * error.py * fun.py * interface.py * lisp.py * lithp.py (this file) * number.py * reader.py * seq.py * core.lisp The Lithp interpreter requires Python 2.6.1+ to function. please add comments, report errors, annecdotes, etc. to the Lithp Github project page
Redmineへの貢献方法は下記HPに手順が書かれている。その中で注目する文章は、「Do not send a pull request on github.」。
台風による帰宅困難の問題に関しては、予想しあらかじめ防ぐということとあわせて、実際に帰宅困難者が出た場合の対応についても再度考える必要があるように感じました。
Walter Bright
企業内人材育成を機能させたいのなら、「自分の職務の後進育成を評価基準の軸にする」という動機付けも必要ですが、仕事を教えた人がそれによって不利益を被らないための安全装置？として、長期間（定年まで）の雇用保障も必要になるわけです。
統計解析フリーソフトウェアRについて。 | OKWave 統計解析フリーソフトウェアRについて。 Rでは、乱数を作ることができますよね。 例えば、サイコロやコイン投げ、じゃんけんなど。 では、次のような乱数を作ることはできますか？ 「100点満点のテストを100人が受けたとき、平均点が60点になるような乱数」 もし作ることができるのであれば、入力式を教えていただきたいです。 回答よろしくお願いします。ANo.1 =round((rand()-0.5)*80+60,0) 上の式は平均点が60で最高点が100点になるような乱数を発生させるはずです。お礼 回答ありがとうございます。 式を入力しみましたが、「エラー： 関数 "rand" を見つけることができませんでした」 と出てきてしまいました。 この式の前に何か他の式が必要なのでしょうか？ また、 関数round()は、四捨五入という意味ですよね？ なぜ四捨五入の式が必要なのですか？ お時間あれば、教えていただきたいです。 よろしくお願いします。ANo.2 no1です.私はエクセルを使いました。rand()はエクセルの乱数を作る関数です。 roundはおっしゃるとおり四捨五入をするためです。これをやらないと小数になるためです。お礼 2度目の回答ありがとうございます。 エクセルを使ったのですね!! ということはRでは、関数の定義が必要そうですね。。。 また色々試してみます☆ ありがとうございました(*_ _)人
0点～100点の範囲で、平均が60点(前後)。それっぽい分布になるようにとか 考えると結構面倒な気がする。 回答で提示された式だと最低点が20点になると思うんだけどそれはいいんだろうか?
んで、R で。
> runif(20, min=50, max=70) [1] 60.95758 59.59813 58.95083 65.19752 52.42425 54.04474 67.60003 69.80771 65.34212 [10] 62.26281 61.13051 68.93199 55.98755 52.73943 52.49520 59.83878 55.28431 53.00740 [19] 63.90235 68.57209 > sapply(runif(20, min=20, max=100), floor) [1] 60 45 47 31 56 78 72 63 56 38 50 30 34 55 69 43 37 92 51 66 > mean(sapply(runif(500, min=20, max=100), floor)) [1] 60.364 > mean(sapply(runif(500, min=20, max=100), floor)) [1] 59.084 > mean(sapply(runif(500, min=20, max=100), floor)) [1] 58.978 > mean(sapply(runif(500, min=20, max=100), floor)) [1] 59.146
それなりのデータはでてるっぽい。
60点を平均点として、正規分布するようなデータを作ってみる。
> u<-rnorm(1000, mean=60, sd=15) > min(u) [1] 11.51223 > max(u) [1] 116.2815 > mean(u) [1] 59.95409 > u[1] [1] 60.89928 > u[u>80] [1] 87.96685 80.36015 81.64465 86.06150 83.56702 88.72765 81.32469 86.92181 [9] 96.29741 100.20053 90.58559 86.69692 94.91039 98.09934 81.21012 80.49002 [17] 94.43125 81.20258 81.19933 85.65191 83.11338 101.89193 88.25325 83.01610 [25] 87.72954 89.19800 83.87994 93.03007 83.77035 82.11482 92.71152 88.88856 [33] 84.06509 90.47678 94.57279 80.74579 82.17579 82.95439 96.12576 82.84452 [41] 82.23468 91.81981 81.70759 92.12713 88.69367 82.73897 83.22090 89.96579 [49] 86.64229 92.53874 87.69451 86.37814 80.21702 80.40126 86.37388 81.06050 [57] 93.99818 83.58136 84.07553 90.94149 82.24431 84.49949 96.37880 87.15657 [65] 102.16134 83.95280 86.09360 91.01359 87.96550 80.17876 92.58915 91.39225 [73] 88.33039 91.55634 80.82914 89.56242 80.08814 81.16425 83.64871 94.89963 [81] 85.20294 82.98195 84.54388 92.28990 82.08427 88.33493 85.27480 96.41021 > u[u>100] [1] 100.2005 101.8919 102.1613
これだと100点オーバーが出ちゃうのよね。 100点オーバーは100点に丸めるのは簡単にできるけど、 それっぽいデータをでっち上げるにはどうするのがいいんだろう (そもそも正規分布するのかという話が)。
Qi の後継だとか。 Qiの作者今どうしてるんだろう… Shen 1.7 is now available - Google グループ
reddit での反応から。
Shen 1.7 released (successor to Qi II which was built on CL) : lisp Why does every "improved" lisp try to incorporate brackets and/or other delimiters? Does anyone really believe that if they could just get away from parenthesis the entire programming world would flock to lisp? I'm instantly annoyed when I see that. (I'm fine if they're optional, as in some Schemes).I hate the brackets in some schemes. It's even worse that they are optional because it gives rise to varying styles. Use of brackets to denote lists (like in Haskell) seems OK, but I haven't used Qi/Shen enough to form an opinion.It's even worse that they are optional because it gives rise to varying styles. You make a valid point. I shall now dislike them in all aspects. (Even to denote lists).I don't think that is the case here. Taking a wild guess I would say that it was done in Qi/Shen in order to provide additional type hinting for the optimization system.I just compiled it with clisp. I like partial application aspect. (map (/. z (z 10)) (map (/. x y (* x y)) [1 2 3])) [10 20 30] Is there any particular reason why Qi never caught on? I guess the Qi license was restrictive, but Shen seems to have fixed that.I looked into it but found the alternate syntax of the typing system to be to far away from the original 'extension of lisp' to be what I was looking for. The syntax basically threw any type-system meta-programming out the window, so I didn't look at it for very long.I would say Qi never caught on because it was based heavily on Common Lisp which doesn't exactly have the install base of CLR or the JVM. The Shen rewrite addressed this by the creation of K1 as a minimalist lisp needed to support Shen.Is there any particular reason why Qi never caught on? Here's my guess (note that all I know about Qi/Shen comes from a looking through its wikipedia page, but it only makes it more relevant): 1. It is not Lisp, syntax is far too complex. E.g. N [M | _] -> M where (> M N). So lispers are not interested. Parts which look lisp-like make it only worse in uncanny-valley kind of way: it looks ugly because you're comparing it with pure lisp syntax. 2. Non-lispers will find it ugly because it looks like lisp. 3. There is a number of mature functional programming languages, like Caml and Haskell. They are widely available, they actually work... Even if Qi implements some interesting features other languages don't have, does it justify switching? 4. Lispers might prefer language with lisp syntax, but Qi isn't one. It actually looks more complex than Haskell (for me) because at least Haskell is logically consistent. 5. Liskell demonstrated that it is possible to implement pattern matching with real lisp syntax in a way which isn't too bad. 6. As I understand, Qi/Shen is Dr. Mark Traver who is a weird guy: http://groups.google.com/group/Qilang/browse_thread/thread/592773c562017d87 7. Qi/ Qi II/Shen. How is language named? Wait, they do not separate language from implementation? Is it PHP or what?Yeah I don't know why Qi/Shen doesn't have an sexp option or least provide macros to convert N [M | _] -> M where (> M N) into an sexp and back again. The question of why not Caml and Haskell is the same question of why Lisp. The answer is absolute power and the end to greenspunning. Look at all the scaffolding and greenspunning Yesod does. Then there's the configuration problem -- lacking dependent types, Haskell has to greenspun away. Qi/Shen has the right idea; how it happens to have materialized is another matter. I would like to write Lisp code first and add static types later, if I choose. Dependent typing can do that. But static typing during development is a total waste because designs are never fully formed from the outset.I didn't think he raised the money to go ahead with Shen. Maybe it just pushed it down to hobby status?The December 2010 newsletter says that he achieved the funding goals for Shen
えーと、Oz が言語の名前だっけ?
Redesigning the Mozart virtual machine | Lambda the Ultimate Redesigning the Mozart virtual machine Dear all, The virtual machine of the Mozart system is in dire need of a refresh! It was originally designed in the early 1990s (twenty years ago!) and is now showing its age. We are working on a new virtual machine that is ready for the future. But some of the issues are still not clear, in particular how to represent the data. Yves Jaradin has prepared a detailed discussion of the issues. We would like to ask advice from the experts on LtU. What is the best way to write a virtual machine today? Is it possible to be simple and still efficient? Please let us know what you think. - Peter Van Roy and the Mozart development team
8月中に読みきって(途中まで読んで放置してる)書評を書く約束をしてたような気がする(^^;
問題。
プログラミングの質問です（ＶＢ、ＶＣ等で） | OKWave 自分は麻雀の結果の集計をしていて面倒な作業があり、プログラムを組めないだろうかと考えて おりますが、アルゴリズムを作成してコーディングしようにもどうやればいいのか分からないの でどうしたものかと困っております。どうしたらよいか、わかる方はどなたかお教え頂ければ助 かります。 質問０１．異なる１６個～２４個の数字があり、その中の４つの数字の和が０ずつになるように それぞれ分けたいのですが、どのようにすればよいでしょうか？ 例えば、４５、１０、－２５、－３０、５５、２０、－４５、－３０、２５、１５、－１０、－ ３０、８０、２５、－３５、－７０の１６個の数字があったとすれば、（４５、１０、－２５、 －３０）、（５５、２０、－４５、－３０）、（２５、１５、－１０、－３０）、（８０、２５、 －３５、－７０）の４つずつ４組にわけられようにできるプログラムを組みたいのです。なお、 数字は整数のみで、他にも２０個の場合もありますし、２４個の場合もあります。 質問０２．１０人～２０人の人数で４人ずつ麻雀卓（１０～１１人の場合は２つの麻雀卓、１２ ～１５人の場合は３つの麻雀卓、１６人以上は４つの麻雀卓（最大４卓））に座らせて、５回戦 を戦わせたいと考えております。その際には、できる限り違う人と戦わせたいとした場合、どの ような組み合わせができるかをプログラムで自動的に割り出したいのですが、どのようにすれば よいでしょうか？ なお、１０人や１１人などの人数の場合は２人余り、３人余りとなり、卓には座れず待つので、 その余った人は５回戦の内１回戦えないため４回戦だけとなります。さらに、できるだけばらけ た組み合わせは表などのようにわかりやすく表示できればより幸いです。 以上ですが、両方できれば最高ですが、どちらか一方でも構いませんので宜しくお願い致します。ANo.2 #1の者です。 麻雀の競技結果の集計だから、ゼロサムになるのは当たり前でしたね。 16個、20個、24個くらいであれば、それらから4個を選ぶ組合せを 総当たりで求めてもさほど大きな数にはならないので、 愚直ではありましょうがいちばん確実だと思います。ANo.1 質問０１についてお聞きします。 当該の16個、20個、または24個の整数の全体の合計が0であることは 保証済みなのでしょうか。補足 はい、それはもちろん保証済みです。合計は０になり、元々４つずつの合計が０だったものなのですが、 どの４つの数字の組み合わせが０であったのかがわからなくなってしまったのです。
24C4 でも16000くらいなので、Ruby でやってみた。 combination とかいうメソッドがあるのでとても楽。
![月刊 アフタヌーン 2011年 11月号 [雑誌]](http://ecx.images-amazon.com/images/I/61g5AfPBcjL._SL160_.jpg)
![日経ソフトウエア 2011年 11月号 [雑誌]](http://ecx.images-amazon.com/images/I/61%2BEPwwzFGL._SL160_.jpg)
>irb
irb(main):001:0> x=[45,10,-25,-30,55,20,-45,-30,25,15,-10,-30,80,25,-35,-70]
=> [45, 10, -25, -30, 55, 20, -45, -30, 25, 15, -10, -30, 80, 25, -35, -70]
irb(main):004:0> x.combination(4){|a,b,c,d| puts "[#{a},#{b},#{c},#{d}]" if a+b+c+d == 0}
[45,10,-25,-30]
[45,10,-25,-30]
[45,10,-25,-30]
[45,10,-45,-10]
[45,10,15,-70]
[45,-25,-45,25]
[45,-25,-45,25]
[45,-25,15,-35]
[45,-30,55,-70]
[45,-30,20,-35]
[45,-30,-30,15]
[45,-30,15,-30]
[45,55,-30,-70]
[45,55,-30,-70]
[45,20,-30,-35]
[45,20,-30,-35]
[45,-30,15,-30]
[10,-25,25,-10]
[10,-25,-10,25]
[10,-30,55,-35]
[10,55,-30,-35]
[10,55,-30,-35]
[10,20,-45,15]
[-25,55,-45,15]
[-25,20,15,-10]
[-25,-45,-10,80]
[-25,15,80,-70]
[-30,55,20,-45]
[-30,20,80,-70]
[-30,25,15,-10]
[-30,15,-10,25]
[55,20,-45,-30]
[55,20,-45,-30]
[55,-45,25,-35]
[55,-45,25,-35]
[55,25,-10,-70]
[55,-10,25,-70]
[20,-30,80,-70]
[20,25,-10,-35]
[20,25,25,-70]
[20,-10,25,-35]
[20,-30,80,-70]
[-30,25,15,-10]
[-30,15,-10,25]
[25,15,-10,-30]
[25,80,-35,-70]
[15,-10,-30,25]
[80,25,-35,-70]
=> [45, 10, -25, -30, 55, 20, -45, -30, 25, 15, -10, -30, 80, 25, -35, -70]
ちょっと悪のり。
irb(main):018:0* x.combination(4).select{|x| x.inject(:+) == 0}
=> [[45, 10, -25, -30], [45, 10, -25, -30], [45, 10, -25, -30], [45, 10, -45, -10],
[45, 10, 15, -70], [45, -25, -45, 25], [45, -25, -45, 25], [45, -25, 15, -35],
[45, -30, 55, -70], [45, -30, 20, -35], [45, -30, -30, 15], [45, -30, 15, -30],
[45, 55, -30, -70], [45, 55, -30, -70], [45, 20, -30, -35], [45, 20, -30, -35],
[45, -30, 15, -30], [10, -25, 25, -10], [10, -25, -10, 25], [10, -30, 55, -35],
[10, 55, -30, -35], [10, 55, -30, -35], [10, 20, -45, 15], [-25, 55, -45, 15],
[-25, 20, 15, -10], [-25, -45, -10, 80], [-25, 15, 80, -70], [-30, 55, 20, -45],
[-30, 20, 80, -70], [-30, 25, 15, -10], [-30, 15, -10, 25], [55, 20, -45, -30],
[55, 20, -45, -30], [55, -45, 25, -35], [55, -45, 25, -35], [55, 25, -10, -70],
[55, -10, 25, -70], [20, -30, 80, -70], [20, 25, -10, -35], [20, 25, 25, -70],
[20, -10, 25, -35], [20, -30, 80, -70], [-30, 25, 15, -10], [-30, 15, -10, 25],
[25, 15, -10, -30], [25, 80, -35, -70], [15, -10, -30, 25], [80, 25, -35, -70]]
irb(main):019:0> x.combination(4).select{|x| x.inject(:+) == 0}.length
=> 48
お粗末。 最初、x.sum とかやったのはナイショだ :)
今日もどこかで
Lisp Scheme Part32 843 デフォルトの名無しさん [sage] 2011/09/24(土) 18:42:41.81 ID: Be: (define (add3 a b c) (+ a b c)) という関数を作ったとき、 (add3 1 2) はエラーではなく、 (lambda (c) (+ 1 2 c)) を返すとかって便利だと思う？ おれは余計なお世話だと思う。 844 デフォルトの名無しさん [sage] 2011/09/24(土) 18:48:50.77 ID: Be: そんな処理系有るのか？ 845 デフォルトの名無しさん [sage] 2011/09/24(土) 18:59:40.70 ID: Be: つまり可変長の多値インターフェースなんか必要ない。 受け側で数が合わなければ未定義ではなく、エラーにすべきだろう。 実装するなら多値の数は固定にすべきだ。 数学的根拠もない、対象性もない、便利でもない、意味がない。 846 デフォルトの名無しさん [sage] 2011/09/24(土) 19:48:47.28 ID: Be: ((values 1 2 3) a b c (+ a b c)) => 6 って感じに使えたら素敵じゃね？ 847 SCHEME餃子 ◆8X2XSCHEME [sage] 2011/09/24(土) 20:02:43.94 ID: Be: >>844 いわゆるカリー化ってやつだろ。 Haskell なんかではそうなってるよ。 例えば↓こう書いたら3引数のように見える。 hoge x y z = x + y + z でも、これは構文糖に過ぎなくて、↓のように書くのと同じと解釈される。 hoge = (\x -> (\y -> (\z -> (x + y + z)))) この場合は演算子の優先順位的に括弧を省略できるので hoge = \x -> \y -> \z -> x + y + z とも書ける。 つまり、 Haskell に於いては全ての関数はたかだかひとつの引数しかとらない。 Haskell のこの方式はそれなりに使い勝手がいい面もあるんだけど、 あくまでも全体がそれで統一されてるから出来ることなんで、 Scheme でうまく整合性はとれんと思う。 定義のときに明示する形であれば出来るけど、便利という気はしないなぁ。 http://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3a%E6%89%8B%E7%B6%9A%E3%81%8D%E3%81%AEcurry%E5%8C%96 848 デフォルトの名無しさん [sage] 2011/09/24(土) 20:03:32.23 ID: Be: + とかどうすんのさ、と 849 デフォルトの名無しさん [sage] 2011/09/24(土) 20:41:06.28 ID: Be: Haskellの自動カリー化は、純粋関数型言語だからこそ、というところがあると思う。 MLは副作用あるくせに自動カリー化らしいけど、納得いかない。 850 デフォルトの名無しさん [sage] 2011/09/24(土) 21:57:54.61 ID: Be: 自動カリー化、とか考えるからおかしくなる 引数をひとつしか取らないだけだ 851 デフォルトの名無しさん [sage] 2011/09/24(土) 21:59:49.67 ID: Be: とゆーかふと思ったが、部分適用のことを「カリー化」って言ってないか？ 852 デフォルトの名無しさん [sage] 2011/09/24(土) 22:25:59.35 ID: Be: Lispで部分適用する関数をcurryとか最初に命名しちゃった人は罪深いな。 853 デフォルトの名無しさん [sage] 2011/09/24(土) 23:50:03.09 ID: Be: >>845 > つまり 飛躍しすぎw
一巻買っとくかなあ。探せばまだあるし。 というか、持ってるのは三巻だけか。 四巻はどうも買おうという気になかなかなれない (分冊なのはいいとして(元からそうだし)、その上であの値段ではなあ)。
推薦図書/必読書のためのスレッド 64 348 デフォルトの名無しさん [sage] 2011/09/24(土) 11:31:57.24 ID: Be: The Art of Computer Programming Volume1 これはいつごろ再版されるのでしょうか？ 349 デフォルトの名無しさん [sage] 2011/09/24(土) 13:57:17.49 ID: Be: 今売ってないんだ 俺の本棚で埃被ってるからやるよ 350 デフォルトの名無しさん [sage] 2011/09/24(土) 16:32:31.69 ID: Be: 電撃と合併しちゃったから、アスキーの硬派な技術系やコンピュータサイエンス系の 出版は今後細くなることはあっても太くなることはないんじゃないかという予感。 Knuth 先生が元気なうちに、Knuth 先生が納得するような電子化のめどがつけばいいが。 351 デフォルトの名無しさん [sage] 2011/09/24(土) 17:32:57.31 ID: Be: Knuth先生は100まで生きるから気長に待っとけということなのか
うは。倍額w
三日分。
それでも、ワールドワイドに尊敬を集め、幾多の開発プロジェクトに参加を請われてきた源は何なのか。
また他路線の運休により乗客が殺到したため、運転を見合わせたケースも。東京メトロでは銀座線、日比谷線など7路線がストップしたが、 地上区間の強風が原因の南北線を除く6路線は、駅構内の過度の混雑が原因で夕方5時ごろから、路線によっては10時まで運休となった。
実際浮動小数点数はどの程度の誤差を生むのでしょうか。猿でも分かる程度教えてください。
基礎過ぎて動物園に帰れのような批判は勘弁してください。。。
エディターの色つけ表示について。
2011-09-18 - odz buffer
とりあえず、emacs 18 ではカラー表示ができたようだ。
Color-Mate
20 あたりかと思ってました。 自分の使ってた端末の問題かも。
ねちねちとこの話題も続けます :)
まずはこの本の記述から
プログラミング言語Java 第4版 p54 2.6.5 パラメータの値 メソッドのパラメータは、すべて「値渡し（by value）」です。言い換えると、メソッドのパラメータ 変数の値は、呼び出し側が引数として指定した値のコピーです。メソッドにdoubleを渡したとすると、 パラメータは、引数として渡されている値のコピーです。メソッドを呼び出したコード内の値に影響を 与えることなく、呼び出されたメソッドはパラメータの値を変更できます。次は、その例です。 略 パラメータがオブジェクト参照の場合には、オブジェクトそのものではなく、オブジェクト参照 が「値渡し」されるのに注意してください。つまり、渡された先の参照に影響を与えることなく、 メソッド内でパラメータがどのオブジェクトを参照するかを変更できます。しかし、オブジェク トのフィールドを変更したり、オブジェクトの状態を変更するメソッドを呼び出すと、そのオブ ジェクトへの参照を持っているプログラム内のすべての箇所に対して、そのオブジェクトを変更 することになります。この違いを示しているのが次の例です。 略 オブジェクトは「参照渡し」されると、誤って言ってしまう人もいます。プログラミング言語の デザインでは、用語「参照渡し（pass by reference）」は、関数に引数が渡される場合に、呼 び出された関数が元の値への参照を得るのであり、値のコピーを得るのではないのが正しい意味 です。もし、関数がそのパラメータを修正すると、引数とパラメータはメモリ上の同じ領域を使 用しますので、呼び出し側の値も変更されてしまいます。もし、プログラミング言語Javaが「参 照渡し」をするパラメータを持っているとしたら、halveIt がoneの値を変更したり、commonName が 変数 sirius を null に設定したりできることになります。しかし、それは不可能です。 プログラミング言語Javaは、オブジェクトを参照渡ししません。オブジェクト参照を値渡ししま す。同じ参照の2つのコピーは同じ実際のオブジェクトを参照していますから、片方の参照変数 により行った修正は、もう片方の参照からも見えます。パラメータの渡したかには、1つの方法 しかなく、それは「値渡し」であり、それにより事を簡単にしています。
さっとJavaの本(入門書)を調べてみたところ、 以下の本で「primitive 型は値渡し、オブジェクト型は参照渡し」のような記述をしてました (三冊目はちょっと微妙な書き方だけど)。 これ以外にもまだあるかもしれません。
情報求む :)
プログラミング言語 Java 第4版からさらに
p125 5.4 無名内部クラス ローカル内部クラスまでは必要でない場合には、クラスを拡張あるいはインタフェースを実装し た無名クラス(anonymous class）を宣言できます。無名クラスは、new でインスタンス化される 時に定義されます。 p172 8.6 ボクシング変換 基本データ型の変数を、そのラッパークラスのインスタンス変数に自動的に変換することは、ボ クシング変換(boxing conversion)と言います。つまり、ラッパーオブジェクトは、基本データ 型の値を保持している「箱(box)」として振る舞います。ラッパークラスのインスタンスから基 本データ型への逆の変換は、アンボクシング変換(unboxing conversion)と言います。 ボクシング変換は、基本データ型の値 v を同じ値のラッパーオブジェクトで置き換えます。その ラッパーオブジェクトの型は、v の型に対応します。
「匿名クラス」「ボックス化」「ボックス化解除」という訳は採用していませんでした。
船の科学館。 写真貼り付けといて何も書いていませんでしたが、 なんというか時代を感じさせるなあというのが各所に。 たとえば、深海開発のガイドのエリアがあったんですけど そこで紹介されてたのが「しんかい2000」だとか 「トリエステ」 ほかにも、何箇所かにガイドのビデオを流すものがあったんですけど ブラウン管の表示機を使っていて、しかも焼きつき起こしてたりして。 最近できたっぽい展示物では液晶のフラットスクリーンだったりしたんですが、 入れ替えたりはできなかったんですかねー。 細かく見はしませんでしたが、いろいろな統計情報(輸出入量とか)の年度も 微妙に古かったような…
わたしは博物館の類は大好きなんですが、 常設の展示だけだとやっぱり厳しいのかもしれませんねえ＞船の科学館 といって、宇宙博みたいのはそうそうできないだろうし。
ダウン
FFI のおはなし。
Which foreign function interface is the best? | Richard WM Jones Which foreign function interface is the best? どの外部関数インターフェースがベストか? I've written libguestfs language bindings for Perl, Python, Ruby, Java, OCaml, PHP, Haskell, Erlang and C#. But which of these is the best? Which is the easiest? What makes this hard? Grubbing around in the internals of a language reveals mistakes made by the language designers, but what are the worst mistakes? わたしは Perl, Python, Ruby, Java, OCaml, PHP, Haskell, Erlang, C# といった言語に対する libguestfs のバインディングを書きました。ところでどの言語向けのものが一番良いものであり、 どの言語向けのものが一番簡単なのでしょうか? これを難しくしているものは何でしょうか? ある言語の内部をあれこれすることはその言語の設計者による間違いを明らかにしますが、 最悪の間違いとは何でしょうか? Note: There is source that goes with this. Download libguestfs-1.13.13.tar.gz and look in the respective directories. The best It's going to be a controversial choice, but in my opinion: C#. You just add some simple annotations to your functions and structs, and you can call into shared libraries (or “DllImport”s as Microsoft insisted on calling them) directly. It's just about as easy as directly calling C and that is no simple achievement considering how the underlying runtime of C# is very different from C. これは controversial な選択になりますが、わたしの意見では C# です。 (C# では) 関数や構造体に単純なアノテーションをいくつか追加するだけです それで共有ライブラリ(もしくは ) を直接呼び出せるようになります。 これは直接 C を呼ぶのと同じくらい簡単で、 C とは非常に異なっている C# のランタイムにどのように依存しているのかを Example: a C struct: [StructLayout (LayoutKind.Sequential)] public class _int_bool { int i; int b; } The worst There are two languages in the doghouse: Haskell and PHP. PHP first because their method of binding is just very broken. For example, 64 bit types aren't possible on a 32 bit platform. It requires a very complex autoconf setup. And the quality of their implementation is very poor verging on broken — it makes me wonder if the rest of PHP can be this bad. 犬小屋に二つの言語があります(??): Hasekk と PHP です。そのバインディングの手順が just very broken なので PHP が一番です。 たとえば、64ビット型は 32ビットプラットフォームでは使えません。 非常に複雑な autoconf のセットアップが要求されます。 また、その実装の質は非常に poor で Haskell: even though I'm an experienced functional programmer and have done a fair bit of Haskell programming in the past, the FFI is deeply strange and very poorly documented. I simply could not work out how to return anything other than integers from my functions. You end up with bindings that look like this: Haskellについて。わたしは経験をつんだ functional programmer で、過去 Haskell プログラミング をかなりこなしてきました。 Haskell の FFI は deeply strange であり、ドキュメントもほとんどありません。 わたしはどのように自分の関数から整数以外の何かを返すのかを simply に work out できませんでした。 write_file h path content size = do r <- withCString path $ \path -> withCString content $ \content -> withForeignPtr h (\p -> c_write_file p path content (fromIntegral size)) if (r == -1) then do err <- last_error h fail err else return () The middle tier There's not a lot to choose between OCaml, Ruby, Java and Erlang. For all of them: you write bindings in C, there's good documentation, it's a bit tedious but basically mechanical, and in 3 out of 4 you're dealing with a reasonable garbage collector so you have to be aware of GC issues. There's not a lot to choose between OCaml, Ruby, Java and Erlang. これらすべてに対して C でバインディングを書きますし良いドキュメントがあります。 多少手間はかかりますが基本的には機械的なもので Erlang is slightly peculiar because the method I chose (out of many possible) is to write an external process that talks to the Erlang over stdin/stdout. But I can't fault their documentation, and the rest of it is sensible. Erlang はとても変わったものです。それは、わたしが選択した手順が Erlang と talk する外部プロセスに書き出すために stdin/stdout を経由したものだからです。 しかしわたしはそのドキュメントで失敗できませんでしたし(??）、 ほかの手段は sensible だったのです。 #びみょー Example: Here is a function binding in OCaml, but with mechanical changes this could be Ruby, Java or Erlang too: 以下の例は OCaml における関数バインディングですが、機械的な変換を施すことで Ruby や Java、Erlang にも使えます: CAMLprim value ocaml_guestfs_add_drive_ro (value gv, value filenamev) { CAMLparam2 (gv, filenamev); CAMLlocal1 (rv); guestfs_h *g = Guestfs_val (gv); if (g == NULL) ocaml_guestfs_raise_closed ("add_drive_ro"); char *filename = guestfs_safe_strdup (g, String_val (filenamev)); int r; caml_enter_blocking_section (); r = guestfs_add_drive_ro (g, filename); caml_leave_blocking_section (); free (filename); if (r == -1) ocaml_guestfs_raise_error (g, "add_drive_ro"); rv = Val_unit; CAMLreturn (rv); } The ugly Perl: Get reading. You'd better start with perlxs because Perl uses its own language — C with bizarre macros on top so your code looks like this: まず perlxs を読むべきでしょう。 Perl は奇妙なマクロをあなたのコードに被せる C であるような固有の言語を持っています。 それは次のような外見をしています: SV * is_config (g) guestfs_h *g; PREINIT: int r; CODE: r = guestfs_is_config (g); if (r == -1) croak ("%s", guestfs_last_error (g)); RETVAL = newSViv (r); OUTPUT: RETVAL After that, get familiar with perlguts. Perl has only 3 structures and you'll be using them a lot. There are some brilliant things about Perl which shouldn't be overlooked, including POD which libguestfs uses to make effortless manual pages. そのあとで perlguts に慣れ親しみましょう。 Perl はたったの三種類の構造体しか持たず、あなたはそれらを大量に使うことになるでしょう。 Python: Best described as half arsed. Rather like the language itself. Python, Ruby, Erlang: If your language depends on “int”, “long”, “long long” without defining what those mean, and differing based on your C compiler and platform, then you've made a big mistake that will unfortunately dog you throughout the runtime, FFIs and the language itself. It's better either to define them precisely (like Java) or to just use int32 and int64 (like OCaml). あなたの言語が “int”, “long”, “long long” というものに依存しているのならば それらが意味していることの定義抜きに 異なるCコンパイラーとプラットフォーム (Javaのように) precisely に定義したり (OCamlのように) int32 や int64 を使うよりも better です And finally, reference counting (Perl, Python). It's tremendously easy to make mistakes that are fiendishly difficult to track down. It's a poor way to do GC and it indicates to me that the language designer didn't know any better. そして最後に、(Perl や Python の) reference counting について。 reference counting は追跡するのがとても難しい間違いを非常に犯しやすいものです。 それは GC を行うには poor way であり、それらの言語の設計者がもっと良いものを 知らなかったことを示すものです。6 Comments 1. Ferry Huberts (@fhuberts) September 21, 2011 at 9:42 pm Actually, Java is pretty good at this too if you use JNA, see http://en.wikipedia.org/wiki/Java_Native_Access and https://github.com/twall/jna. * rich September 21, 2011 at 9:57 pm Yes, this looks like it gets why C# is so good. Thanks for pointing it out. 2. Daniel Svensson September 21, 2011 at 10:04 pm When it comes to Python, you should really have a look at the Cython project over at http://cython.org/. The bare C-bindings are not that user friendly. Also, if the library you bind is ref-counted, binding it to Python fits very well. I do however agree that it's flawed to use refcounting as the benefits of freeing data predictable is defeated when you get a VM-stall due to freeing a ton of data at the time it goes out of scope.. although as long as Azul Systems JVM is proprietary, I'd say all VM's are flawed. 3. Kevin Kofler September 22, 2011 at 5:13 am Oh joy, I also had my fun with the Haskell FFI. In my case, I was trying to make the Grammatical Framework (GF) runtime in Haskell accessible to C code, i.e. I was using it in the opposite direction as you. Now the good news is that, unlike for many other FFIs (which are only unidirectional), that direction is actually supported. The bad news is that it's even more poorly documented and painful, and that there are some implementation peculiarities: In particular, the most popular compiler (GHC) requires you to call some initialization function under #ifdef if you're calling any GHC-compiled code from a main function in C, and there's no telling whether less popular compilers won't require some other non-standard code to actually work. (If an initialization function is needed in practice, why isn't it part of the FFI spec?) Another annoyance is that a StablePtr (which is pretty much the only sane way to return a Haskell object to C code) cannot officially be NULL: (castPtrToStablePtr nullPtr) works in practice (at least with GHC), but the Haskell FFI spec explicitly warns that this is not guaranteed to work. Yet returning NULL is the best way to report an error, or to return a Maybe with Nothing in it. It's possible to use Ptr () instead of StablePtr a in all the interfaces, which will lead to the same API on the C side, but that's not going to make the code more readable. I went for the (castPtrToStablePtr nullPtr) hack and hoped for the best. 4. Scott Tsai (@scottttw) September 22, 2011 at 5:18 am 1. Is C#'s DllImport better than Python's ctypes? http://docs.python.org/library/ctypes.html 2. Re: GC and FFI, although reference counting is tedious, many C programmers are not used to interfacing with automatic garbage collection and if the FFI designer doesn't take special care to make interacting with GC “hard to get wrong” you can get bugs like: http://www.reddit.com/r/programming/comments/iwyi0/the_broken_promises_of_mrireeyarv_now_you_have/ 5. Romain Beauxis September 22, 2011 at 8:57 am Try node.js with a callback-based API like libflac, I bet you'll put it at the bottom right away…
まあ、Cython は無視できませんよね。
結構前からあるページで、自分も以前に見たことがあるのですが reddit でまた取り上げられていたので。
article | Perl 5 to Perl 6 Perl 5 to Perl 6 This collection of articles started out as a series of blog posts, and has been assembled here because it's easier to read in the chronological order. Table of Contents * Introduction * Strings, Arrays, Hashes; * Types * Basic Control Structures * Subroutines and Signatures * Objects and Classes * Contexts * Regexes (also called "rules") * Junctions * Comparing and Matching * Containers and Values * Changes to Perl 5 Operators * Laziness * Custom Operators * The MAIN sub * Twigils * Enums * Unicode * Scoping * Regexes strike back * A grammar for (pseudo) XML * Subset Types * The State of the implementations * Quoting and Parsing * The Reduction Meta Operator * The Cross Meta Operator * Exceptions and control exceptions * Common Perl 6 data processing idioms * Currying (略) Currying with assuming assuming を使った currying Perl 6 provides a method assuming on code objects, which applies the arguments passed to it to the invocant, and returns the partially applied function. Perl 6 は、与えられた引数を invocant のために適用して 部分的に適用された関数を返すような コードオブジェクトを assuming する手順を提供しています #わからねー my &f := &substr.assuming('Hello, World'); Now f(1, 2) is the same as substr('Hello, World', 1, 2). これで f(1, 2) は substr('Hello, World', 1, 2) と同じになります。 assuming also works on operators, because operators are just subroutines with weird names. To get a subroutine that adds 2 to whatever number gets passed to it, you could write 演算子は単なる weird name を持ったサブルーチンに過ぎません。 渡されたなんらかの数値に 2 を加えるサブルーチンを得るには次のように書けます my &add_two := &infix:<+>.assuming(2); But that's tedious to write, so there's another option. しかしこれは書くのが面倒ですから、別のオプションがあります。 Currying with the Whatever-Star Whatever-Star を使った currying my &add_two := * + 2; say add_two(4); # 6 The asterisk, called Whatever, is a placeholder for an argument, so the whole expression returns a closure. Multiple Whatevers are allowed in a single expression, and create a closure that expects more arguments, by replacing each term * by a formal parameter. So * * 5 + * is equivalent to -> $a, $b { $a * 5 + $b }. この Whatever と呼ばれるアスタリスクは引数に対するプレースホルダーであり、式全体はクロージャ を返します。複数の Whatever を一つの式の中で使うことも可能で、それは より多くの引数を期待するひとつのクロージャを生成します。 ですから、* * 5 + * は -> $a, $b { $a * 5 + $b } と等価です。 my $c = * * 5 + *; say $c(10, 2); # 52 Note that the second * is an infix operator, not a term, so it is not subject to Whatever-currying. 二番目の * は中置演算子であり term ではないので、 Whatever-currying のための subject ではないことに注意してください。 The process of lifting an expression with Whatever stars into a closure is driven by syntax, and done at compile time. This means that Whatever stars を伴った式のクロージャへの lifting 処理は構文によって drive されるので コンパイル時に行われます。 これはつまり、 my $star = *; my $code = $star + 2 does not construct a closure, but instead dies with a message like がクロージャを構築しないことを意味し、 代わりに以下のようなメッセージを伴って die します。 Can't take numeric value for object of type Whatever Whatever currying is more versatile than .assuming, because it allows to curry something else than the first argument very easily: currying は .assuming よりも汎用的です 第一引数以外の何かをとても簡単に curry するのが可能なので say ~(1, 3).map: 'hi' x * # hi hihihi This curries the second argument of the string repetition operator infix x, so it returns a closure that, when called with a numeric argument, produces the string hi as often as that argument specifies. これは curry します 二番目の引数を 文字列繰り返し中置演算子 x の そしてクロージャを返します 数値引数を伴って呼ばれたときに 与えられた引数の回数だけ文字列 hi を作り出す The invocant of a method call can also be Whatever star, so あるメソッド呼び出しの invocat は Whatever star にもできるので、 say <a b c>.map: *.uc; # ABC involves a closure that calls the uc method on its argument. その引数に対して uc メソッドを呼び出すクロージャを involve します MOTIVATION Perl 5 could be used for functional programming, which has been demonstrated in Mark Jason Dominus' book Higher Order Perl. Perl 6 strives to make it even easier, and thus provides tools to make typical constructs in functional programming easily available. Currying and easy construction of closures is a key to functional programming, and makes it very easy to write transformation for your data, for example together with map or grep. SEE ALSO http://perlcabal.org/syn/S02.html#Built-In_Data_Types http://hop.perl.plover.com/ http://en.wikipedia.org/wiki/CurryingCopyright 2008 - 2010: Moritz Lenz This page may be used under the terms of the Creative Commons Attribution 3.0 Germany License. Please place a link to the pages you use for your derivative work.
ボツ
ボツ
電人ザボーガー上映館
都内だとバルト9(新宿)と 渋谷TOEI、もう一箇所大泉学園あたりの三箇所のようだけど
渋谷は一週間しかやらないのね。つーことは16日(日曜日)にがんばっていくしかない?
バルト9はどうなんだろう
買った・読んだ
感想などはまた。
結構いろんな方に, 「あの菌類の人ですか？(意訳)」と聞かれました(^^;;
CoffeeScript の list comprehension の動作について。 comprehension を「内包表記」とするのはちょっと引っかかるものを感じていたりいなかったり。
brehaut.net: CoffeeScript Comprehensions Are Broken CoffeeScript Comprehensions Are Broken I have recently been using a small amount of CoffeeScript at work and evaluating its merit in my web development toolbox. This post is about a particular feature in CoffeeScript that is poorly considered. CoffeeScript provides notation for comprehensions; A comprehension allows the programmer to concisely express operations over one or more sets of items. While Javascript programmers do not currently have a syntactic mechanism for this, it is part of the Harmony project. Comprehensions can be found in a number of languages these days. The big names are Python (list and generator comprehensions) and C# (LINQ). Both languages took their ideas from Haskell which in turn took them from prior functional languages. In both cases comprehensions are deep and very expressive tool. Comprehensions (内包) は今日の多くの言語に見られます。 主なものには Python (list や generator の comprehension があります) や C# (LINQ) があります。どちらの言語も先行していた関数型言語の Haskell から そのアイデアを取り込んでいます。また、どちらの言語でも comprehensions は deep で very expressive なツールです。 First up lets examine a comprehension in CoffeeScript. The basic notion is that a comprehension is a for loop as an expression. For example: l = x * 2 for x in [0..5] // => [0, 2, 4, 6, 8, 10] or alternatively: l = for x in [0..5] x * 2 // => [0, 2, 4, 6, 8, 10] This is clearly a straight forward mapping. We can also add filtering clause e.g.: l = x * 2 for x in [0..5] when x % 2 // => [2, 6, 10] So what is the problem? The answer is two-fold: firstly, the semantics of nested comprehensions are non-optimal (even incorrect), and secondly they are strict. いったい何が問題なのでしょうか? その答えは二つに集約されます: 第一に、ネストした comprehensions の semantics が non-optimal である (不正 (incorrect) なものでさえあります) ことで、第二に、それが strict であることです。 Nested comprehensions ネストした comprehensions To examine this issue, I am going to compare CoffeeScript and Python for the semantics of nested comprehensions. Firstly the CoffeeScript: 問題点を明確にするために、CoffeScript と Python とでネストした comprehensions の semantics を比較します。まず CoffeScript: l = for x in [0, 1, 2] for y in ["a", "b", "c"] "#{x},#{y}" // => [["0,a", "0,b", "0,c"], // ["1,a", "1,b", "1,c"], // ["2,a", "2,b", "2,c"]] And now Python: 次に Python: l = ["%s,%s"% (x,y) for x in [0,1,2] for y in ["a","b","c"]] # => ['0,a', '0,b', '0,c', # '1,a', '1,b', '1,c', # '2,a', '2,b', '2,c'] This illustrates the difference quite clearly. In Python, a language with real comprehensions, the comprehension results in a single list that is the cross product of both source lists. In CoffeeScript, we get a list of lists of objects. この比較は、両者の違いを明らかなものにしています。 Python では、本物の comprehension が実装されていて、単一のリストにおける comprehension の結果は二つのソースリストの cross product になっています。 CoffeeScript では、リストのリストが手に入ります。 To illustrate that the Python version is in fact more expressive, the following Python generates the same shaped result as the CoffeeScript version: Python のものがより expressive であることを示すために、 次の Python スクリプト片は CoffeeScript 版と同様に同一の shared result を生成します。 l = [["%s,%s" % (x,y) for y in ["a","b","c"]] for x in [0,1,2]] # => [['0,a', '0,b', '0,c'], # ['1,a', '1,b', '1,c'], # ['2,a', '2,b', '2,c']] I refer to the CoffeeScript behaviour as ‘map' oriented comprehensions, and the Python behaviour as ‘mapcat' oriented comprehensions. The mapcat model is more compositional than the map model. This means that the result of a function that is defined as mapcat oriented comprehension can be the input to itself recursively. For example: わたしはこの CoffeeScipt 版の動作を 'map' 指向の comprehesions であるとみなしていて、 そして Python の動作を'mapcat' 指向の comprehensions であるとみなしています。 mapcat モデルは map モデルよりも一層 compositional です。 それはつまり、mapcat 指向の comprehension として定義されているある関数の結果は それを再帰的に自身の入力とすることができるということです。 def flatten(l): try: return [y for x in l for y in flatten(x)] except TypeError, e: # horrible test for iterability return [l] flatten(1) # => [1] flatten([1,2]) # => [1, 2] flatten([[[1,2], 3], [[4]]]) # => [1, 2, 3, 4] Strictness Strictness is the property of a program to be evaluated in its entirety as soon as possible, in contrast to laziness which delays as much computation as long as possible. Most languages exist somewhere on the spectrum of fully strict to mostly lazy. With regard to comprehensions, a strict comprehension takes one or more lists and creates a new list. A lazy comprehension takes a stream of values and returns a stream of values, computing them by need. strictness は可能な限り即座にその全体を評価しようとするプログラムの性質で、 可能な限り computation を遅延させる laziness と対称的なものです。 Most languages exist somewhere on the spectrum of fully strict to mostly lazy. comprehensions について、strict comprehension はひとつ以上のリストを受け取り 新しいリストをひとつ作り出します。lazy comprehension は値のストリームを受け取って 値のストリームを返し、必要に応じて computing します。 The underlying mechanism of this laziness in an otherwise strict programming language is typically something resembling an iterator: You have an object with a current value and method of retrieving the remaining values. One of the advantages of this is that you can perform computations on an infinite stream. E.g. in Pythoniii, taking the first 10 items for a stream: import itertools i = itertools.islice(itertools.cycle("abc"), 10) # i => <itertools.islice object at 0x1004c1f70> list(i) # use a list to realise the iterator and produce a print friendly # representation # => ['a', 'b', 'c', 'a', 'b', 'c', 'a', 'b', 'c', 'a'] 略Copyright © Andrew Brehaut 2004–2011.
明日でイカサマータイムがようやく終わりだこんちくしょー
一つ前へ
2011年9月(中旬)
一つ後へ
2011年10月(上旬)
リンクはご自由にどうぞ
メールの宛先はこちら
