■_
一つ前へ
2012年6月(上旬)
一つ後へ
2012年6月(下旬)
いっかいやすみ
御茶ノ水→秋葉原→(総武線)→代々木→新宿三丁目→新宿西口 と結構歩いて疲れたw 新宿駅南口から代々木の辺りってああいう風に変わってたのねえ。
The JavaScript Problem - HaskellWiki 1 The problem The JavaScript problem is two-fold and can be described thus: JavaScript の問題は二つに集約でき、次のようにまとめられる JavaScript sucks. The depths to which JavaScript sucks is well-documented and well-understood. Its main faults are: its lack of module system, weak-typing, verbose function syntax¹, late binding², which has led to the creation of various static analysis tools to alleviate this language flaw³, but with limited success⁴ (there is even a static type checker⁵), finicky equality/automatic conversion, this behaviour, and lack of static types. Coffeescript is the most mainstream javascript alternative. Although it makes many aspects of Javascript sane and convenient, it still suffers from weak-typing. JavaScript sucks. The depths to which JavaScript sucks は詳しくドキュメント化されているし、理解もされています。 その主な失敗は以下のとおりです。 モジュールシステムの欠如、弱い型付け、冗長な関数の構文、 この language flaw を代替するためのさまざまな static analysis tools を作らせることとなったが 限定的な成功しか収められてなかった遅延束縛、 finicky な equality や自動変換、静的な型の欠如。 Coffeescript は JavaSript の代替の most mainstream です。 Although it makes many aspects of Javascript sane and convenient, it still suffers from weak-typing. We need JavaScript. Using it for what it is good for, i.e. providing a platform for browser development, but not using the language per se, is therefore desirable, and many are working to achieve this, in varying forms. There various ways to do it, but we ought to opt for compiling an existing language, Haskell, to JavaScript, because we do not have time to learn or teach other people a new language, garner a new library set and a new type checker and all that Haskell implementations provide. わたしたちには JavaScriptが必要です。 それを良いこと、つまり、ブラウザー開発のためのプラットフォームを提供のために使います。 しかし、言語そのものを使うことは当然 desirable であり、多くの人がさまざまな形で それを achieve するために作業しています。 様々なやり方がありますが、わたしたちが採用したのは既存の言語である Haskell を JavaScript にコンパイルするというものです。 なぜならわたしたちには、新しい言語や新しいライブラリ、新しい型チェッカーを ほかの人たちに教えたり、自分たちが学ぶような時間がないからです。
不調 ○| ̄|_
Super-star programmers | Hacker News で盛り上がってる話
Super-star programmers: Difference engine: Wired for speed | The Economist Super-star programmers Difference engine: Wired for speed Jun 15th 2012, 13:42 by N.V. | LOS ANGELES ARE geniuses just born with their brains wired differently? Or do their early experiences fashion a richer set of neuronal interconnections that let them view the world through a sharper lens? The literature is replete with accounts of people who went on to accomplish great things—in the arts, sciences, philosophy or even politics—after exhibiting little promise in their youth. It would be encouraging to think that, if nurturing does indeed play a crucial part, there could yet be hope for the rest of us. An outfit in San Francisco called “tenXer” has begun testing a service that aims to help people boost their mental accomplishments by up to tenfold—hence its name. That has made your correspondent wonder what distinguishes the truly talented from the journeymen of any trade. And what, if anything, the rest can do to improve their more menial lot. (略)
Haskell web programming 図が豊富なので元記事をどぞ。
Haskell web programming Its efficiency (see Snap Benchmark & Warp Benchmark). Haskell is an order of magnitude faster than interpreted languages like Ruby and Python. Haskell is a high level language and make it harder to shoot you in the foot than C, C++ or Java for example. One of the best property of Haskell being: Haskell は高水準言語であり、たとえばCやC++、Javaよりも自分の足を打ち抜きにくいようになっています。 One of the best property of Haskell being: “If your program compile it will be very close to what the programmer intended”. (もしあなたのプログラムがコンパイルに成功すればそれは意図したものと非常に近いものでしょう) Haskell web frameworks handle parallel tasks perfectly. For example even better than node.js. Haskell の webフレームワークは parallel task を完璧にハンドルします。 From the pure technical point of view, Haskell seems to be the perfect web development tool. Weaknesses of Haskell certainly won't be technical: 純粋に技術的な点から言って、Hasjell は完璧な web 開発ツールとなっているようです。 Haskell の弱点は間違いなく技術的なものではないでしょう: Hard to grasp Haskell Haskell を理解するのは難しい Hard to find a Haskell programmer Haskell プログラマーを見つけるのは難しい The Haskell community is smaller than the community for /.*/ Haskellコミュニティは ××× 言語のコミュニティよりも小さい There is no heroku for Haskell (even if Greg Weber did it, it was more a workaround). Haskell 向けの heroku がない I won't say these are not important drawbacks. But, with Haskell your web application will have both properties to absorb an impressive number of parallel request securely and to adapt to change. わたしはこれらのことがらが重大な欠点ではないと主張するつもりはありません。 しかし、Haskell を使って、あなたの web アプリケーションは 非常に多数の parallel request を安全に緩衝する性質と 変更を適用する性質の両方ともを手に入れることになるのです。 #なんかよくわからない Actually there are three main Haskell web frameworks: Happstack Snap Yesod I don't think there is a real winner between these three framework. The choice I made for yesod is highly subjective. I just lurked a bit and tried some tutorials. I had the feeling yesod make a better job at helping newcomers. Furthermore, apparently the yesod team seems the most active. Of course I might be wrong since it is a matter of feeling. 1. Draw some circles. 2. Draw the rest of the fucking owl Why did I write this article? The yesod documentation and particularly the book are excellent. But I missed an intermediate tutorial. This tutorial won't explain all details. I tried to give a step by step of how to start from a five minute tutorial to an almost production ready architecture. Furthermore explaining something to others is a great way to learn. If you are used to Haskell and Yesod, this tutorial won't learn you much. If you are completely new to Haskell and Yesod it might hopefully helps you. Also if you find yourself too confused by the syntax, it might helps to read this article (略
根本的な疑問として、何に対してデコレータを使うことができるのだろう?
三昧。
登録してみた。Weekly Design Patterns
クライシスレスポンスを支えた夜食のパスタ – 東日本大震災と情報、インターネット、Google を読んで、あの日(とその後数日)の某社の行動をちょっと思い返した。
Good Developer, Bad Developer | Guy Nirpaz Blog Good Developer, Bad Developer Posted on June 11, 2012 by guynirpaz I recently read Ben Horowitz's piece on the importance of training people in startup companies. At the end of this article he put together a document “Good Product Manager, Bad Product Manager”. Here's my spin on it: Good Developer, Bad Developer. Enjoy, I look forward to your comments! Good Developer, Bad Developer 優れた developer と劣った developer Good developer is an artist, a craftsman who enjoys the process of creation. Bad developer considers himself as a programmer, responsible for generating lines of code. 優れた developer は、process of creation を楽しむ artist であり、craftman です。 劣った developer は自身をプログラマーであるとみなし、コードを書くことに responsible です。 Good developer understands the problems of the customers. Bad developer understands only the technical problem at hand. Good developer does not define the why, but constantly strives to understand why. He's responsible for the how, and still sees the big picture. Bad developer is focused on building classes and methods and configuration files, but does not get the big picture. 優れた developer は顧客の問題を理解しています。 劣った developer は技術的な問題だけしか理解していません。 優れた developer は define the why しませんが、 but constantly strives to understand why. He's responsible for the how, and still sees the big picture. 劣った developer はクラスとメソッドや、コンフィグレーションファイルの構築にフォーカスしていて big picture を把握していません。 Good developer understands the complete architecture of the product. Bad developer knows only the components he's written. Good developer fully understands the technologies that are used within the product. He understands what they are used for, and how they work internally. 優れた developer は製品の複雑なアーキテクチャ全体を理解しています。 劣った developer は自分の書いたコンポーネントだけしか理解していません。 製品で使われているテクノロジーを、優れた developer は完全に理解しています。 He understands what they are used for, and how they work internally. Good developer is not afraid of new technologies but embraces them by quickly getting a grip. Bad developer only sticks to what he knows. His immediate reaction to any technical change is negative. 優れた developer は (quickly に getting a grip して) 新しいテクノロジーを恐れずに embrace します。 劣った developer は自分が知っているものにだけこだわります。 技術的な変化全般に対する劣った developer の immediate reaction は negative なものです。 Good developer is constantly learning and improving his skills. Good developer reads technical articles, and finishes several technical books a year. Bad developer does not have time to learn. He's always too busy with other stuff. 優れた developer は constantly に学習し、自分の skill を向上させます。 また、technical articles を読み、一年に数冊の technical な本を読破します。 劣った developer は学ぶための時間を持ちません。 ほかのこと (other stuff) のためにいつでも忙しすぎるのです。 Good developer cares about the product quality. He is also very much concerned with the process quality. Good developer pushes himself to create bug-free code; bad developer leaves it to QA to find bugs to fix. 優れた developer は製品の quality に注意を払います。 また、プロセスの quality にも関心を持っています。 そして、バグのないコード (bug-free code) を作るために自らを push します。 劣った developer は修正すべきバグを QA にまかせっきりにします。 Good developer develops features which create value for customers. Bad developer completes tasks. Good developer will never claim the requirements are incomplete, and will make sure to fully understand the features he's working on. Bad developer will wait until the finest details are available. To emphasize: good developer is the CEO of the feature – he's going to make sure he always has the information needed to accomplish the feature, and in case information is missing he'll make sure he gets it. 優れた developer は顧客にとって価値のあるものを作り出す機能を develop します。 劣った developer は task を完了します。 優れた developer は requrements が不完全であるとは決して主張しないでしょうし 自分が作業している機能を完全に理解しようとするでしょう。 劣った developer は finest details が available になるまで待ち続けるでしょう。 To emphasize: 優れた developer は機能の CEO です。 つまり、機能を accomplish させるために必要となる情報を常に保持しようとし、 情報が欠けている場合にはそれを得るようにするでしょう。 Good developer is not afraid to go into anyone's code. Bad developer is afraid of others looking into his. Good developer understands that it shouldn't take more time to write self-explanatory and well-documented code. Bad developer always needs to allocate extra time to document and simplify. 優れた developer は誰のコードであってもそれを読むことを躊躇しません。 劣った developer は他人が自分のコードを見ることを恐れませす。 優れた developer は self-explanatry なコードや well-documented なコードを書くために 余計な時間をかけるべきでないことを理解しています。 劣った developer は document や simplify のための extra time を常に必要としています。 Good developer will never feel his code is good enough, and will always continue to clean and fix. Good developer always strives to create elegant solutions but understands that his job is to deliver value to customers. Bad developer thinks only about the elegance of his code and leave the job of delivering value to others. 優れた developer は自分のコードが good enough であるとは決して考えず、 常に clean and fix を続けようとします。 また、elegant な solution を作りあげることを常に追い求めていますが 自分の job が顧客に対する deliver value であることを理解しています。 劣った developer は自分のコードの elegance だけを考え、 他人に対する job of delivering value を放置します。 Is that all? Did I miss anything or got some of these wrong? Feel free to chime in the comments below! Guy Nirpaz Co-Founder & CEO, Totango
This is a series of short Lisp tutorials I recently wrote to help my teenage daughter learn Lisp.
余談ですが、昭和の特撮の歌詞は「倒れたら立ち上がり前よりも強くなれ」、「戦うのさお前の弱さと」、「立ち止まるな弱音をはくな」で、 平成の場合は「負けたってまた次があるさ、涙は俺が拭いてやるだからもう一人じゃない」なので、なるほど今の日本の子供も弱く、自分で何もしなくなる訳です。
人工知能のような複雑なプログラムを作るためにLispを使う理由として少なくとも以下の8つがある、らしい。
Smalltalkの素晴らしさは、そのダイナミズムにあります。できるかぎりあらゆる事が動的に決まります。 アラン・ケイ博士がいうところの「あらゆる事の、極限までの遅延」です。
今日は、私が仕事で書いたOCamlのコードを晒して、如何にOCamlがプログラマの仕事の道具として優れているかを主張したい。泥臭く、関数的でない、エレガントさのかけらもない、生活臭のあるコードだ。
Why R is Hard to Learn | (R news & tutorials) Why R is Hard to Learn June 13, 2012 By r4stats (This article was first published on r4stats.com » R, and kindly contributed to R-bloggers) The open source R software for analytics has a reputation for being hard to learn. It certainly can be, especially for people who are already familiar with similar packages such as SAS, SPSS or Stata. Training and documentation that leverages their existing knowledge and points out where their previous knowledge is likely to mislead them can save much of frustration. This is the approach used in my books, R for SAS and SPSS Users and R for Stata Users as well as the workshops that are based on them. My next Internet-based workshop starts June 26. Here is a list of complaints about R that I commonly hear from people learning it. In the comments section below, I'd like to hear about things that drive you crazy about R. Misleading Function or Parameter Names (data=, sort, if) 誤解を招く関数名やパラメーターの名前 The most difficult time people have learning R is when functions don't do the “obvious” thing. For example when sorting data, SAS, SPSS and Stata users all use commands appropriately named “sort.” Turning to R they look for such a command and, sure enough, there's one named exactly that. However, it does not sort data sets! Instead it sorts individual variables, which is often a very dangerous thing to do. In R, the “order” function sorts data sets and it does so in a somewhat convoluted way. However there are add-on packages that have sorting functions that work just as SAS/SPSS/Stata users would expect. R を学んでいるときに遭遇する most difficult time は関数が“obvious”(明白) なことをしないときです。 たとえばデータをソートするときに、SAS や SPSS、Stata のユーザーであればみな適切な名前がつけられた “sort”というコマンドを使います。 Turning to R they look for such a command and, sure enough, there's one named exactly that. しかし R の sort 関数はデータセットのソートをしないのです! R では sort は個々の変数をソートし、これはしばしば非常に危険な動作です。 R では “order”関数がデータセットのソートを行い、 it does so in a somewhat convoluted way. ただし、SAS/SPSS/Stata ユーザーが期待する通りの動作をするソート関数を持った アドオンパッケージがあります Perhaps the biggest shock comes when the new R user discovers that sorting is often not even needed by R. When other packages require sorting before they can do three common tasks: 最大のショックはおそらく、新規の R ユーザーが R ではソートがほとんど必要とならないことに 気づいたときに来るでしょう。 他のパッケージでは実行前のソートが必須である三つの common task がありますが Summarizing / aggregating data Repeating an analysis for each group (“by” or “split file” processing) Merging files by key variables R does not need to sort files before any of these tasks! So while sorting is a very helpful thing to be able to do for other reasons, R does not require it for these common situations. R ではこれらのタスクをするときに事前にファイルをソートしておく必要がないのです! So while sorting is a very helpful thing to be able to do for other reasons, R does not require it for these common situations. (略) Loop-a-phobia ループ恐怖症 R has loops to control program flow, but people (especially beginners) are told to avoid them. Since loops are so critical to applying the same function to multiple variables, this seems strange. R instead uses the “apply” family of functions. You tell R to apply the function to either rows or columns. It's a mental adjustment to make, but the result is the same. R にはプログラムのフローを制御するためのループがありますが ユーザー (特に初心者) はそれを使わないように教えられます。 変数群の乗算に同じ関数を適用するのにはループはとても critical なので このことは奇妙に思われます。 R では代わりに “apply”ファミリーの関数群を使います。 You tell R to apply the function to either rows or columns. It's a mental adjustment to make, but the result is the same. (略) Too Much Complexity 複雑すぎる People complain that R has too much complexity overall compared to other software. This comes from the fact that you can start learning software like SAS and SPSS with relatively few commands: the basic ones to read and analyze data. However when you start to become more productive you then have to learn whole new languages! To help reduce repitition in your programs you'll need to learn the macro language. To use the output from one procedure in another, you'll need to learn an output management system like SAS ODS or SPSS OMS. To add new capabilities you need to learn a matrix language like SAS IML, SPSS Matrix or Stata Mata. Each of these languages has its own commands and rules. There are also steps for tranferring data or parameters from one language to another. R has no need for that added complexity because it integrates all these capabilities into R itself. So it's true that beginners have to see more complexity in R. Howevever, as they learn more about R, they begin to realize that there is actually less complexity and more power in R! Lack of Graphical User Interface (GUI) GUI の欠如 Like most other packages R's full power is only accessible through programming. However unlike the others, it does not offer a standard GUI to help non-programmers do analyses. The two which are most like SAS, SPSS and Stata are R Commander and Deducer. While they offer enough analytic methods to make it through an undergraduate degree in statistics, they lack control when compared to a powerful GUI such as those used by SPSS or JMP. Worse, beginners must initially see a programming environment and then figure out how to find, install, and activate either GUI. Given that GUIs are aimed at people with fewer computer skills, this is a problem. Conclusion 結論 Most of the issues described above are misunderstandings caused by expecting R to work like other software that the person already knows. What examples like this have you come across? 上記の問題の大半は、すでに他のソフトウェアを知っている人がそれと同じように R が動くだろうと 期待してしまっている誤解に起因しています。 What examples like this have you come across? Acknowledgements Thanks to Patrick Burns and Tal Galili for their suggestions that improved this post.
某板戦艦スレッドより。
新・戦艦スレッド 11といったら独のアレしかないよね 820 名無し三等兵 [sage] 2012/06/11(月) 22:57:34.51 ID:??? Be: 中途半端な戦艦は、高度に組織化された巡洋艦隊にすら負ける事が証明された 830 名無し三等兵 [sage] 2012/06/12(火) 14:56:05.37 ID:??? Be: >>820を見て 『高度に発達した巡洋戦艦は、戦艦と見分けが付かない。』 という言葉を思いついた。 831 名無し三等兵 [sage] 2012/06/12(火) 18:58:29.88 ID:??? Be: 「充分に発達した科学技術は、魔法と見分けが付かない」 SF作家A.C.クラークの第三法則w 832 名無し三等兵 [sage] 2012/06/12(火) 19:59:25.33 ID:??? Be: 「充分に発達したフリゲートは、駆逐艦と見分けが付かない」 「充分に発達した駆逐艦は、巡洋艦と見分けが付かない」 色々と応用が利きそう。 833 名無し三等兵 [sage] 2012/06/12(火) 20:16:00.27 ID:??? Be: >>830 日本では天城型の事だな。 834 名無し三等兵 [sage] 2012/06/12(火) 20:19:18.17 ID:??? Be: アメリカではアイオワ 835 名無し三等兵 [sage] 2012/06/12(火) 20:56:43.62 ID:??? Be: 「充分に発達したシアーは、スキージャンプと見分けが付かない」 by伊太利海軍 836 名無し三等兵 [sage] 2012/06/13(水) 11:11:05.00 ID:??? Be: >>833 天城型は巡洋戦艦じゃなく平賀譲に言わせれば「実質高速戦艦型」だからな。 当時の日本では確実にカタログ性能を発揮出来る艦だったし。 838 名無し三等兵 [sage] 2012/06/13(水) 23:20:02.97 ID:??? Be: >>830 ソレダ! 究極の巡洋戦艦と言われる天城型は高速戦艦と区別できないし、 アイオワ型に至っては「巡洋戦艦何それ!?」状態。
大学時代に本読みまくったなー。 専攻とかにはまるで関係なくて純粋に興味があって。 第3回 認知科学と人工知能 フレームモデル
Gauche > Archives > 2012/06/15 2012/06/15 11:40:10 UTC yamasushi 1988年に出版された人工知能の入門書を読んでいるのですが、知識表現として紹介されている 「手続き的意味ネットワーク(procedual semantic network)」「フレーム(frame)」の項を読むと まるでオブジェクト指向の話です。この本では「オブジェクト主導」と翻訳しています。Lispの オブジェクト機能はこの知識表現のために作れたのかなと思いました。2012/06/15 12:06:38 UTC shiro 「Lispのオブジェクト機能」って言ってもいろんなのがあるので (CLOSはそれまであった色々な オブジェクト指向機能をまとめたみたいな感じ) そのうちのいくつかがAI研究起源である可能性は十分にありますが、同時期に盛り上がってた色々な 研究との関連もあると思いますよ。
例の MySQL のバグについて寄せられた意見(の一部)。
Security flaw in MySQL, MariaDB allows access with any password--just keep submitting it : programming If this were in a movie, you wouldn't believe it. "We need to hack the database!" "Enter a random password" "Did not work" "Try it again, a thousand times" "We have access!" "Now launch the nuclear missiles..."Like Will Ferrell in Austin Powers.Why were they assuming the return value would fit in a signed char when memcmp is defined to return an int?On most systems, memcmp returns 0 or 1, so it is not that strange to assume it would fit in a char.If it's just returning 0 or 1, it's not adhering to the standard. The sign of a non-zero return value shall be determined by the sign of the difference between the values of the first pair of bytes (both interpreted as type unsigned char) that differ in the objects being compared. The standard only specifies the sign. The return value is allowed to be any it. You'd think people would be more careful about undefined behavior when it's security critical.Things like these the probably the best reason to use a programming language with stronger type checks than C, in my opinion.Stronger checks would be nice, but in the meantime for those of us stuck with c, there are a lot of static analysis tools out there for c. When I saw the code, it reminded me how glad I was our buildbox would yell at me for this kind of cast.Stronger than C is good, but going as far as C++ did is annoying. You shouldn't need a typecast for malloc and free.You don't, because you don't ever use malloc and free directly in C++. Use new and delete.Unless you need to interact with C stuff. I'm not sure what would happen if you tried to do "new" for a C struct.It is good software design to never allocate a pointer that you aren't also going to free, and to not free a pointer that you haven't allocated — it is highly unlikely to encounter a library that requires you to allocate memory for it in an unspecified way, which is then freed by the library, because such a library would be designed to ask for memory leaks. Allocating a C struct with new in C++ works as expected — the only thing that can go wrong is if you call free on a new'ed pointer, or if you call delete on a malloc'ed pointer.I'm not sure what would happen if you tried to do "new" for a C struct. Umm... nothing extraordinary? Memory would get allocated and you would get a pointer back. (new doesn't return NULL by default; it throws bad_alloc instead)Hah, they got screwed by multiple intertwined things: The password checking function returns my_bool パスワード検査関数が my_boolを返している (first fail: introducing a bool type that's not understood by the compiler) 第一の失敗: コンパイラーの理解できない bool 型を持ち込んだ my_bool should have been typedef'd to int my_bool は int に typedef されたものであるべき (second fail: there's no difference between using char and int; unless you have an array, the compiler will allocate at least sizeof(int) for alignment anyway) 第二の失敗: 配列にしない限りはコンパイラーはアラインメント調整のために少なくとも sizeof(int) の割り当てを行うので char を使うことと int を使うことには差がない returns zero on success 成功時にゼロを返している (third fail; declaring function to return "my_bool" and returning ZERO/FALSE on success) 第三の失敗: 関数が "my_bool" を返すように宣言していて、成功時にZERO/FALSEを返している no explicit checking (the should have explicitly compared memcmp with zero) explicit なチェックをしていない
オースチンパワーズが出てくるとはw
たとえば、まつもとゆきひろさんを使い捨てにする会社とかあるんでしょうか?
泳ぐやる夫シアター 歴史系(世界史) やる夫で学ぶ第一次世界大戦 更新が来ないなあ
IIJ Security Diary: CVE-2012-2122 MySQLにおける認証迂回の脆弱性について MySQL Bugs: #64884: logins with incorrect password are allowed melancholic afternoon MySQLのバグ - てきとうなメモ
ようやく把握。IIJのリンク先に詳しく書かれてるけど
IIJ Security Diary: CVE-2012-2122 MySQLにおける認証迂回の脆弱性について == sql/password.c my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { ... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
このコードで、my_bool (の実体) が char なんだけど 実行環境によっては memcmp の戻り値が char で表現できる範囲を外れることがあり (intとしては0ではないけれども)下位8ビットが0な値が戻り値だったりすると… ということだと。わかってしまえばどうってことないけれども なんともはや。
突如として言語を越えたショートコーディングが
【Perl,PHP】LL バトルロワイヤル 22【JavaScript,Python】 743 デフォルトの名無しさん [] 2012/06/11(月) 17:02:39.02 ID: Be: ■Python print map(lambda x: x*2, filter(lambda x: x>2 and x<5, [1,2,3,4,5])) ■Ruby puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2} ■C# new{}{ 1,2,3,4,5 }.Where(x => 2 < x && x < 5).Select(x => x*2); ■Haskell print [x*2| x <-[1,2,3,4,5], x > 2, x < 5] 745 デフォルトの名無しさん [sage] 2012/06/11(月) 17:09:50.74 ID: Be: [n * 2 for n in [1,2,3,4,5] if 2 < n < 5] Pythonの優勝だよ!やったね! 753 uy [sage] 2012/06/12(火) 04:42:42.87 ID: Be: >>743 n=(1..5).select do |i| (3..4) === i end.each_with_object(2).map &:* p n 754 uy [sage] 2012/06/12(火) 05:21:22.37 ID: Be: >>743 p (1..5).select { |i| (3..4) === i }.map(&2.method(:*)) 756 uy [sage] 2012/06/12(火) 07:27:25.99 ID: Be: >>743 p ([*1..5]&[*3..4]).map &2.method(:*) またRubyが勝ってしまったか 757 デフォルトの名無しさん [sage] 2012/06/12(火) 07:37:26.03 ID: Be: Haskellのほうが短いけど? print[x*2|x<-[1..5],x>2,x<5] 758 デフォルトの名無しさん [sage] 2012/06/12(火) 07:40:51.67 ID: Be: どっちも読みにくい 759 デフォルトの名無しさん [sage] 2012/06/12(火) 07:46:09.38 ID: Be: Haskellはちゃんとスペース入れたら一番読み易い 760 デフォルトの名無しさん [sage] 2012/06/12(火) 07:50:49.79 ID: Be: >>743ではC#だけ飛び抜けて汚い ていうかC#だけ出力してないじゃん 763 uy [sage] 2012/06/12(火) 08:55:53.69 ID: Be: p (1..5).map{|i|i*2}[2,2] 本気をだしたrubyに勝てるとか勘違いされても困るというか 768 デフォルトの名無しさん [sage] 2012/06/12(火) 17:18:43.77 ID: Be: 範囲(1..5)と条件2<x<5が密結合したセンスのないコードだな (0..5)に変えただけで条件部のコードも変更する必要がある 769 デフォルトの名無しさん [sage] 2012/06/12(火) 17:22:39.16 ID: Be: >>743 Haskellの一人勝ち。 770 デフォルトの名無しさん [sage] 2012/06/12(火) 17:34:54.50 ID: Be: え?コードのキモさを競ってるんじゃないの? 今のところRubyの圧勝だろキモさでは。 775 デフォルトの名無しさん [sage] 2012/06/12(火) 23:57:27.61 ID: Be: J +:(((>&2)*.(<&5)) a) # a=:1+i.5 リファレンス見ながら、書いてみた もっと短く出来るのかも知れないけど、俺には無理だ。 778 デフォルトの名無しさん [sage] 2012/06/13(水) 01:22:27.24 ID: Be: Common Lisp (print (loop for x in '(1 2 3 4 5) if (< 2 x 5) collect (* x 2))) R print((function(){x<-c(1,2,3,4,5);x[2<x&x<5]*2})()) 779 デフォルトの名無しさん [sage] 2012/06/13(水) 02:08:42.95 ID: Be: Clojure (print (for [x [1,2,3,4,5] :when (< 2 x 5)] (* x 2))) 781 デフォルトの名無しさん [sage] 2012/06/13(水) 02:49:48.69 ID: Be: >>775 +:(5&>#])(2&<#])(1+i.5) 782 デフォルトの名無しさん [sage] 2012/06/13(水) 02:59:34.85 ID: Be: Squeak Smalltalk (1 to: 5) select: [:x | x between: 3 and: 4] thenCollect: [:x | x * 2] 783 デフォルトの名無しさん [sage] 2012/06/13(水) 03:00:57.69 ID: Be: C#のコードを無名クラスを 使って書きなおしたぐらいじゃないのか? new{}{ 1,2,3,4,5 }.Where( new Filter<Int>(){public bool apply(Int x) {return 2 < x && x < 5;}} ).Select( new Function<Int>(){public Int apply(Int x) {return x*2;}} ); まあこんなメソッドはないけれど概ねあってると思う 784 デフォルトの名無しさん [sage] 2012/06/13(水) 03:01:12.00 ID: Be: for( const char *s="12345"; *s; ++s ) if( '2'<*s&&*s<'5' ) printf( "%d", (*s-'0')*2 ); Cでもこの程度だしな。 785 デフォルトの名無しさん [sage] 2012/06/13(水) 03:06:28.36 ID: Be: ちなみにJava8だとこうかけるっぽい。 new{}{ 1,2,3,4,5 }.Where(x -> 2 < x && x < 5).Select( x-> x*2); 795 デフォルトの名無しさん [sage] 2012/06/13(水) 12:23:01.77 ID: Be: PowerShell 1..5 -lt 5 -gt 2 | % { $_ * 2 } 800 デフォルトの名無しさん [sage] 2012/06/13(水) 13:59:03.32 ID: Be: ?- assert(mul(X,Y,Z):-Z is X*Y), sublist(between(3,4),[1,2,3,4,5],Xs),maplist(mul(2),Xs,Ys).
C to Go - Preface Preface Go was born out of frustration with existing languages and environments for systems programming. Thus spake the Go FAQ. I empathize. I dislike C++ and Java so much that I've stayed with C. More precisely, I've stayed with GNU C, because of lexical closures and a few other extensions. Could Go replace C? Does Go truly combine efficient compilation, efficient execution, and ease of use? The best way to judge was to try real systems programming with Go. A good place to start is the list of GNU Core Utilities. Here are my experiences with implementing some of the simpler utilities.
内容はこれからかな?
教えてくれた方の話によると、近似ではなく、延々求めていくと延々近くなるそうです。 開平法ぐらいしか知らないのですが、習ったことがある!という方が居たら教えて下さい :-)
この調査の為のコードもGitHubで公開されていますので、フォークして日本語のメッセージで分析したり別の観点のレポートを作ってみるのも面白いかもしれません。
最後に「Ruby2.0は来年(2013年)2月に出ます。100%コンパチ(互換)です」と締めくくった。
Learn C The Hard Way by Zed Shaw
Learn C The Hard Way by Zed Shaw by Zed Shaw This will be the companion course to my new book, "Learn C The Hard Way" whch I'm working on right now. As I complete enough exercises in the book I'll be creating videos and putting them in this course. If you sign up for the course you'll also get a free PDF/ePub when the book is released. "Learn C The Hard Way" (available online at http://c.learncodethehardway.org) will introduce the C programming language to beginning/intermediate programmers who know one other language. It will teach modern well written C code as well as debugging techniques, safe coding practices, and general software engineering principles typically not covered in other books. The book culminates in a simple client/server Bulletin Board System (BBS) that you create.
Learn C The Hard Way by Zed Shaw | Hacker News zedshaw Just a warning to everyone, like the book this course is in development as I write the book. It's covering a lot of the chapters, but I have to go back and clean up some videos and do the final ones. That's why the price is low for now.I watched the intro on udemy. Very cool. You talked about installing xcode. For newer osx versions, people may be able to install just the [command line tools for xcode][1], which is only about 170MB or so. It might save some people from waiting around for the full xcode. [1]: http://kennethreitz.com/xcode-gcc-and-homebrew.htmlzedshaw Yes, I have to update to point people there. Apparently also the latest xcode is missing a bunch of stuff people might need and requires separate downloads of those pieces. I forget what but it's still annoying.What's your method for making the ePub version of your books? I'm considering writing a custom program for my own stuff, but I'd love to be able to use something off the shelf.zedshaw I'm ditching ePub. It's a crap format that has a bewildering number of options and it seems every viewer wants to implement some different subset of them. From now on, it's PDF and HTML only.I'm excited - Learn Python the Hard Way completely jumpstarted me into what has become a large internal django site, and I refer back to it often. I really enjoy python, and I thank Zed for the straightforward aproach. So even though I love python I want to see if the same technique can introduce me again to C, a language I never felt comfortable with.zedshaw Try going through the HTML version, and drop comments when you hit problems. That'll help me make the book solid.zedshaw IDEs are bad for you. It's much better to simply use a real programmer's editor that you can craft into being what you need. In fact, I can usually take vim plus cscope, exuberant ctags, and ack and demolish any code base you throw at me. Similar with emacs and other power editors. IDEs are usually useful if you're stuck using them to build GUIs or use specialized build tools they require.zedshaw I am a very experienced C programmer, and I have full comments on any page. You find an error, drop a comment and I'll fix it immediately. Chances are though, you're someone who read the K&R chapter, then went through nitpicking minor semantics about things like "NULL is 0" and then consider all the code broken in the book. But, any errors you find, let me know and I'll fix them. Just don't call me an inexperienced C programmer.
なにがプログラミング言語の存亡を分けるのか « WIRED.jp 世界最強の「テクノ」ジャーナリズム
を読んでてなんか変だなと思ったら
※この翻訳は抄訳です
と注意書きが。
あらら。なんかもったいない気が
なにがプログラミング言語の存亡を分けるのか « WIRED.jp 世界最強の「テクノ」ジャーナリズム (略) ラブキン氏は問題の要因の1つとして、言語の開発者が必ずしも実用的な目的を持って言語を作 るわけではないことを挙げる。「学術研究の分野では、抱えている人がいないような問題に関し ても解決策を見つけようとする傾向がある」とラブキン氏は話す。「この分野では、利用法や必 要性を考えずに一般からかけ離れた言語の開発を決定することがしばしばある。そうしたプロジ ェクトのなかには、その言語についてのドキュメンテーションなど、もっとも基本的な事柄が欠 けているものもある。また、開発者が自分で作った言語に次々と新たな機能を追加することで、 利用しようとするエンジニアに負担をかけ過ぎることもある」(ラブキン氏) 「たぶん、この解決は全く困難なことというわけではないだろう」ともう一人の研究者であるレ オ・メイェロヴィッチは言う。「われわれは、他の人間が使うことをもっと意識した言語を作る 必要がある」(メイェロヴィッチ氏) また、二人が集めたデータによれば、プログラマーが新たな言語を使い始めたとき、実際にその 言語の学習に十分な時間をかけないことや、ほとんどのプログラマーが3つか4つの言語を学ぶと 満足してやめてしまうことも、問題の要因として指摘されている。
Why Do Some Programming Languages Live and Others Die? | Wired Enterprise | Wired.com (略) Part of the problem, he says, is that language designers don't always have practical objectives. “There's a tendency in academics of trying to solve a problem when no one actually ever had that problem,” said Rabkin, who recently received his computer science PhD at Berkeley and is now at Princeton working on a post-doc. He says that academics are so often determined to build a language that stands out from the crowd, without thinking about what's needed to actually make it useful. In some cases, he says, they fail with the simplest of things, like documentation for their language. In other cases, he says, designers will keep adding new features to a language and effectively overload the engineers who are trying to use it. “Maybe the solution isn't entirely technical,” Meyerovich says. “We need to start building more ‘socially aware' languages.” Yang Zhang, co-founder of analytics outfit Slice-Data and an MIT PhD dropout, is among that many who have jumped behind a new-age programming language called Scala, but he acknowledges that the language was originally hampered by poor documentation and support from the designers. “I was a much bigger masochist back then,” he says of fighting to learn the language in 2006. Meyerovich also says the data he and Rabkin are collecting also indicate that programmers aren't always taking the time to really learn a language when they start using it — and that this trips them up down the road. An example, he says, is ActionScript, an object-oriented language developed by Adobe. According to Meyerovich's data, programmers see ActionScript as easy to use. But, he says, when they start doing something new with it — moving from, say, media development to game development — they run into problems. Another issue is complacency. Most programmers learn three to four languages, the researchers say, but then stop. “Over time, you'd expect that as developers get older, they'd get more wisdom; they'd learn more languages,” Meyerovich says. “We've found that's not true. They plateau.” Part of the problem is that by the time they hit 35 to 40 years old, they're often moving from hands-on coding to managing other programmers. At that point, there's little motivation to learn and implement new languages. Meyerovich believes that the language is an issue that the development community as a whole is still struggling to acknowledge. As he and Rabkin plow through the data — much of which is sortable online — they hope to develop new insights into not only the causes over the problem, but also how to solve it. “This is a hot-button issue I didn't even think we'd be looking at when we went through this data,” Meyerovich says.
後半のニュアンスがだいぶ違うような?
前半の
“We need to start building more ‘socially aware' languages.”
「われわれは、他の人間が使うことをもっと意識した言語を作る必要がある」
はどうなんだろか。よくわからん。
先日もイタリアに行ってきたが、イタリアならではの考え方、ものづくりの方法があった。なにかを作るとき、日本ならではの考え方、作り方があるだろうから、それを大切にしてもらいたいと思っている。
contracts.ruby Contracts let you clearly – even beautifully – express how your code behaves, and free you from writing tons of boilerplate, defensive code.
中身を見ないで言うのはフェアではないと思うけど、 この種の「入門書」はもういいんじゃないかなあ スラスラわかるC言語 - 岡嶋裕史/翔泳社:SEShop.com
「女王陛下のLisp」が出る前に「チューリングを読む」を読みきりたいのだけどなかなかに歯ごたえが。
プログラミング言語を記述性と光/闇度で平面にプロットしてみた twitter.com/fumieval/statu…
— ふみ(実際Haskeller)さん (@fumieval) 6月 11, 2012
今回はみなさんにアナウンスがあります。
それにしても、メタプログラミングRubyですが、本屋でもう売ってないし、Amazonで見かけてもマーケットプレイスで超高くなってるし、アスキーさん、お願いだから増刷してください!!すごくいい本なんですよ!
なんか数日前にも C がどうたらいうのがなかったっけか
What's to love about C? « Musing Dragoman Musing Dragoman What's to love about C? 11 Monday Jun 2012 Antiquated, clunky, and unsafe. Though beloved to some, C is a language that many choose to hate. The mass opinion is indeed so negative it's hard to believe that anybody would program anything in C. Yet they do. In fact a lot of things, even new things, are programmed in C. The standard was recently updated and the tools continue to evolve. While many are quick to dismiss the language it is in no danger of disappearing. 時代遅れで、不細工で、危険な代物。 C は一部の人には愛用されているのだけれども、多くの人が嫌っている言語です。 大多数の意見はとてもネガティブなもので、誰かが何かのプログラムを C で書くなんてことは 信じがたいというものです。しかし実際には C でプログラムが書かれているのです。 新しいものでさえ、C でプログラムが書かれているというのが現実なのです。 C の標準は最近更新されましたし、ツールも進化し続けています。 While many are quick to dismiss the language it is in no danger of disappearing. So why do people still use C? What features does this language have that other languages don't? Too often newer languages are so intent on avoiding C's pitfalls they completely ignore all of its positive qualities. This ultimately leads to C's survival simply because there isn't much to replace it. Here I'll look at a several of the key reasons why C is still in use, and what features it offers for system programming. ではなぜ、未だに皆 C を使っているのでしょうか? C にあって他の言語にない機能とはなんでしょうか? あまりにも多くの新言語が C の落とし穴をなくそうとして、C の positive qualities をも 台無しにしてしまっています。 ここで、なぜC が今でも使われていているのかに関するいくつかの理由と システムプログラミング向けに C が提供している機能とを挙げていきます。 Access to the hardware ハードウェアに対するアクセス 略 Guaranteed simple flow 略 Clear and unambiguous 略 A macro preprocessor マクロプリプロセッサー 略 Conditional compilation 条件コンパイル 略 Libraries and API ライブラリとAPI C is still the standard for a shared library API. If a library needs to be used by multiple projects, in possibly multiple languages, then a C header file will be provided. The C function signatures are simple and easy to understand. Importantly they are easy to support in cross-language situations. The calling convention is standard and simple to implement.The boundaries the C API imposes are very strong and thus make it suitable for shared libraries. Only fundamental and POD types are possible, thus there is no concern about how memory is managed. There are no exceptions to handle. While extremely limited it is also extremely portable. C は今でも共有ライブラリ API の標準です。 あるライブラリが複数のプロジェクトで使う必要があり、 複数の言語で使う可能性があるのなら、C のヘッダーファイルが提供されることでしょう。 C の関数シグネチャーは単純かつ理解が容易です。 特に重要なのが、言語をまたがったシチュエーションをサポートするのが用意だということです。 C の呼び出し規約は標準であり、実装も単純です。 Small to tiny binaries 略 Speed スピード 略 Forever C? C is still widely used for systems programmings because there aren't many alternatives. While C++ retains a lot of these features, it is at times difficult to avoid the higher level functionality and provide guarantees about behaviour. Nonetheless C++ is usually a good choice if you need the features that C offers. Ada needs to also be mentioned here as it is used for critical systems programming. Though not standard, common Ada compilers offer a preprocessor and inline assembler. Integration with C is also quite straight forward. So perhaps this is also a suitable combination. 代替できるものが多くないがゆえに、C はシステムプログラミングに広く使われ続けています。 C++ は C の機能の多くを備えてはいるのですが、 it is at times difficult to avoid the higher level functionality and provide guarantees about behaviour. それでもなお、C++ はあなたが C の提供している機能を必要としている場合にはおおむね良い選択肢となります。 critical なシステムプログラミングに使われるものとして Ada にも触れておく必要があるでしょう。 標準ではありませんが、一般的な Adaコ ンパイラーにはプリプロセッサーとインラインアセンブラーがあります。 C との統合もとても stragight forward なものです。 So perhaps this is also a suitable combination. So while you may still not love C, as I do not, you can certainly bemoan the lack of these features in other programming languages. While perhaps often domain specific, I can't recall ever working on a project that couldn't have benefited from at least a couple of the above features. # bemoan ~を悲しむ、嘆く ですから、わたしと同じくあなたもまだ C を好きになれないかもしれませんが、 今挙げたような機能が他の言語にはないことを嘆き悲しむことはできるでしょう。
MySQL の脆弱性のアレ、情報がまだ少なくてよくわからんところが。
Zed がまた話題になるようなことを言ったようで。 動画なのでまだ自分では確認していないんですが(^^; Zed A. Shaw - The Web Will Die When OOP Dies on Vimeo
Zed A. Shaw - The Web Will Die When OOP Dies : programming The presentation has some good points especially regarding HTML, CSS and JS. It's an absolutely bad platform for making applications. The anecdote about how it is possible to create a 3D character that is shooting inside the browser but it's not possible to center a div is spot on. We can't do any components, we don't have any sort of a reliable grid system. There's no proper means for reusability, no modules for code organization. We are tied to a single programming language that has stupid semantics which are unlikely to ever be eliminated to keep everything backwards compatible. There's no denial that HTML has outgrown itself. It was designed with just documents in mind. Currently they are shoving additional features on top of it to bridge some of the gaps between desktop and mobile platforms. It is sort of necessary, because people want better, more modern applications and the web has to keep up to have any appeal. We, the developers have to suffer through it though - the inconsistencies, the glacial slow improvements and all the difficulties that come with using a platform that wasn't meant for what people demand now and will in the future. I find it sad that companies are wasting time and money and developing operating systems such as Boot2Gecko or Tizen that are based on HTML. It doesn't benefit anyone. Instead they should be using it as a playground for research, trying something new that has no ties to HTML. (Since they are very unlikely to get any marketshare anyway...)He is not saying OOP is broken because the web is broken. He is stating OOP is broken which, quite frankly, at this point should be pretty self-evident. Over the last few years OOPs has been falling apart, particularly once testing was introduced inheritance is pretty much dead in the water and it is pretty hard to argue that it ever delivered on its promise of easy code reuse.This is a very common misconception – object-oriented programming is not now and never was about inheritance. While it was always present this idea that inheritance is somehow central came about much later. As Alan Kay (the father of object-oriented programming) once puts it: OOP to me means only messaging, local retention, and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. Notice that this description doesn't even mention classes or inheritance. This should give you an indication of how unimportant these things are in the grand scale of things. Unfortunately the mainstream object-oriented languages we have today completely missed the point and decided to eliminated message-passing (choosing instead to try and derive polymorphism from inheritance and encapsulation from a supernatural compiler) and in so doing they all but forgot about late binding – which is the real secret to easy code reuse. So no, object-oriented programming is not broken. Our languages are. If you're interested this is a good read: http://www.cs.duke.edu/~jdougan/downloads/papers/Smalltalk-Getting-the-Message.html
Python で書いた方が短くすっきりできるだろうというのはまず納得できるところではあるんですが
VBAよ、さようなら!Excelで動くPythonプラグイン | 円と生活 365yen ExcelでVBAの代わりにPythonが利用できるようになります。 セルなどの操作は、 Cell(“A1″).value = “Hello, World!” や Cell(1,1).value = “Hello, World!” といったコードで行います。直感的でわかりやすいですね。 ビデオではPythonでコードを書くとVisual Basicと比較して、4分の1のコード量で済むデモが披露されています。
上記のサンプルコード片、VBAでどう書くのかというとこうです
Excel VBA 入門講座 セルの指定とプロパティセット セルの指定方法にはRangeプロパティを使用する方法とCellsプロパティを使用する方法とがあり ます。 RangeプロパティとCellsプロパティはいずれも指定したセル(Range オブジェクト)を返 します。 Rangeプロパティを使用する方法では、"A1"、"B2"などの形式で セルを指定し、 Cellsプロパティを使用する方法では、行番号と列番号によりセルを指定します。 以下の例では、Rangeプロパティを使用しValueプロパティに値をセットしています。 Range("A1").Value="EXCEL VBA" 以下の例では、Cellsプロパティを使用しValueプロパティに値をセットしています。 Cells(1,1).Value="EXCEL VBA" 上記の例では、いずれもアクティブなシートのセル"A1"に"EXCEL VBA"と いう文字列がセットされます。
Cell と Cells とか細かい違いはありますけど、この二つを比較して Python の方は「直感的」で、VBA はそうでないと主張するのはいささか無理があるんじゃないでしょうか。 たぶん、VBA では for ~ next なんかのループを使わざるを得ないロジックなんかを Python ではすっきり書けるだろうとは思いますけど。
補足しておくと、VBA のRange の方は複数のセルを一度に指定できます
Range("A1:C10") = "ほげ"
みたいな感じに。
これは A1~A10、B1~B10、C1~C10 のセル全部に「ほげ」を放り込みます。
とはいえこれではあまりに意味がないか(^^;
const volatile unsigned * const volatile foo;
一つ前へ
2012年1月(下旬)
一つ後へ
2012年2月(中旬)
リンクはご自由にどうぞ
メールの宛先はこちら